From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5DBB11144 for ; Thu, 3 Oct 2019 23:42:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D8261FB for ; Thu, 3 Oct 2019 23:42:35 +0000 (UTC) Date: Thu, 03 Oct 2019 23:42:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1570146153; bh=QDtnOywM+wzIMuRS9fmxqmC1ebYlUQpElHyG8Oa9W6s=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=QE5rU4597eOObm3zoB5BOFJuhSDTJTSEUcRsd25c/PMtGQ4tnwFIVBf15FFJQVAkG 5xxxhQnKL2A2FkFcEQwGcYVKFNXw8k2lEd0zJxavzNnjkt1fv8FB/flCm6hedudZVp AP4sfHSFBfXUt0WmvvdSvbv6gghA23XidEh8upM0= To: Ethan Heilman From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <87wodp7w9f.fsf@gmail.com> <20191001155929.e2yznsetqesx2jxo@erisian.com.au> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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 , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 23:42:36 -0000 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 6= 4 > Bytes or less. Why 64 bytes in particular? It seems obvious to me that this 64 bytes is most suited for building Merkl= e 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 th= e 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 le= aves, 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 o= nly 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 retai= ned 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 c= oordinate). > > `OP_CHECKSIG` and friends then look at the public key to determine sigh= ash 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 `S= IGHASH`. > > However, we can then utilize the many many ways to hide public keys awa= y until they are needed, exemplified in MAST-inside-Taproot. > > I propose also the addition of the opcode: > > > > OP_SETPUBKEYSIGHASH > > > > > > - `sighash` must be one byte. > > - `pubkey` may be the special byte `0x1`, meaning "just use the Tapro= ot internal pubkey". > > - `pubkey` may be 33-byte public key, in which case the `sighash` byt= e 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-s= pending rather than time-of-payment. > > This is done by using the script: > > > > OP_SETPUBKEYSIGHASH OP_CHECKSIG > > > > > > Then the sighash can be put in the witness stack after the signature, l= etting the `SIGHASH` flag be selected at time-of-signing, but only if the S= CRIPT specifically is formed to do so. > > This is malleability-safe as the signature still commits to the `SIGHAS= H` it was created for. > > However, by default, public keys will not have an attached `SIGHASH` by= te, 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