Topic: Economic majority voting - page 2. (Read 4002 times)

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.

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.

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.

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

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.

Interesting offer. There is something to think about!

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.

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.

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.

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.

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.

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