From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 74876110C for ; Wed, 30 Dec 2015 20:16:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148100.authsmtp.co.uk (outmail148100.authsmtp.co.uk [62.13.148.100]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8B315129 for ; Wed, 30 Dec 2015 20:16:21 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBUKGJsj017534; Wed, 30 Dec 2015 20:16:19 GMT Received: from [25.160.140.243] ([24.114.24.50]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBUKGEkJ038438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Dec 2015 20:16:16 GMT In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Wed, 30 Dec 2015 20:16:12 +0000 To: =?ISO-8859-1?Q?Emin_G=FCn_Sirer?= , =?ISO-8859-1?Q?Emin_G=FCn_Sirer_via_bitcoin-dev?= , Bitcoin Dev Message-ID: <6741032F-757F-4D9E-A722-3A62271B6BFD@petertodd.org> X-Server-Quench: 2f2ccbb3-af32-11e5-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdQIUHFAXAgsB AmMbWVReUVt7WGQ7 aQ5PbARZfEhKQQBq T01BRU1TWkEaZGd2 c0VkUhp6cwZONn9x Y0BmEHINXhcpJxR+ Xx8CFm8bZGY1bX0X UkkNagNUcQZLeRZA PlV6Uj1vNG8XDSg5 AwQ0PjZ0MThBHWx1 RR5FMVVaWVwGBTMm WR1KATUiVVMMQzg+ ZxsoYlUbHUAKekw8 LVY7EVtQPRgICUs2 X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.24.50/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] How to preserve the value of coins after a fork. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2015 20:16:22 -0000 -----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" 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-----