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 <gmaxw...@gmail.com> wrote: > On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos <mor...@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. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ 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=121054471&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
