4 ms·

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

by gomox 9y ago

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/0xaa1a6e3e6ef20068f7f8d8c835d2d22fd5116444#code https://etherscan.io/address/0xaa1a6e3e6ef20068f7f8d8c835d2d... And this is the related helper that checks which chain you are in: https://etherscan.io/address/0x2bd2326c993dfaef84f696526064ff22eba5b362#code 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.

BenoitP 9y ago
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 ^^.
- gomox 9y ago
  > 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.
  - cesarb 9y ago
    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.
    - gomox 9y ago
      > 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.
  - 9500 9y ago
    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.
    - gomox 9y ago
      Yes, but that's hardly practical. I guess someone will make software for this (with the corresponding caveats, bugs, security and trust issues, etc).

by gomox 9y ago

BenoitP 9y ago

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

gomox 9y ago
> 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.
- cesarb 9y ago
  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.
  - gomox 9y ago
    > 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.
- 9500 9y ago
  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.
  - gomox 9y ago
    Yes, but that's hardly practical. I guess someone will make software for this (with the corresponding caveats, bugs, security and trust issues, etc).