path: root/07/c4561c91aaec95aaec1782ae36f633a12a54ea

Return-Path: <desnider@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9B5FD7A8;
	Mon, 30 Apr 2018 18:26:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com
	[209.85.216.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D0E1678;
	Mon, 30 Apr 2018 18:26:13 +0000 (UTC)
Received: by mail-qt0-f174.google.com with SMTP id m5-v6so12047066qti.1;
	Mon, 30 Apr 2018 11:26:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=YQjHNzclP3wI4RiJ+yZTupMOaz2XqFGG8Krlf2A9IEw=;
	b=ByOT5j+V5ZN/e0GYTRIPShXQUDLfaUFUOn8+M/WI8FNf9bkz6HOBmEL21of3mX2AqK
	NTXCUnNknndBatUqgJf/08UGFMsPSxqj84RmYnt2JyHzjBHuuqxlf7oR2FkbcpRfYFfT
	oRXyIWlZVWtTw8yJEvnYOr79lpe5FxztT3jheXZKfAc7TG8xaXnNbq/BtJ/tQP7dsbkI
	Rrlx2RPZI1YxDEdT6XOVQzRmxMGovoaYFhYYiMweWZgRMfOpDW45c9+Iuykv+/OjwE3R
	LF2m4qd1ofLBRRYkOXh12T1pu8IA7gxJjWeqDjztq5Ce9LQeJLm1e6MRmDFE10ln0zmR
	F+HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=YQjHNzclP3wI4RiJ+yZTupMOaz2XqFGG8Krlf2A9IEw=;
	b=HjqxzZSZoF0NL3uz2MvDIY2PPupq3zCG+ImyO8FvnUzxyaEuMyp24bK0lCp2VAQoLm
	C44dyKwbtzI1Ki6pj5uc5oo7aDtOPHXwLYxlpb84WWEEVSus6hyYmbrfGn+SEnJVNjTE
	lcJswpMOCOkPQD8EdT9qNP6Yf1pkb5HGRG5bUChT5U1uSNSIhp44LBG8B6Jn7nEXSbf5
	6opgzmrxG9xud1+MbJ89r9tEVcdRHzW7vL/VNcacQXXLKVY8aW+4FL9Y12x7Arj0r0aZ
	GMevdz43cIuJJ65490Cn8q2U8UHLR86o4EGwfhJ078CKv9mcYeilkdcnsK3Lf9KE9g0C
	KkqA==
X-Gm-Message-State: ALQs6tDkbmK5C/dYPl3tQMm/+ZOTXD3Ct+AYdCrNV+y8QTu7bOuaYTP9
	fQrvRzu/InmRE1U8QCPkLCdYhdBToRicVwDjMFI=
X-Google-Smtp-Source: AB8JxZqr0XTb04toGSz76plBm1AzQEuN1stWUQbdeL0egQDcfDYDe4JRu+WeKRqvgEu9yX3yOLe2hBXCfhGT2x1mpS0=
X-Received: by 2002:a0c:f8c9:: with SMTP id
	h9-v6mr11757015qvo.122.1525112772715; 
	Mon, 30 Apr 2018 11:26:12 -0700 (PDT)
MIME-Version: 1.0
Sender: desnider@gmail.com
Received: by 10.233.239.214 with HTTP; Mon, 30 Apr 2018 11:25:42 -0700 (PDT)
In-Reply-To: <871sewirni.fsf@gmail.com>
References: <871sewirni.fsf@gmail.com>
From: Dario Sneidermanis <dariosn@gmail.com>
Date: Mon, 30 Apr 2018 15:25:42 -0300
X-Google-Sender-Auth: Qwms6WLa2NZ3w1z9JlkuUhd4Nm8
Message-ID: <CAHBM8UgvJvwHcM0jEtFzDDUGArZ=k4jUVY6ZVNEh4+2v6u5x0Q@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000f6989056b14fd67"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, 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: Mon, 30 Apr 2018 19:37:43 +0000
Cc: lightning-dev@lists.linuxfoundation.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: Mon, 30 Apr 2018 18:26:14 -0000

--0000000000000f6989056b14fd67
Content-Type: text/plain; charset="UTF-8"

Something like this might also be useful for several use cases related to
RBF. For example:

Alice sends Bob an RBF-activated transaction T1 with the intention of
bumping its fee if necessary. Bob wants to send these funds to Carol, but
cannot wait until T1 confirms, so he crafts a transaction T2 that spends T1
using SIGHASH_NOINPUT, and pays Carol. Carol can now make sure she receives
the money even if Alice fee-bumps T1, as long as the outputs of the
replaced transactions are compatible.

Extra care should be taken to avoid rebinding, maybe by including an extra
input in T2 that doesn't use SIGHASH_NOINPUT.

On Mon, Apr 30, 2018 at 1: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
>

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

<div dir=3D"ltr">Something like this might also be useful for several use c=
ases related to RBF. For example:<div><br></div><div>Alice sends Bob an RBF=
-activated transaction T1 with the intention of bumping its fee if necessar=
y. Bob wants to send these funds to Carol, but cannot wait until T1 confirm=
s, so he crafts a transaction T2 that spends T1 using SIGHASH_NOINPUT, and =
<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:s=
mall;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm=
al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t=
ext-transform:none;white-space:normal;word-spacing:0px;background-color:rgb=
(255,255,255);text-decoration-style:initial;text-decoration-color:initial;f=
loat:none;display:inline">pays Carol</span>. Carol can now make sure she re=
ceives the money even if Alice fee-bumps T1, as long as the outputs of the =
replaced transactions are compatible.</div><div><br></div><div>Extra care s=
hould be taken to avoid rebinding, maybe by including an extra input in T2 =
that doesn&#39;t use=C2=A0<span style=3D"color:rgb(34,34,34);font-family:ar=
ial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:nor=
mal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-=
decoration-color:initial;float:none;display:inline">SIGHASH_NOINPUT.</span>=
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mo=
n, Apr 30, 2018 at 1:29 PM, Christian Decker via bitcoin-dev <span dir=3D"l=
tr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc 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>

--0000000000000f6989056b14fd67--