Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XmWEF-0007jp-8J for bitcoin-development@lists.sourceforge.net; Thu, 06 Nov 2014 23:12:35 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.154 as permitted sender) client-ip=62.13.148.154; envelope-from=pete@petertodd.org; helo=outmail148154.authsmtp.co.uk; Received: from outmail148154.authsmtp.co.uk ([62.13.148.154]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XmWED-0006VT-VX for bitcoin-development@lists.sourceforge.net; Thu, 06 Nov 2014 23:12:35 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA6NCQFf035048; Thu, 6 Nov 2014 23:12:26 GMT Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA6NCM03070325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 6 Nov 2014 23:12:24 GMT Date: Thu, 6 Nov 2014 18:12:25 -0500 From: Peter Todd To: Matt Corallo Message-ID: <20141106231225.GA26859@savin.petertodd.org> References: <20141106213215.GA12918@savin.petertodd.org> <545BF0C2.3030201@bluematt.me> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <545BF0C2.3030201@bluematt.me> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 5e80f41a-660a-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgQUFloCAgsB AmIbWVdeUV97W2c7 bA9PbARUfEhLXhtr VklWR1pVCwQmQm0H eG1jUhpycAVFens+ ZERrWHkVWRFydRB5 Qx9JE2sGNHphaTUb TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIj4x DxwDEzsuFlABWzR7 KBJuNUQdAEcXPQ05 Nl06VFQDLgRwQgZE Hl1MCyZdb1IGSyd5 RR9aUAYlMRJ9aBx8 NSYJBDBsL3RYRyUw X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1XmWED-0006VT-VX Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:12:36 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 06, 2014 at 10:05:54PM +0000, Matt Corallo wrote: > Depends, without BIP62 a /lot/ of the even basic contracts that people > want to use today (or wanted to use 18 months ago) are unusable, in > fact, without BIP62, the atomic swaps suggested as important for > sidechains are not secure. While redoing Bitcoin in a hardfork is nice, > its a very long-term thing, so I'm not sure about making people wait for > a large hardfork just to use payment channels. BIP62 is a less-than-ideal way of making contracts secure against malleability as it relies on a "whack-a-mole" approach to security that is insecure if any flaw is missed. If you only wanted to make contracts secure, you'd either implement a new SignatureHash() that could leave out the prevout field in favor of hashing the previous input's CTxOut() structure, and/or implement the significantly more limited CHECKLOCKTIMEVERIFY. Equally BIP62 fails at making more complex types of contracts secure. For instance suppose I had a multi-step protocol that required more than two transactions: tx1: Alice -> (Alice, Bob) tx1_refund: (Alice, Bob) -> Alice tx2: (Alice, Bob) -> Charlie tx2_refund: (Alice, Bob) -> Bob tx1 can only be modified by Alice, so tx1_refund is secure. However the second stage, where the output of tx1 is spent by tx2, with a refund transaction giving the funds back to Bob, can't be made secure as BIP62 can't prevent Alice from changing her signature, getting tx2' mined instead, and making tx2_refund invalid. OTOH a new form of signature hash that was a signature on tx2.vout structure rather than it's txid would be secure, as tx2_refund would be valid regardless of tx2's actual txid. Obviously there are good reasons to not use such signature hashes in the general case, as they imply you can't reuse scriptPubKeys securely, but that's a minor problem for purpose-built contract protocols. It's certainly a much more minor problem then the huge number of holes possible with BIP62. BIP62 does make life easier for wallet authors as they don't have to deal with malleability - maybe! - but for contracts it's a bad design. > Also, I echo the difficulty of writing consensus-compatible code and > highly suggest anyone with money behind an implementation that is doing > script verification in code that isnt Bitcoin Core rethink that decision. FWIW I've done due-dilligence reviews for investors on projects and companies that have re-implemented Bitcoin Core consensus-critical code, and every time my review lists doing so as a major red flag. --=20 'peter'[:-1]@petertodd.org 0000000000000000166801ed3959dde6b7d979735c290e7c4271ae3cf75ced63 --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJUXABVXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwOGYyMjkwOTI0YTY4ODI5MjhkNDU2NmY0ODdmMzNjYzU3 MjAzYTY1MzU3OTUyMDEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsOdQf+POdzNhLoqBZwksceM161iVEY VT7D43xVgpnrJjraama8IwVWvac2ZqaSs7WF9WWTWd7v5pgaBABV4x913NFnnZe0 yQTGznWCPICcXLa7TajgpHO+4SBQHKl9YsE/M1ex8iPHgLS+odPV6/BQYEqTtlRb iLVb3sQVkpivr5BvvkCY+eHeOUxoj+R4BdrAxiXoX0wstpWH3P8kqQ+ToY40GGlD xkFnrGy55CpjsEDMgoM9Z0CBCCYJRj6nnwNiQ5lMDNQuSSm3gMwYzP+V2R9nmSmM BjmnlC8gE6AxpqmVx7hCsvm3xWUAy6E5Z9MfJNI61zm6cEey+4/Nv7QjhkxqRQ== =E0/C -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--