MIME-Version: 1.0
In-Reply-To: <87sh73fe4h.fsf@gmail.com>
References: <871sewirni.fsf@gmail.com> <87sh73fe4h.fsf@gmail.com>
From: Bram Cohen <bram@chia.net>
Date: Mon, 7 May 2018 13:51:11 -0700
Message-ID: <CAHUJnBCBp2kPh+4_XmrX==b8t0zFTydWYHiJQzVbVApkbeCC8A@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000786ec5056ba3d4c0"
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP sighash_noinput
Precedence: list

--000000000000786ec5056ba3d4c0
Content-Type: text/plain; charset="UTF-8"

A technical point about SIGHASH_NOINPUT: It seems like a more general and
technically simpler to implement idea would be to have a boolean specifying
whether the inputs listed must be all of them (the way it works normally)
or a subset of everything. It feels like a similar boolean should be made
for outputs as well. Or maybe a single boolean should apply to both. In any
case, one could always use SIGHASH_SUBSET and not specify any inputs and
that would have the same effect as SIGHASH_NOINPUT.

On Mon, May 7, 2018 at 12:40 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Given the general enthusiasm, and lack of major criticism, for the
> `SIGHASH_NOINPUT` proposal, I'd like to formally ask the BBEs (benevolent
> BIP editors) to be assigned a BIP number. I have hacked together a
> simple implementation of the hashing implementation in Bitcoin Core [1]
> though I think it's unlikely to sail through review, and given the lack
> of ground-work on witness V1 scripts, I can't really test it now, and
> only the second commit is part of the implementation itself.
>
> One issue that was raised off list was that some fork coins have used
> sighash 0x40 as FORKID. This does not conflict with this proposal since
> the proposal only applies to segwit transactions, which the fork coins
> have explicitly disabled :-)
>
> I'm looking forward to discussing how to we can move forward to
> implementing this proposal, and how we can combine multiple proposals
> into the next soft-fork.
>
> Cheers,
> Christian
>
> [1] https://github.com/cdecker/bitcoin/tree/noinput
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">A technical point about SIGHASH_NOINPUT: It seems like a m=
ore general and technically simpler to implement idea would be to have a bo=
olean specifying whether the inputs listed must be all of them (the way it =
works normally) or a subset of everything. It feels like a similar boolean =
should be made for outputs as well. Or maybe a single boolean should apply =
to both. In any case, one could always use SIGHASH_SUBSET and not specify a=
ny inputs and that would have the same effect as SIGHASH_NOINPUT.</div><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, May 7, 2018 a=
t 12:40 PM, Christian Decker via bitcoin-dev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Given the general enthusiasm, and lack of major criticism, fo=
r the<br>
`SIGHASH_NOINPUT` proposal, I&#39;d like to formally ask the BBEs (benevole=
nt<br>
BIP editors) to be assigned a BIP number. I have hacked together a<br>
simple implementation of the hashing implementation in Bitcoin Core [1]<br>
though I think it&#39;s unlikely to sail through review, and given the lack=
<br>
of ground-work on witness V1 scripts, I can&#39;t really test it now, and<b=
r>
only the second commit is part of the implementation itself.<br>
<br>
One issue that was raised off list was that some fork coins have used<br>
sighash 0x40 as FORKID. This does not conflict with this proposal since<br>
the proposal only applies to segwit transactions, which the fork coins<br>
have explicitly disabled :-)<br>
<br>
I&#39;m looking forward to discussing how to we can move forward to<br>
implementing this proposal, and how we can combine multiple proposals<br>
into the next soft-fork.<br>
<br>
Cheers,<br>
Christian<br>
<br>
[1] <a href=3D"https://github.com/cdecker/bitcoin/tree/noinput" rel=3D"nore=
ferrer" target=3D"_blank">https://github.com/cdecker/<wbr>bitcoin/tree/noin=
put</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--000000000000786ec5056ba3d4c0--