What do you mean your crowdfunding isn't on-chain?!
— Joshua Henslee (@cryptoAcorns) May 20, 2020
With the launch of Dimely.io, RelayX was yet again the pioneer in allowing users to vote and contribute towards new features they would like to see implemented on the platform.
Users can choose how much they want to contribute to which feature. Once the feature is sufficiently funded, Dimely then implements it.
We raised 2.5 BSV for Screenshare on https://t.co/PKHxRkO9rd and now it's launched. Thank you!
— 1jack 🌱 (@liujackc) May 25, 2020
When funding a feature on Twetch, an OP_RETURN output is added to the Bitcoin transaction containing a custom Bitcom prefix, some value indicating which feature was funded, the satoshis contributed, a signature and more. This way, anyone can run their own query against the ledger to validate independently how much has been allocated towards a particular feature.
One could also check how much time has passed since the funding goal was met, establishing accountability of the platform to their contributors. Additionally, the coins contributed could even be tracked to ensure they are not being redistributed in case of fraud.
Another implication of setting goals for features is setting expectations with their customers about what direction the platform is moving, as well as what may or may not be on the table.
For example, both Twetch and Baemail have delivery of iOS and Android applications at rather high amounts, perhaps to indicate an unwillingness to implement them, or with the intention of informing the market their perceived cost of development.
As far as allowing submissions for feature requests, only Baemail has this enabled, where they then are curated by the platform.
This crowdfunding model does have some issues, mainly to do with refunds.
Sighash_ALL | ANYONE_CAN_PAY or it doesn't count
— Brandon Bryant (@brandonbryant02) May 20, 2020
HandCash developer Brandon Bryant pointed out that crowdfunding is enabled at the protocol level using the SIGHASH flags. The ANYONECANPAY flag allows the platform to set the goal by specifying its output amount in the Bitcoin transaction (ex. 5 BSV) then contributions (inputs) can be made such that the transaction is only spendable if all of the added inputs total up to the exact output amount.
This would eliminate the technical debt and potential manual labor that comes with managing refunds downstream in case a feature remains unfunded in perpetuity. Another accountability aspect is that the platform cannot spend any of the funds until the full goal is met.
Unfortunately, this has been possible for 11 years, yet no Bitcoin wallet currently supports this feature. BSV wallets have inherited and thus far persisted the tunnel-vision mindset from BTC and BCH that only P2PKH and SIGHASH_ALL transactions need to be supported.
As more innovative services are developed and new business models are explored, complex transaction types will be required. The various SIGHASH flags are an indication that Satoshi Nakamoto really thought through what types of functionality was necessary when designing the protocol. Hopefully, its potential can be realized now that we have a chain with that functionality re-enabled.
New to Bitcoin? Check out CoinGeek’s Bitcoin for Beginners section, the ultimate resource guide to learn more about Bitcoin—as originally envisioned by Satoshi Nakamoto—and blockchain.