Return-Path: <jlrubin@mit.edu> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BC6AFD0A; Fri, 4 Oct 2019 18:33:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB5308BB; Fri, 4 Oct 2019 18:33:22 +0000 (UTC) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x94IXKqv028848 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 4 Oct 2019 14:33:21 -0400 Received: by mail-io1-f44.google.com with SMTP id z19so15743409ior.0; Fri, 04 Oct 2019 11:33:21 -0700 (PDT) X-Gm-Message-State: APjAAAUGowNjQZANtRRyZzZGieHY+fegnDcktHaxPvDUS6mcVki6rdu1 mznftwrIt6GrV8HUCv2BN2bw9d2IOcYp7ZVZVK4= X-Google-Smtp-Source: APXvYqw1ZRbAjY3NH1JsmkUmk7a0d9ve1v9PQmKRHNiCOAm2AsrDrw0droZ2WyO3yKanKHxSSkGVgo0wLkY3ndzM56s= X-Received: by 2002:a6b:c382:: with SMTP id t124mr2121770iof.105.1570214000448; Fri, 04 Oct 2019 11:33:20 -0700 (PDT) MIME-Version: 1.0 References: <87wodp7w9f.fsf@gmail.com> <20191001155929.e2yznsetqesx2jxo@erisian.com.au> <CR-etCjXB-JWkvecjDog4Pkq1SuLUgndtSrZo-V4f4EGcNXzNCeAHRvCZGrxDWw7aHVdDY0pAF92jNLb_Hct0bMb3ew6JEpB9AfIm1tSGaQ=@protonmail.com> <CAEM=y+XbP3Dn7X8rHu7h0vbX6DkKA0vFK5nQqzcJ_V+D4EVMmw@mail.gmail.com> <C1OLL5FLxdOgfQ_A15mf88wIyztDapkyXJ2HZ0HxwmQADhRXGRe3le7Veso4tMIlbis6I0qiCd22xug5_GCKtgrjGnBtojWxOCMgn1UldkE=@protonmail.com> <CAEM=y+WCGSF_=WXpgXJUZCZcGUQhxzXF6Wv1_iX+VwEyYSWypg@mail.gmail.com> <CAD5xwhi7=5eiv1jjf72-rUezZMfj3caR+PGfZEa8i8rjNjodFg@mail.gmail.com> <NVDIhcpuRV6VduUgfMNyGSU1U24ErWPuxpA07fMkIIgXqxEL2aX1_oYJ189Wf5ZigGDBa860gJ-p8d3iAMAWsjHx-5tZHZLjXr7gEmQbL0c=@protonmail.com> In-Reply-To: <NVDIhcpuRV6VduUgfMNyGSU1U24ErWPuxpA07fMkIIgXqxEL2aX1_oYJ189Wf5ZigGDBa860gJ-p8d3iAMAWsjHx-5tZHZLjXr7gEmQbL0c=@protonmail.com> From: Jeremy <jlrubin@mit.edu> Date: Fri, 4 Oct 2019 11:33:09 -0700 X-Gmail-Original-Message-ID: <CAD5xwhh_WbpSvou7sORjG9JeVonU8UR3qR0Bc9cmhp5sep34OA@mail.gmail.com> Message-ID: <CAD5xwhh_WbpSvou7sORjG9JeVonU8UR3qR0Bc9cmhp5sep34OA@mail.gmail.com> To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Content-Type: multipart/alternative; boundary="000000000000b7dbbf059419efb4" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>, "lightning-dev@lists.linuxfoundation.org" <lightning-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout 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: Fri, 04 Oct 2019 18:33:24 -0000 --000000000000b7dbbf059419efb4 Content-Type: text/plain; charset="UTF-8" Good point -- in our discussion, we called it OP_FFS -- Fold Functional Stream, and it could be initialized with a different integer to select for different functions. Therefore the stream processing opcodes would be generic, but extensible. -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Fri, Oct 4, 2019 at 12:00 AM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Jeremy, > > > Awhile back, Ethan and I discussed having, rather than OP_CAT, an > OP_SHA256STREAM that uses the streaming properties of a SHA256 hash > function to allow concatenation of an unlimited amount of data, provided > the only use is to hash it. > > > > You can then use it perhaps as follows: > > > > // start a new hash with item > > OP_SHA256STREAM (-1) -> [state] > > // Add item to the hash in state > > OP_SHA256STREAM n [item] [state] -> [state] > > // Finalize > > OP_SHA256STREAM (-2) [state] -> [Hash] > > > > <-1> OP_SHA256STREAM <tag> <subnode 2> <subnode 3> <3> OP_SHA256STREAM > <-2> OP_SHA256STREAM > > > > Or it coul > > > > This seems a good idea. > > Though it brings up the age-old tension between: > > * Generically-useable components, but due to generalization are less > efficient. > * Specific-use components, which are efficient, but which may end up not > being useable in the future. > > In particular, `OP_SHA256STREAM` would no longer be useable if SHA256 > eventually is broken, while the `OP_CAT` will still be useable in the > indefinite future. > In the future a new hash function can simply be defined and the same > technique with `OP_CAT` would still be useable. > > > Regards, > ZmnSCPxj > > > -- > > @JeremyRubin > > > > On Thu, Oct 3, 2019 at 8:04 PM Ethan Heilman <eth3rs@gmail.com> wrote: > > > > > I hope you are having an great afternoon ZmnSCPxj, > > > > > > You make an excellent point! > > > > > > I had thought about doing the following to tag nodes > > > > > > || means OP_CAT > > > > > > `node = SHA256(type||SHA256(data))` > > > so a subnode would be > > > `subnode1 = SHA256(1||SHA256(subnode2||subnode3))` > > > and a leaf node would be > > > `leafnode = SHA256(0||SHA256(leafdata))` > > > > > > Yet, I like your idea better. Increasing the size of the two inputs to > > > OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowable > > > size of object on the stack seems sensible and also doesn't special > > > case the logic of OP_CAT. > > > > > > It would also increase performance. SHA256(tag||subnode2||subnode3) > > > requires 2 compression function calls whereas > > > SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3 compression > > > function calls (due to padding). > > > > > > >Or we could implement tagged SHA256 as a new opcode... > > > > > > I agree that tagged SHA256 as an op code that would certainty be > > > useful, but OP_CAT provides far more utility and is a simpler change. > > > > > > Thanks, > > > Ethan > > > > > > On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> > wrote: > > > > > > > > Good morning Ethan, > > > > > > > > > > > > > To avoid derailing the NO_INPUT conversation, I have changed the > > > > > subject to OP_CAT. > > > > > > > > > > Responding to: > > > > > """ > > > > > > > > > > - `SIGHASH` flags attached to signatures are a misdesign, sadly > > > > > retained from the original BitCoin 0.1.0 Alpha for Windows > design, on > > > > > par with: > > > > > [..] > > > > > > > > > > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends > > > > > [..] > > > > > """ > > > > > > > > > > OP_CAT is an extremely valuable op code. I understand why it > was > > > > > removed as the situation at the time with scripts was dire. > However > > > > > most of the protocols I've wanted to build on Bitcoin run into > the > > > > > limitation that stack values can not be concatenated. For > instance > > > > > TumbleBit would have far smaller transaction sizes if OP_CAT > was > > > > > supported in Bitcoin. If it happens to me as a researcher it is > > > > > probably holding other people back as well. If I could wave a > magic > > > > > wand and turn on one of the disabled op codes it would be > OP_CAT. Of > > > > > course with the change that size of each concatenated value > must be 64 > > > > > Bytes or less. > > > > > > > > Why 64 bytes in particular? > > > > > > > > It seems obvious to me that this 64 bytes is most suited for > building Merkle trees, being the size of two SHA256 hashes. > > > > > > > > However we have had issues with the use of Merkle trees in Bitcoin > blocks. > > > > Specifically, it is difficult to determine if a hash on a Merkle > node is the hash of a Merkle subnode, or a leaf transaction. > > > > My understanding is that this is the reason for now requiring > transactions to be at least 80 bytes. > > > > > > > > The obvious fix would be to prepend the type of the hashed object, > i.e. add at least one byte to determine this type. > > > > Taproot for example uses tagged hash functions, with a different tag > for leaves, and tagged hashes are just > prepend-this-32-byte-constant-twice-before-you-SHA256. > > > > > > > > This seems to indicate that to check merkle tree proofs, an `OP_CAT` > with only 64 bytes max output size would not be sufficient. > > > > > > > > Or we could implement tagged SHA256 as a new opcode... > > > > > > > > Regards, > > > > ZmnSCPxj > > > > > > > > > > > > > > > > > > On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev > > > > > bitcoin-dev@lists.linuxfoundation.org wrote: > > > > > > > > > > > > > > > > Good morning lists, > > > > > > Let me propose the below radical idea: > > > > > > > > > > > > - `SIGHASH` flags attached to signatures are a misdesign, > sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on > par with: > > > > > > - 1 RETURN > > > > > > - higher-`nSequence` replacement > > > > > > - DER-encoded pubkeys > > > > > > - unrestricted `scriptPubKey` > > > > > > - Payee-security-paid-by-payer (i.e. lack of P2SH) > > > > > > - `OP_CAT` and `OP_MULT` and `OP_ADD` and friends > > > > > > - transaction malleability > > > > > > - probably many more > > > > > > > > > > > > So let me propose the more radical excision, starting with > SegWit v1: > > > > > > > > > > > > - Remove `SIGHASH` from signatures. > > > > > > - Put `SIGHASH` on public keys. > > > > > > > > > > > > Public keys are now encoded as either 33-bytes (implicit > `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type, > followed by pubkey coordinate). > > > > > > `OP_CHECKSIG` and friends then look at the public key to > determine sighash algorithm rather than the signature. > > > > > > As we expect public keys to be indirectly committed to on every > output `scriptPubKey`, this is automatically output tagging to allow > particular `SIGHASH`. > > > > > > However, we can then utilize the many many ways to hide public > keys away until they are needed, exemplified in MAST-inside-Taproot. > > > > > > I propose also the addition of the opcode: > > > > > > > > > > > > <sighash> <pubkey> OP_SETPUBKEYSIGHASH > > > > > > > > > > > > > > > > > > - `sighash` must be one byte. > > > > > > - `pubkey` may be the special byte `0x1`, meaning "just use > the Taproot internal pubkey". > > > > > > - `pubkey` may be 33-byte public key, in which case the > `sighash` byte is just prepended to it. > > > > > > - `pubkey` may be 34-byte public key with sighash, in which > case the first byte is replaced with `sighash` byte. > > > > > > - If `sighash` is `0x00` then the result is a 33-byte public > key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit. > > > > > > > > > > > > This retains the old feature where the sighash is selected at > time-of-spending rather than time-of-payment. > > > > > > This is done by using the script: > > > > > > > > > > > > <pubkey> OP_SETPUBKEYSIGHASH OP_CHECKSIG > > > > > > > > > > > > > > > > > > Then the sighash can be put in the witness stack after the > signature, letting the `SIGHASH` flag be selected at time-of-signing, but > only if the SCRIPT specifically is formed to do so. > > > > > > This is malleability-safe as the signature still commits to the > `SIGHASH` it was created for. > > > > > > However, by default, public keys will not have an attached > `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default > non-`SIGHASH_ALL`). > > > > > > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, > as they are allowed only if the output specifically says they are allowed. > > > > > > Would this not be a superior solution? > > > > > > Regards, > > > > > > ZmnSCPxj > > > > > > > > > > > > bitcoin-dev mailing list > > > > > > bitcoin-dev@lists.linuxfoundation.org > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > > > > > Lightning-dev mailing list > > > > > Lightning-dev@lists.linuxfoundation.org > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > > > > > > > > _______________________________________________ > > > Lightning-dev mailing list > > > Lightning-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > --000000000000b7dbbf059419efb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= lvetica,sans-serif;font-size:small;color:#000000">Good point -- in our disc= ussion, we called it OP_FFS -- Fold Functional Stream, and it could be init= ialized with a different integer to select for different functions. Therefo= re the stream processing opcodes would be generic, but extensible.<br clear= =3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartma= il=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.co= m/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter= .com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><br><di= v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 4= , 2019 at 12:00 AM ZmnSCPxj via Lightning-dev <<a href=3D"mailto:lightni= ng-dev@lists.linuxfoundation.org">lightning-dev@lists.linuxfoundation.org</= a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p= x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Go= od morning Jeremy,<br> <br> > Awhile back, Ethan and I discussed having, rather than OP_CAT, an OP_S= HA256STREAM that uses the streaming properties of a SHA256 hash function to= allow concatenation of an unlimited amount of data, provided the only use = is to hash it.<br> ><br> > You can then use it perhaps as follows:<br> ><br> > // start a new hash with item<br> > OP_SHA256STREAM=C2=A0 (-1) -> [state]<br> > // Add item to the hash in state<br> > OP_SHA256STREAM n [item] [state] -> [state]<br> > // Finalize<br> > OP_SHA256STREAM (-2) [state] -> [Hash]<br> ><br> > <-1> OP_SHA256STREAM <tag> <subnode 2> <subnode 3= > <3> OP_SHA256STREAM <-2> OP_SHA256STREAM<br> ><br> > Or it coul<br> ><br> <br> This seems a good idea.<br> <br> Though it brings up the age-old tension between:<br> <br> * Generically-useable components, but due to generalization are less effici= ent.<br> * Specific-use components, which are efficient, but which may end up not be= ing useable in the future.<br> <br> In particular, `OP_SHA256STREAM` would no longer be useable if SHA256 event= ually is broken, while the `OP_CAT` will still be useable in the indefinite= future.<br> In the future a new hash function can simply be defined and the same techni= que with `OP_CAT` would still be useable.<br> <br> <br> Regards,<br> ZmnSCPxj<br> <br> > --<br> > @JeremyRubin<br> ><br> > On Thu, Oct 3, 2019 at 8:04 PM Ethan Heilman <<a href=3D"mailto:eth= 3rs@gmail.com" target=3D"_blank">eth3rs@gmail.com</a>> wrote:<br> ><br> > > I hope you are having an great afternoon ZmnSCPxj,<br> > ><br> > > You make an excellent point!<br> > ><br> > > I had thought about doing the following to tag nodes<br> > ><br> > > || means OP_CAT<br> > ><br> > > `node =3D SHA256(type||SHA256(data))`<br> > > so a subnode would be<br> > > `subnode1 =3D SHA256(1||SHA256(subnode2||subnode3))`<br> > > and a leaf node would be<br> > > `leafnode =3D SHA256(0||SHA256(leafdata))`<br> > ><br> > > Yet, I like your idea better. Increasing the size of the two inpu= ts to<br> > > OP_CAT to be 260 Bytes each where 520 Bytes is the maximum allowa= ble<br> > > size of object on the stack seems sensible and also doesn't s= pecial<br> > > case the logic of OP_CAT.<br> > ><br> > > It would also increase performance. SHA256(tag||subnode2||subnode= 3)<br> > > requires 2 compression function calls whereas<br> > > SHA256(1||SHA256(subnode2||subnode3)) requires 2+1=3D3 compressio= n<br> > > function calls (due to padding).<br> > ><br> > > >Or we could implement tagged SHA256 as a new opcode...<br> > ><br> > > I agree that tagged SHA256 as an op code that would certainty be<= br> > > useful, but OP_CAT provides far more utility and is a simpler cha= nge.<br> > ><br> > > Thanks,<br> > > Ethan<br> > ><br> > > On Thu, Oct 3, 2019 at 7:42 PM ZmnSCPxj <<a href=3D"mailto:Zmn= SCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>> wro= te:<br> > > ><br> > > > Good morning Ethan,<br> > > ><br> > > ><br> > > > > To avoid derailing the NO_INPUT conversation, I have ch= anged the<br> > > > > subject to OP_CAT.<br> > > > ><br> > > > > Responding to:<br> > > > > """<br> > > > ><br> > > > > -=C2=A0 =C2=A0`SIGHASH` flags attached to signatures ar= e a misdesign, sadly<br> > > > >=C2=A0 =C2=A0 =C2=A0retained from the original BitCoin 0= .1.0 Alpha for Windows design, on<br> > > > >=C2=A0 =C2=A0 =C2=A0par with:<br> > > > >=C2=A0 =C2=A0 =C2=A0[..]<br> > > > ><br> > > > > -=C2=A0 =C2=A0`OP_CAT` and `OP_MULT` and `OP_ADD` and f= riends<br> > > > >=C2=A0 =C2=A0 =C2=A0[..]<br> > > > >=C2=A0 =C2=A0 =C2=A0"""<br> > > > ><br> > > > >=C2=A0 =C2=A0 =C2=A0OP_CAT is an extremely valuable op c= ode. I understand why it was<br> > > > >=C2=A0 =C2=A0 =C2=A0removed as the situation at the time= with scripts was dire. However<br> > > > >=C2=A0 =C2=A0 =C2=A0most of the protocols I've wante= d to build on Bitcoin run into the<br> > > > >=C2=A0 =C2=A0 =C2=A0limitation that stack values can not= be concatenated. For instance<br> > > > >=C2=A0 =C2=A0 =C2=A0TumbleBit would have far smaller tra= nsaction sizes if OP_CAT was<br> > > > >=C2=A0 =C2=A0 =C2=A0supported in Bitcoin. If it happens = to me as a researcher it is<br> > > > >=C2=A0 =C2=A0 =C2=A0probably holding other people back a= s well. If I could wave a magic<br> > > > >=C2=A0 =C2=A0 =C2=A0wand and turn on one of the disabled= op codes it would be OP_CAT. Of<br> > > > >=C2=A0 =C2=A0 =C2=A0course with the change that size of = each concatenated value must be 64<br> > > > >=C2=A0 =C2=A0 =C2=A0Bytes or less.<br> > > ><br> > > > Why 64 bytes in particular?<br> > > ><br> > > > It seems obvious to me that this 64 bytes is most suited for= building Merkle trees, being the size of two SHA256 hashes.<br> > > ><br> > > > However we have had issues with the use of Merkle trees in B= itcoin blocks.<br> > > > Specifically, it is difficult to determine if a hash on a Me= rkle node is the hash of a Merkle subnode, or a leaf transaction.<br> > > > My understanding is that this is the reason for now requirin= g transactions to be at least 80 bytes.<br> > > ><br> > > > The obvious fix would be to prepend the type of the hashed o= bject, i.e. add at least one byte to determine this type.<br> > > > Taproot for example uses tagged hash functions, with a diffe= rent tag for leaves, and tagged hashes are just prepend-this-32-byte-consta= nt-twice-before-you-SHA256.<br> > > ><br> > > > This seems to indicate that to check merkle tree proofs, an = `OP_CAT` with only 64 bytes max output size would not be sufficient.<br> > > ><br> > > > Or we could implement tagged SHA256 as a new opcode...<br> > > ><br> > > > Regards,<br> > > > ZmnSCPxj<br> > > ><br> > > ><br> > > > ><br> > > > >=C2=A0 =C2=A0 =C2=A0On Tue, Oct 1, 2019 at 10:04 PM ZmnS= CPxj via bitcoin-dev<br> > > > >=C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:bitcoin-dev@lists.= linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or= g</a> wrote:<br> > > > ><br> > > > ><br> > > > > > Good morning lists,<br> > > > > > Let me propose the below radical idea:<br> > > > > ><br> > > > > > -=C2=A0 =C2=A0`SIGHASH` flags attached to signatur= es are a misdesign, sadly retained from the original BitCoin 0.1.0 Alpha fo= r Windows design, on par with:<br> > > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A01 RETURN<br> > > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0higher-`nSequence= ` replacement<br> > > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0DER-encoded pubke= ys<br> > > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0unrestricted `scr= iptPubKey`<br> > > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0Payee-security-pa= id-by-payer (i.e. lack of P2SH)<br> > > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0`OP_CAT` and `OP_= MULT` and `OP_ADD` and friends<br> > > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0transaction malle= ability<br> > > > > >=C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0probably many mor= e<br> > > > > ><br> > > > > > So let me propose the more radical excision, start= ing with SegWit v1:<br> > > > > ><br> > > > > > -=C2=A0 =C2=A0Remove `SIGHASH` from signatures.<br= > > > > > > -=C2=A0 =C2=A0Put `SIGHASH` on public keys.<br> > > > > ><br> > > > > > Public keys are now encoded as either 33-bytes (im= plicit `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type,= followed by pubkey coordinate).<br> > > > > > `OP_CHECKSIG` and friends then look at the public = key to determine sighash algorithm rather than the signature.<br> > > > > > As we expect public keys to be indirectly committe= d to on every output `scriptPubKey`, this is automatically output tagging t= o allow particular `SIGHASH`.<br> > > > > > However, we can then utilize the many many ways to= hide public keys away until they are needed, exemplified in MAST-inside-Ta= proot.<br> > > > > > I propose also the addition of the opcode:<br> > > > > ><br> > > > > >=C2=A0 =C2=A0 =C2=A0<sighash> <pubkey> = OP_SETPUBKEYSIGHASH<br> > > > > ><br> > > > > ><br> > > > > > -=C2=A0 =C2=A0`sighash` must be one byte.<br> > > > > > -=C2=A0 =C2=A0`pubkey` may be the special byte `0x= 1`, meaning "just use the Taproot internal pubkey".<br> > > > > > -=C2=A0 =C2=A0`pubkey` may be 33-byte public key, = in which case the `sighash` byte is just prepended to it.<br> > > > > > -=C2=A0 =C2=A0`pubkey` may be 34-byte public key w= ith sighash, in which case the first byte is replaced with `sighash` byte.<= br> > > > > > -=C2=A0 =C2=A0If `sighash` is `0x00` then the resu= lt is a 33-byte public key (the sighash byte is removed) i.e. `SIGHASH_ALL`= implicit.<br> > > > > ><br> > > > > > This retains the old feature where the sighash is = selected at time-of-spending rather than time-of-payment.<br> > > > > > This is done by using the script:<br> > > > > ><br> > > > > >=C2=A0 =C2=A0 =C2=A0<pubkey> OP_SETPUBKEYSIGH= ASH OP_CHECKSIG<br> > > > > ><br> > > > > ><br> > > > > > Then the sighash can be put in the witness stack a= fter the signature, letting the `SIGHASH` flag be selected at time-of-signi= ng, but only if the SCRIPT specifically is formed to do so.<br> > > > > > This is malleability-safe as the signature still c= ommits to the `SIGHASH` it was created for.<br> > > > > > However, by default, public keys will not have an = attached `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default= non-`SIGHASH_ALL`).<br> > > > > > This removes the problems with `SIGHASH_NONE` `SIG= HASH_SINGLE`, as they are allowed only if the output specifically says they= are allowed.<br> > > > > > Would this not be a superior solution?<br> > > > > > Regards,<br> > > > > > ZmnSCPxj<br> > > > > ><br> > > > > > bitcoin-dev mailing list<br> > > > > > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio= n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> > > > > > <a href=3D"https://lists.linuxfoundation.org/mailm= an/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists= .linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> > > > ><br> > > > > Lightning-dev mailing list<br> > > > > <a href=3D"mailto:Lightning-dev@lists.linuxfoundation.o= rg" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br> > > > > <a href=3D"https://lists.linuxfoundation.org/mailman/li= stinfo/lightning-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.li= nuxfoundation.org/mailman/listinfo/lightning-dev</a><br> > > ><br> > > ><br> > > _______________________________________________<br> > > Lightning-dev mailing list<br> > > <a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target= =3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br> > > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lig= htning-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundat= ion.org/mailman/listinfo/lightning-dev</a><br> <br> <br> _______________________________________________<br> Lightning-dev mailing list<br> <a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank= ">Lightning-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev= " rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev</a><br> </blockquote></div> --000000000000b7dbbf059419efb4--