📅 Original date posted:2017-11-29
📝 Original message:
Actually this was merged as policy rules in 0.14, not 0.15.1.
Not as bad as I thought, but still a bit uneasy about someone malleating my
transaction.
Another way to fix the situation which would not require the BOLT to change
is to enable RBF of the Penalty transaction so Eve transaction would be
replaced by the initial one.
Nicolas,
On Wed, Nov 29, 2017 at 4:11 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> I noticed the Commitment Transaction Output script is weak to
> malleability, this can be used to delay confirmation of the revocation.
> Luckily, fixing the situation does not require lots of development.
>
> ```
> OP_IF
> # Penalty transaction
> <revocationkey>
> OP_ELSE
> `to_self_delay`
> OP_CSV
> OP_DROP
> <local_delayedkey>
> OP_ENDIF
> OP_CHECKSIG
> ```
>
> An attacker can delay the Penalty Transaction by malleating it. Which can
> lead to very bad outcome as Lightning dependant on time locks.
>
> The penalty transaction would have.
>
> ```
> <revocation_sig> 1
> ```
>
> Problem is that Eve could malleate OP_1 into a positive, huge number. This
> would have for effect to fill the mempool of nodes/miners with the
> malleated version which will have an higher fee rate, delaying the
> confirmation of the penalty transaction.
>
> Now, there is a policy rule called SCRIPT_VERIFY_MINIMALIF by jl2012 which
> was merged into v0.15.1. (https://github.com/bitcoin/bi
> tcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14)
>
> I guess that by the time LN is ready, 0.15.1 will be spread enough among
> miners, but still I think a 2 bytes overhead is well worth the fix.
>
> ```
> 1 OP_EQUAL OP_IF
> # Penalty transaction
> <revocationkey>
> OP_ELSE
> `to_self_delay`
> OP_CSV
> OP_DROP
> <local_delayedkey>
> OP_ENDIF
> OP_CHECKSIG
> ```
>
> Nicolas,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171129/b09e1ce1/attachment.html>;
Nicolas Dorier [ARCHIVE] /
npub1hu…9q4u3
2023-06-09 12:47:52
in reply to nevent1q…rkmz
Author Public Key
npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3Published at
2023-06-09 12:47:52Event JSON
{
"id": "113cbda00cf04dea8cf52e9021a194b77fcf32c473987a661d1d4d6a8f52d360",
"pubkey": "bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57",
"created_at": 1686314872,
"kind": 1,
"tags": [
[
"e",
"9f91982bc4954a3c5f27221faaed89e1ee1e26160e0c41e8e02949f21fa117e8",
"",
"root"
],
[
"e",
"6fb1832bdb366e67495e893c53f8ea8ac96e13c72ec693621b9e06b258ed22ca",
"",
"reply"
],
[
"p",
"bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57"
]
],
"content": "📅 Original date posted:2017-11-29\n📝 Original message:\nActually this was merged as policy rules in 0.14, not 0.15.1.\nNot as bad as I thought, but still a bit uneasy about someone malleating my\ntransaction.\n\nAnother way to fix the situation which would not require the BOLT to change\nis to enable RBF of the Penalty transaction so Eve transaction would be\nreplaced by the initial one.\n\nNicolas,\n\nOn Wed, Nov 29, 2017 at 4:11 PM, Nicolas Dorier \u003cnicolas.dorier at gmail.com\u003e\nwrote:\n\n\u003e I noticed the Commitment Transaction Output script is weak to\n\u003e malleability, this can be used to delay confirmation of the revocation.\n\u003e Luckily, fixing the situation does not require lots of development.\n\u003e\n\u003e ```\n\u003e OP_IF\n\u003e # Penalty transaction\n\u003e \u003crevocationkey\u003e\n\u003e OP_ELSE\n\u003e `to_self_delay`\n\u003e OP_CSV\n\u003e OP_DROP\n\u003e \u003clocal_delayedkey\u003e\n\u003e OP_ENDIF\n\u003e OP_CHECKSIG\n\u003e ```\n\u003e\n\u003e An attacker can delay the Penalty Transaction by malleating it. Which can\n\u003e lead to very bad outcome as Lightning dependant on time locks.\n\u003e\n\u003e The penalty transaction would have.\n\u003e\n\u003e ```\n\u003e \u003crevocation_sig\u003e 1\n\u003e ```\n\u003e\n\u003e Problem is that Eve could malleate OP_1 into a positive, huge number. This\n\u003e would have for effect to fill the mempool of nodes/miners with the\n\u003e malleated version which will have an higher fee rate, delaying the\n\u003e confirmation of the penalty transaction.\n\u003e\n\u003e Now, there is a policy rule called SCRIPT_VERIFY_MINIMALIF by jl2012 which\n\u003e was merged into v0.15.1. (https://github.com/bitcoin/bi\n\u003e tcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14)\n\u003e\n\u003e I guess that by the time LN is ready, 0.15.1 will be spread enough among\n\u003e miners, but still I think a 2 bytes overhead is well worth the fix.\n\u003e\n\u003e ```\n\u003e 1 OP_EQUAL OP_IF\n\u003e # Penalty transaction\n\u003e \u003crevocationkey\u003e\n\u003e OP_ELSE\n\u003e `to_self_delay`\n\u003e OP_CSV\n\u003e OP_DROP\n\u003e \u003clocal_delayedkey\u003e\n\u003e OP_ENDIF\n\u003e OP_CHECKSIG\n\u003e ```\n\u003e\n\u003e Nicolas,\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171129/b09e1ce1/attachment.html\u003e",
"sig": "eab90a9064c3b64ef733ee05528d12a2e4a264f149c62cce69b5d1d8e5be77a32b51312ba5fecdb8a7d9336986309503d88eacbe8cb60b628d0cef060e00ca1a"
}