From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A59F5AD for ; 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 ; Tue, 1 May 2018 16:58:58 +0000 (UTC) Received: by mail-it0-f54.google.com with SMTP id j186-v6so13792896ita.5 for ; 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" Date: Tue, 1 May 2018 12:58:37 -0400 Message-ID: To: Christian Decker , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
At the risk of bikeshedding, shouldn't NOINPUT also ze= ro out the hashSequence so that its behaviour is consistent with ANYONECANP= AY?

On M= on, 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 previou= s
output. This was previously mentioned on the list by Joseph Poon [1], but w= as
never formally proposed, so I wrote a proposal [2].

We have long known that `SIGHASH_NOINPUT` would be a great fit for Lightnin= g.
They enable simple watch-towers, i.e., outsource the need to watch the
blockchain for channel closures, and react appropriately if our counterpart= y
misbehaves. In addition to this we just released the eltoo [3,4] paper whic= h
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<= br> 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 w= e
suggest using contract specific key-pairs, in order to avoid having any unw= anted
rebinding opportunities.

The proposal is very minimalistic, and simple. However, there are a few thi= ngs
where we'd like to hear the input of the wider community with regards t= o the
implementation details though. We had some discussions internally on whethe= r 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<= br> `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 com= mit
to the amount of the outpoint being spent. The rationale behind this is tha= t,
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 t= o
collide with any other proposals. It should be possible to introduce it by<= br> bumping the segwit script version and adding the new behavior.

I hope the proposal is well received, and I'm looking forward to discus= sing
variants and tradeoffs here. I think the applications we proposed so far ar= e
quite interesting, and I'm sure there are many more we can enable with = this
change.

Cheers,
Christian

[1] https://lists.l= inuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.htm= l
[2] https://github.com/cdecker/bi= ps/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--