From: Rusty Russell <rusty@rustcorp•com.au>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Christian Decker <decker.christian@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: lightning-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP sighash_noinput
Date: Thu, 10 May 2018 08:34:58 +0930 [thread overview]
Message-ID: <87in7we8h1.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20180508144021.GA15921@erisian.com.au>
Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev wrote:
>> Given the general enthusiasm, and lack of major criticism, for the
>> `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so....
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.
If I can convince you to sign with SIGHASH_NONE, it's already a problem
today.
> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.
That was also suggested by Mark Friedenbach, but I think we'll end up
with more "magic key" a-la Schnorr/taproot/graftroot and less script in
future.
That means we'd actually want a different Segwit version for
"NOINPUT-can-be-used", which seems super ugly.
> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.
In a world where SIGHASH_NONE didn't exist, this might be an argument :)
Cheers,
Rusty.
next prev parent reply other threads:[~2018-05-10 2:13 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 16:29 Christian Decker
2018-04-30 18:25 ` Dario Sneidermanis
2018-05-01 16:58 ` Russell O'Connor
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 [this message]
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=87in7we8h1.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=decker.christian@gmail$(echo .)com \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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