public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: "Emin Gün Sirer" <el33th4x0r@gmail•com>,
	"Emin Gün Sirer via bitcoin-dev"
	<bitcoin-dev@lists•linuxfoundation.org>,
	"Bitcoin Dev" <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] How to preserve the value of coins after a fork.
Date: Wed, 30 Dec 2015 20:16:12 +0000	[thread overview]
Message-ID: <6741032F-757F-4D9E-A722-3A62271B6BFD@petertodd.org> (raw)
In-Reply-To: <CAPkFh0tj4cXYuk8=8QJOP5z4qea6bv_sELhkfHO6nU16mMnnZA@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
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@lists•linuxfoundation.org> wrote:
>Ittay Eyal and I just put together a writeup that we're informally
>calling
>Bitcoin-United for preserving the value of coins following a permanent
>fork:
>
>
>http://hackingdistributed.com/2015/12/30/technique-to-unite-bitcoin-factions/
>
>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
>of
>transactions on chain A and chain B when considering whether a payment
>has
>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
>maximum.
>This is achieved by creating a one-to-one correspondence between coins
>on
>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
>the
>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
>devs
>are split, and even if one of the forks is (in the worst case)
>completely
>non-cooperative. Bitcoin-United is a trick to create a cohesive coin
>even
>when there is no consensus at the lowest level.
>
>Bitcoin-United opens up a lot of new, mostly game-theoretic questions:
>what
>happens to native clients who prefer A or B? What will happen to the
>value
>of native-A or native-B coins? And so on.
>
>We're actively working on these questions and more, but we wanted to
>share
>the Bitcoin-United idea, mainly to receive feedback, and partly to
>provide
>some hope about future consensus to the community. It turns out that it
>is
>possible to craft consensus at the network level even when there isn't
>one
>at the developer level.
>
>Happy New Year, and may 2016 be united,
>- egs & ittay
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists•linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhDuA
AAoJEMCF8hzn9Lncz4MIAIObFNbRRJ5g52H8yprqAjX76Lt7vw+cwCnICNzHra5h
iuTWxgbwED5fki2Q96ZzYAyUf7ju7rI45qBl8YuuVUlyxJgE6oV6h2oJoxGQNGz0
WvrOjWMkmARNs0FM4GMsKQWcmIMgZxWnWTMOXv0EDBLySsm8WFRu9H4drGBB+Fmb
wFRyi0XVDiXxsVUoNj6pCdcpekdnuq+V87IoweoxigfqgWIM31Vb9QK8Y/7vWO2b
0lu0CvVdqvw5Npx55LWLF1tY8jbw6BYvgXwZGtUazKO+x8i3Qt6+tRm07+UXvkoR
3erxzhnoZa3F66ufz+ImY7l0E/AyRE5ox+1W68hO6sk=
=d0+L
-----END PGP SIGNATURE-----



  reply	other threads:[~2015-12-30 20:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30 20:08 Emin Gün Sirer
2015-12-30 20:16 ` Peter Todd [this message]
2015-12-30 20:22   ` Emin Gün Sirer
2015-12-30 20:32     ` Peter Todd
2015-12-30 23:13       ` Nick ODell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6741032F-757F-4D9E-A722-3A62271B6BFD@petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=el33th4x0r@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox