From: Peter Todd <pete@petertodd•org>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Date: Sun, 9 Feb 2014 22:00:48 -0500 [thread overview]
Message-ID: <20140210030048.GB31925@savin> (raw)
In-Reply-To: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]
On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
> Hello all,
>
> it was something I planned to do since a long time, but with the
> recent related issues popping up, I finally got around to writing a
> BIP about how we can get rid of transaction malleability over time.
>
> The proposed document is here: https://gist.github.com/sipa/8907691
>
> I expect most rules to not be controversial. Maybe rules 1 and 3, as
> they require modifications to wallet software (Bitcoin Core 0.9 and
> BitcoinJ already implement it, though) and potentially invalidate some
> script functionality. However, these new rules remain optional and
> controlled by an nVersion increase.
>
> Comments please!
You should probably add making CHECKMULTISIG require the dummy value to
be exactly equal to OP_FALSE; verifying that in the transaction itself is
laborious. A more subtle example is we may want both CHECKSIG and
CHECKMULTISIG to fail the transaction if the signature is invalid but
not exactly equal to OP_FALSE; some transaction forms are significantly
more compact if you can have failed signatures, but that's a source of
malleability. (are there counter examples people can think of?)
But as I said on IRC, I'm a bit hesitant to bake in assumptions about
malleability when we have no solid idea if ECC signatures are or are not
malleable on a fundemental level; if "whack-a-mole" anti-malleability is
all we've got it could be ugly if a break is found. Similarly, we may
find we missed something, or some needed change makes the malleability
rules difficult to work with for some new script type that is required.
I'd rather see a new CHECKSIG mode for the case where malleability
absolutely must be eliminated - certain multi-party protocols - and fix
wallet software instead. (the malleability problems people see are
closely related to inability to handle double-spends and reorgs) But I
can easily see that being an impossible goal engineering wise...
--
'peter'[:-1]@petertodd.org
0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-02-10 3:01 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-09 23:33 Pieter Wuille
2014-02-10 3:00 ` Peter Todd [this message]
2014-02-12 15:12 ` Rune Kjær Svendsen
2014-02-12 16:22 ` Alan Reiner
2014-02-12 16:38 ` Allen Piscitello
2014-02-12 16:44 ` Alan Reiner
2014-02-12 20:27 ` Mark Friedenbach
2014-02-12 22:52 ` Luke-Jr
2014-02-13 0:39 ` Alex Morcos
2014-02-13 0:47 ` Gregory Maxwell
2014-02-19 14:11 ` Michael Gronager
2014-02-19 14:38 ` Pieter Wuille
2014-02-19 20:28 ` Michael Gronager
2014-02-19 20:39 ` Gregory Maxwell
2014-02-19 20:49 ` Peter Todd
2014-02-19 21:05 ` Gregory Maxwell
2014-02-19 21:11 ` Pieter Wuille
2014-02-20 0:22 ` Natanael
2014-02-20 1:29 ` Allen Piscitello
2014-02-20 7:50 ` Natanael
2014-02-20 10:59 ` Michael Gronager
2014-02-20 14:08 ` Mike Hearn
2014-02-20 14:15 ` Gregory Maxwell
2014-02-20 14:29 ` Gavin Andresen
2014-02-20 14:36 ` Gregory Maxwell
2014-02-20 14:58 ` Gavin Andresen
2014-02-20 15:11 ` Pieter Wuille
2014-02-20 15:24 ` Gregory Maxwell
2014-02-21 6:07 ` Mike Hearn
2014-02-21 6:30 ` Gregory Maxwell
2014-02-19 19:15 ` Jeremy Spilman
2014-02-12 17:13 ` Jeff Garzik
2014-02-12 17:21 ` Pieter Wuille
2014-02-12 18:03 ` Gregory Maxwell
[not found] ` <CALf2ePyQeOxL3d+QoaWSYy_cCKaF9qq1StBwXFms9NyedUg3eg@mail.gmail.com>
2014-02-12 18:21 ` Alan Reiner
2014-02-10 4:39 ` Luke-Jr
2014-02-12 16:56 ` Pavol Rusnak
2014-02-12 17:22 ` Pieter Wuille
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=20140210030048.GB31925@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/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