Bitcoin Forum

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.


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


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

You can spend multiple rows. 

To skip a row, you just include


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.

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.

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.


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


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.

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.

Exactly.


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.

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!

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

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.

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.

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.

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.

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.

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

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.

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


Remember there's also a chance that lots of people are actually running NotBitcoinXT (https://bitcointalk.org/index.php?topic=1154520.0), so the 75% mining majority still doesn't guarantee anything.


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

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.

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.

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.

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.

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.

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

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.

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

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?

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.

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.

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 (https://bitcointalk.org/index.php?topic=1154520.0) 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.

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.

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.

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.