rich1.0npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452https://nostr.ae/npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452njumphttps://nostr.ae📅 Original date posted:2014-02-19 📝 Original message: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.wuille at gmail.com> wrote: > On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager <gronager at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140219/f91a05d2/attachment.sig>