New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time-locked incentive for Bitcoin hardfork #72

Closed
oleganza opened this Issue Jul 14, 2017 · 10 comments

Comments

Projects
None yet
7 participants
@oleganza

oleganza commented Jul 14, 2017

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.

Specification

A hardfork implementation with name <label> (e.g. BIP101 or segwit2x) allows redeeming coins from the outputs with the following script:

RETURN "HF<label>" <script>

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:

  1. The script is well-formed: exactly 3 opcodes, first one is RETURN, second one is minimally encoded PUSHDATA that pushes exactly the "HF"-prefixed hard fork name. If multiple hardforks have happened previously, all of their canonical names are allowed. Last opcode is also PUSHDATA, minimally-encoded.
  2. The string encoded in the second PUSHDATA operation is interpreted as a raw script as if it was used in the output without being wrapped in RETURN "HF<name>" "...". Therefore, traditional P2PK, P2PKH, P2SH (BIP16), Segwit (BIP141) scripts and whatever other scripts that are supported before the hard forked block are all supported without modifications (BIP141 is mentioned assuming SegWit is activated in the chain prior to hard fork, but that is not a requirement for this proposal: if SegWit is not activated, then BIP141 validation rules are not applicable to the inner script).

Implementation

Reference code is TBD, but the general outline is:

  1. In case the transaction is validated after the hard fork is activated, the following special rule is applied:
  2. For each unspent output pulled from the UTXO state for verification, the script is statically analyzed to match the above pattern and the underlying script is extracted and placed in the copy of that output replacing the original RETURN-prefixed script.
  3. The inner script and the modified output are provided to the Bitcoin Script interpreter with usual falgs as if the output had that script all along in the original transaction.
  4. Transaction input and/or witness data must contain necessary data satisfying that inner script, per existing rules.

Forward compatibility

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).

TODO

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).

@hoffmabc

This comment has been minimized.

Show comment
Hide comment
@hoffmabc

hoffmabc Jul 14, 2017

Other than being ASCII are there any other constraints on the HF name in <label>?

hoffmabc commented Jul 14, 2017

Other than being ASCII are there any other constraints on the HF name in <label>?

@oleganza

This comment has been minimized.

Show comment
Hide comment
@oleganza

oleganza Jul 14, 2017

@hoffmabc good point, I'll mention "should pass standardness checks that exist prior to HF, to make participation as easy as possible"

oleganza commented Jul 14, 2017

@hoffmabc good point, I'll mention "should pass standardness checks that exist prior to HF, to make participation as easy as possible"

@christophebiocca

This comment has been minimized.

Show comment
Hide comment
@christophebiocca

christophebiocca Jul 14, 2017

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:

  1. Losing a likely non-zero proportion of the value (the value of the legacy coins).
  2. Locking coins up for a period of time (time-value of money).

You can fix some of these issues by (somehow) allowing the following construction:

OP_IF OP_TRUE_ON_HARD_FORK_SIDE_FALSE_OTHERWISE
    OP_CHECKSIGVERIFY KEY1
OP_ELSE
     OP_CHECKSIGVERIFY KEY2

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.

This construction:

  • Avoids the burning of funds.
  • Allows a form of on-chain fork futures trading.

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.

christophebiocca commented Jul 14, 2017

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:

  1. Losing a likely non-zero proportion of the value (the value of the legacy coins).
  2. Locking coins up for a period of time (time-value of money).

You can fix some of these issues by (somehow) allowing the following construction:

OP_IF OP_TRUE_ON_HARD_FORK_SIDE_FALSE_OTHERWISE
    OP_CHECKSIGVERIFY KEY1
OP_ELSE
     OP_CHECKSIGVERIFY KEY2

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.

This construction:

  • Avoids the burning of funds.
  • Allows a form of on-chain fork futures trading.

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.

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Jul 15, 2017

Quite an interesting proposal. The use as opt-in replay protection is very interesting as well (cc @chjj )

jgarzik commented Jul 15, 2017

Quite an interesting proposal. The use as opt-in replay protection is very interesting as well (cc @chjj )

@bithobbes

This comment has been minimized.

Show comment
Hide comment
@bithobbes

bithobbes Jul 16, 2017

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.

bithobbes commented Jul 16, 2017

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.

@oleganza

This comment has been minimized.

Show comment
Hide comment
@oleganza

oleganza Jul 17, 2017

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.

That's by design.

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).

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.

It still suffers from the risk that the hard fork doesn't happen at all.

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.

oleganza commented Jul 17, 2017

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.

That's by design.

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).

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.

It still suffers from the risk that the hard fork doesn't happen at all.

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.

@joshbabb

This comment has been minimized.

Show comment
Hide comment
@joshbabb

joshbabb Jul 18, 2017

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

joshbabb commented Jul 18, 2017

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

@christophebiocca

This comment has been minimized.

Show comment
Hide comment
@christophebiocca

christophebiocca Jul 19, 2017

That's by design.

The fact that supporting one branch with this mechanism makes the opposite branch more valuable for miners is by design? Why would anyone use this mechanism then?

christophebiocca commented Jul 19, 2017

That's by design.

The fact that supporting one branch with this mechanism makes the opposite branch more valuable for miners is by design? Why would anyone use this mechanism then?

@Sjors

This comment has been minimized.

Show comment
Hide comment
@Sjors

Sjors Jul 28, 2017

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:
1 - you don't lose the coins if the hard fork is renamed, or such trivial problem
2 - your commitment is conditional to that of others
3 - [edit] your commitment is conditional on the hard-fork happening

In addition I would consider:
4 - being the first to commit should not put you at a disadvantage if others don't follow
5 - there should be some gain if the outcome happens (in addition to off-chain world benefits participants expect even without committing coins)

A condition like this would satisfy (1), (2) and (3):
"if hard fork [x] has support of >51% of hash power for N blocks, my coins will be burnt on the original chain and only spendable on the HF chain"

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:
"if more than X BTC signs this transaction, my coins will be burnt on the original chain and only spendable on the HF chain" - which is the original proposal but with SIGHASH_SINGLE.

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)

Sjors commented Jul 28, 2017

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:
1 - you don't lose the coins if the hard fork is renamed, or such trivial problem
2 - your commitment is conditional to that of others
3 - [edit] your commitment is conditional on the hard-fork happening

In addition I would consider:
4 - being the first to commit should not put you at a disadvantage if others don't follow
5 - there should be some gain if the outcome happens (in addition to off-chain world benefits participants expect even without committing coins)

A condition like this would satisfy (1), (2) and (3):
"if hard fork [x] has support of >51% of hash power for N blocks, my coins will be burnt on the original chain and only spendable on the HF chain"

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:
"if more than X BTC signs this transaction, my coins will be burnt on the original chain and only spendable on the HF chain" - which is the original proposal but with SIGHASH_SINGLE.

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)

@jgarzik

This comment has been minimized.

Show comment
Hide comment
@jgarzik

jgarzik Aug 17, 2017

Overall interesting but agree with the consensus that it's not really for this hard fork.

jgarzik commented Aug 17, 2017

Overall interesting but agree with the consensus that it's not really for this hard fork.

@jgarzik jgarzik closed this Aug 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment