public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Matt Corallo <bitcoin-list@bluematt.me>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Date: Thu, 6 Nov 2014 18:12:25 -0500	[thread overview]
Message-ID: <20141106231225.GA26859@savin.petertodd.org> (raw)
In-Reply-To: <545BF0C2.3030201@bluematt.me>

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

On Thu, Nov 06, 2014 at 10:05:54PM +0000, Matt Corallo wrote:
> Depends, without BIP62 a /lot/ of the even basic contracts that people
> want to use today (or wanted to use 18 months ago) are unusable, in
> fact, without BIP62, the atomic swaps suggested as important for
> sidechains are not secure. While redoing Bitcoin in a hardfork is nice,
> its a very long-term thing, so I'm not sure about making people wait for
> a large hardfork just to use payment channels.

BIP62 is a less-than-ideal way of making contracts secure against
malleability as it relies on a "whack-a-mole" approach to security that
is insecure if any flaw is missed. If you only wanted to make contracts
secure, you'd either implement a new SignatureHash() that could leave
out the prevout field in favor of hashing the previous input's CTxOut()
structure, and/or implement the significantly more limited
CHECKLOCKTIMEVERIFY.

Equally BIP62 fails at making more complex types of contracts secure.
For instance suppose I had a multi-step protocol that required more than
two transactions:

    tx1: Alice -> (Alice, Bob)
    tx1_refund: (Alice, Bob) -> Alice

    tx2: (Alice, Bob) -> Charlie
    tx2_refund: (Alice, Bob) -> Bob

tx1 can only be modified by Alice, so tx1_refund is secure. However the
second stage, where the output of tx1 is spent by tx2, with a refund
transaction giving the funds back to Bob, can't be made secure as BIP62
can't prevent Alice from changing her signature, getting tx2' mined
instead, and making tx2_refund invalid.

OTOH a new form of signature hash that was a signature on tx2.vout
structure rather than it's txid would be secure, as tx2_refund would be
valid regardless of tx2's actual txid.

Obviously there are good reasons to not use such signature hashes in the
general case, as they imply you can't reuse scriptPubKeys securely, but
that's a minor problem for purpose-built contract protocols. It's
certainly a much more minor problem then the huge number of holes
possible with BIP62.

BIP62 does make life easier for wallet authors as they don't have to
deal with malleability - maybe! - but for contracts it's a bad design.

> Also, I echo the difficulty of writing consensus-compatible code and
> highly suggest anyone with money behind an implementation that is doing
> script verification in code that isnt Bitcoin Core rethink that decision.

FWIW I've done due-dilligence reviews for investors on projects and
companies that have re-implemented Bitcoin Core consensus-critical code,
and every time my review lists doing so as a major red flag.

-- 
'peter'[:-1]@petertodd.org
0000000000000000166801ed3959dde6b7d979735c290e7c4271ae3cf75ced63

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  parent reply	other threads:[~2014-11-06 23:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 21:32 [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug Peter Todd
2014-11-06 21:58 ` Tamas Blummer
2014-11-06 22:05   ` Matt Corallo
2014-11-06 22:11     ` Jeff Garzik
2014-11-06 22:48       ` Justus Ranvier
2014-11-06 23:26         ` Peter Todd
2014-11-06 23:36           ` Justus Ranvier
2014-11-07  0:03             ` Peter Todd
2014-11-07  8:07               ` Tamas Blummer
2014-11-07  8:48                 ` Peter Todd
2014-11-07 11:30                   ` Clément Elbaz
2014-11-07 11:47                     ` Peter Todd
2014-11-07 12:01                     ` Wladimir
2014-11-07 16:52               ` Mike Hearn
2014-11-15  4:43             ` Jean-Pierre Rupp
2014-11-06 23:19       ` Peter Todd
2014-11-06 23:12     ` Peter Todd [this message]
2014-11-07  2:04       ` Gregory Maxwell

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=20141106231225.GA26859@savin.petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=bitcoin-list@bluematt.me \
    /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