Twisting your words a bit I read: * you want to support relay of transactions that can be changed on the fly, but you consider it wrong to modify them. * #3 is already not forwarded, but you still find it relevant to support it.
Rational use cases of #3 will be pretty hard to find given the fact that they can be changed on the fly. We are down to inclusion in blocks by miners for special purposes - or did I miss out something? I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions. /M On Feb 19, 2014, at 3:38 PM, Pieter Wuille <pieter.wui...@gmail.com> wrote: > 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
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
