This document proposes a novel way to improve coordination of users who wish to activate a new soft fork in Bitcoin. The main idea is to use smart contracts to incentivize users to actually enforce the soft fork with lower risk of support being too low. At the same time the contract is in effect only if significant part of economy agrees to it. The contract also signals the intent to miners and other users in a way that would be otherwise expensive for sybil attackers. This proposal also suggests an interesting way to pay developers for the development of the soft fork code.
I'd like to thank /u/baltakatei and Luke-Jr for the inspiration.
As is being observed while writing this proposal, there's a certain amount of confusion in Bitcoin community. Some people would like to activate SegWit using UASF. The problem with UASF is how to measure support. The fear is that if the support is too low, a chain split might occur. Also, it is difficult to say how strong the desire to enforce the new rules is.
It might also be that some people would like to enforce new rules but they fear lack of support and would like to minimize risk.
It'd be helpful to have a mechanism which would measure the support for particular soft fork or at least provide a useful hint. This proposal explains how such mechanism could be implemented.
A community of people who'd like a soft fork choose parameters and a (trustless but ideally competent) coordinator. The main purpose of the coordinator is to prepare a large transaction. The parameters are:
- activation threshold - an amount of Bitcoins, as opposed to percentage of blocks. This needs to be a huge value, e.g. one million of Bitcoins.
- enforcement deadline - the day (or block height) at which they start enforcing new rules if the activation threshold is reached
The participants start sending new outputs to the coordinator as if the new rules were activated. E.g., in the case of SegWit the script could allow the sender to spend the output using SegWit transaction. Such output is considered anyone-can-spend at given time but should be spendable only by the participant who created the output once the new rules activate. The coordinator waits until enough people provide the outputs.
When the sum of the outputs reaches activation threshold, the coordinator prepares a huge time locked unsigned transaction with provided outputs. Each output of this transaction is spendable only after the enforcement deadline, even under the current rules. The coordinator then provides the transaction to all participants who sign it with ANYONECANPAY flag. (This is probably not very important though.) Finally the transaction is broadcasted to the network.
Once the transaction confirms, the participants are in interesting situation: if they don't enforce the rules after enforcement deadline, they risk someone spending the coin after enforcement deadline. If enough people do this with high amount of coins, it gives off clear signal: the change is really desired. Since those people committed money to it, they are unlikely to drop the support. It'd also be very expensive for an attacker to do it as a Sybil attack - he'd risk many coins.
Of course, the participants must consider the risk of soft fork not succeeding anyway. There are two thing that should make it likely for them to accept the risk:
- They might find new features worth it
- There's no risk if support is too low - the transaction will simply never be made
It might be possible to use this method to pay the developers for their time implementing the soft fork. The developers might simply publish their addresses, so the final transaction would contain their outputs. That means if the soft fork activates, the developers get the money. If it doesn't, the money will be probably taken by miners. In order to prevent careless or malicious developers from promising the implementation but not actually implementing, the developers could be participants at the same time.
Note that this allows developers to earn money and so they'd be probably incentivized to become the coordinator(s) if none exists yet.
There's a risk of a developer slacking off and someone else implementing the soft fork instead. This can be mitigated by choosing a developer with good reputation. Another way is to use slightly different output and make the payout part of the consensus. If someone else develops the software instead, he can code his address into it. If the original developer fails to work in obvious way, the users may run the code which only allows the new developer to spend the money.
This might cause disruption in case it's not obvious whether the developer worked hard enough. The problem could be resolved by simple weighted vote by the participants. (Others shouldn't care much what is done with other people's money.) Alternatively, the output might be spent by transaction splitting it between developers as users choose.
In order to prevent attackers from infinitely spamming the coordinator and stalling the coordination a valid signature of the output might be required. The key should be associated with existing Bitcoin UTXO. If someone submits the output but is later uncooperative, he can be simply blacklisted and the operation might be retried. This way nobody can stall the coordination indefinitely.
This proposal demonstrates how coordination of UASFs might be improved. It mitigates risks associated with economic minority enforcing new rules, prevents Sybil attacks and provides a way to reward the developers for working on the code. There is still a risk of fork not being activated and the participants losing money but it could be accepted as reasonable by those who desire the feature very much.
Martin Habovštiak martin.habovstiak@gmail.com 4ABF 7B25 5514 2E94 C3EE 87F4 7ED4 E0F0 9914 082B
The author hereby declares that he won't use government violence against anyone who chooses to copy, modify or distribute this document. For legal purposes this is considered to be released under CC0 1.0 Universal license.
The author also kindly asks people to not attribute this document to somebody else and not to attribute modified document to the author.