📅 Original date posted:2014-02-19
📝 Original message: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
Pieter Wuille [ARCHIVE] /
npub1tj…jtl6r
2023-06-07 15:13:24
in reply to nevent1q…al24
Author Public Key
npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6rPublished at
2023-06-07 15:13:24Event JSON
{
"id": "19a30e41edbb60dc97393e29b9023a2da0366616f3fa38711fe1217f912f5e9c",
"pubkey": "5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6",
"created_at": 1686150804,
"kind": 1,
"tags": [
[
"e",
"76969a008b621e54c247029127aebdfbea1794fb79dd58e07b32a76157512d29",
"",
"root"
],
[
"e",
"029f01533963d31b066060d1801e592f51e7b22f7241c7f4eebcfc5bbf3393cc",
"",
"reply"
],
[
"p",
"9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02"
]
],
"content": "📅 Original date posted:2014-02-19\n📝 Original message:On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager \u003cgronager at mac.com\u003e wrote:\n\u003e Why introduce a new transaction version for this purpose ? Wouldn't it be more elegant to simply let:\n\u003e\n\u003e 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.\n\nI consider actively mutating other's transactions worse than not\nrelaying them. If we want people to make their software deal with\nmalleability, either will work.\n\nRegarding deterministic hash: that's impossible. Some signature hash\ntypes are inherently (and intentionally) malleable. I don't think we\nshould pretend to want to change that. The purpose is making\nnon-malleability a choice the sender of a transaction can make.\n\nMost of the rules actually are enforced by IsStandard already now.\nOnly #1 and #7 aren't. #1 affects the majority of all transactions, so\nchanging it right now would be painful. #7 only affects multisig.\n\n\u003e 2. In a version later one could block relay of non deterministic transactions, as well as the acceptance of blocks with non-confirming transactions.\n\u003e\n\u003e 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.\n\u003e\n\u003e 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:\n\u003e * Switch on forcing of unmalleable transactions in blocks when there has been only conforming transactions for 1000 blocks.\n\nThe problem in making these rules into consensus rule (affecting\ntx/block validity) is that some rules (in particular #3) may not be\nwanted by everyone, as they effectively limit the possibilities of the\nscript language further. As it is ultimately only about protecting\nsenders who care about non-malleability, introducing a new transaction\nversion is a very neat way of accomplishing that. The new block\nversion number is only there to coordinate the rollout, and choosing\nan automatic forking point.\n\n-- \nPieter",
"sig": "291bcd9a37c0606db8606918840e90ac260428c9c52ce71f2fd7284ba9085cb7a8667082b207c04db1538980af318be0fa211e7bdf978061b9b588ef8aafd64e"
}