diff options
| author | Gregory Maxwell <gmaxwell@gmail.com> | 2015-04-24 20:16:57 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-04-24 20:17:06 +0000 |
| commit | 485b92b1e2d990a5526129368223ad987227c499 (patch) | |
| tree | 7e4a3d18f604bf9c4eddced67c9684aa747a203c | |
| parent | 5ccac922393c50d94afe8b0c7b7e9ea389ab1791 (diff) | |
| download | pi-bitcoindev-485b92b1e2d990a5526129368223ad987227c499.tar.gz pi-bitcoindev-485b92b1e2d990a5526129368223ad987227c499.zip | |
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
| -rw-r--r-- | 6f/38e5cb3ff7fb6bc1688006a177eccf11892aa0 | 99 |
1 files changed, 99 insertions, 0 deletions
diff --git a/6f/38e5cb3ff7fb6bc1688006a177eccf11892aa0 b/6f/38e5cb3ff7fb6bc1688006a177eccf11892aa0 new file mode 100644 index 000000000..e622640e4 --- /dev/null +++ b/6f/38e5cb3ff7fb6bc1688006a177eccf11892aa0 @@ -0,0 +1,99 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gmaxwell@gmail.com>) id 1Ylk26-00029k-LL + for bitcoin-development@lists.sourceforge.net; + Fri, 24 Apr 2015 20:17:06 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.223.171 as permitted sender) + client-ip=209.85.223.171; envelope-from=gmaxwell@gmail.com; + helo=mail-ie0-f171.google.com; +Received: from mail-ie0-f171.google.com ([209.85.223.171]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Ylk23-00015x-11 + for bitcoin-development@lists.sourceforge.net; + Fri, 24 Apr 2015 20:17:06 +0000 +Received: by iedfl3 with SMTP id fl3so103312976ied.1 + for <bitcoin-development@lists.sourceforge.net>; + Fri, 24 Apr 2015 13:16:57 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.50.12.10 with SMTP id u10mr1050523igb.8.1429906617777; Fri, + 24 Apr 2015 13:16:57 -0700 (PDT) +Received: by 10.107.15.82 with HTTP; Fri, 24 Apr 2015 13:16:57 -0700 (PDT) +In-Reply-To: <CABjHNoTeMiLWkDBUqdV4HJ=nAhj8wqOjD4cypY9Dv2y9HJWJMg@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> +Date: Fri, 24 Apr 2015 20:16:57 +0000 +Message-ID: <CAAS2fgSay0DqeWXfZwX-sN71sLHdRLD51PBmnJfJ5+TC0BQ8zg@mail.gmail.com> +From: Gregory Maxwell <gmaxwell@gmail.com> +To: William Swanson <swansontec@gmail.com> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Score: -1.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 + (gmaxwell[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + -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: 1Ylk23-00015x-11 +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: Fri, 24 Apr 2015 20:17:06 -0000 + +On Fri, Apr 24, 2015 at 7:58 PM, William Swanson <swansontec@gmail.com> wrote: +> On Thu, Apr 16, 2015 at 9:12 AM, s7r <s7r@sky-ip.org> wrote: +>> Thanks for your reply. I agree. Allen has a good point in the previous +>> email too, so the suggestion might not fix anything and complicate things. +> +> The BIP 62 approach to malleability isn't the only option. Another +> approach is to sign the transaction in such a way that the input +> txid's are allowed to change without invalidating the signatures. That +> way, if malleability happens, you just adjust you transaction to match +> and re-broadcast. That proposal is here: + +This is not a free choice. There are several concerns, from mild to +severe, that arise when you do not sign enough. + +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). + +Other fun effects also show up like being able to backwards compute +signatures to result in a kind of limited covenant- coins which can +only be spent a particular way which has some implications for +fungibility. (See here for a discussion in general of covenants: +https://bitcointalk.org/index.php?topic=278122.0) + +There are no free lunches; the proposal linked to there is itself a +game of wack-a-mole with assorted masking flags; many of which we have +no notion of if they're useful for any particular application(s); and +it doesn't provide tools to address the replay issue; and in order to +'improve' malleability via that mechanism you must always mask out the +inputs completely; meaning you'd always be exposed to replay and not +just in specialized 'contract' applications where "there won't be +address reuse" could be a strong assumption enforced by the +application. + + |