From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5DBB11144
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <eth3rs@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <C1OLL5FLxdOgfQ_A15mf88wIyztDapkyXJ2HZ0HxwmQADhRXGRe3le7Veso4tMIlbis6I0qiCd22xug5_GCKtgrjGnBtojWxOCMgn1UldkE=@protonmail.com>
In-Reply-To: <CAEM=y+XbP3Dn7X8rHu7h0vbX6DkKA0vFK5nQqzcJ_V+D4EVMmw@mail.gmail.com>
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>
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 <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: 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:
> >
> >     <sighash> <pubkey> 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:
> >
> >     <pubkey> 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