public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Russell O'Connor" <roconnor@blockstream.io>
To: Christian Decker <decker.christian@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP sighash_noinput
Date: Tue, 1 May 2018 12:58:37 -0400	[thread overview]
Message-ID: <CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com> (raw)
In-Reply-To: <871sewirni.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3437 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4556 bytes --]

  parent reply	other threads:[~2018-05-01 16:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-30 16:29 [bitcoin-dev] BIP sighash_noinput Christian Decker
2018-04-30 18:25 ` Dario Sneidermanis
2018-05-01 16:58 ` Russell O'Connor [this message]
2018-05-01 17:32   ` Christian Decker
2018-05-04  9:15     ` ZmnSCPxj
2018-05-04 11:09       ` Christian Decker
2018-05-04 14:25         ` ZmnSCPxj
2018-09-26  9:36   ` Jonas Nick
2018-09-26 19:45     ` Johnson Lau
2018-09-26 20:40       ` Jonas Nick
2018-05-07 19:40 ` Christian Decker
2018-05-07 20:51   ` Bram Cohen
2018-07-03  6:58     ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2018-07-03 11:54       ` William Casarin
2018-05-08 14:40   ` [bitcoin-dev] " Anthony Towns
2018-05-09 23:01     ` Olaoluwa Osuntokun
2018-05-09 23:04     ` Rusty Russell
2018-05-14  9:23       ` [bitcoin-dev] [Lightning-dev] " Anthony Towns
2018-05-15 14:28         ` Christian Decker
2018-05-07 23:47 ` [bitcoin-dev] " Olaoluwa Osuntokun
2018-05-10 14:12   ` Christian Decker
2018-07-02 18:11 ` Gregory Maxwell
2018-07-03  4:56   ` Rusty Russell
2018-07-03  5:21     ` Peter Todd
2018-07-03 23:45       ` Gregory Maxwell
2018-07-09  9:41         ` Peter Todd
2018-07-03 12:05   ` Christian Decker
2018-07-03 12:13   ` [bitcoin-dev] [Lightning-dev] " Luke Dashjr
2018-07-04 18:08     ` fred savage
2018-07-05  8:18       ` vv01f
     [not found]     ` <CAK_c0Xo0G9-YiOGZK_8WsYNkzjQRaH+u7XOUAozKosggXeXTNg@mail.gmail.com>
2018-07-11  7:43       ` ZmnSCPxj
2018-07-13  0:04       ` Rusty Russell
2018-07-13  9:50         ` fred savage
2018-07-13 11:07           ` Christian Decker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMZUoK=V9Dii7ja6n6mpW_tWt00PuT=-9Z8XoyKOY3y0_AwK5w@mail.gmail.com' \
    --to=roconnor@blockstream.io \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=decker.christian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox