📅 Original date posted:2017-11-29
📝 Original message:
FWIW, going by the bitnodes tracker [1], most upgraded nodes are currently
running a bitcoind version >= 0.14. With segwit widely deployed, I'd safe
say it's a safe bet to assume that most miners are already running with
the standard malleability reducing policy that shipped in that version.
However, as you point out there's still the possibility that the Eve's
first element of Eve's witness stack would pushes the fee rate of Alice's
justice transaction to an "insufficient" range. If the justice transaction
is delayed excessively, then there's a chance that the commitment output
of the peer breaching the transaction matures before Alice's justice
transaction is confirmed. In this case, Eve may successfully breach the
contract.
In lnd, we have plans to implement a scorched earth policy when responding
to on-chain contract breach event. With this policy, once our justice
transaction punishing the violator of the contract has been broadcast, for
each block it doesn't confirm in, we'll gradually bump of the fee on the
transaction (with RBF). The additional fee would be drawn from from the
*violator's* settled balance in that state. With each iteration (block, no
confirmation, fee bump) we gradually bleed away the funds of the violator,
supplementing the fee already present on that commitment state. Assuming
that rational miners accept the higher fee transaction (and the violator
isn't colluding with miners), then our justice transaction will make it
into the block before the transaction breaching the contract. In an
attempt to counter act this, the violator may try to use CPFP to anchor
the transaction into the chain with a more attractive fee package.
However, in order to beat us in, they must spend a total amount of fees
that is greater than the current cumulative fee rate on our justice
transaction. If they do so, they'll either end up net negative, or fail to
profit (as they'll also bleed away all their funds).
The vindication strategy described requires the justice transaction to
signal RBF. This serves as another reason to signal RBF in justice
transactions. I recommend that all implementations adopt the scorched
earth vindication strategy when handling breached contracts. It addresses
Dorier's malleability concern, and also further stack the incentives
against attempting a contract breach.
[1]: https://bitnodes.earn.com/nodes/
-- Laolu
On Tue, Nov 28, 2017 at 11:40 PM Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> 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/bitcoin/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,
>>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171129/ab719344/attachment-0001.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:47:52
in reply to nevent1q…8dcs
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:47:52Event JSON
{
"id": "e0f959735f5ab0f5ad169d1934de2be0aa424886c0ec904069fd83fa234266c4",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686314872,
"kind": 1,
"tags": [
[
"e",
"9f91982bc4954a3c5f27221faaed89e1ee1e26160e0c41e8e02949f21fa117e8",
"",
"root"
],
[
"e",
"113cbda00cf04dea8cf52e9021a194b77fcf32c473987a661d1d4d6a8f52d360",
"",
"reply"
],
[
"p",
"bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57"
]
],
"content": "📅 Original date posted:2017-11-29\n📝 Original message:\nFWIW, going by the bitnodes tracker [1], most upgraded nodes are currently\nrunning a bitcoind version \u003e= 0.14. With segwit widely deployed, I'd safe\nsay it's a safe bet to assume that most miners are already running with\nthe standard malleability reducing policy that shipped in that version.\n\nHowever, as you point out there's still the possibility that the Eve's\nfirst element of Eve's witness stack would pushes the fee rate of Alice's\njustice transaction to an \"insufficient\" range. If the justice transaction\nis delayed excessively, then there's a chance that the commitment output\nof the peer breaching the transaction matures before Alice's justice\ntransaction is confirmed. In this case, Eve may successfully breach the\ncontract.\n\nIn lnd, we have plans to implement a scorched earth policy when responding\nto on-chain contract breach event. With this policy, once our justice\ntransaction punishing the violator of the contract has been broadcast, for\neach block it doesn't confirm in, we'll gradually bump of the fee on the\ntransaction (with RBF). The additional fee would be drawn from from the\n*violator's* settled balance in that state. With each iteration (block, no\nconfirmation, fee bump) we gradually bleed away the funds of the violator,\nsupplementing the fee already present on that commitment state. Assuming\nthat rational miners accept the higher fee transaction (and the violator\nisn't colluding with miners), then our justice transaction will make it\ninto the block before the transaction breaching the contract. In an\nattempt to counter act this, the violator may try to use CPFP to anchor\nthe transaction into the chain with a more attractive fee package.\nHowever, in order to beat us in, they must spend a total amount of fees\nthat is greater than the current cumulative fee rate on our justice\ntransaction. If they do so, they'll either end up net negative, or fail to\nprofit (as they'll also bleed away all their funds).\n\n\nThe vindication strategy described requires the justice transaction to\nsignal RBF. This serves as another reason to signal RBF in justice\ntransactions. I recommend that all implementations adopt the scorched\nearth vindication strategy when handling breached contracts. It addresses\nDorier's malleability concern, and also further stack the incentives\nagainst attempting a contract breach.\n\n\n[1]: https://bitnodes.earn.com/nodes/\n\n-- Laolu\n\nOn Tue, Nov 28, 2017 at 11:40 PM Nicolas Dorier \u003cnicolas.dorier at gmail.com\u003e\nwrote:\n\n\u003e Actually this was merged as policy rules in 0.14, not 0.15.1.\n\u003e Not as bad as I thought, but still a bit uneasy about someone malleating\n\u003e my transaction.\n\u003e\n\u003e Another way to fix the situation which would not require the BOLT to\n\u003e change is to enable RBF of the Penalty transaction so Eve transaction would\n\u003e be replaced by the initial one.\n\u003e\n\u003e Nicolas,\n\u003e\n\u003e On Wed, Nov 29, 2017 at 4:11 PM, Nicolas Dorier \u003cnicolas.dorier at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e I noticed the Commitment Transaction Output script is weak to\n\u003e\u003e malleability, this can be used to delay confirmation of the revocation.\n\u003e\u003e Luckily, fixing the situation does not require lots of development.\n\u003e\u003e\n\u003e\u003e ```\n\u003e\u003e OP_IF\n\u003e\u003e # Penalty transaction\n\u003e\u003e \u003crevocationkey\u003e\n\u003e\u003e OP_ELSE\n\u003e\u003e `to_self_delay`\n\u003e\u003e OP_CSV\n\u003e\u003e OP_DROP\n\u003e\u003e \u003clocal_delayedkey\u003e\n\u003e\u003e OP_ENDIF\n\u003e\u003e OP_CHECKSIG\n\u003e\u003e ```\n\u003e\u003e\n\u003e\u003e An attacker can delay the Penalty Transaction by malleating it. Which can\n\u003e\u003e lead to very bad outcome as Lightning dependant on time locks.\n\u003e\u003e\n\u003e\u003e The penalty transaction would have.\n\u003e\u003e\n\u003e\u003e ```\n\u003e\u003e \u003crevocation_sig\u003e 1\n\u003e\u003e ```\n\u003e\u003e\n\u003e\u003e Problem is that Eve could malleate OP_1 into a positive, huge number.\n\u003e\u003e This would have for effect to fill the mempool of nodes/miners with the\n\u003e\u003e malleated version which will have an higher fee rate, delaying the\n\u003e\u003e confirmation of the penalty transaction.\n\u003e\u003e\n\u003e\u003e Now, there is a policy rule called SCRIPT_VERIFY_MINIMALIF by jl2012\n\u003e\u003e which was merged into v0.15.1. (\n\u003e\u003e https://github.com/bitcoin/bitcoin/commit/c72c5b1e3bd42e84465677e94aa83316ff3d9a14\n\u003e\u003e )\n\u003e\u003e\n\u003e\u003e I guess that by the time LN is ready, 0.15.1 will be spread enough among\n\u003e\u003e miners, but still I think a 2 bytes overhead is well worth the fix.\n\u003e\u003e\n\u003e\u003e ```\n\u003e\u003e 1 OP_EQUAL OP_IF\n\u003e\u003e # Penalty transaction\n\u003e\u003e \u003crevocationkey\u003e\n\u003e\u003e OP_ELSE\n\u003e\u003e `to_self_delay`\n\u003e\u003e OP_CSV\n\u003e\u003e OP_DROP\n\u003e\u003e \u003clocal_delayedkey\u003e\n\u003e\u003e OP_ENDIF\n\u003e\u003e OP_CHECKSIG\n\u003e\u003e ```\n\u003e\u003e\n\u003e\u003e Nicolas,\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171129/ab719344/attachment-0001.html\u003e",
"sig": "fdb057b51491fde2a7572f2d0d747d97539e2e8f65915c11f767801c292f2cfd1be9e1fa8ba608868ee27a1a0b275c926832f152a8c39e317644d7689b8315a5"
}