path: root/73/2974e0ca65407ff6a1ce6fed33898317e69229

Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9F6D2DE1;
	Sun,  6 Oct 2019 07:03:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com
	[209.85.166.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1AFF6604;
	Sun,  6 Oct 2019 07:03:20 +0000 (UTC)
Received: by mail-io1-f50.google.com with SMTP id q1so22203701ion.1;
	Sun, 06 Oct 2019 00:03:20 -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=7JlFEt9N4y++N7gDlE9to1FKtajy6dy1pH0PeLhwGQc=;
	b=HKfw7jhY5HvlMBmHxbE2vfT1quJ8kuEw/f+jw/6JH5+SlkRI6rdf99lCkL5mmftbqp
	6okpq8DRInFWaiuLhJpcQtgB9UkEi2i/iP0mpRmHrqW1UQnRrGg5ye7UkRV1EwZJ+DX2
	cVyJOU3x6GRt+aGvSnlW0A9/+l/GpshuPMFY81nVjTVy/uQ1x0rl8fIwC9n3uQfjuoET
	d1B/TMoed5tPTtryCRqb+bRk8jqvZoDvvEiDtEzKGDc8ppBgytlhRTBMMRABzCbEPhHv
	EhJoseTbbaBl2Llpn2mQvzT2GizzWufwQEHiUJPSG1BG8DbW+30LX0xxPsypC3d+/GEn
	aHww==
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=7JlFEt9N4y++N7gDlE9to1FKtajy6dy1pH0PeLhwGQc=;
	b=H6W9q/MZ43ppbzEnvmwIUfcPi/x1QISf+UJu0EwjXJ6abI/jWRRAX8ac9ET+zX84TP
	TNua+8+NWiFbvj1hUkolD/3B3+0JJLhVCEegVUv5Cmm6KbUUSxNHSrq76Dg5HvcluOaW
	AGNoUX8+6CCwX0FX6tA104Q3OJqrhqpTG2M1Lv8tQYg0YzBDvTUaiB0pLK2xTr/fTjrQ
	qv4lzNTwtEpJ3jAKCCCibSrnltg4r683xVRIUt4AK2TdsdAzRIOuaF53iE1ya+ZyWc1k
	7gWe7vnRit04ISCPEnXz6xDQm4R03vSCZpCIQTo+XryxMcoCLyAjo0WcyV2moLy/Qlpj
	EK6A==
X-Gm-Message-State: APjAAAVQYOymT4Fcc0a6CIaAHfoBzD9GIG3BSPJtxXWvyUBQ4UDiUzwq
	k3rxTeIHGb6P6ppfUyKrMB33gS/j+7iTUXNXRQk=
X-Google-Smtp-Source: APXvYqx9NmIRby4/kJMD0CjW+L+G9zrOPkkc2F1xChhrA9PcdeWZ5u+7fFsHNmYFh+rEchvmv2zcDjFLwfAa2oEUt4E=
X-Received: by 2002:a02:b09c:: with SMTP id v28mr22325815jah.137.1570345399086;
	Sun, 06 Oct 2019 00:03:19 -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>
In-Reply-To: <CAEM=y+XbP3Dn7X8rHu7h0vbX6DkKA0vFK5nQqzcJ_V+D4EVMmw@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Sun, 6 Oct 2019 10:02:52 +0300
Message-ID: <CAH5Bsr1DP-7bEUYVhffCmNXjxTb2KJLASQd6NTz8O9P9OpSKCQ@mail.gmail.com>
To: Ethan Heilman <eth3rs@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000aff45505943887be"
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,
	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: Sun, 06 Oct 2019 07:56:48 +0000
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: Sun, 06 Oct 2019 07:03:21 -0000

--000000000000aff45505943887be
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Thread,

I made a reply to the OP but didn't "reply all" so it just went directly to
Ethan. Since the comments were interesting I'll attempt to salvage them by
posting them in full:

=3D=3D Lloyd's post =3D=3D
Hi Ethan,

I'd be interested to know what protocols you need OP_CAT for. I'm trying to
figure out if there really exists any script based protocol that doesn't
have a more efficient scriptless counterpart.  For example,
A=C2=B2L[1] achieves the same thing as Tumblebit but requires no script. I =
can
imagine paying based on a merkle path could be useful, but a protocol was
recently suggested on lightning-dev [2] that does this but without OP_CAT
(and without any script!).


[1] https://eprint.iacr.org/2019/589.pdf
[2]
https://www.mail-archive.com/lightning-dev@lists.linuxfoundation.org/msg014=
27.html
(*I linked to the wrong thread in the original email*).

LL

=3D=3D Ethan's response =3D=3D
Hi Lloyd,

Thanks for your response. I am not sure if you intended to take this off
list or not.

I plan to at some point to enumerate in detail protocols that OP_CAT would
benefit. A more important point is that OP_CAT is a basic building block
and that we don't know what future protocols it would allow. In my own
research I have avoiding going down certain paths because it isn't worth
the time to investigate knowing that OP_CAT wouldn't make the protocol
practical.

In regards to scriptless scripts they almost always require an interactive
protocol and sometimes ZKPs. A2L is very impressive but like TumbleBit it
places a large burden on the developer. Additionally I am aware of no way
to reveal a subset of preimages with scriptless scripts, do a conditioned
reveal i.e. these preimages can only spend under these two pubkeys and
timelockA where after timelockZ this other pubkey can spend without a
preimages. Scriptless scripts are a fantastic tool but they shouldn't be
the only tool that we have.

I'm not sure I follow what you are saying with [2]

This brings me back a philosophical point:
Bitcoin should give people basic tools to build protocols without first
knowing what all those protocols are especially when those tools have very
little downside.

I really appreciate your comments.

Thanks,
Ethan
=3D=3D

*Back to normal thread*

Hi Ethan,

Thanks for the insightful reply and sorry for my mailing list errors.

> I plan to at some point to enumerate in detail protocols that OP_CAT
would benefit.

Sweet. Thanks.

> Additionally I am aware of no way to reveal a subset of preimages with
scriptless scripts, do a conditioned reveal i.e. these preimages can only
spend under these two pubkeys and timelockA where after timelockZ this
other pubkey can spend without a preimages. Scriptless scripts are a
fantastic tool but they shouldn't be the only tool that we have.

Yes. With adaptor signatures there is no way to reveal more than one
pre-image; you are limited to revealing a single scalar. But you can have
multiple transactions spending from the same output, each with a different
set of scriptless conditions (absolute time locks, relative time locks and
pre-image reveal). This is enough to achieve what I think you are
describing. FWIW there's a growing consensus that you can do lightning
without script [1]. Perhaps we can't do everything with this technique. My
current focus is figuring out what useful things we can't do like this
(even if we were to go wild and add whatever opcodes we wanted). So far it
looks like covenants are the main exception.

> I'm not sure I follow what you are saying with [2]

That is perfectly understandable as I linked the wrong thread (sorry!).
Here's the right one:
https://www.mail-archive.com/lightning-dev@lists.linuxfoundation.org/msg014=
27.html

I was pointing to the surprising result that you can actually pay for a
merkle path with a particular merkle root leading to a particular leaf that
you're interested in without validating the merkle path on chain (e.g.
OP_CAT and OP_SHA256). The catch is that the leaves have to be pedersen
commitments and you prove the existence of your data in the merkle root by
showing an opening to the leaf pedersen commitment. This may not be general
enough to cover every merkle tree use case (but I'm not sure what those
are!).

> This brings me back a philosophical point:
> Bitcoin should give people basic tools to build protocols without first
knowing what all those protocols are especially when those tools have very
little downside.

This is a really powerful idea. But I've started feeling like you have to
just design the layer 2 protocols first and then design layer 1! It seems
like almost every protocol that people want to make requires very
particular fundamental changes: SegWit for LN-penalty and NOINPUT for eltoo
for example. On top of that it seems like just having the right signature
scheme (schnorr) at layer 1 is enough to enable most useful stuff in an
elegant way.

[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/0173=
09.html

Cheers,

LL

On Fri, Oct 4, 2019 at 1:08 AM Ethan Heilman <eth3rs@gmail.com> wrote:

> 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
> <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 retaine=
d
> 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 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 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 th=
e
> 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
>

--000000000000aff45505943887be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Thread,</div><div><br></div>I made a reply to the =
OP but didn&#39;t &quot;reply all&quot; so it just went directly to Ethan. =
Since the comments were interesting I&#39;ll attempt to salvage them by pos=
ting them in full:<div><br></div><div>=3D=3D Lloyd&#39;s post =3D=3D</div><=
div>Hi Ethan,<div><br></div><div>I&#39;d be interested to know what protoco=
ls you need OP_CAT for. I&#39;m trying to figure out if there really exists=
 any script based protocol that doesn&#39;t have a more efficient scriptles=
s counterpart.=C2=A0 For example, A=C2=B2L[1]=C2=A0achieves=C2=A0the same t=
hing as Tumblebit but requires no script. I can imagine paying based on a m=
erkle path could be useful, but a protocol was recently suggested on lightn=
ing-dev [2] that does this but without OP_CAT (and without any script!).</d=
iv><div><div><br></div><div></div><div><br></div><div>[1]=C2=A0<a href=3D"h=
ttps://eprint.iacr.org/2019/589.pdf" target=3D"_blank">https://eprint.iacr.=
org/2019/589.pdf</a></div><div>[2] <a href=3D"https://www.mail-archive.com/=
lightning-dev@lists.linuxfoundation.org/msg01427.html">https://www.mail-arc=
hive.com/lightning-dev@lists.linuxfoundation.org/msg01427.html</a> (*I link=
ed to the wrong thread in the original email*).</div><div><br></div><div>LL=
</div></div></div><div><br></div><div>=3D=3D Ethan&#39;s response =3D=3D</d=
iv><div>Hi Lloyd,<br><br>Thanks for your response. I am not sure if you int=
ended to take this off list or not.<br><br>I plan to at some point to enume=
rate in detail protocols that OP_CAT would benefit. A more important point =
is that OP_CAT is a basic building block and that we don&#39;t know what fu=
ture protocols it would allow. In my own research I have avoiding going dow=
n certain paths because it isn&#39;t worth the time to investigate knowing =
that OP_CAT wouldn&#39;t make the protocol practical.<br><br>In regards to =
scriptless scripts they almost always require an interactive protocol and s=
ometimes ZKPs. A2L is very impressive but like TumbleBit it places a large =
burden on the developer. Additionally I am aware of no way to reveal a subs=
et of preimages with scriptless scripts, do a conditioned reveal i.e. these=
 preimages can only spend under these two pubkeys and timelockA where after=
 timelockZ this other pubkey can spend without a preimages. Scriptless scri=
pts are a fantastic tool but they shouldn&#39;t be the only tool that we ha=
ve.<br><br>I&#39;m not sure I follow what you are saying with [2]<br><br>Th=
is brings me back a philosophical point:<br>Bitcoin should give people basi=
c tools to build protocols without first knowing what all those protocols a=
re especially when those tools have very little downside.<br><br>I really a=
ppreciate your comments.<br><br>Thanks,<br>Ethan<br></div><div>=3D=3D</div>=
<div><br></div><div>*Back to normal thread*</div><div><br></div><div>Hi Eth=
an,</div><div><br></div><div>Thanks for the insightful reply and sorry for =
my mailing list errors.</div><div><br></div><div>&gt; I plan to at some poi=
nt to enumerate in detail protocols that OP_CAT would benefit.</div><div><b=
r></div><div>Sweet. Thanks.</div><div><br></div><div>&gt; Additionally I am=
 aware of no way to reveal a subset of preimages with scriptless scripts, d=
o a conditioned reveal i.e. these preimages can only spend under these two =
pubkeys and timelockA where after timelockZ this other pubkey can spend wit=
hout a preimages. Scriptless scripts are a fantastic tool but they shouldn&=
#39;t be the only tool that we have.</div><div><br></div><div>Yes. With ada=
ptor signatures there is no way to reveal more than one pre-image; you are =
limited to revealing a single scalar. But you can have multiple transaction=
s spending from the same output, each with a different set of scriptless co=
nditions (absolute time locks, relative time locks and pre-image reveal). T=
his is enough to achieve what I think you are describing. FWIW there&#39;s =
a growing consensus that you can do lightning without script [1]. Perhaps w=
e can&#39;t do everything with this technique. My current focus is figuring=
 out what useful things we can&#39;t do like this (even if we were to go wi=
ld and add whatever opcodes we wanted). So far it looks like covenants are =
the main exception.</div><div><br></div><div>&gt; I&#39;m not sure I follow=
 what you are saying with [2]</div><div><br></div><div>That is perfectly un=
derstandable as I linked the wrong thread (sorry!). Here&#39;s the right on=
e:=C2=A0<a href=3D"https://www.mail-archive.com/lightning-dev@lists.linuxfo=
undation.org/msg01427.html">https://www.mail-archive.com/lightning-dev@list=
s.linuxfoundation.org/msg01427.html</a></div><div><br></div><div>I was poin=
ting to the surprising result that you can actually pay for a merkle path w=
ith a particular merkle root leading to a particular leaf that you&#39;re i=
nterested in without validating the merkle path on chain (e.g. OP_CAT and O=
P_SHA256). The catch is that the leaves have to be pedersen commitments and=
 you prove the existence of your data in the merkle root by showing an open=
ing to the leaf pedersen commitment. This may not be general enough to cove=
r every merkle tree use case (but I&#39;m not sure what those are!).</div><=
div><br></div><div>&gt; This brings me back a philosophical point:<br>&gt; =
Bitcoin should give people basic tools to build protocols without first kno=
wing what all those protocols are especially when those tools have very lit=
tle downside.<br><br></div><div>This is a really powerful idea. But I&#39;v=
e started feeling like you have to just design the layer 2 protocols first =
and then design layer 1! It seems like almost every protocol that people wa=
nt to make requires very particular fundamental changes: SegWit for LN-pena=
lty  and NOINPUT for eltoo for example. On top of that it seems like just h=
aving the right signature scheme (schnorr) at layer 1 is enough to enable m=
ost useful stuff in an elegant way.</div><div><br></div><div>[1]=C2=A0<a hr=
ef=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Septembe=
r/017309.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermai=
l/bitcoin-dev/2019-September/017309.html</a></div><div><br></div><div>Cheer=
s,</div><div><br></div><div>LL</div></div><div dir=3D"ltr"></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Oct 4, 2=
019 at 1:08 AM Ethan Heilman &lt;<a href=3D"mailto:eth3rs@gmail.com" target=
=3D"_blank">eth3rs@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">To avoid derailing the NO_INPUT conversation, I=
 have changed the<br>
subject to OP_CAT.<br>
<br>
Responding to:<br>
&quot;&quot;&quot;<br>
* `SIGHASH` flags attached to signatures are a misdesign, sadly<br>
retained from the original BitCoin 0.1.0 Alpha for Windows design, on<br>
par with:<br>
[..]<br>
* `OP_CAT` and `OP_MULT` and `OP_ADD` and friends<br>
[..]<br>
&quot;&quot;&quot;<br>
<br>
OP_CAT is an extremely valuable op code. I understand why it was<br>
removed as the situation at the time with scripts was dire. However<br>
most of the protocols I&#39;ve wanted to build on Bitcoin run into the<br>
limitation that stack values can not be concatenated. For instance<br>
TumbleBit would have far smaller transaction sizes if OP_CAT was<br>
supported in Bitcoin. If it happens to me as a researcher it is<br>
probably holding other people back as well. If I could wave a magic<br>
wand and turn on one of the disabled op codes it would be OP_CAT.=C2=A0 Of<=
br>
course with the change that size of each concatenated value must be 64<br>
Bytes or less.<br>
<br>
<br>
On Tue, Oct 1, 2019 at 10:04 PM ZmnSCPxj via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Good morning lists,<br>
&gt;<br>
&gt; Let me propose the below radical idea:<br>
&gt;<br>
&gt; * `SIGHASH` flags attached to signatures are a misdesign, sadly retain=
ed from the original BitCoin 0.1.0 Alpha for Windows design, on par with:<b=
r>
&gt;=C2=A0 =C2=A0* 1 RETURN<br>
&gt;=C2=A0 =C2=A0* higher-`nSequence` replacement<br>
&gt;=C2=A0 =C2=A0* DER-encoded pubkeys<br>
&gt;=C2=A0 =C2=A0* unrestricted `scriptPubKey`<br>
&gt;=C2=A0 =C2=A0* Payee-security-paid-by-payer (i.e. lack of P2SH)<br>
&gt;=C2=A0 =C2=A0* `OP_CAT` and `OP_MULT` and `OP_ADD` and friends<br>
&gt;=C2=A0 =C2=A0* transaction malleability<br>
&gt;=C2=A0 =C2=A0* probably many more<br>
&gt;<br>
&gt; So let me propose the more radical excision, starting with SegWit v1:<=
br>
&gt;<br>
&gt; * Remove `SIGHASH` from signatures.<br>
&gt; * Put `SIGHASH` on public keys.<br>
&gt;<br>
&gt; 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).<br>
&gt; `OP_CHECKSIG` and friends then look at the *public key* to determine s=
ighash algorithm rather than the signature.<br>
&gt;<br>
&gt; As we expect public keys to be indirectly committed to on every output=
 `scriptPubKey`, this is automatically output tagging to allow particular `=
SIGHASH`.<br>
&gt; However, we can then utilize the many many ways to hide public keys aw=
ay until they are needed, exemplified in MAST-inside-Taproot.<br>
&gt;<br>
&gt; I propose also the addition of the opcode:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;sighash&gt; &lt;pubkey&gt; OP_SETPUBKEYSIGHASH<=
br>
&gt;<br>
&gt; * `sighash` must be one byte.<br>
&gt; * `pubkey` may be the special byte `0x1`, meaning &quot;just use the T=
aproot internal pubkey&quot;.<br>
&gt; * `pubkey` may be 33-byte public key, in which case the `sighash` byte=
 is just prepended to it.<br>
&gt; * `pubkey` may be 34-byte public key with sighash, in which case the f=
irst byte is replaced with `sighash` byte.<br>
&gt; * If `sighash` is `0x00` then the result is a 33-byte public key (the =
sighash byte is removed) i.e. `SIGHASH_ALL` implicit.<br>
&gt;<br>
&gt; This retains the old feature where the sighash is selected at time-of-=
spending rather than time-of-payment.<br>
&gt; This is done by using the script:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;pubkey&gt; OP_SETPUBKEYSIGHASH OP_CHECKSIG<br>
&gt;<br>
&gt; 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.<br>
&gt; This is malleability-safe as the signature still commits to the `SIGHA=
SH` it was created for.<br>
&gt;<br>
&gt; However, by default, public keys will not have an attached `SIGHASH` b=
yte, implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).=
<br>
&gt;<br>
&gt; This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as the=
y are allowed only if the output specifically says they are allowed.<br>
&gt;<br>
&gt; Would this not be a superior solution?<br>
&gt;<br>
&gt; Regards,<br>
&gt; ZmnSCPxj<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/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.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>

--000000000000aff45505943887be--