Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Time-locked incentive for Bitcoin hardfork #72
It is well-known that cryptocurrency development can be incentivized by long-term time-locked coins. Meaning, that the coins cannot be spent in the peak of a bubble, or right before a disaster that was not prevented or worked around. For instance, Greg Maxwell claims that Blockstream uses such scheme (source).
Considering that any hard fork by definition carries an increased systemic risk: from producing chain splits inadvertantly (due to overlooked software incompatibility), to splitting the market and shattering the faith in the technology and perspectives of our social experiment, it makes sense to introduce a special kind of time-locked incentives that get unlocked only on a hard-forked chain. Such incentives allow community to measure amount of "skin in the game" to gauge the responsibility of the people behind a hard fork proposal.
A hardfork implementation with name
The first opcode is RETURN, followed with PUSHDATA opcode pushing ASCII-encoded name of the hard fork proposal prefixed with two bytes "HF", followed by the PUSHDATA opcode containing raw redeem script.
The script must pass standardness checks that existed prior to hard fork on the chain. E.g. in 2017 that's "up to 83 bytes of data from all PUSHDATA opcodes combined".
Existing chain does not allow redeeming such funds, therefore sending coins to such address permanently destroys them. The hard forked chain allows spending from such output, with the following conditions:
Reference code is TBD, but the general outline is:
This proposal is meant to be forward-looking and the code is expected to be modified to preserve the spirit of the proposal for the future hard forks.
Example 1: If in the future Bitcoin is extended with extension blocks, and then a hard fork occurs, the time-locked incentive must be supported in the extension blocks just as well as in the original blocks.
Example 2: If in the future Bitcoin supports additional types of scripts (in the ancestor chain of the hard fork), those must be equally supported when validating the inner script extracted from the RETURN-prefixed wrapper. Of course, if the scripts are activated on the parallel chain to the one where hard fork occurs, they do not apply to the post-HF validation (just like rules that exist in altcoins are not applicable).
For symmetry, we may also include another script, that's spendable sans HF, but non-spendable in the HF chain. So people against the HF can bet that it will not happen.
Additionally, there should be a time-lock to guarantee that the outcome is stabilized (e.g. in 1 year) to prevent quick cashing out before the market evaluates the results of the hard fork (or absence thereof).
Burning coins on the legacy branch that are redeemable on the hard-fork branch has the perverse effect of increasing the value of the legacy branch's remaining coins, relative to the hard-fork branch.
To take an extreme example, if 8 million coins got burned in this way, miner reward on the legacy branch would be 2x that of the hard fork branch.
It also stops people from selling coins on their least favored side, which is one of the ways we'd expect price discovery to happen.
Then there's the coordination problem, most people participating in the hardfork have no ability to ensure its viability (especially in advance of the fork, especially wrt hashpower).
So really this proposal just provides an opt-in way for miners to prove that they will be mining on the new branch (if only to redeem and sell them on an exchange) at the cost of:
You can fix some of these issues by (somehow) allowing the following construction:
This allows 2 parties to store money such that one party will be able to redeem it on the legacy branch, and another party on the hard-fork branch.
It can also be used for opt-in replay protection.
It still suffers from the risk that the hard fork doesn't happen at all.
While I also consider this an interesting idea, in this case it seems to cement an ongoing split, causing severe financial losses and bad blood.
I am trying hard to keep assuming good faith but given this complex proposal came on the day of the planned release it obviously will not make it into this project.
That's by design.
Correct, the point of this proposal is to allow people to coordinate with a better metric than loud words and funny hats. Those who organize mining cartels or financial intermediaries who put customers' funds at risk (payment processors and wallet services) should be able to either put their own money where their mouths are, or witness the lack of any measurable support of their activity.
That's by design; see "skin in the game" argument in the opening paragraphs. If there is no risk, there's no way to securely communicate seriousness. Anyone can support anything on words: there are too many twisted incentives for some people to screw other people.
ACK that this will allow signalling of intent and incentivization of a hard fork
I fear that this would be used to bribe miners somehow... Much better than those tx that spend all their outputs in fees but are exactly 1000000 bytes, but still in the same vein, I feel.
Overall I NACK because I'm sure some people will regret the burn, honestly, but allowing it does provide interesting opportunities for future bitcoin hard-forks
There is a difference between conditionally and unconditionally supporting a hard fork. The above proposal assumes unconditional support. Unconditional support certainly implies skin in the game, but the SegWit2x agreement is not unconditional.
I don't think there is an on-chain solution to prove skin in the game about the actual SegWit2x agreement, let alone one that can safely be implemented in three months. I could obviously be wrong.
Three conditions seem crucial to me:
In addition I would consider:
A condition like this would satisfy (1), (2) and (3):
The 51% part seems impossible to determine without checking both chains.
Difficulty could be used as a weak proxy, although it would lead to funds being released - or lost - on both chains under some conditions:
"if current chain is not the hard fork chain, and difficulty < X, burn the coins || if current chain is the hard fork chain, and difficulty < X, burn the coins"
This would require an opcode to get the difficulty, at minimum...
Real calendar time could be used as an even weaker proxy for difficulty.
A simpler condition could be:
That no longer satisfies (3) and X would likely need to be in the order of millions of BTC for anyone to consider it. That's likely more than the combined SegWit2x signatories have, let alone could spend without being sued by their shareholders.
None of these address (5).
An anyone-can-spend rather than proof-of-burn transaction could address the concern of creating scarcity on the chain you don't want, but that creates its own problems if miners have any stake in the outcome.
(sorry for the edit mess)