[Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
gronager at mac.com
Wed Feb 19 14:11:51 UTC 2014
Why introduce a new transaction version for this purpose ? Wouldn't it be more elegant to simply let:
1. the next bitcoin version "prettify" all relayed transactions as deterministic transactions fulfilling the scheme 1-6 effectively blocking any malleability attack? If miners would upgrade then all transactions in blocks would have a deterministic hash.
2. In a version later one could block relay of non deterministic transactions, as well as the acceptance of blocks with non-confirming transactions.
To non-standard conforming clients this "prettify" change of hash would be seen as a constant malleability attack, but given the "prettify" code it is to fix any client into producing only conforming transactions, just by running the transaction through it before broadcast.
There is a possible fork risk in step 2. above - if a majority of miners still havn't upgraded to 1 when 2 is introduced. We could monitor % non conforming transaction in a block and only introduce 2. once that number is sufficiently small for a certain duration - criteria:
* Switch on forcing of unmalleable transactions in blocks when there has been only conforming transactions for 1000 blocks.
On Feb 13, 2014, at 1:47 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos <morcos at gmail.com> wrote:
>> I apologize if this has been discussed many times before.
> It has been, but there are probably many people like you who have not
> bothered researching who may also be curious.
>> As a long term solution to malleable transactions, wouldn't it be possible
>> to modify the signatures to be of the entire transaction. Why do you have
>> to zero out the inputs? I can see that this would be a hard fork, and maybe
>> it would be somewhat tricky to extract signatures first (since you can sign
>> everything except the signatures), but it would seem to me that this is an
>> important enough change to consider making.
> Because doing so would be both unnecessary and ineffective.
> Unnecessary because we can very likely eliminate malleability without
> changing what is signed. It will take time, but we have been
> incrementally moving towards that, e.g. v0.8 made many kinds of
> non-canonical encoding non-standard.
> Ineffective— at least as you describe it— because the signatures
> _themselves_ are malleable.
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the bitcoin-dev