📅 Original date posted:2016-08-24
📝 Original message:In a previous thread ("New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH") it was briefly discussed what happens if someone
modifies segwit data during transmission. I think the discussion should
continue.
What worries me is what happens with non-segwit transactions after segwit
is activated. I've followed the code from transaction arrival to
transaction relay and it seems that a malicious node could receive a
non-segwit tx, and re-format it into a segwit tx having as high as 400
Kbytes of segwit witness program data, and then relay it. Both transaction
would have the same hash.
The MAX_SCRIPT_ELEMENT_SIZE limit is only enforced on segwit execution, not
in old non-segwit execution, so witness program stack elements could be as
large as 400 Kbytes (MAX_STANDARD_TX_WEIGHT prevents increasing more).
Such large modified transaction will probably not be properly relayed by
the network due too low fee/byte, so the honest miner will probably win and
forward the original transaction through the network.
But if the attacker has better connectivity with the network and he
modifies the original transaction adding segwit witness program data only
up to the point where the transaction is relayed but miners are discouraged
to include it in blocks due to low fees/byte, then the attacker has
successfully prevented a transaction from being mined (or at least it will
take much more).
Also an attacker can encode arbitrary data (such as virus signatures or
illegal content) into passing non-segwit transactions.
One solution would be to increase the transaction version to 3 for segwit
transactions, so a non-segwit transaction cannot be converted into a segwit
transaction without changing the transaction hash. But this seems not to be
a good solution, because it does not solve all the problems. Transactions
having a mixture of segwit and non-segwit inputs could suffer the same
attack (even if they are version 3).
I proposed that a rule is added to IsStandardTX() that prevents witness
programs of having a stack elements of length greater than
MAX_SCRIPT_ELEMENT_SIZE. (currently this is not a rule)
That's a simple check that prevents most of the problems.
A long term solution would be to add the maximum size of the witness stack
in bytes (maxWitnessSize) as a field for each input, or as a field of the
whole transaction.
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/1158ef31/attachment.html>;
Sergio Demian Lerner [ARCHIVE] /
npub1fv…3vq7f
2023-06-07 17:53:11
in reply to nevent1q…wjsl
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 17:53:11Event JSON
{
"id": "46cc08f6664d91cbac7014850b111c734ff27b75a06fe3c3e59a9f4e427a01a2",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686160391,
"kind": 1,
"tags": [
[
"e",
"128a131efc65035b83779a292b3279ef7d164a0e4f2ca63efa11944d72321447",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2016-08-24\n📝 Original message:In a previous thread (\"New BIP: Dealing with OP_IF and OP_NOTIF\nmalleability in P2WSH\") it was briefly discussed what happens if someone\nmodifies segwit data during transmission. I think the discussion should\ncontinue.\n\nWhat worries me is what happens with non-segwit transactions after segwit\nis activated. I've followed the code from transaction arrival to\ntransaction relay and it seems that a malicious node could receive a\nnon-segwit tx, and re-format it into a segwit tx having as high as 400\nKbytes of segwit witness program data, and then relay it. Both transaction\nwould have the same hash.\n\nThe MAX_SCRIPT_ELEMENT_SIZE limit is only enforced on segwit execution, not\nin old non-segwit execution, so witness program stack elements could be as\nlarge as 400 Kbytes (MAX_STANDARD_TX_WEIGHT prevents increasing more).\nSuch large modified transaction will probably not be properly relayed by\nthe network due too low fee/byte, so the honest miner will probably win and\nforward the original transaction through the network.\nBut if the attacker has better connectivity with the network and he\nmodifies the original transaction adding segwit witness program data only\nup to the point where the transaction is relayed but miners are discouraged\nto include it in blocks due to low fees/byte, then the attacker has\nsuccessfully prevented a transaction from being mined (or at least it will\ntake much more).\n\nAlso an attacker can encode arbitrary data (such as virus signatures or\nillegal content) into passing non-segwit transactions.\n\nOne solution would be to increase the transaction version to 3 for segwit\ntransactions, so a non-segwit transaction cannot be converted into a segwit\ntransaction without changing the transaction hash. But this seems not to be\na good solution, because it does not solve all the problems. Transactions\nhaving a mixture of segwit and non-segwit inputs could suffer the same\nattack (even if they are version 3).\n\nI proposed that a rule is added to IsStandardTX() that prevents witness\nprograms of having a stack elements of length greater than\nMAX_SCRIPT_ELEMENT_SIZE. (currently this is not a rule)\n\nThat's a simple check that prevents most of the problems.\n\nA long term solution would be to add the maximum size of the witness stack\nin bytes (maxWitnessSize) as a field for each input, or as a field of the\nwhole transaction.\n\nRegards\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160824/1158ef31/attachment.html\u003e",
"sig": "c61b68b470fcfd2e00e8b808d75b31390d48c5732eaf833a0a710e054044dac6166aaf3d34dd7b62c873e6efe850512eee22c41469b77a04e02de31cdcf52fb3"
}