Comment by BenoitP | Hacker News Reader

Comment by BenoitP | Hacker News Reader

I'm starting to see a bit clearer on how a fork would pan out:

Miners: Hashing power has little influence. As long as there are miners, and two chains rejecting each other transactions will be processed. At first, transactions processing might take a while, but difficulty will adapt. This will create two legitimate currencies. Now everybody in possession of 1 BTC would have 1 BTCa + 1 BTCb.

Exchanges: Little power. They will trade both BTCa and BTCb, and accept commissions.

Trader of goods, in embedded devices: They might have to modify their client to accept both currencies, but they would have to follow the market rates. Otherwise they would have to suffer income loss from people using them to profit from arbitrating the markets.

BTC-rich individuals: They have now 1 BTCa + 1 BTCb. But there is transaction replayability. If they spend 1 BTCa, their BTCb can also get spend the same way. And they lose their BTCb. Chains have a strategic advantage to replay transactions getting to the other one because: 1) they get to keep the commission, 2) they ascertain themselves as more encompassing economically (not sure on this one maybe, they want to stay neutral).

Now, if BTC-holders can wallet-emptying-double-spend them to 2 different addresses they control on the 2 chains. And, compared to the ones who got their transaction replayed, they have kept both their BTCa and BTCb.

TL;DR: IMHO, come the technical fork, some BTC-holders will be tumbling until they irrevocably acquire their BTCa + BTCb, and use them to make runs on the markets, effectively materializing the economic fork.

----

I'd love the opinion of someone who lived through the ETH-ETC split, especially about the transaction replayability part.

I was there at the ETH/ETC split and replay was a thing. Someone put together a special smart contract that received 2 addresses (one for the ETH chain and one for the ETC chain), checked which chain you were in and wired ether to either address accordingly.

After doing that (and because valid transaction execution was contingent on the actual chain you were in) each wallet became independent and you were free to use funds in each as desired.

This is the contract:

https://etherscan.io/address/0xaa1a6e3e6ef20068f7f8d8c835d2d...

And this is the related helper that checks which chain you are in:

https://etherscan.io/address/0x2bd2326c993dfaef84f696526064f...

I'm not clear on what a BTC equivalent of this operation would be. Seems like smart contracts saved the day, as trying to move BTC to 2 different wallets on split chains by hand risks a race condition.

Thanks for this reference code!

I got to say, Ethereum really is showing the way to Bitcoin here. The smart contract ecosystem surrounding it is astounding.

----

The BTC equivalent would be to do it by hand; and I don't think it is all that risky, as long as you keep control of all three addresses.

Or, ... maybe a BTC smart contract could help us do it easily? What do we need to enable smart contracts on BTC?

Oh wait, that's right. We need Segwit. The thing potentially causing a fork itself.

We're supposed to have it by the time Segwit2x's double-sized blocks hardfork come, though ^^.

> and I don't think it is all that risky, as long as you keep control of all three addresses.

By "doing it by hand" I meant the following:

  - Original wallet A holds BTC before hard fork
  - Chain splits and forks coexist (lets call them C1 and C2)
  - New wallet W1 is created for use in the new chain C1 exclusively
  - New wallet W2 is created for use in the new chain C2 exclusively
  - You connect to network that uses C1, and move all the funds from A to W1
  - You connect to network that uses C2, and move all the funds from A to W2

The problem is in such a scenario you can expect that malicious software will exist that monitors transactions being broadcasted in C1 to try to replay them in C2. By the time you attempt to perform the last step outlined above, you might find that the funds are gone from A in C2 because some replayed your transaction on C2 already.

A solution would be to add a dependency on the chain itself. By definition, in a hard fork you have blocks in one chain which won't ever be accepted by the other. Suppose C2 has a block, let's call it B2, which won't ever be accepted by C1 (because it's larger than the C1 maximum block size, for instance).

Now get the block reward from B2, or some other coin which depends on it. This block reward, and any coin which depends on it, will never be accepted by C1. Mix it somehow with your coins from wallet A, and send the result to W2. Wait a few confirmations for it to stick.

Now you have in C2 all your coins in W2, and in C1 all your coins are still in A (the A->W2 transaction can't be replayed in C1, since it depends on an invalid block). All that's left is to move all funds from A to W1; this will happen only on C1, since it would be a double-spend in C2.

As you can see, it's not that complicated. The only hard part, if you aren't a miner, is to get the "one-sided" coin, but I'd expect either a service to pop up soon to do the mixing for you, for not much more than the transaction fee (the "one-sided" coin can be recycled indefinitely), or a "faucet" to pop up on C2 to give out tiny "one-sided" coins for anyone who needs them, for free.

> The only hard part, if you aren't a miner, is to get the "one-sided" coin

Indeed, but this is the kind of technical annoyance that cripples the "it just works" perception/marketing of BTC. I guess this is what makes people look forward to BTC ETFs as opposed to the real thing for their investo-gambling.

But by ensuring that A, W1 and W2 wallets are yours, you are able to try as many times as you want (provided you're willing to pay for the fees). And the more times you try, more your probability of success approaches 1.

Yes, but that's hardly practical. I guess someone will make software for this (with the corresponding caveats, bugs, security and trust issues, etc).

They fixed the transaction replay ability I believe. I still have all my ETC, seems like it's not going anywhere.

How is that technically possible to prevent?

The miners in the two chains gain from listening to what is going on in the other chain, and could just copy transactions and take the commission.

Have no miner attempted to grab some fees? Or maybe the price of ETC is so low that it would be unprofitable?

----

Addendum:

It is addressed in EIP #155 [1], where they changed the signing of transactions and put some sort of chain identity to be included in the transaction signatures.

Which brings the question: Is there something changed in transaction signatures in the segwit2x hard fork? Is there already some chain identity in it?

[1] https://github.com/ethereum/eips/issues/155

In btc1 there is not any replay protection right now, as the timeline didn't allow for development of this. It is an important feature request though, maybe follow along here:

https://github.com/btc1/bitcoin/issues/34

Reply on news.ycombinator.com