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 145601028; Thu, 3 Oct 2019 15:06:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93A1B19B; Thu, 3 Oct 2019 15:06:30 +0000 (UTC) Received: by mail-pl1-f177.google.com with SMTP id u20so1662916plq.4; Thu, 03 Oct 2019 08:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Emj6sK+VwQQIMdbafYSaKH3m3nbTNVtpA8pddr5OOI=; b=gZiHg11iGbWQ98k9gw4GI7CnBNWnkW1+LdW4QC+xjudy8Ff9q0K+p1B4mpWoymPs+6 DCfceG159PZyA4WE+3Sr8xYTfJsWTa/d9hvKNWDSf/GThct3DWWKuMp+RVtSdso7fU5t +vHZW8INBmsDBvaR4Sg4JJY9gkgUuU1lDXB/qZuFdulFsRQe8fLEob4f09BNn9OImABG JW2IOIRluN4j+gbYQ3NT5lXGVAc5XQNXLUqTH38+oUJdmEAoUL5/6JItJneNgLsx6i4q 5QDJwh42Eic0pbfZcGV+dOB5p5KXo44RCw+T/jCorMw4oSYxPM9PTPa1fCOcQFy/u3u0 +m8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Emj6sK+VwQQIMdbafYSaKH3m3nbTNVtpA8pddr5OOI=; b=FRkc4rQHp6SESJEr/fC59pOFqUPO4uHr02q0oN0HJegxNYDMng/cpw8+3gP4b+0wTN NTaugzoXWlFk5GWhYNWAnDw7aaA8hZekaQiQIwe6TpDVfkMdtCp6tPiJrJOpuDLn+qig 4bJlLaZBo/9FDpfDGmj7SJUXBEmYqYnGtSW8KW5uMbcDo22xvobA8t3SUOjwsIQtaaqp YT8LPnofph7DLC8gsOWWHxXYfOT0RzVRdCsYq+tlFudBBcEFaJRXSss3OSrOzsVoL+xL 5sdJIZ9O5iB+pbZKz+eihOUVD9EdmmpS2IeJ+xzCm4xCh0+KQOtqIpThghtOLZ9s7+gi u/6w== X-Gm-Message-State: APjAAAXrLITBOZ86TqlEzWj54TaJg5nlX5/TyZM2pC/bABmuciYIOh7E fzW5OhtFOW8TUqsOaLhR1Ypm5Eh/NIEoZEkJ3+31TOuPTwQ= X-Google-Smtp-Source: APXvYqxnjx8o4o1Se+uh8mTpFGwXap31thSMX2JLCjvUpZBltJ2EGvD9gIF4HfBlEghhZ1EtkXfnSjuVXBpTVAllcg8= X-Received: by 2002:a17:902:9349:: with SMTP id g9mr9707543plp.71.1570115189457; Thu, 03 Oct 2019 08:06:29 -0700 (PDT) MIME-Version: 1.0 References: <87wodp7w9f.fsf@gmail.com> <20191001155929.e2yznsetqesx2jxo@erisian.com.au> In-Reply-To: From: Ethan Heilman Date: Thu, 3 Oct 2019 11:05:52 -0400 Message-ID: To: ZmnSCPxj via bitcoin-dev Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM, 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 Cc: "lightning-dev@lists.linuxfoundation.org" Subject: [bitcoin-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 15:06:31 -0000 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. On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev 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: > > 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: > > 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