path: root/44/f36dbb45d08e890942eba4e935b5bd000164a8

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A59F5AD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 May 2018 16:58:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f54.google.com (mail-it0-f54.google.com
	[209.85.214.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A46592C4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 May 2018 16:58:58 +0000 (UTC)
Received: by mail-it0-f54.google.com with SMTP id j186-v6so13792896ita.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 01 May 2018 09:58:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream.io; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=qKGZTS8iKuMJUHFr1OhR93XoZW2vhNmVsI3fCSmB5Es=;
	b=LXbZzJKZ6PCydyTakAULKhPpD6tNyQsvUo1+J7OyQ3T601GtLo/aXONCXJjqIbwJPw
	d2tkpF3NPoJM/I7QfYTmMU/VGFGFsL8uWT+jWwv6owIXNtSUy8+qWsPLVo/1qlVmSr8E
	rdg3pzN1klwsqeE6xH7ZwC1VjZKKTUxQ7YzrY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=qKGZTS8iKuMJUHFr1OhR93XoZW2vhNmVsI3fCSmB5Es=;
	b=noTYXjgNmDb05fE8DJ9glrYKchxc5Hwrhm4ek7+gViW0ceKqFtMUvGdL9V68DjHdo1
	bBIrB1+xMst5AjA1BaNa4cR0EU25XDYp0uYC55Iaqujcb5uGUCj2UXqsAVWVfh8MzP7l
	b0Tv0JCDjSndogks4AiFZpj86G0rET4Y3kyg+gciudSy5QdruJxwOWU+tMfRsLb3b/4N
	lOawxVOAFmaL7xKLL03tzyQiRAVkimTqWlcT3GhqRq88CrzSDxCY9hSQMbYFTYT0TT86
	R2ts6OLTxhZWY9ZIOaj5bko8RBd+JCt9NHK0+HG05mPpQq3e4/UFg2EGTnuVTSpuaOEm
	Y/rw==
X-Gm-Message-State: ALQs6tBZTyA8hMFZaBqZQCT1PeXveHyjrJVqIKaLYlOBOfkR/6ahOJLs
	umbrJbcF9od3tAUJUzb5zBP2/1PaIFEn26qWydoCaA==
X-Google-Smtp-Source: AB8JxZqDTmsFuqll2LXvSG8rw/bmReWGj8OQMWxV7Y5mOqpA/D/l4rlR0Pf4jvaYMfhOcaQyvl43mljg1RyoSqpZiqY=
X-Received: by 2002:a24:ad1e:: with SMTP id
	c30-v6mr16302928itf.38.1525193937949; 
	Tue, 01 May 2018 09:58:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:1086:0:0:0:0:0 with HTTP;
	Tue, 1 May 2018 09:58:37 -0700 (PDT)
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"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, 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
Subject: Re: [bitcoin-dev] BIP sighash_noinput
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: Tue, 01 May 2018 16:58:59 -0000

--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--