[bitcoin-dev] How to preserve the value of coins after a fork.

Peter Todd pete at petertodd.org
Wed Dec 30 20:16:12 UTC 2015

Hash: SHA512

Note how transaction malleability can quickly sabotage naive notions of this idea.

Equally, if this looks like it might ever be implemented, rather than using a hard fork, using a forced soft-fork to deploy changes becomes attractive.

On 30 December 2015 12:08:36 GMT-08:00, "Emin Gün Sirer via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Ittay Eyal and I just put together a writeup that we're informally
>Bitcoin-United for preserving the value of coins following a permanent
>Half of the core idea is to eliminate double-spends (where someone
>spends a
>UTXO on chain A and the same UTXO on chain B, at separate merchants) by
>placing transactions from A on chain B, and by taking the intersection
>transactions on chain A and chain B when considering whether a payment
>been received.
>The other half of the core idea is to enable minting of new coins and
>collection of mining fees on both chains, while preserving the 21M
>This is achieved by creating a one-to-one correspondence between coins
>one chain with coins on the other.
>Given the level of the audience here, I'm keeping the description quite
>terse. Much more detail and discussion is at the link above, as well as
>assumptions that need to hold for Bitcoin-United.
>The high bit is that, with a few modest assumptions, it is possible to
>create a cohesive coin in the aftermath of a fork, even if the core
>are split, and even if one of the forks is (in the worst case)
>non-cooperative. Bitcoin-United is a trick to create a cohesive coin
>when there is no consensus at the lowest level.
>Bitcoin-United opens up a lot of new, mostly game-theoretic questions:
>happens to native clients who prefer A or B? What will happen to the
>of native-A or native-B coins? And so on.
>We're actively working on these questions and more, but we wanted to
>the Bitcoin-United idea, mainly to receive feedback, and partly to
>some hope about future consensus to the community. It turns out that it
>possible to craft consensus at the network level even when there isn't
>at the developer level.
>Happy New Year, and may 2016 be united,
>- egs & ittay
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org

- --
Sent from my Android device with K-9 Mail. Please excuse my brevity.


More information about the bitcoin-dev mailing list