diff options
| author | Allen Piscitello <allen.piscitello@gmail.com> | 2014-02-12 10:38:18 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-02-12 16:38:26 +0000 |
| commit | e346a9582448c937a9c5092a69c3292dbae6093f (patch) | |
| tree | cdff6f13a2787e380a5922f165d55105c4b7383f | |
| parent | 6e696b6ecaecbf100c2dd4dd90da923ae615a11e (diff) | |
| download | pi-bitcoindev-e346a9582448c937a9c5092a69c3292dbae6093f.tar.gz pi-bitcoindev-e346a9582448c937a9c5092a69c3292dbae6093f.zip | |
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
| -rw-r--r-- | ff/5da6f370f8e29b6f88a95d8e2a1892ee62a246 | 460 |
1 files changed, 460 insertions, 0 deletions
diff --git a/ff/5da6f370f8e29b6f88a95d8e2a1892ee62a246 b/ff/5da6f370f8e29b6f88a95d8e2a1892ee62a246 new file mode 100644 index 000000000..7f71343ce --- /dev/null +++ b/ff/5da6f370f8e29b6f88a95d8e2a1892ee62a246 @@ -0,0 +1,460 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <allen.piscitello@gmail.com>) id 1WDcpO-00039X-76 + for bitcoin-development@lists.sourceforge.net; + Wed, 12 Feb 2014 16:38:26 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 74.125.82.180 as permitted sender) + client-ip=74.125.82.180; + envelope-from=allen.piscitello@gmail.com; + helo=mail-we0-f180.google.com; +Received: from mail-we0-f180.google.com ([74.125.82.180]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WDcpM-0000rw-F6 + for bitcoin-development@lists.sourceforge.net; + Wed, 12 Feb 2014 16:38:26 +0000 +Received: by mail-we0-f180.google.com with SMTP id u57so6169048wes.39 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 12 Feb 2014 08:38:18 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.180.188.141 with SMTP id ga13mr2716771wic.55.1392223098342; + Wed, 12 Feb 2014 08:38:18 -0800 (PST) +Received: by 10.194.76.135 with HTTP; Wed, 12 Feb 2014 08:38:18 -0800 (PST) +In-Reply-To: <CALf2ePyDTZ_43uBfS9-5znhTyBR-5H10SpZ=N-z1DBacM_rDgA@mail.gmail.com> +References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com> + <20140210030048.GB31925@savin> + <CAH2=CKzNGN7mpe1NLtsLRNSszSD2ZNwjoAsaH40EvGtA5ezDeQ@mail.gmail.com> + <CALf2ePyDTZ_43uBfS9-5znhTyBR-5H10SpZ=N-z1DBacM_rDgA@mail.gmail.com> +Date: Wed, 12 Feb 2014 10:38:18 -0600 +Message-ID: <CAJfRnm5pVA+gd3t=bXO188S4uwtUvx5F8V_bO_YV+74Ev4Q9jg@mail.gmail.com> +From: Allen Piscitello <allen.piscitello@gmail.com> +To: Alan Reiner <etotheipi@gmail.com> +Content-Type: multipart/alternative; boundary=001a11c37f5a39b17504f238334c +X-Spam-Score: -0.6 (/) +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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (allen.piscitello[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1WDcpM-0000rw-F6 +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with + malleability +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: Wed, 12 Feb 2014 16:38:26 -0000 + +--001a11c37f5a39b17504f238334c +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +While that solution does work for many use cases, it does make it much +harder to do anything needing chained transactions. Granted, this is the +short term solution for current implementations, but having a transaction +identifier that does not change does open up other use cases. + +For example, Alice wants to send coins to a multisignature address with +Bob, such that both parties are required to spend the coins. Alice also +requires for Bob to send coins to this address as well before they will +proceed. Alice cannot guarantee that Bob will cooperate (and vice versa), +so before she broadcasts the transaction to send to A+B, she sends Bob a +transaction that spends her incoming transaction back to herself, but has a +time lock of far into the future. Bob signs this, returns it to Alice, and +she broadcasts her funding transaction. At this point, Bob disappears, +loses his key, or just decides to spite Alice and her coins are locked. + Since she has a refund transaction, she can broadcast it in a month and +get her coins back. Except her funding transaction has been modified such +that the txhash is different, so her refund is now invalid. She would need +Bob to issue a new refund as soon as her funding transaction hits the +blockchain if it is modified, which defeats the point of the trustless +refund transaction. + +Longer term it would be more ideal have a canonical identifier for the +transaction before it even gets to the chain to support these use cases, +even if wallets are able to properly identify the status of it's +transactions. Obviously this is a difficult problem to solve and cannot be +implemented without breaking changes, but it would be a nice goal to be +able to completely remove malleability. There are other important use +cases where having a unique identifier just for internal accounting is +insufficient. + +-Allen + + +On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner <etotheipi@gmail.com> wrote: + +> I think the solution is simply to encourage Bitcoin software developers t= +o +> design their software to use this static ID, instead of the full +> transaction hash. If MtGox had talked those IDs instead of the TX ID, +> their software would've correctly identified the mutated transactions and +> there would be no problem. +> +> Armory is slightly different, since it doesn't deal with the same stuff a= +s +> exchanges do. But it didn't have any problems with malleability because = +it +> doesn't track anything by ID, it only pays attention to whether inputs an= +d +> outputs are related to your wallets. It's not necessarily hard to do it +> this way, people just have to be aware of it. +> +> -Alan +> +> Sent from my overpriced smartphone +> On Feb 12, 2014 10:15 AM, "Rune Kj=E6r Svendsen" <runesvend@gmail.com> +> wrote: +> +>> Instead of trying to remove the possibility of transaction +>> malleability, would it make sense to define a new, "canonical +>> transaction hash/ID" (cTxID), which would be a hash of the part of the +>> transaction data which we know is not malleable, and have clients use +>> this cTxID internally, thus making the traditional transaction hash +>> irrelevant for a client to function correctly? +>> +>> We already have a non-malleable transaction hash: the hash that is +>> signed, ie. the transaction with each scriptSig replaced by the +>> scriptPubKey it redeems. This could be the cTxID. +>> +>> Or is this simply a too fundamental change to the way bitcoin-qt (and +>> all other clients) work in order to be feasible? +>> +>> As far as I can see, it completely solves the issue of not having a +>> canonical ID for a transaction, but it also increases the +>> computational requirements for a node. For one, as far as I can see, +>> it requires the node to index all transactions, because in order to +>> calculate a cTxID, it would be necessary to fetch all transactions +>> referred to by the transaction in question, in order to pull in the +>> scriptPubKeys that are redeemed. +>> +>> +>> On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete@petertodd.org> wrote: +>> > On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote: +>> >> Hello all, +>> >> +>> >> it was something I planned to do since a long time, but with the +>> >> recent related issues popping up, I finally got around to writing a +>> >> BIP about how we can get rid of transaction malleability over time. +>> >> +>> >> The proposed document is here: https://gist.github.com/sipa/8907691 +>> >> +>> >> I expect most rules to not be controversial. Maybe rules 1 and 3, as +>> >> they require modifications to wallet software (Bitcoin Core 0.9 and +>> >> BitcoinJ already implement it, though) and potentially invalidate som= +e +>> >> script functionality. However, these new rules remain optional and +>> >> controlled by an nVersion increase. +>> >> +>> >> Comments please! +>> > +>> > You should probably add making CHECKMULTISIG require the dummy value t= +o +>> > be exactly equal to OP_FALSE; verifying that in the transaction itself +>> is +>> > laborious. A more subtle example is we may want both CHECKSIG and +>> > CHECKMULTISIG to fail the transaction if the signature is invalid but +>> > not exactly equal to OP_FALSE; some transaction forms are significantl= +y +>> > more compact if you can have failed signatures, but that's a source of +>> > malleability. (are there counter examples people can think of?) +>> > +>> > +>> > But as I said on IRC, I'm a bit hesitant to bake in assumptions about +>> > malleability when we have no solid idea if ECC signatures are or are n= +ot +>> > malleable on a fundemental level; if "whack-a-mole" anti-malleability = +is +>> > all we've got it could be ugly if a break is found. Similarly, we may +>> > find we missed something, or some needed change makes the malleability +>> > rules difficult to work with for some new script type that is required= +. +>> > +>> > I'd rather see a new CHECKSIG mode for the case where malleability +>> > absolutely must be eliminated - certain multi-party protocols - and fi= +x +>> > wallet software instead. (the malleability problems people see are +>> > closely related to inability to handle double-spends and reorgs) But I +>> > can easily see that being an impossible goal engineering wise... +>> > +>> > -- +>> > 'peter'[:-1]@petertodd.org +>> > 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1 +>> > +>> > +>> ------------------------------------------------------------------------= +------ +>> > Managing the Performance of Cloud-Based Applications +>> > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. +>> > Read the Whitepaper. +>> > +>> http://pubads.g.doubleclick.net/gampad/clk?id=3D121051231&iu=3D/4140/ost= +g.clktrk +>> > _______________________________________________ +>> > Bitcoin-development mailing list +>> > Bitcoin-development@lists.sourceforge.net +>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>> > +>> +>> +>> ------------------------------------------------------------------------= +------ +>> Android apps run on BlackBerry 10 +>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. +>> Now with support for Jelly Bean, Bluetooth, Mapview and more. +>> Get your Android app in front of a whole new audience. Start now. +>> +>> http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&iu=3D/4140/ost= +g.clktrk +>> _______________________________________________ +>> Bitcoin-development mailing list +>> Bitcoin-development@lists.sourceforge.net +>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>> +> +> +> -------------------------------------------------------------------------= +----- +> Android apps run on BlackBerry 10 +> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. +> Now with support for Jelly Bean, Bluetooth, Mapview and more. +> Get your Android app in front of a whole new audience. Start now. +> +> http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&iu=3D/4140/ostg= +.clktrk +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> +> + +--001a11c37f5a39b17504f238334c +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">While that solution does work for many use cases, it does = +make it much harder to do anything needing chained transactions. =A0Granted= +, this is the short term solution for current implementations, but having a= + transaction identifier that does not change does open up other use cases. = +=A0<div> +<br></div><div>For example, Alice wants to send coins to a multisignature a= +ddress with Bob, such that both parties are required to spend the coins. = +=A0Alice also requires for Bob to send coins to this address as well before= + they will proceed. =A0Alice cannot guarantee that Bob will cooperate (and = +vice versa), so before she broadcasts the transaction to send to A+B, she s= +ends Bob a transaction that spends her incoming transaction back to herself= +, but has a time lock of far into the future. =A0Bob signs this, returns it= + to Alice, and she broadcasts her funding transaction. =A0At this point, Bo= +b disappears, loses his key, or just decides to spite Alice and her coins a= +re locked. =A0Since she has a refund transaction, she can broadcast it in a= + month and get her coins back. =A0Except her funding transaction has been m= +odified such that the txhash is different, so her refund is now invalid. = +=A0She would need Bob to issue a new refund as soon as her funding transact= +ion hits the blockchain if it is modified, which defeats the point of the t= +rustless refund transaction.</div> +<div><br></div><div>Longer term it would be more ideal have a canonical ide= +ntifier for the transaction before it even gets to the chain to support the= +se use cases, even if wallets are able to properly identify the status of i= +t's transactions. =A0Obviously this is a difficult problem to solve and= + cannot be implemented without breaking changes, but it would be a nice goa= +l to be able to completely remove malleability. =A0There are other importan= +t use cases where having a unique identifier just for internal accounting i= +s insufficient.</div> +<div><br></div><div>-Allen</div></div><div class=3D"gmail_extra"><br><br><d= +iv class=3D"gmail_quote">On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner <spa= +n dir=3D"ltr"><<a href=3D"mailto:etotheipi@gmail.com" target=3D"_blank">= +etotheipi@gmail.com</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><p dir=3D"ltr">I think the solution is simpl= +y to encourage Bitcoin software developers to design their software to use = +this static ID, instead of the full transaction hash.=A0=A0=A0 If MtGox had= + talked those IDs instead of the TX ID, their software would've correct= +ly identified the mutated transactions and there would be=A0 no problem.=A0= +=A0 </p> + + +<p dir=3D"ltr">Armory is slightly different, since it doesn't deal with= + the same stuff as exchanges do.=A0 But it didn't have any problems wit= +h malleability because it doesn't track anything by ID, it only pays at= +tention to whether inputs and outputs are related to your wallets.=A0 It= +9;s not necessarily hard to do it this way, people just have to be aware of= + it. </p> + + +<p dir=3D"ltr">-Alan </p> +<p dir=3D"ltr">Sent from my overpriced smartphone </p><div class=3D"HOEnZb"= +><div class=3D"h5"> +<div class=3D"gmail_quote">On Feb 12, 2014 10:15 AM, "Rune Kj=E6r Sven= +dsen" <<a href=3D"mailto:runesvend@gmail.com" target=3D"_blank">run= +esvend@gmail.com</a>> wrote:<br type=3D"attribution"><blockquote class= +=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= +ing-left:1ex"> + +Instead of trying to remove the possibility of transaction<br> +malleability, would it make sense to define a new, "canonical<br> +transaction hash/ID" (cTxID), which would be a hash of the part of the= +<br> +transaction data which we know is not malleable, and have clients use<br> +this cTxID internally, thus making the traditional transaction hash<br> +irrelevant for a client to function correctly?<br> +<br> +We already have a non-malleable transaction hash: the hash that is<br> +signed, ie. the transaction with each scriptSig replaced by the<br> +scriptPubKey it redeems. This could be the cTxID.<br> +<br> +Or is this simply a too fundamental change to the way bitcoin-qt (and<br> +all other clients) work in order to be feasible?<br> +<br> +As far as I can see, it completely solves the issue of not having a<br> +canonical ID for a transaction, but it also increases the<br> +computational requirements for a node. For one, as far as I can see,<br> +it requires the node to index all transactions, because in order to<br> +calculate a cTxID, it would be necessary to fetch all transactions<br> +referred to by the transaction in question, in order to pull in the<br> +scriptPubKeys that are redeemed.<br> +<br> +<br> +On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <<a href=3D"mailto:pete@pete= +rtodd.org" target=3D"_blank">pete@petertodd.org</a>> wrote:<br> +> On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:<br> +>> Hello all,<br> +>><br> +>> it was something I planned to do since a long time, but with the<b= +r> +>> recent related issues popping up, I finally got around to writing = +a<br> +>> BIP about how we can get rid of transaction malleability over time= +.<br> +>><br> +>> The proposed document is here: <a href=3D"https://gist.github.com/= +sipa/8907691" target=3D"_blank">https://gist.github.com/sipa/8907691</a><br= +> +>><br> +>> I expect most rules to not be controversial. Maybe rules 1 and 3, = +as<br> +>> they require modifications to wallet software (Bitcoin Core 0.9 an= +d<br> +>> BitcoinJ already implement it, though) and potentially invalidate = +some<br> +>> script functionality. However, these new rules remain optional and= +<br> +>> controlled by an nVersion increase.<br> +>><br> +>> Comments please!<br> +><br> +> You should probably add making CHECKMULTISIG require the dummy value t= +o<br> +> be exactly equal to OP_FALSE; verifying that in the transaction itself= + is<br> +> laborious. A more subtle example is we may want both CHECKSIG and<br> +> CHECKMULTISIG to fail the transaction if the signature is invalid but<= +br> +> not exactly equal to OP_FALSE; some transaction forms are significantl= +y<br> +> more compact if you can have failed signatures, but that's a sourc= +e of<br> +> malleability. (are there counter examples people can think of?)<br> +><br> +><br> +> But as I said on IRC, I'm a bit hesitant to bake in assumptions ab= +out<br> +> malleability when we have no solid idea if ECC signatures are or are n= +ot<br> +> malleable on a fundemental level; if "whack-a-mole" anti-mal= +leability is<br> +> all we've got it could be ugly if a break is found. Similarly, we = +may<br> +> find we missed something, or some needed change makes the malleability= +<br> +> rules difficult to work with for some new script type that is required= +.<br> +><br> +> I'd rather see a new CHECKSIG mode for the case where malleability= +<br> +> absolutely must be eliminated - certain multi-party protocols - and fi= +x<br> +> wallet software instead. (the malleability problems people see are<br> +> closely related to inability to handle double-spends and reorgs) But I= +<br> +> can easily see that being an impossible goal engineering wise...<br> +><br> +> --<br> +> 'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank= +">petertodd.org</a><br> +> 0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1<br> +><br> +> ----------------------------------------------------------------------= +--------<br> +> Managing the Performance of Cloud-Based Applications<br> +> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.= +<br> +> Read the Whitepaper.<br> +> <a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121051231&a= +mp;iu=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.ne= +t/gampad/clk?id=3D121051231&iu=3D/4140/ostg.clktrk</a><br> +> _______________________________________________<br> +> Bitcoin-development mailing list<br> +> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D= +"_blank">Bitcoin-development@lists.sourceforge.net</a><br> +> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo= +pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco= +in-development</a><br> +><br> +<br> +---------------------------------------------------------------------------= +---<br> +Android apps run on BlackBerry 10<br> +Introducing the new BlackBerry 10.2.1 Runtime for Android apps.<br> +Now with support for Jelly Bean, Bluetooth, Mapview and more.<br> +Get your Android app in front of a whole new audience. =A0Start now.<br> +<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&iu= +=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam= +pad/clk?id=3D124407151&iu=3D/4140/ostg.clktrk</a><br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= +nk">Bitcoin-development@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +</blockquote></div> +</div></div><br>-----------------------------------------------------------= +-------------------<br> +Android apps run on BlackBerry 10<br> +Introducing the new BlackBerry 10.2.1 Runtime for Android apps.<br> +Now with support for Jelly Bean, Bluetooth, Mapview and more.<br> +Get your Android app in front of a whole new audience. =A0Start now.<br> +<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&iu= +=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam= +pad/clk?id=3D124407151&iu=3D/4140/ostg.clktrk</a><br>__________________= +_____________________________<br> + +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +<br></blockquote></div><br></div> + +--001a11c37f5a39b17504f238334c-- + + |