diff options
| author | Peter Todd <pete@petertodd.org> | 2015-04-27 15:21:12 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-04-27 19:21:25 +0000 |
| commit | a8bea76d711ad4d3170611f3c1f5978726cf4922 (patch) | |
| tree | 4b45c4b944a460fefa600c43c5da93ce3629370a | |
| parent | b31777df211a09d9bee18d9e9c5d588b6effd772 (diff) | |
| download | pi-bitcoindev-a8bea76d711ad4d3170611f3c1f5978726cf4922.tar.gz pi-bitcoindev-a8bea76d711ad4d3170611f3c1f5978726cf4922.zip | |
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
| -rw-r--r-- | 3f/2bfb4b3f033f3e83c7e0cc6089cf8013a01789 | 145 |
1 files changed, 145 insertions, 0 deletions
diff --git a/3f/2bfb4b3f033f3e83c7e0cc6089cf8013a01789 b/3f/2bfb4b3f033f3e83c7e0cc6089cf8013a01789 new file mode 100644 index 000000000..14c77ea78 --- /dev/null +++ b/3f/2bfb4b3f033f3e83c7e0cc6089cf8013a01789 @@ -0,0 +1,145 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pete@petertodd.org>) id 1Ymoar-0007wY-NR + for bitcoin-development@lists.sourceforge.net; + Mon, 27 Apr 2015 19:21:25 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org + designates 62.13.148.113 as permitted sender) + client-ip=62.13.148.113; envelope-from=pete@petertodd.org; + helo=outmail148113.authsmtp.com; +Received: from outmail148113.authsmtp.com ([62.13.148.113]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1Ymoaq-0008Fk-6F for bitcoin-development@lists.sourceforge.net; + Mon, 27 Apr 2015 19:21:25 +0000 +Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) + by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t3RJLGCp027394; + Mon, 27 Apr 2015 20:21:16 +0100 (BST) +Received: from muck (rrcs-23-246-65-155.nyc.biz.rr.com [23.246.65.155]) + (authenticated bits=128) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t3RJLDZX024602 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); + Mon, 27 Apr 2015 20:21:15 +0100 (BST) +Date: Mon, 27 Apr 2015 15:21:12 -0400 +From: Peter Todd <pete@petertodd.org> +To: Stephen Morse <stephencalebmorse@gmail.com> +Message-ID: <20150427191855.GE5223@muck> +References: <552EF785.7000207@sky-ip.org> + <CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com> + <552FDF73.6010104@sky-ip.org> + <CABjHNoTeMiLWkDBUqdV4HJ=nAhj8wqOjD4cypY9Dv2y9HJWJMg@mail.gmail.com> + <CABHVRKTMg3sih8i3ta0v=jZU+fBzBR-i5b_b7C+drV4CAfGQJg@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="s5/bjXLgkIwAv6Hi" +Content-Disposition: inline +In-Reply-To: <CABHVRKTMg3sih8i3ta0v=jZU+fBzBR-i5b_b7C+drV4CAfGQJg@mail.gmail.com> +X-Server-Quench: 9321eb97-ed12-11e4-b396-002590a15da7 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aQdMdAUUGUUGAgsB AmMbWVReUlx7WGU7 aQlPbwFbfExLQQRv + VVdMSlVNFUssAn57 emp0OhlwcwNGejBx YUFlXD5SX0Z7IBR0 + RVMBQWwEeGZhPWQC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES + HhM4ODE3eDlSNilR RRkIIFQOdA5UQ3N7 Fk1PVSkvB0AeRyI3 + I1QoLURUAFwYNF47 OkcgXlRQLRIIEQxZ GVol +X-Authentic-SMTP: 61633532353630.1023:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 23.246.65.155/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: 1Ymoaq-0008Fk-6F +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 27 Apr 2015 19:21:25 -0000 + + +--s5/bjXLgkIwAv6Hi +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Sat, Apr 25, 2015 at 10:32:36AM -0400, Stephen Morse wrote: +> Hi William, +>=20 +> I personally prefer this solution, since it nails the problem +> > completely with one simple and obvious change. The BIP 62 approach is +> > more like a game of wac-a-mole. +> > +>=20 +> The two are complementary, not competing. BIP62 prevents *non-signers* fr= +om +> mutating the transactions, which is very important. + +I strongly disagree. + +There are exactly two cases where mutation matters to normal wallets: + +1) Spending unconfirmed change. This can be more efficiently done by + double-spending the first tx with a second that pays both recipients. + +2) Large reorganizations. Making mutation impossible makes it more + likely that after a large reorg all previously confirmed transactions + will make it back to the blockchain succesfully. + +Meanwhile, the "whack-a-mole" aspect of BIP62 is worrying - it's very +likely we'll miss a case. Even right now there are edge cases without +good solutions, like how in a multisig environment any of the key +holders can mutate transactions. Building wallets that make strong +assumptions about malleability and fail if those assumptions turn out to +be wrong is poor engineering. + +> The 'Build your own +> nHashType' proposal enables chained transactions even in the face of +> *signers* mutating the transaction. I believe that integrating both will +> lead to the best defense against transaction malleability, and will enable +> more complicated uses of chained transactions (such as micropayment +> channels). + +While I think there are better ways to do 'Build your own nHashType' +than what was recently proposed, I strongly agree that for protocols +that really, truly, need malleability resistance it's far better to use +a purpose-built signature hashing algorithm. + +--=20 +'peter'[:-1]@petertodd.org +00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 + +--s5/bjXLgkIwAv6Hi +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- + +iQGrBAEBCACVBQJVPowlXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw +MDAwMDAwMDAwMDAwMDAwZTc5ODBhYWI5YzA5NmM0NmU3ZjM0YzQzYTY2MWM1Y2Iy +ZWE3MTUyNWViYjhhZjcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 +ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxJmgf6Ay81VmHzKWlChPK+d0b5y5fG +ttnWNAPZUgWGK1i4bxykIOUSHLmk0NI7aIb0sAhEbGjwSKphNGe2MDOi9qErBEK4 +ZWMQvna3zGI1lq9Z2r9KF2Th3HRgQbKhPWsQcR8VUM0EkFVw9iFBWG1KS4fLSlve +ObHrLdngVHST2EIWjhijR9JFs58x/O5YnQvclwxadJhqPm/g3BenWe9dkNf+XUSF +ar1Mpxx3BaL+ujJeyJQrbK+rnk0l5rXOFPQtDypp+shHsILpqgtkfh3XB2/NCtK/ +OCLt/5nYzX6VHUezgPh6WEJwf+5Kn9y70nHKGyTq46cwhbz5imvJWCbcSxGoUg== +=w262 +-----END PGP SIGNATURE----- + +--s5/bjXLgkIwAv6Hi-- + + |