Economic majority voting

[TierNolan]

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

That's a core win, since the reference client will accept the chain.

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?

There needs to be a delay of the decision if the XT bit is supported by a majority of the hashing power.

A fork counts as a "Core Fork" if it is valid according to the reference client rules and less than half of the last 1000 blocks support larger blocks in their header but not before 11th Febuary 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 a decision hasn't been made by the 11th of April 2016, then the money is refunded.

Note: 
The reference client means the latest official release of Bitcoin Core and the release is supported by at least a majority of the core devs (as of now).

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.

I think the reference client is a reasonable trigger.  This means that if core decides to allow 2MB blocks, then the Big Block fork needs 3MB blocks.

[1715052937]

1715052937

[johoe]

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.

On second thought, I'm not sure if this case is really necessary.  If a 20 block fork of bip-101 finally failed, then bip-101 doesn't have much hope anyway.  Miners would probably abandon it, after they lost 500 BTC.

Okay, how about they are settled on the deadline (+ two hours to accommodate for inaccurate timestamps) using 20 block fork criterion: If a fork with a bip-101 chain with 20 (of 40) blocks and a core chain with 20 blocks occurred, the bet counts, otherwise, it is paid back.  But both parties can in mutual agreement change the deadline.  If a fork happens, it is in both their interests to settle immediately, because then they both get the coins immediately.  Of course, one party can delay by not agreeing to change the deadline, but I don't see any advantage for anyone doing this.

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.

Also there is no easy way to distinguish bip-101+Core from BitcoinXT when analyzing the mined blocks.  I think miners run customized full nodes and they probably would just include the bip-101 patch.

[johoe]

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

That's a core win, since the reference client will accept the chain.

Call me boring, but I want to count this as a tie.  Also any other case where bip-101 never reaches the 75 % miner majority.

I want to bet "if XT forks, it will be on the winning side" not "XT will fork and it will be on the winning side".   I think most people supporting bip-101 don't necessarily want to see it win; they would rather see a compromise solution that all can agree to.  XT is now more a signal and is only used as last resort if finding a compromise doesn't succeed.

I think the reference client is a reasonable trigger.  This means that if core decides to allow 2MB blocks, then the Big Block fork needs 3MB blocks.

So if the core developers give in and implement BIP-101, then this is an automatic win for core with these rules.

But I wouldn't even bet if you say "<=1mb" instead of "accepted by reference client".  A compromise that raises the block size half a year later should also count as a tie.  Of course, this is my personal view; if you want to bet with other terms, you are free to do this, provided the other party agrees to your terms.

[jonny1000]

This thread is interesting.  It seems the coinbase coins on both sides of the fork may be more valuable because they could be reliably used to split coins between the two chains.

Could this motivate a miner to produce the first block over 1MB?  The miner could wait 100 blocks and then distribute the coinbase coins out quickly for a large premium.  Knowing they can be the first to perform arbitrage on the two chains.

Also there are 7 classes of bitcoin, with potentially different prices:

1. Coins on both chains, which have not been split
2. XT coinbase coins, or coins merged with these
3. Core coinbase coins, or coins merged with these
4. Coins spent in a core block, but double spent to a different output in XT
5. Coins spent in an XT block, but double spent to a different core output.
6. Coins spent in a core block, but unconfirmed in XT
7. Coins spent in an XT block, but unconfirmed in core

This would be complete chaos

[belcher]

Instead of calling it "core" or "the reference client" it might be more accurate to saying "core version 0.11" or "the reference client from Aug 2015".
Because if Bitcoin Core is patched in the future to support bip101 just like xt, that is still a protocol hardfork.

So then if another potential proposal gains popularity (dunno, maybe bip102 ?) then separate new futures can be written for the coins from that hardfork.


Also, it may not be helpful to talk about winning, losing or tying a bet. Futures contracts are about trading and exchange. They are about exchanging the status quo btc-core coins for hardforked bip101 btc-xt coins. As this exchange is entered into freely, it's possible and probably that both parties will be happy and neither will see themselves as losing the bet.

Not everything using futures will be speculators interested in betting. For example there may be people who just want to hedge their exposure and who don't see it as a bet to be won or lost.

Remember why futures contracts gained popularity historically. The farmer wanted to agree a price of his grain in spring even though the grain wouldn't exist until harvest time in autumn. If the price of grain went up between those times the farmer might kick himself that he should've waited, but fact is he didn't want to take the risk. So both the farmer and speculator who enter into the contract have won.


@TierNolan where did you get the date of 11th April 2016? I know you have to pick some date and they're all kinda arbitrary but is there a reason you chose this one?

[belcher]

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.

On second thought, I'm not sure if this case is really necessary.  If a 20 block fork of bip-101 finally failed, then bip-101 doesn't have much hope anyway.  Miners would probably abandon it, after they lost 500 BTC.

Well now that I think of it some more, the single settlement date could simplify the whole thing, then you don't need to do all this counting blocks stuff.
I'll consider a bit more, can't really decide. I guess the two options are quite similar anyway.

Okay, how about they are settled on the deadline (+ two hours to accommodate for inaccurate timestamps) using 20 block fork criterion: If a fork with a bip-101 chain with 20 (of 40) blocks and a core chain with 20 blocks occurred, the bet counts, otherwise, it is paid back.  But both parties can in mutual agreement change the deadline.  If a fork happens, it is in both their interests to settle immediately, because then they both get the coins immediately.  Of course, one party can delay by not agreeing to change the deadline, but I don't see any advantage for anyone doing this.

Yeah sounds OK.

[TierNolan]

Instead of calling it "core" or "the reference client" it might be more accurate to saying "core version 0.11" or "the reference client from Aug 2015".
Because if Bitcoin Core is patched in the future to support bip101 just like xt, that is still a protocol hardfork.

If that is the rule, then a > 1MB counts as the trigger.

"Big block" pays out if the fork has a 1MB ancestor.
"Core" pays out if the fork has no 1MB ancestor and it is after 11th Feb 2016 and the Big block version bits don't have a majority.

@TierNolan where did you get the date of 11th April 2016? I know you have to pick some date and they're all kinda arbitrary but is there a reason you chose this one?

11th of January is the trigger for BIP 101 and that was 3 months later.

[belcher]

Instead of calling it "core" or "the reference client" it might be more accurate to saying "core version 0.11" or "the reference client from Aug 2015".
Because if Bitcoin Core is patched in the future to support bip101 just like xt, that is still a protocol hardfork.

If that is the rule, then a > 1MB counts as the trigger.

"Big block" pays out if the fork has a 1MB ancestor.
"Core" pays out if the fork has no 1MB ancestor and it is after 11th Feb 2016 and the Big block version bits don't have a majority.

A problem with the "Big block" payout is that there could be many different types of big block. If someone enters into a contract expecting to speculate on bitcoin-xt-coins but it turns out a totally different bip wins (for example BIP 102: Increase block size limit to 2MB, which is very different in spirit to bip101/xt)

This would be an uncertain outcome and bad for the market. Speculators must be able to know exactly what they're getting into when they enter a contract. It would be much better to simply write other contracts for the core/bip102 trade along with core/bip101.

Also the Big Block version bits criterion might be problematic because miners might be lying (by running NotBitcoinXT for example) It's probably much better to define the Core fork as the one which hasn't hardforked, the one which follows the consensus rules of the Bitcoin Core 0.11 client from Aug 2015.

[belcher]

This thread is interesting.  It seems the coinbase coins on both sides of the fork may be more valuable because they could be reliably used to split coins between the two chains.

Could this motivate a miner to produce the first block over 1MB?  The miner could wait 100 blocks and then distribute the coinbase coins out quickly for a large premium.  Knowing they can be the first to perform arbitrage on the two chains.

I don't think so. Coinbase coins are not the only way to split coins between the two chains. Someone could easily create a split by having a UTXO be spent differently on each side of the fork, perhaps using BitcoinXT's different relaying rules as described by goatpig in this thread.
Also the person who makes a transaction like this can split coins without waiting for the 100 block maturity.

[Was]

This is not what we need, we need Bitcoin Core to publish Satoshi 12.0 with dynamic block size and thats it. this XT vs Core will kill bitcoin. Two bitcoins? Two blockchains?

This all sounds very dangerous and juvenile.

[belcher]

This is not what we need, we need Bitcoin Core to publish Satoshi 12.0 with dynamic block size and thats it. this XT vs Core will kill bitcoin. Two bitcoins? Two blockchains?

This all sounds very dangerous and juvenile.

Trouble is that would require everyone to agree to update to this Bitcoin Core with dynamic block sizes. I for one will be unlikely to do that for bip101.

Yes it is very dangerous and juvenile, the falling exchange rate clearly shows this. I won't be assigning any blame here. This futures market could actually help by reducing uncertainly and allowing people to express a view.

[belcher]

https://www.reddit.com/r/Bitcoin/comments/3i9qdj/25_of_hashing_power_is_now_publicly_backing_bip100/

Some miners vote for a proposal that puts all control with the miners.
Anyone want to write some bip100/core futures?

Also this thing shows that there are many different ways of getting >1MB. bip101 coins are not the same as bip100 coins, futures contracts should not treat them the same.