diff options
| author | Russell O'Connor <roconnor@blockstream.io> | 2017-10-01 15:05:38 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-10-01 19:06:01 +0000 |
| commit | e47daa97c4a255c384db9528cb4743480d912857 (patch) | |
| tree | a438bb1278b10ad320c67d7478834a8e434dcfca | |
| parent | 998ba0bca7aa2c7a9d93896633720c76c8e75adf (diff) | |
| download | pi-bitcoindev-e47daa97c4a255c384db9528cb4743480d912857.tar.gz pi-bitcoindev-e47daa97c4a255c384db9528cb4743480d912857.zip | |
Re: [bitcoin-dev] Version 1 witness programs (first draft)
| -rw-r--r-- | ff/0102c294fd57ff90217a8a4089cb9700187f49 | 212 |
1 files changed, 212 insertions, 0 deletions
diff --git a/ff/0102c294fd57ff90217a8a4089cb9700187f49 b/ff/0102c294fd57ff90217a8a4089cb9700187f49 new file mode 100644 index 000000000..c5be7a121 --- /dev/null +++ b/ff/0102c294fd57ff90217a8a4089cb9700187f49 @@ -0,0 +1,212 @@ +Return-Path: <roconnor@blockstream.io> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 354311BB + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 1 Oct 2017 19:06:01 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com + [209.85.217.179]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 24E951AE + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 1 Oct 2017 19:06:00 +0000 (UTC) +Received: by mail-ua0-f179.google.com with SMTP id b34so2212260uab.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 01 Oct 2017 12:06:00 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=blockstream-io.20150623.gappssmtp.com; s=20150623; + h=mime-version:in-reply-to:references:from:date:message-id:subject:to + :cc; bh=udfWgMikJ3sebgGUNJycpjYlrVxydQTQ38Kfpy9WNeM=; + b=1SfxneSdvzPyd9lAS9o+OE3GZjA3ZAzSjU3eQVpaVoqAzP69kgaYfsxOHFdt3LU8Wg + 0QGEI6MO5/j5rPvVzmnt8h6CxPG9ST/KXJwnLxuRw3bbx7ujLIC1sM+M+kS834tOQYxd + 5H//59gR1HpovyPQMx0UPlo7BU11GWf0JPNf0trWS0Z1VaYuDdam7s65Nb8appaSAt81 + jl85nXkUdudtfaZvpACsZWLn9f6t/PZMjLS/jaSvwWq7/SksmFQZPvNv0pHf+9Cw1nw4 + vp9va3s84Ao6yDdp27IRKFBpv61UESMclcSZs6HqaVVhpi16hiksAswCx6kuyQDOniSA + E7NA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:in-reply-to:references:from:date + :message-id:subject:to:cc; + bh=udfWgMikJ3sebgGUNJycpjYlrVxydQTQ38Kfpy9WNeM=; + b=d2mtyBe1m62CKVS5yx2hhV+65VzoM64nDptmmxAp1JR5MAjG4z6oVFugaRtQYiwPag + 4p/E68WahNYXZDRiyrNJAeBEUo89BezjBR1t/1CH6D5kYrmF5pLlLOQeJjYjpuAxXHS4 + 2AdNCiZ67xdJnlHpGEfJ3RkxgfhcQTSr4EaojhdYPiWosg1oYBebCLg7IMsZCME22I2e + ILiuwqUnbNdTkNlYnushjwvjKgE4odrh+XSDIYLMQ3M4NQA71o0wijIHRQe2KkdeECWt + gfPCP/hKZGXsQKQ/iebEeHJvwPviAy1PfRkmmH9p6gfFsliTipT/7NCQS2oiaGKt/nXN + PNnQ== +X-Gm-Message-State: AHPjjUhswdSd/XSURR1BqSF9azQmeG3Us5egZeEdZjecLhn/6xHHdOdE + 6Wc+AMcb+lxAmaBJiFdJSExGkAeDYMU1MW38RlQdlg== +X-Google-Smtp-Source: AOwi7QCa5JreJDsVUCbiBIo+KzLBShAL1WsV0nAJOzbtkEDS5tBT/ZyIvxDIcPp+p+INhdcVXIDzIUbPeBj5ePJvtMI= +X-Received: by 10.159.37.201 with SMTP id 67mr7742333uaf.59.1506884759128; + Sun, 01 Oct 2017 12:05:59 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.159.41.161 with HTTP; Sun, 1 Oct 2017 12:05:38 -0700 (PDT) +In-Reply-To: <D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org> +References: <201710010113.30518.luke@dashjr.org> + <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org> + <201710010247.42180.luke@dashjr.org> + <D811BF0D-8286-4A40-A443-09147E4EADDD@friedenbach.org> +From: "Russell O'Connor" <roconnor@blockstream.io> +Date: Sun, 1 Oct 2017 15:05:38 -0400 +Message-ID: <CAMZUoK=1fZUeKkA6V2pFwqj-Fd-YnZD4sffP9yc0Y7vv8-XvhQ@mail.gmail.com> +To: Mark Friedenbach <mark@friedenbach.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="001a113c4f3cc92a39055a80f209" +X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, + HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft) +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 01 Oct 2017 19:06:01 -0000 + +--001a113c4f3cc92a39055a80f209 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Given the proposed fixed signature size, It seems better to me that we +create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH. + +Mark, you seem to be arguing that in general we still want weight +malleability even with witness depth fixed, but I don't understand in what +scenario we would want that. + +It strikes me that is most scenarios all parties signing an input would do +so after an execution path through the script has been agreed upon by all +parties, in which case the witness weight can be fixed. +In rare cases where the smart contract requires that some parties sign in +advance of the decision about the execution path (for example, I'm thinking +about delegation here, but I want to keep my remarks general), we wouldn't +want to fix the witness depth either. + +A SIGHASH_WITNESS_WEIGHT would prevent all possible malleability that would +modify the transaction's fee/weight priority (at least for that one input), +and greatly reduce the overall attack surface of witness malleability +issues. + +On Sun, Oct 1, 2017 at 1:04 AM, Mark Friedenbach via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Clean stack should be eliminated for other possible future uses, the most +> obvious of which is recursive tail-call for general computation capabilit= +y. +> I=E2=80=99m not arguing for that at this time, just arguing that we shoul= +dn=E2=80=99t +> prematurely cut off an easy implementation of such should we want to. Cle= +an +> stack must still exist as policy for future soft-fork safety, but being a +> consensus requirement was only to avoid witness malleability, which +> committing to the size of the witness also accomplishes. +> +> Committing to the number of witness elements is fully sufficient, and +> using the number of elements avoids problems of not knowing the actual si= +ze +> in bytes at the time of signing, e.g. because the witness contains a merk= +le +> proof generated by another party from an unbalanced tree, and unbalanced +> trees are expected to be common (so that elements can be placed higher in +> the tree in accordance with their higher expected probability of usage). +> Other future extensions might also have variable-length proofs. +> +> > On Sep 30, 2017, at 7:47 PM, Luke Dashjr <luke@dashjr.org> wrote: +> > +> > Should it perhaps commit to the length of the serialised witness data +> instead +> > or additionally? Now that signatures are no longer variable-length, +> that'd be +> > possible... +> > +> > As far as tail-call needs are concerned, CLEANSTACK wouldn't have been +> checked +> > until AFTER the tail-call in the first draft. But I suppose eliminating +> it for +> > other possible future purposes is still useful. +> > +> > Luke +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--001a113c4f3cc92a39055a80f209 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Given the proposed fixed signature size, It seems bet= +ter to me that we create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHAS= +H_WITNESS_DEPTH.<br></div><div><br></div><div>Mark, you seem to be arguing = +that in general we still want weight malleability even with witness depth f= +ixed, but I don't understand in what scenario we would want that.</div>= +<div><br></div><div>It strikes me that is most scenarios all parties signin= +g an input would do so after an execution path through the script has been = +agreed upon by all parties, in which case the witness weight can be fixed.<= +/div><div>In rare cases where the smart contract requires that some parties= + sign in advance of the decision about the execution path (for example, I&#= +39;m thinking about delegation here, but I want to keep my remarks general)= +, we wouldn't want to fix the witness depth either.</div><div><br></div= +><div>A SIGHASH_WITNESS_WEIGHT would prevent all possible malleability that= + would modify the transaction's fee/weight priority (at least for that = +one input), and greatly reduce the overall attack surface of witness mallea= +bility issues.<br></div><div><div><div class=3D"gmail_extra"><br><div class= +=3D"gmail_quote">On Sun, Oct 1, 2017 at 1:04 AM, Mark Friedenbach via bitco= +in-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfound= +ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>><= +/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Clean st= +ack should be eliminated for other possible future uses, the most obvious o= +f which is recursive tail-call for general computation capability. I=E2=80= +=99m not arguing for that at this time, just arguing that we shouldn=E2=80= +=99t prematurely cut off an easy implementation of such should we want to. = +Clean stack must still exist as policy for future soft-fork safety, but bei= +ng a consensus requirement was only to avoid witness malleability, which co= +mmitting to the size of the witness also accomplishes.<br> +<br> +Committing to the number of witness elements is fully sufficient, and using= + the number of elements avoids problems of not knowing the actual size in b= +ytes at the time of signing, e.g. because the witness contains a merkle pro= +of generated by another party from an unbalanced tree, and unbalanced trees= + are expected to be common (so that elements can be placed higher in the tr= +ee in accordance with their higher expected probability of usage). Other fu= +ture extensions might also have variable-length proofs.<br> +<span class=3D"gmail-im gmail-HOEnZb"><br> +> On Sep 30, 2017, at 7:47 PM, Luke Dashjr <<a href=3D"mailto:luke@da= +shjr.org">luke@dashjr.org</a>> wrote:<br> +><br> +> Should it perhaps commit to the length of the serialised witness data = +instead<br> +> or additionally? Now that signatures are no longer variable-length, th= +at'd be<br> +> possible...<br> +><br> +> As far as tail-call needs are concerned, CLEANSTACK wouldn't have = +been checked<br> +> until AFTER the tail-call in the first draft. But I suppose eliminatin= +g it for<br> +> other possible future purposes is still useful.<br> +><br> +> Luke<br> +<br> +</span><div class=3D"gmail-HOEnZb"><div class=3D"gmail-h5">________________= +______________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +</div></div></blockquote></div><br></div></div></div></div> + +--001a113c4f3cc92a39055a80f209-- + |