public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Anthony Towns <aj@erisian.com.au>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] SIGHASH_ANYPREVOUT proposal
Date: Wed, 22 May 2019 12:17:31 +0930	[thread overview]
Message-ID: <87d0kbkxx8.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20190510203804.554q333lw3l7qql4@erisian.com.au>

Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:

> Hi everybody!
>
> Here is a followup BIP draft that enables SIGHASH_ANYPREVOUT and
> SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. (This is NOINPUT,
> despite the name change)

I really like this proposal, and am impressed with how cleanly it
separated from taproot/tapscript.

I believe the chaparone signature requirement should be eliminated: I am
aware of four suggested benefits, which I don't believe are addressed
adaquately enough by chaparones to justify enshrining this complexity
into the protocol.

1. "These features could be used dangerously, and chaparone signatures make
   them harder to use, thus less likely to be adopted by random wallet
   authors."

   This change is already hard to implement, even once you're on v1
   segwit; you can't just use it with existing outputs.  I prefer to
   change the bip introduction to expliclty shout "THESE SIGNATURE
   HASHES ARE UNSAFE FOR NORMAL WALLET USAGE.", and maybe rename it
   SIGHASH_UNSAFE_ANYPREVOUT.

2. "Accidental key reuse can make this unsafe."

   This is true, but chaparones don't seem to help.  The main purpose of
   ANYPREV is where you can't re-sign; in particular, in lightning you
   are co-signing with an untrusted party up-front.  So you have to
   share the chaparone privkeys with one untrusted party.

   The BIP says "SHOULD limit the distribution of those private keys".
   That seems ridiculously optimistic: don't tell the secret to more
   than *one* untrusted party?

   In fact, lightning will also need to hand chaparone keys to
   watchtowers, so we'll probably end up using some fixed known secret.

3. "Miners can reorg and invalidate downstream txs".

   There's a principle (ISTR reading it years ago from Greg Maxwell?)
   that if no spender is malicious, a transaction should generally not
   become invalid.  With ANYPREV, a miner could reattach a transaction
   during a reorg, changing its txid and invalidating normal spends from
   it.

   In practice, I believe this principle will remain just as generally
   true with ANYPREV:

   1. For lightning the locktime will be fairly high before these txs are
      generally spendable.
   2. Doing this would require special software, since I don't see bitcoin
      core indexing outputs to enable this kind of rewriting.
   3. We already added such a common possibility with RBF, but before I
      brought it up I don't believe anyone realized.  We certainly
      haven't seen any problems in practice, for similar practical
      reasons.

4. "Rebinding is a new power in bitcoin, and it makes me uncomfortable".

   I have a degree of sympathy for this view, but objections must be
   backed in facts.  If we don't understand it well enough, we should
   not do it.  If we do understand it, we should be able to point out
   real problems.

Finally, it seems to me that chaparones can be opt-in, and don't need to
burden the protocol.

Cheers,
Rusty.


  reply	other threads:[~2019-05-22  2:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 20:38 [bitcoin-dev] SIGHASH_ANYPREVOUT proposal Anthony Towns
2019-05-22  2:47 ` Rusty Russell [this message]
2019-05-22 20:11   ` Anthony Towns
2019-05-27  1:26     ` Rusty Russell

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=87d0kbkxx8.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-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