public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Olaoluwa Osuntokun <laolu32@gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP sighash_noinput
Date: Wed, 09 May 2018 23:01:39 +0000	[thread overview]
Message-ID: <CAO3Pvs9WZ2+oNrXo6r0ic7jmZ8wbH6eA=WJt6nsUSV5c7STwBw@mail.gmail.com> (raw)
In-Reply-To: <20180508144021.GA15921@erisian.com.au>

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

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

The typical address re-use doesn't apply here as this is a sighash flag that
would only really be used for doing various contracts on Bitcoin. I don't
see any reason why "regular" wallets would update to use this sighash flag.
We've also seen first hand with segwit that wallet authors are slow to pull
in the latest and greatest features available, even if they solve nuisance
issues like malleability and can result in lower fees.

IMO, sighash_none is an even bigger footgun that already exists in the
protocol today.

-- Laolu


On Tue, May 8, 2018 at 7:41 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>
> 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.
>
> Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)
> wouldn't be equally effective for the forseeable usecases? That would
> ensure that a _NOINPUT signature is only ever valid for keys deliberately
> intended to be single use, rather than potentially valid for every key.
>
> It would be ~34 witness bytes worse than being able to spend a Schnorr
> aggregate key directly, I guess; but that's not worse than the normal
> taproot tradeoff: you spend the aggregate key directly in the normal,
> cooperative case; and reserve the more expensive/NOINPUT case for the
> unusual, uncooperative cases. I believe that works fine for eltoo: in
> the cooperative case you just do a SIGHASH_ALL spend of the original
> transaction, and _NOINPUT isn't needed.
>
> 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.
>
> A new opcode has the theoretical advantage that it could be deployed
> into the existing segwit v0 address space, rather than waiting for segwit
> v1. Not sure that's really meaningful, though.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

  reply	other threads:[~2018-05-09 23:01 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
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 [this message]
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='CAO3Pvs9WZ2+oNrXo6r0ic7jmZ8wbH6eA=WJt6nsUSV5c7STwBw@mail.gmail.com' \
    --to=laolu32@gmail.com \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lightning-dev@lists.linuxfoundation.org \
    /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