diff options
| author | Stephen Morse <stephencalebmorse@gmail.com> | 2015-04-25 11:40:37 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-04-25 15:40:45 +0000 |
| commit | 18d3c8d4a0ebc096b677f6c5633945566b34bd42 (patch) | |
| tree | ccb21d7d1f4c2854d9c7a172ddbd8e39755dc84c | |
| parent | 247a3dd466b411ab3330a2106ab63b6e16cd6b7d (diff) | |
| download | pi-bitcoindev-18d3c8d4a0ebc096b677f6c5633945566b34bd42.tar.gz pi-bitcoindev-18d3c8d4a0ebc096b677f6c5633945566b34bd42.zip | |
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
| -rw-r--r-- | 79/0c02b28629c1d4dd5a097a3b61cebb33d10aa5 | 167 |
1 files changed, 167 insertions, 0 deletions
diff --git a/79/0c02b28629c1d4dd5a097a3b61cebb33d10aa5 b/79/0c02b28629c1d4dd5a097a3b61cebb33d10aa5 new file mode 100644 index 000000000..00783bf9d --- /dev/null +++ b/79/0c02b28629c1d4dd5a097a3b61cebb33d10aa5 @@ -0,0 +1,167 @@ +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 <stephencalebmorse@gmail.com>) id 1Ym2CD-0007sD-Ab + for bitcoin-development@lists.sourceforge.net; + Sat, 25 Apr 2015 15:40:45 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.212.195 as permitted sender) + client-ip=209.85.212.195; + envelope-from=stephencalebmorse@gmail.com; + helo=mail-wi0-f195.google.com; +Received: from mail-wi0-f195.google.com ([209.85.212.195]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Ym2CB-0005x5-5B + for bitcoin-development@lists.sourceforge.net; + Sat, 25 Apr 2015 15:40:45 +0000 +Received: by wivr20 with SMTP id r20so6208039wiv.3 + for <bitcoin-development@lists.sourceforge.net>; + Sat, 25 Apr 2015 08:40:37 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.180.102.74 with SMTP id fm10mr6105056wib.25.1429976437155; + Sat, 25 Apr 2015 08:40:37 -0700 (PDT) +Received: by 10.194.185.68 with HTTP; Sat, 25 Apr 2015 08:40:37 -0700 (PDT) +In-Reply-To: <CAAS2fgSay0DqeWXfZwX-sN71sLHdRLD51PBmnJfJ5+TC0BQ8zg@mail.gmail.com> +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> + <CAAS2fgSay0DqeWXfZwX-sN71sLHdRLD51PBmnJfJ5+TC0BQ8zg@mail.gmail.com> +Date: Sat, 25 Apr 2015 11:40:37 -0400 +Message-ID: <CABHVRKS0EYV0CqKW1MVtUZC3u4KvSxMB=Uks9UrCUBQbozO9xQ@mail.gmail.com> +From: Stephen Morse <stephencalebmorse@gmail.com> +To: Gregory Maxwell <gmaxwell@gmail.com> +Content-Type: multipart/alternative; boundary=f46d0444812b92eb3805148e5573 +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 + (stephencalebmorse[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: 1Ym2CB-0005x5-5B +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: Sat, 25 Apr 2015 15:40:45 -0000 + +--f46d0444812b92eb3805148e5573 +Content-Type: text/plain; charset=UTF-8 + +Hi Gregory, + +In particular not covering the ID allows for transaction replay which +> can result in monetary losses far more severe than any possible +> mishandling of malleability could result in. Byzantine attackers can +> costlessly replay your old transactions any time anyone reuses an +> address, even accidentally (which cannot be easily prevented since +> they can race). +> + +With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly +specify that they are to be signed without the previous UTXO's +value/amount. This means that, at worst, replay attacks can send the money +to the same place it was sent before (which in many cases is likely not be +a loss of funds), and only if the amount sent to the reused address is the +exact same as it was before. I don't think this is worse than an attacker +being able to mutate their transaction and extort a merchant who accepts +zero-conf transactions. Anyway, not signing the input ID wouldn't exactly +be the norm, there would be a defined set of flags for standard use cases. +Not signing the input TXID would only be used in specialized cases, such as +setting up micropayment channels. + + +> There are no free lunches; the proposal linked to there is itself a +> game of wack-a-mole with assorted masking flags; + + +I agree that it is also a bit of wac-a-mole, but the defined space of +issues is possibly more limited here. There are only X number of things +that can be signed/not signed in a transaction, and the 'Build your own +nHashType' proposal enables you to fully specify which of those are being +signed. If you don't want to get burned by not fully signing your +transactions, then don't use the non-standard sighash flags. + +many of which we have +> no notion of if they're useful for any particular application(s); + + +A few of the flags, indeed, may not ever be useful. But we can't predict +the future, and I think it's better to build in a more flexible solution +now than to wish we had more flexible nHashTypes later. + +To the original point of this thread, hopefully the suggested proposal +won't be necessary as wallets will upgrade to use version 3 transactions +and the rules associated with them over time. + +Best, +Stephen + +--f46d0444812b92eb3805148e5573 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Gregory,<br><div class=3D"gmail_extra"><br><div class= +=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l= +eft-style:solid;padding-left:1ex">In particular not covering the ID allows = +for transaction replay which<br> +can result in monetary losses far more severe than any possible<br> +mishandling of malleability could result in. Byzantine attackers can<br> +costlessly replay your old transactions any time anyone reuses an<br> +address, even accidentally (which cannot be easily prevented since<br> +they can race).<br></blockquote><div><br></div>With the SIGHASH_WITHOUT_PRE= +V_VALUE flag, signatures have to explicitly specify that they are to be sig= +ned without the previous UTXO's value/amount. This means that, at worst= +, replay attacks can send the money to the same place it was sent before (w= +hich in many cases is likely not be a loss of funds), and only if the amoun= +t sent to the reused address is the exact same as it was before. I don'= +t think this is worse than an attacker being able to mutate their transacti= +on and extort a merchant who accepts zero-conf transactions. Anyway, not si= +gning the input ID wouldn't exactly be the norm, there would be a defin= +ed set of flags for standard use cases. Not signing the input TXID would on= +ly be used in specialized cases, such as setting up micropayment channels.= +=C2=A0<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p= +x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo= +rder-left-style:solid;padding-left:1ex">There are no free lunches;=C2=A0 th= +e proposal linked to there is itself a<br> +game of wack-a-mole with assorted masking flags; </blockquote><div><br></di= +v><div>I agree that it is also a bit of wac-a-mole, but the defined space o= +f issues is possibly more limited here. There are only X number of things t= +hat can be signed/not signed in a transaction, and the 'Build your own = +nHashType' proposal enables you to fully specify which of those are bei= +ng signed. If you don't want to get burned by not fully signing your tr= +ansactions, then don't use the non-standard sighash flags.</div><div><b= +r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= +;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style= +:solid;padding-left:1ex">many of which we have<br> +no notion of if they're useful for any particular application(s); </blo= +ckquote><div><br></div><div>A few of the flags, indeed, may not ever be use= +ful. But we can't predict the future, and I think it's better to bu= +ild in a more flexible solution now than to wish we had more flexible nHash= +Types later.</div><div><br></div><div>To the original point of this thread,= + hopefully the suggested proposal won't be necessary as wallets will up= +grade to use version 3 transactions and the rules associated with them over= + time.=C2=A0</div><div><br></div><div>Best,</div><div>Stephen</div></div></= +div></div> + +--f46d0444812b92eb3805148e5573-- + + |