public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Rune Kjær Svendsen" <runesvend@gmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Date: Wed, 12 Feb 2014 16:12:25 +0100	[thread overview]
Message-ID: <CAH2=CKzNGN7mpe1NLtsLRNSszSD2ZNwjoAsaH40EvGtA5ezDeQ@mail.gmail.com> (raw)
In-Reply-To: <20140210030048.GB31925@savin>

Instead of trying to remove the possibility of transaction
malleability, would it make sense to define a new, "canonical
transaction hash/ID" (cTxID), which would be a hash of the part of the
transaction data which we know is not malleable, and have clients use
this cTxID internally, thus making the traditional transaction hash
irrelevant for a client to function correctly?

We already have a non-malleable transaction hash: the hash that is
signed, ie. the transaction with each scriptSig replaced by the
scriptPubKey it redeems. This could be the cTxID.

Or is this simply a too fundamental change to the way bitcoin-qt (and
all other clients) work in order to be feasible?

As far as I can see, it completely solves the issue of not having a
canonical ID for a transaction, but it also increases the
computational requirements for a node. For one, as far as I can see,
it requires the node to index all transactions, because in order to
calculate a cTxID, it would be necessary to fetch all transactions
referred to by the transaction in question, in order to pull in the
scriptPubKeys that are redeemed.


On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd <pete@petertodd.org> wrote:
> 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
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



  reply	other threads:[~2014-02-12 15:12 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-09 23:33 [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability Pieter Wuille
2014-02-10  3:00 ` Peter Todd
2014-02-12 15:12   ` Rune Kjær Svendsen [this message]
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='CAH2=CKzNGN7mpe1NLtsLRNSszSD2ZNwjoAsaH40EvGtA5ezDeQ@mail.gmail.com' \
    --to=runesvend@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.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