MIME-Version: 1.0
In-Reply-To: <871sewirni.fsf@gmail.com>
References: <871sewirni.fsf@gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Tue, 1 May 2018 12:58:37 -0400
Message-ID: <CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e2b3a6056b27e2be"
Subject: Re: [bitcoin-dev] BIP sighash_noinput
Precedence: list

--000000000000e2b3a6056b27e2be
Content-Type: text/plain; charset="UTF-8"

At the risk of bikeshedding, shouldn't NOINPUT also zero out the
hashSequence so that its behaviour is consistent with ANYONECANPAY?

On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
> previous
> output. This was previously mentioned on the list by Joseph Poon [1], but
> was
> never formally proposed, so I wrote a proposal [2].
>
> We have long known that `SIGHASH_NOINPUT` would be a great fit for
> Lightning.
> They enable simple watch-towers, i.e., outsource the need to watch the
> blockchain for channel closures, and react appropriately if our
> counterparty
> misbehaves. In addition to this we just released the eltoo [3,4] paper
> which
> describes a simplified update mechanism that can be used in Lightning, and
> other
> off-chain contracts, with any number of participants.
>
> By not committing to the previous output being spent by the transaction,
> we can
> rebind an input to point to any outpoint with a matching output script and
> value. The binding therefore is no longer explicit through a reference, but
> through script compatibility, and the transaction ID reference in the
> input is a
> hint to validators. The sighash flag is meant to enable some off-chain
> use-cases
> and should not be used unless the tradeoffs are well-known. In particular
> we
> suggest using contract specific key-pairs, in order to avoid having any
> unwanted
> rebinding opportunities.
>
> The proposal is very minimalistic, and simple. However, there are a few
> things
> where we'd like to hear the input of the wider community with regards to
> the
> implementation details though. We had some discussions internally on
> whether to
> use a separate opcode or a sighash flag, some feeling that the sighash flag
> could lead to some confusion with existing wallets, but given that we have
> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
> flags, we decided to go the sighash way. Another thing is that we still
> commit
> to the amount of the outpoint being spent. The rationale behind this is
> that,
> while rebinding to outpoints with the same value maintains the value
> relationship between input and output, we will probably not want to bind to
> something with a different value and suddenly pay a gigantic fee.
>
> The deployment part of the proposal is left vague on purpose in order not
> to
> collide with any other proposals. It should be possible to introduce it by
> bumping the segwit script version and adding the new behavior.
>
> I hope the proposal is well received, and I'm looking forward to discussing
> variants and tradeoffs here. I think the applications we proposed so far
> are
> quite interesting, and I'm sure there are many more we can enable with this
> change.
>
> Cheers,
> Christian
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-February/012460.html
> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [4] https://blockstream.com/eltoo.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">At the risk of bikeshedding, shouldn&#39;t NOINPUT also ze=
ro out the hashSequence so that its behaviour is consistent with ANYONECANP=
AY?<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On M=
on, Apr 30, 2018 at 12:29 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:1p=
x #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I&#39;d like to pick up the discussion from a few months ago, and propose a=
 new<br>
sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previou=
s<br>
output. This was previously mentioned on the list by Joseph Poon [1], but w=
as<br>
never formally proposed, so I wrote a proposal [2].<br>
<br>
We have long known that `SIGHASH_NOINPUT` would be a great fit for Lightnin=
g.<br>
They enable simple watch-towers, i.e., outsource the need to watch the<br>
blockchain for channel closures, and react appropriately if our counterpart=
y<br>
misbehaves. In addition to this we just released the eltoo [3,4] paper whic=
h<br>
describes a simplified update mechanism that can be used in Lightning, and =
other<br>
off-chain contracts, with any number of participants.<br>
<br>
By not committing to the previous output being spent by the transaction, we=
 can<br>
rebind an input to point to any outpoint with a matching output script and<=
br>
value. The binding therefore is no longer explicit through a reference, but=
<br>
through script compatibility, and the transaction ID reference in the input=
 is a<br>
hint to validators. The sighash flag is meant to enable some off-chain use-=
cases<br>
and should not be used unless the tradeoffs are well-known. In particular w=
e<br>
suggest using contract specific key-pairs, in order to avoid having any unw=
anted<br>
rebinding opportunities.<br>
<br>
The proposal is very minimalistic, and simple. However, there are a few thi=
ngs<br>
where we&#39;d like to hear the input of the wider community with regards t=
o the<br>
implementation details though. We had some discussions internally on whethe=
r to<br>
use a separate opcode or a sighash flag, some feeling that the sighash flag=
<br>
could lead to some confusion with existing wallets, but given that we have<=
br>
`SIGHASH_NONE`, and that existing wallets will not sign things with unknown=
<br>
flags, we decided to go the sighash way. Another thing is that we still com=
mit<br>
to the amount of the outpoint being spent. The rationale behind this is tha=
t,<br>
while rebinding to outpoints with the same value maintains the value<br>
relationship between input and output, we will probably not want to bind to=
<br>
something with a different value and suddenly pay a gigantic fee.<br>
<br>
The deployment part of the proposal is left vague on purpose in order not t=
o<br>
collide with any other proposals. It should be possible to introduce it by<=
br>
bumping the segwit script version and adding the new behavior.<br>
<br>
I hope the proposal is well received, and I&#39;m looking forward to discus=
sing<br>
variants and tradeoffs here. I think the applications we proposed so far ar=
e<br>
quite interesting, and I&#39;m sure there are many more we can enable with =
this<br>
change.<br>
<br>
Cheers,<br>
Christian<br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016=
-February/012460.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2016-February/012460.htm=
l</a><br>
[2] <a href=3D"https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawi=
ki" rel=3D"noreferrer" target=3D"_blank">https://github.com/cdecker/<wbr>bi=
ps/blob/noinput/bip-xyz.<wbr>mediawiki</a><br>
[3] <a href=3D"https://blockstream.com/2018/04/30/eltoo-next-lightning.html=
" rel=3D"noreferrer" target=3D"_blank">https://blockstream.com/2018/<wbr>04=
/30/eltoo-next-lightning.<wbr>html</a><br>
[4] <a href=3D"https://blockstream.com/eltoo.pdf" rel=3D"noreferrer" target=
=3D"_blank">https://blockstream.com/eltoo.<wbr>pdf</a><br>
______________________________<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>
</blockquote></div><br></div>

--000000000000e2b3a6056b27e2be--