On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager <grona...@mac.com> wrote: > 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.
I consider actively mutating other's transactions worse than not relaying them. If we want people to make their software deal with malleability, either will work. Regarding deterministic hash: that's impossible. Some signature hash types are inherently (and intentionally) malleable. I don't think we should pretend to want to change that. The purpose is making non-malleability a choice the sender of a transaction can make. Most of the rules actually are enforced by IsStandard already now. Only #1 and #7 aren't. #1 affects the majority of all transactions, so changing it right now would be painful. #7 only affects multisig. > 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. The problem in making these rules into consensus rule (affecting tx/block validity) is that some rules (in particular #3) may not be wanted by everyone, as they effectively limit the possibilities of the script language further. As it is ultimately only about protecting senders who care about non-malleability, introducing a new transaction version is a very neat way of accomplishing that. The new block version number is only there to coordinate the rollout, and choosing an automatic forking point. -- Pieter ------------------------------------------------------------------------------ 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
