Economic majority voting

[TierNolan]

In the block size fork, the proposal is to have the miners vote.  However, the users of the system (merchants/exchanges/clients) are the ones who have control in the end.  They choice made by them is the one that has the support of the economic majority.

One way to measure that choice is to see which fork has the coin with the highest value.  If a fork is not very popular, then its coins on that fork will be less valuable.

Assuming that the XT fork activates, then the XT fork will have the support of 75% of the hashing power and the core fork will have at most 25%.  If the core fork still has reasonable hashing support, then it would continue, though with around 45 mins block time.

If any of the inputs into a transaction spend a coinbase output from one of the forks (or any of its descendents) that it can only be included on that fork.  This allows trading coins between the two forks.

Exchanges could add BTC-XT and BTC-core coins to allow trading between the two forks.  This would clearly show which fork had the support of the economic majority.  If the loser doesn't go to zero, then at least some people want to keep it going.

This trading cannot happen until the fork itself happens, so can't be used to tell in advance which side has the support of the economic majority.

This could be rectified with a soft fork.  It works similar to colored coins.  Outputs have information about who can spend them on each fork.  Each fork has an id based on the fork deadline.

Fork-id = 0 means the core chain
Fork-id = deadline means fork chain

The deadline is the unix timestamp of when the hard fork is going to happen.  Each fork would have to pick their own switch moment, but that isn't that big a restriction.  It is not likely we are going to have more "serious" hard fork proposals than one per second.

The soft fork allows the user to specify who owns the output in each of the potential forks.

A user can spend their money to the following output script.  This is a template match like P2SH.

Code:

OP_IF
    <fork_id1> <fork_id2> OP_DROP OP_DROP OP_HASH160 <hash script 1> OP_EQUAL
OP_ENDIF
OP_IF
     <fork_id3> OP_DROP OP_HASH160 <hash script 2> OP_EQUAL
OP_ENDIF

This spends the output to

In forks 1 and 2, the owner of script 1 owns the owner.  In fork 3, the owner of script 2 owns the output.

To spend an output, you include

Code:

<signature for script N> <script N> OP_1

The OP_IF activates and the script is checked like with P2SH.

You can spend multiple rows. 

To skip a row, you just include

Code:

OP_0

This causes the OP_IF to skip that row.

In the outputs, the sum of the inputs for a fork id must be greater or equal to the sum of the outputs for that fork id.

All signed inputs can be consolidated as desired (and committed to fees).  Unsigned inputs must have outputs equal inputs, since it isn't your money to commit to fees.  If two inputs pay to the same script hash, they can be consolidated.

Once the deadline has passed, it is possible to convert encumbered coins back into normal outputs. 

In the core chain, once median timestamp is greater than the dead line, once the fork id = 0 row matters and nobody else is allowed to spend the output.  On the fork chain, only the output that paid to the deadline is spendable.

This allows users of legacy BTC to convert x BTC into x BTC-Core and x BTC-XT in advance of the fork.  These can be traded on exchanges to determine the view of the economic majority.

If most users think large blocks will destroy Bitcoin, they can convert their BTC to BTC-Core.  On the other hand, if they feel that a block size increase is necessary, they can convert their BTC to BTC-XT.  Both sides would be putting their money where their mouth is. 

The most valuable coin isn't necessarily the winner.  If both sides maintain some value, then the fork will split the coin.  On the other hand, if one coin is trading at a few percent of the price of the other, then the economic majority would have given a clear verdict.

[1714134132]

1714134132

[1714134132]

1714134132

[1714134132]

1714134132

[1714134132]

1714134132

[belcher]

It's an excellent idea to allow traders to speculate on the btc-core/btc-xt pair before a hardfork actually happens.

The p2sh script stuff looks like a nice way of doing it, but as you said it would require a softfork which might be difficult to get merged into the codebase and would take months to complete anyway.

However there might be other ways of doing it than spot-market. For example trading futures or another derivative. I'm sure I saw something similar being done in the recent greek trouble, where traders could speculate on the price of the new greek drachma before it was actually circulated.

A simple way to do it (which would require counterparty risk) is that there is simply a central issuer of tokens. Those tokens can be redeemed for btc-xt bitcoins in the event of a hardfork. The issuer can fulfill obligations simply by owning coins from before the hardfork and proving their ownership with proof-of-reserves. These tokens can then be traded for btc-core to establish the market's view on economic majority.


By the way, this could be done in an OTC manner right now. Two people simply make a futures-contract type deal where they agree a btc-xt/btc-core price now to be settled if and when bitcoin hardforks.

[TierNolan]

A simple way to do it (which would require counterparty risk) is that there is simply a central issuer of tokens. Those tokens can be redeemed for btc-xt bitcoins in the event of a hardfork. The issue can fulfill obligations simply by owning coins from before the hardfork and proving their ownership with proof-of-reserves. These tokens can then be traded for btc-core to establish the market's view on economic majority.

That is probably easier.  The soft fork has the advantage that it helps in the future too and means that exchanges could support it easily.

Bitcoin-XT could unilaterally implement it using lock times.

This transaction means that money is locked until the end of January.  OP_FORKVERIFY fails the script unless on the XT fork.  The OP_1 means fork-id = 1.

Since core doesn't support this, they have an additional 2 weeks locktime.

Code:

OP_IF
    <timestamp of Feb 15th> OP_CHECKLOCKTIMEVERIFY OP_DROP <pub key hash> OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
    <timestamp of Feb 1st> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_1 OP_FORKVERIFY OP_DROP <pub key hash> OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
OP_ENDIF

OP_FORKVERIFY would fail unless at least one big block has occurred.  It could be based on the 75% vote too.

By the way, this could be done in an OTC manner right now. Two people simply make a futures-contract type deal where they agree a btc-xt/btc-core price now to be settled if and when bitcoin hardforks.

Yeah, it can be done off-chain pretty easily.  The problem is that it means the coins are locked until the end of January.

The suggestion I made means that you can still trade the (split) coins.  They could be recombined if you have coins on all forks.

[belcher]

Of course a soft fork with a new OP would be amazing, but we have to think practically. It would be nice to flesh out these contracts and start trading them today.

EDIT: I just realised from a practical point of view, it might be easy to convince Mike Hearn to add OP_FORKVERIFY to BitcoinXT, since the opcode only needs to exist on that fork. Someone still needs to write the code and tests and make it that all the BitcoinXT users upgrade their client.

I thought of yet another solution. Before the proposed hard fork, the buyer, seller and an arbitrator create a p2sh 2-of-3 multisig address. Coins are paid into this address which will be exist on both blockchains after the fork. The buyer and seller settle simply by moving the bitcoins out at whatever their agreed-upon rate is. The arbitrator is there in case things go wrong. There can also be an nLockTime signed transaction to implement a timeout in case the fork never happens and the seller and/or arbitrator disappear after a few years.

Downside:
The coins have to be locked up (although many people will probably be speculating with coins that just sit around in paper wallets anyway)
The contract might be quite hard to resell in the secondary market, which is incredibly important for price discovery.

Maybe the centralized-issuer idea can be combined with this multisig thing somehow.

[TierNolan]

I just realised from a practical point of view, it might be easy to convince Mike Hearn to add OP_FORKVERIFY to BitcoinXT, since the opcode only needs to exist on that fork.

Exactly.

Someone still needs to write the code and tests and make it that all the BitcoinXT users upgrade their client.

As long as miners use the latest version, then the soft fork is "locked in".

With a trusted third party, they could have an automatic system where they will sign any transaction that follows the split coin rules.  The server wouldn't even need to track the block chain.

[belcher]

There's no reason we cant try both at once. Perhaps post this on the bitcoin-xt subreddit or their mailing list?

I'll make a start with the OTC market.
I'd like to put up an offer for trading my future btc-xt for your future btc-core at a rate of 1:3 for the amount of 0.01btc. Meaning I think btc-core coins will be at least 3 times more valuable than btc-xt coins and I want to put my money where my mouth is.

We can use the 2-of-3 multisig method, with an agreed-upon arbitrator.

[SimpleIn]

There's no reason we cant try both at once. Perhaps post this on the bitcoin-xt subreddit or their mailing list?

I'll make a start with the OTC market.
I'd like to put up an offer for trading my future btc-xt for your future btc-core at a rate of 1:3 for the amount of 0.01btc. Meaning I think btc-core coins will be at least 3 times more valuable than btc-xt coins and I want to put my money where my mouth is.

We can use the 2-of-3 multisig method, with an agreed-upon arbitrator.

Interesting offer. There is something to think about!

[TierNolan]

I'd like to put up an offer for trading my future btc-xt for your future btc-core at a rate of 1:3 for the amount of 0.01btc. Meaning I think btc-core coins will be at least 3 times more valuable than btc-xt coins and I want to put my money where my mouth is.

For increased clarity, is this the offer?

Both people agree on arbitrator

You send 0.01BTC to the transaction
The other person sends 0.00334 BTC to the transaction

The output is locked by a 2 of 3 signature.

On 15th February 2016, if there is a clear winner, the arbitrator will send the money to you if no big blocks have been produced and the other person if they have been.

If the network has actually forked, each participant has to obtain a transaction output that is a descendant of a coinbase transaction from a block that is only on the fork that they picked.  A transaction is created with that output as an input (and also the 2 of 3 multisig).  That arbitrator signs that transaction.

[belcher]

I'd like to put up an offer for trading my future btc-xt for your future btc-core at a rate of 1:3 for the amount of 0.01btc. Meaning I think btc-core coins will be at least 3 times more valuable than btc-xt coins and I want to put my money where my mouth is.

For increased clarity, is this the offer?

Both people agree on arbitrator

You send 0.01BTC to the transaction
The other person sends 0.00334 BTC to the transaction

The output is locked by a 2 of 3 signature.

On 15th February 2016, if there is a clear winner, the arbitrator will send the money to you if no big blocks have been produced and the other person if they have been.

If the network has actually forked, each participant has to obtain a transaction output that is a descendant of a coinbase transaction from a block that is only on the fork that they picked.  A transaction is created with that output as an input (and also the 2 of 3 multisig).  That arbitrator signs that transaction.

I'll rewrite/extend it.

Both agree on an arbitrator. All three people put up a public key and use it to create a 2-of-3 p2sh multisig address.

I send 0.01btc to the address
The counterparty sends 0.03btc to the address.

If the hard fork never happens after some timeout, the coins are returned (using the arbitrator to tie-break if there's any problems)

If there's a hard fork, the 0.04 coins are now forked into 0.04btc-core and 0.04 btc-xt
The 0.04btc-core coins are sent to me, the 0.04btc-xt coins are sent to my counterparty.

I put in 0.01btc and ended with 0.04btc-core and 0.00btc-xt => My balance goes up by 0.03btc-core and down by 0.01btc-xt
Counterparty put in 0.03btc and ended with 0.00btc-core and 0.04btc-xt => His balance goes up by 0.01btc-xt and down by 0.03btc-core

The trade of my 0.03btc-xt for his 0.01btc-core is completed.


Two things left.
1. Figure out a suitable timeout date
2. Figure out how to sell these contracts on in the secondary market

[belcher]

A small caveat. (thanks to phantomcircuit on IRC)

When the 0.04btc-core coins are sent to me, the 0.04btc-xt coins are sent to my counterparty, the two networks are actually joined together so the transactions might get confirmed on the wrong block.

To remedy this, the transactions must be combined with a UTXO input that is valid on only the correct fork.

[TierNolan]

To remedy this, the transactions must be combined with a UTXO input that is valid on only the correct fork.

Yeah, that is why I said that two transactions must be descendants of a coinbase transaction from either side of the fork.  That guarantees that they cannot be spent on the other fork.

Even a zero value output would be enough.

If that coinbase is 2000 blocks deep, then it is very unlikely to be forked off.

[belcher]

Yep, a coinbase tx is one way.

You could also attempt to spend a UTXO in a different way on each chain. Perhaps using the /pushtx pages of certain mining pools (assuming they dont rebroadcast). For example push to eligius which would probably be mining on Bitcoin Core, and also push to Slush which is currently on Bitcoin XT.

[goatpig]

You could also attempt to spend a UTXO in a different way on each chain

XT double spend relaying could achieve this I believe. First broadcast a transaction, give it a minute to make sure it makes it into Core Miners' mempool. Then emit a double spend through XT (since I read it will relay the first double spend attempt per UTXO) with a much higher fee (maybe the original tx should be a 0 fee with decent coin-age). I expect XT miners will see the double spend (since that is relayed by XT) and act upon it (essentially an RBF), while Core miners will simply reject it without consideration. A few attempt at this should be enough to create UTXOs exclusive to each forks.

[belcher]

Yep goatpig thats a good way too.

Some other thoughts on this whole idea.

** Arbitrators. The best arbitrator is one who has a neutral view on whether core or xt are good. They're less likely to throw their toys out the pram and screw up the deal for everyone if their side doesn't win. That's also why its a good idea to settle very soon after the hardfork when it may not yet be clear how it will turn out.
Also they will have to earn a fee, naturally nobody should do this for free.

** Reselling. Actually not that hard. Involves sending the coins to another multisig address.
This is how:

My counterparty wants to resell the contract, he has found a buyer and agreed terms with them.
If the counterparty sells his contract for 0.02btc for example that implies the value of btc-xt coins have fallen by half against btc-core.

The buyer announces his public key which is used along with mine and the arbitrator's to create a new multisig address.

The coins (0.04btc in this example) are sent to the new address with the original counterparty and either the arbitrator or me signing.

I don't care if the counterparty resells, I'm still going to get my 0.04btc-core whatever happens.

(Bonus) The transfer to the new multisig address and the payment from the new counterparty to the original counterparty could be done within a single bitcoin on-chain transaction, coinjoin-style where different people sign the transaction only if they're happy. Removes the risk of one guy scamming halfway through by just taking the money.

The situation is symmetric, I could also resell.

The arbitrator could also be changed I guess... with the agreement of myself and my counterparty.

** Painting the tape. It's possible for someone to trade with themselves and publicly announce their trades in an effort to manipulate the price.
So if someone announces we have to check their reputation and other stuff so that they're clearly not a sybil.

[Delek]

This is very clever and should be developed. Maybe as a simple VoteCoin fork with POS?

[johoe]

I'd like to put up an offer for trading my future btc-xt for your future btc-core at a rate of 1:3 for the amount of 0.01btc. Meaning I think btc-core coins will be at least 3 times more valuable than btc-xt coins and I want to put my money where my mouth is.
[...]

I send 0.01btc to the address
The counterparty sends 0.03btc to the address.
[...] => My balance goes up by 0.03btc-core and down by 0.01btc-xt

The trade of my 0.03btc-xt for his 0.01btc-core is completed.

I hope the middle part is a typo and not some way to trick a 1:3 ratio into a 3:1 ratio
So to clarify:  You send 0.03 btc and I send 0.01 btc and in the end you receive 0.04 btc-core and I 0.04 btc-xt?

As you said, one can also double-spend a coin differently on each fork to generate an input that can be used to split the coins.  If it is buried under enough confirmations it is fine.  Double spending should be easy, because if core-chain has 1MB limit and only 25 % mining power, it will not be able to mine all transactions (if they occur with the current rate).

A few special cases may need clarification.  What if the 75 % majority is reached but then the fork never happens because before January everyone is urged to abandon bip101?  What if the chain doesn't split because nobody produces a big block until the timeout is reached?  What happens if almost every miner updates and the bitcoin-core chain grows only by three or four block in total before it stops, or if there is not even a single block?  What if one of the chains stops before the multisig can be paid back?  What if a different consensus than bip-101 is reached and that caused a fork?

My suggestion would be to only consider the fork to have happened if there are 20 blocks each on two disjoint chains, one of which contains a >1MB block and the other compatible to the current core.  In that case the bet counts and if the 0.04 btc can't be paid back on one chain because that chain stopped that is the problem of the loser.  As timeout date we could say April 1st 2016, 0:00 UTC and the 20th block on each chain has to occur before then (timestamp of the block).  It can be extended anytime (even after the deadline) if both parties agree; it can also be shortened, e.g., if both parties agree that it is impossible that there will be a fork at all.


@goatpig: It works but not for the reason you think.  XT will broadcast the double spend (to all parties including core nodes) but it will never implement RBF (see Mike Hearn's blog).  So probably the low fee transaction will go into the XT chain and the high fee transaction into the core chain.

[belcher]

Thanks for the reply. It's important to flesh all these things out.

I'd like to put up an offer for trading my future btc-xt for your future btc-core at a rate of 1:3 for the amount of 0.01btc. Meaning I think btc-core coins will be at least 3 times more valuable than btc-xt coins and I want to put my money where my mouth is.
[...]

I send 0.01btc to the address
The counterparty sends 0.03btc to the address.
[...] => My balance goes up by 0.03btc-core and down by 0.01btc-xt

The trade of my 0.03btc-xt for his 0.01btc-core is completed.

I hope the middle part is a typo and not some way to trick a 1:3 ratio into a 3:1 ratio
So to clarify:  You send 0.03 btc and I send 0.01 btc and in the end you receive 0.04 btc-core and I 0.04 btc-xt?

Yes thats correct, well spotted.
Probably the ratio way of writing things shouldnt be used. Instead we could write 3 xt/core (three xt coins per core coin) or 0.333 core/xt in line with how other currency pairs are written.

A few special cases may need clarification.  What if the 75 % majority is reached but then the fork never happens because before January everyone is urged to abandon bip101?  What if the chain doesn't split because nobody produces a big block until the timeout is reached?  What happens if almost every miner updates and the bitcoin-core chain grows only by three or four block in total before it stops, or if there is not even a single block?  What if one of the chains stops before the multisig can be paid back?  What if a different consensus than bip-101 is reached and that caused a fork?

My suggestion would be to only consider the fork to have happened if there are 20 blocks each on two disjoint chains, one of which contains a >1MB block and the other compatible to the current core.  In that case the bet counts and if the 0.04 btc can't be paid back on one chain because that chain stopped that is the problem of the loser.  As timeout date we could say April 1st 2016, 0:00 UTC and the 20th block on each chain has to occur before then (timestamp of the block).  It can be extended anytime (even after the deadline) if both parties agree; it can also be shortened, e.g., if both parties agree that it is impossible that there will be a fork at all.

Yes I think that's probably fair.
The 20 blocks (or another number, maybe 6, or even 100 which is the coinbase maturity time) is a good idea because it reduces the likelyhood that the core chain will catch up and overtake the XT chain that then dies. The XT might fork away again later and become much more longer lived.

What if the 75 % majority is reached but then the fork never happens because before January everyone is urged to abandon bip101? What if the chain doesn't split because nobody produces a big block until the timeout is reached?

If a hardfork never happens then it hasn't happened. For the actual definition we could go by the one from here https://en.bitcoin.it/wiki/Hardfork

A hardfork is a change to the bitcoin protocol that makes previously invalid blocks/transactions valid

Remember there's also a chance that lots of people are actually running NotBitcoinXT, so the 75% mining majority still doesn't guarantee anything.

What if a different consensus than bip-101 is reached and that caused a fork?

For me, these futures contracts are only for btc-xt coins. For a definition of those we could say anything that follows bip101. https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

[TierNolan]

My suggestion would be to only consider the fork to have happened if there are 20 blocks each on two disjoint chains, one of which contains a >1MB block and the other compatible to the current core.

It depends on what is being predicted really.  I think if Core wins without causing any split, then that is a win for the core side.

Ultimately, the defining characteristic is the larger block.

A fork counts as a "Core Fork" if it is valid according to the reference client rules and has a timestamp past 11th Feb 2016.

A fork counts as a "Big Block Fork" if it is valid according to the reference client rules other than having at least one block that fails the rules due to being to large.

If XT fails to get any traction, then the Core fork side wins.  If there is just one chain and XT and core agree, then that is a core win.

[johoe]

A fork counts as a "Core Fork" if it is valid according to the reference client rules and has a timestamp past 11th Feb 2016.

A fork counts as a "Big Block Fork" if it is valid according to the reference client rules other than having at least one block that fails the rules due to being to large.

If XT fails to get any traction, then the Core fork side wins.  If there is just one chain and XT and core agree, then that is a core win.

This shows how important it is to fix the definition.  With your definition I wouldn't agree to a bet, because IMHO a likely outcome is that the community finds a compromise before a fork happens (the hope never dies).  Also it may be that XT slowly gains traction and by your definition it would even lose if it reaches 75 % on Feb 1st, because it still needs to wait two weeks before producing the first > 1MB block.  Or if the miners keep the soft limit to 1MB for a month.  If the fork happens after Feb 11 but before the reward is transferred, is it enough to send the 0.4 btc-core in the Core fork?

I admit that with my proposal I even tie if XT tries to fork but fails because it has less than 50 % at that time.   But to even this out, it also results in a tie if the core people all agree on BIP-101.

The 20 blocks (or another number, maybe 6, or even 100 which is the coinbase maturity time) is a good idea because it reduces the likelyhood that the core chain will catch up and overtake the XT chain that then dies. The XT might fork away again later and become much more longer lived.

This opens the question what happens if there is a 20 block fork but core catches up and XT is still strong.  My suggestion would be to consider core as a winner but wait with the reward for the deadline in case XT forks again (in which case both parties receive their coins on their chain).

For me, these futures contracts are only for btc-xt coins. For a definition of those we could say anything that follows bip101. https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

okay how to define an xt fork?  Suggestion: One >1MB block starting a chain that contains at least 20 blocks with BIP101 version number in the first 40 blocks.  So if some >1MB proposal wins and there are less then 50 % xt users at that time it is considered a tie.

Note that "xt" also wins if core implements BIP-101 but too few people upgrade core so that a 20 block fork of not-upgraded core occurs.  So the bet is really on bip-101 not on xt.

[belcher]

The 20 blocks (or another number, maybe 6, or even 100 which is the coinbase maturity time) is a good idea because it reduces the likelyhood that the core chain will catch up and overtake the XT chain that then dies. The XT might fork away again later and become much more longer lived.

This opens the question what happens if there is a 20 block fork but core catches up and XT is still strong.  My suggestion would be to consider core as a winner but wait with the reward for the deadline in case XT forks again (in which case both parties receive their coins on their chain).

So that would mean contact is settled as a specific date, either one way if the fork has happened or another way if not. Instead of being settled if-and-when a hardfork happens.
I don't have an opinion yet on which way is better.

For me, these futures contracts are only for btc-xt coins. For a definition of those we could say anything that follows bip101. https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

okay how to define an xt fork?  Suggestion: One >1MB block starting a chain that contains at least 20 blocks with BIP101 version number in the first 40 blocks.  So if some >1MB proposal wins and there are less then 50 % xt users at that time it is considered a tie.

Note that "xt" also wins if core implements BIP-101 but too few people upgrade core so that a 20 block fork of not-upgraded core occurs.  So the bet is really on bip-101 not on xt.

I think I could accept that, if there does end up being another hard fork which isnt bip101 (maybe which has overwhelming consensus) then the contract is impossible to settle because the xt-fork doesnt exist (and the core fork maybe no longer works either if the entire consensus moves to this new one)

Yes, the contract depends on bip101 not necessarily BitcoinXT. After all there are version of the client which only implement the bigger block sizes and non of Mike Hearn's privacy tor blacklisting stuff.