Topic: Economic majority voting (Read 3998 times)

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.

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.

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.

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.

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.

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.


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

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.


Yeah sounds OK.

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?

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

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.

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.

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.


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.

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


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


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


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.

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.


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


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.

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.

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


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.


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.


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


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

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.

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

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.

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.