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 060FE1009 for ; Wed, 30 Dec 2015 20:32:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148102.authsmtp.net (outmail148102.authsmtp.net [62.13.148.102]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 257FD120 for ; Wed, 30 Dec 2015 20:32:52 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBUKWpxB061402; Wed, 30 Dec 2015 20:32:51 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 tBUKWlO7090771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Dec 2015 20:32:49 GMT In-Reply-To: References: <6741032F-757F-4D9E-A722-3A62271B6BFD@petertodd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Wed, 30 Dec 2015 20:32:43 +0000 To: =?ISO-8859-1?Q?Emin_G=FCn_Sirer?= Message-ID: X-Server-Quench: 7ee9a7ac-af34-11e5-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdQIUHFAXAgsB AmMbWVReU197XGM7 aQ5PbARZfEhKQQBq T01BRU1TWkEaZGdm WmEZUhBycAJHNnh0 bEIsWSUOVRV9JBVg ExhXEXAHZDJldWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk FAgyOXU9MCtqYARS XUkRKhoKW0sQEyQi SlgeHThnA0QBWih7 KBJuIVkdGl1ZO0su PEFpUBoWNAURTGUA 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 Cc: =?ISO-8859-1?Q?Emin_G=FCn_Sirer_via_bitcoin-dev?= 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:32:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer" wrote: >On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd wrote: > >> Note how transaction malleability can quickly sabotage naive notions >of >> this idea. >> > >Bitcoin-United relies on a notion of transaction equivalence that >doesn't >involve the transaction hash at all, so it should be immune to >malleability >issues and compatible with segwit. > >From the post, two transactions are equal if they "consume the same >inputs >and result in the same outputs, not counting the miner fee. Simple >pay-to-pubkey-hash and pay-to-script-hash transactions are >straightforward. >Multikey transactions are evaluated for equivalency by their inputs and >outputs, so it is allowable for a 2-out-of-3 payment to be signed by >one >set of two keys on Dum and another set of two keys on Dee, as long as >the >transaction consumes the same coins and produces the same outputs. Not >that >we'll ever encounter such a case, but making this point helps >pedagogically >with getting across the notion of transaction equivalence. What counts >are >the consumed inputs and the destination and amounts of the outputs." You seem to not be familiar with how multisig transactions on Bitcoin work - 99.9% of the time theyre hidden behind p2sh and there is no way to know what keys are involved. Equally, multisig is just one of many complex scripts possible. Look into what a segwit transaction hashes - that's a better notion of non-malleable transaction. But even then lots of transactions are malleable, and its easy to trigger those cases intentionally by third parties. Most likely any Bitcoin United scheme would quickly diverge and fail; much simpler and more predictable to achieve convincing consensus, e.g. via proof of stake voting, or Adam Bank's extension blocks suggestions. (or of course, not trying to force controversial forks in the first place) -----BEGIN PGP SIGNATURE----- iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJWhD9N AAoJEMCF8hzn9Lncz4MH/0JPGVc2JLtD5q0I2w0vqmBqsoSzSueCtnKa2K1Ea10g w9I4uhK7+cgfCLbofJznVHMChXu0uCxtWwqSj++uJx238TEupcu951gUhFfuPOeH Egye8jmDkDFiB1P40kUSVk9N64Zt3kWLk4xSsfjawVHz/WWpM24Fn8k/bmI7JiLl nmVwoBdRsTKffM/1dr8ix4U8YPSmJ7W+jAByNHUpSgc1R73YylqNT95pF8QD35df dQwSK9DIc+2N4CKnp22xLvYeCivFjeS2Fm4kbcKQwMjcqlJ1mWghP/c8q/lzhaGN Ac15/pgeHp8dPP8c81zkN9ps14rrnXoHnrzjiY+TwKY= =FfK1 -----END PGP SIGNATURE-----