diff options
| author | Bram Cohen <bram@chia.net> | 2018-03-21 17:47:01 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-03-22 00:47:05 +0000 |
| commit | fa773867b11c6b48f337cc2d486b54beb0bc6a8f (patch) | |
| tree | 880d7fc47ab9609d35174e8fc01789263f4626c5 | |
| parent | 4a24eca02b83be4e93fec9489d24e27f7ca4dd92 (diff) | |
| download | pi-bitcoindev-fa773867b11c6b48f337cc2d486b54beb0bc6a8f.tar.gz pi-bitcoindev-fa773867b11c6b48f337cc2d486b54beb0bc6a8f.zip | |
Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation
| -rw-r--r-- | 47/917ae8be62c6310c9f97afaadfff2bcf39e94a | 172 |
1 files changed, 172 insertions, 0 deletions
diff --git a/47/917ae8be62c6310c9f97afaadfff2bcf39e94a b/47/917ae8be62c6310c9f97afaadfff2bcf39e94a new file mode 100644 index 000000000..9d9d6b5de --- /dev/null +++ b/47/917ae8be62c6310c9f97afaadfff2bcf39e94a @@ -0,0 +1,172 @@ +Return-Path: <bram@chia.net> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A6FC12C9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 22 Mar 2018 00:47:05 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 34588624 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 22 Mar 2018 00:47:04 +0000 (UTC) +Received: by mail-wm0-f51.google.com with SMTP id t7so12898186wmh.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 21 Mar 2018 17:47:04 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=chia-net.20150623.gappssmtp.com; s=20150623; + h=mime-version:from:date:message-id:subject:to; + bh=TDqPZNbgdpbH0xBHxIrY6o2IcvBJ8fzozAsQUR0/ECY=; + b=EtXNGJ1O9FY6w0mY+w69t0jNLu15sj+uSkRUAOYVj0EOP66MJcyZO2V1Zhiske5gKG + PBoJF8mGWbCSSGhyKsP3TFu36BVnTivHXso9PXKrdt+wuvzWCq/P8r+4+ou4qBGON8QC + tW3TMdjvVJetlHJxw0BEMP9sN7KOljosgGz+qvzhbTmEZu/JaDMHjH8bdT3koQQhd5LA + j0xedQ7pKg5Thw1DJTeSFGV418uTDuCuO6FVWs5fe7bnbt52EHS0C4803Lae9CwmGSqh + KAJUQZFGQh/4bULHuzqNqNtcTXMeCC0AjqgaYbz27jR9DoVhzeXwh7Pi4jmeCCnYVu1p + giFw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:from:date:message-id:subject:to; + bh=TDqPZNbgdpbH0xBHxIrY6o2IcvBJ8fzozAsQUR0/ECY=; + b=dOq3XqNVtEsIU8fx6XJLLpIQIVbdCfYWURpnLCccwnuBoRrRVc8whibUiyRP38kDV4 + f0nDKPapzFWHYOH1Y7pk8YRToTv1is6wPQmt4GApIl/92NC23SNA7eggOSwKnoEG0Ex0 + 9hkty+vxmVI04NoRur56deWp6oHxP+H635gDZFxvsVwiugHlskqGibWNgvn+oJUQpLKI + snPZnnkBA5ouBYbcB9tlWfFQZ+ZQgGBPTdbDxVAl/w3NtfheIKdt1OXF/zCawjwsUT+y + P4rUEtefKh1MXkYrztawj+uyeZ5C6+lhJU7V36fuSkTLqXaucJcFV0cv2EENeEcZpy8Z + lRNg== +X-Gm-Message-State: AElRT7FQJJicw2+wWiag2f/aScA/Aff5yC9UFY44MeLOF/vL/dvgg8FE + jjGZAJyidIfgHVWrisxkz6XiLDPzBuPdSF0e6nCDz1K9 +X-Google-Smtp-Source: AG47ELsI0JBeqozLofCrkcizRAiYSdKf8CrEgzq+k+LKO9al+38EhhOuOeYdMxkbyLUaZfdX6Vniz9xOVnvIkCuDllM= +X-Received: by 10.28.125.84 with SMTP id y81mr4083914wmc.66.1521679622355; + Wed, 21 Mar 2018 17:47:02 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.28.29.78 with HTTP; Wed, 21 Mar 2018 17:47:01 -0700 (PDT) +X-Originating-IP: [65.204.128.202] +From: Bram Cohen <bram@chia.net> +Date: Wed, 21 Mar 2018 17:47:01 -0700 +Message-ID: <CAHUJnBAQwLfmvLyApcw8dKz1u8xX1KmdjiUmzSHXyw7npWUXHQ@mail.gmail.com> +To: bitcoin-dev@lists.linuxfoundation.org +Content-Type: multipart/alternative; boundary="001a1141d7005a4f520567f5a554" +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Thu, 22 Mar 2018 01:45:31 +0000 +Subject: Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation +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: Thu, 22 Mar 2018 00:47:05 -0000 + +--001a1141d7005a4f520567f5a554 +Content-Type: text/plain; charset="UTF-8" + +Regarding the proposed segwit v2 with reclaiming most things as +RETURN_VALID, the net result for what's being proposed in the near future +for supporting aggregated signatures in the not-so-near future is to punt. +A number of strategies are possible for how to deal with new opcodes being +added later on, and the general strategy of making unused opcodes be +RETURN_VALID for now and figuring out how to handle it later works for all +of them. I think this is the right approach, but wanted to clarify that it +is in fact the approach being proposed. + +That said, there are some subtleties to getting it right which the last +message doesn't really cover. Most unused opcodes should be reclaimed as +RETURN_VALID, but there should still be one OP_NOP and there should be a +'real' RETURN_VALID, which (a) is guaranteed to not be soft forked into +something else in the future, and (b) doesn't have any parsing weirdness. +The parsing weirdness of all the unclaimed opcodes is interesting. Because +everything in an IF clause needs to be parsed in order to find where the +ELSE is, you have a few options for dealing with an unknown opcode getting +parsed in an unexecuted section of code. They are (a) avoid the problem +completely by exterminating IF and MASTing (b) avoid the problem completely +by getting rid of IF and adding IFJUMP, IFNJUMP, and JUMP which specify a +number of bytes (this also allows for script merkleization) (c) require all +new opcodes have fixed length 1, even after they're soft forked, (d) do +almost like (c) but require that on new soft forks people hack their old +scripts to still parse properly by avoiding the OP_ELSE in inopportune +places (yuck!) (e) make it so that the unknown opcodes case a RETURN_VALID +even when they're parsed, regardless of whether they're being executed. + +By far the most expedient option is (e) cause a RETURN_VALID at parse time. +There's even precedent for this sort of behavior in the other direction +with disabled opcodes causing failure at parse time even if they aren't +being executed. + +A lot can be said about all the options, but one thing I feel like snarking +about is that if you get rid of IFs using MAST, then it's highly unclear +whether OP_DEPTH should be nuked as well. My feeling is that it should and +that strict parsing should require that the bottom thing in the witness +gets referenced at some point. + +Hacking in a multisig opcode isn't a horrible idea, but it is very stuck +specifically on m-of-n and doesn't support more complex formulas for how +signatures can be combined, which makes it feel hacky and weird. + +Also it may make sense to seriously consider BLS signatures, which have a +lot of practical benefits starting with them being noninteractively +aggregatable so you can always assume that they're aggregated instead of +requiring complex semantics to specify what's aggregated with what. My team +is working on an implementation which has several advantages over what's +currently in the published literature but it isn't quite ready for public +consumption yet. This should probably go on the pile of reasons why it's +premature to finalize a plan for aggregation at this point. + +--001a1141d7005a4f520567f5a554 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Regarding the proposed segwit v2 with reclaiming most thin= +gs as RETURN_VALID, the net result for what's being proposed in the nea= +r future for supporting aggregated signatures in the not-so-near future is = +to punt. A number of strategies are possible for how to deal with new opcod= +es being added later on, and the general strategy of making unused opcodes = +be RETURN_VALID for now and figuring out how to handle it later works for a= +ll of them. I think this is the right approach, but wanted to clarify that = +it is in fact the approach being proposed.<div><br></div><div>That said, th= +ere are some subtleties to getting it right which the last message doesn= +9;t really cover. Most unused opcodes should be reclaimed as RETURN_VALID, = +but there should still be one OP_NOP and there should be a 'real' R= +ETURN_VALID, which (a) is guaranteed to not be soft forked into something e= +lse in the future, and (b) doesn't have any parsing weirdness. The pars= +ing weirdness of all the unclaimed opcodes is interesting. Because everythi= +ng in an IF clause needs to be parsed in order to find where the ELSE is, y= +ou have a few options for dealing with an unknown opcode getting parsed in = +an unexecuted section of code. They are (a) avoid the problem completely by= + exterminating IF and MASTing (b) avoid the problem completely by getting r= +id of IF and adding IFJUMP, IFNJUMP, and JUMP which specify a number of byt= +es (this also allows for script merkleization) (c) require all new opcodes = +have fixed length 1, even after they're soft forked, (d) do almost like= + (c) but require that on new soft forks people hack their old scripts to st= +ill parse properly by avoiding the OP_ELSE in inopportune places (yuck!) (e= +) make it so that the unknown opcodes case a RETURN_VALID even when they= +9;re parsed, regardless of whether they're being executed.</div><div><b= +r></div><div>By far the most expedient option is (e) cause a RETURN_VALID a= +t parse time. There's even precedent for this sort of behavior in the o= +ther direction with disabled opcodes causing failure at parse time even if = +they aren't being executed.</div><div><br></div><div>A lot can be said = +about all the options, but one thing I feel like snarking about is that if = +you get rid of IFs using MAST, then it's highly unclear whether OP_DEPT= +H should be nuked as well. My feeling is that it should and that strict par= +sing should require that the bottom thing in the witness gets referenced at= + some point.</div><div><br></div><div>Hacking in a multisig opcode isn'= +t a horrible idea, but it is very stuck specifically on m-of-n and doesn= +9;t support more complex formulas for how signatures can be combined, which= + makes it feel hacky and weird.</div><div><br></div><div>Also it may make s= +ense to seriously consider BLS signatures, which have a lot of practical be= +nefits starting with them being noninteractively aggregatable so you can al= +ways assume that they're aggregated instead of requiring complex semant= +ics to specify what's aggregated with what. My team is working on an im= +plementation which has several advantages over what's currently in the = +published literature but it isn't quite ready for public consumption ye= +t. This should probably go on the pile of reasons why it's premature to= + finalize a plan for aggregation at this point.</div><div><br></div></div> + +--001a1141d7005a4f520567f5a554-- + |