📅 Original date posted:2019-10-28
📝 Original message:On Mon, Oct 28, 2019 at 10:45:39AM +0100, Johan Torås Halseth wrote:
> Relay cost is the obvious problem with just naively removing all limits.
> Relaxing the current rules by allowing to add a child to each output as
> long as it has a single unconfirmed parent would still only allow free
> relay of O(size of parent) extra data (which might not be that bad? Similar
> to the carve-out rule we could put limits on the child size).
A parent transaction near the limit of 100,000 vbytes could have almost
10,000 outputs paying OP_TRUE (10 vbytes per output). If the children
were limited to 10,000 vbytes each (the current max carve-out size),
that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger
than the default maximum mempool size in Bitcoin Core).
As Matt noted in discussion on #lightning-dev about this issue, it's
possible to increase second-child carve-out to nth-child carve-out but
we'd need to be careful about choosing an appropriately low value for n.
For example, BOLT2 limits the number of HTLCs to 483 on each side of the
channel (so 966 + 2 outputs total), which means the worst case free
relay to support the current LN protocol would be approximately:
(100000 + 968 * 10000) * 4 = ~39 MB
Even if the mempool was empty (as it sometimes is these days), it would
only cost an attacker about 1.5 BTC to fill it at the default minimum
relay feerate[1] so that they could execute this attack at the minimal
cost per iteration of paying for a few hundred or a few thousand vbytes
at slightly higher than the current mempool minimum fee.
Instead, with the existing rules (including second-child carve-out),
they'd have to iterate (39 MB / 400 kB = ~100) times more often to
achieve an equivalent waste of bandwidth, costing them proportionally
more in fees.
So, I think these rough numbers clearly back what Matt said about us
being able to raise the limits a bit if we need to, but that we have to
be careful not to raise them so far that attackers can make it
significantly more bandwidth expensive for people to run relaying full
nodes.
-Dave
[1] Several developers are working on lowering the default minimum in
Bitcoin Core, which would of course make this attack proportionally
cheaper.
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-07 18:21:27
in reply to nevent1q…zykm
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 18:21:27Event JSON
{
"id": "50a1e1ff024304a7fafaa36acca7348e0d8f80f10a940c10dd03e1f1ce28ab36",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686162087,
"kind": 1,
"tags": [
[
"e",
"9aab911e37aa7c38b30f72993772a8e76d2c1c6cde53a9a5722e25bbe194efbd",
"",
"root"
],
[
"e",
"6c7f46724accb8944e6f8cf6bd0afba7ef0b6ac2017cffb3d2715329fd230492",
"",
"reply"
],
[
"p",
"0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f"
]
],
"content": "📅 Original date posted:2019-10-28\n📝 Original message:On Mon, Oct 28, 2019 at 10:45:39AM +0100, Johan Torås Halseth wrote:\n\u003e Relay cost is the obvious problem with just naively removing all limits.\n\u003e Relaxing the current rules by allowing to add a child to each output as\n\u003e long as it has a single unconfirmed parent would still only allow free\n\u003e relay of O(size of parent) extra data (which might not be that bad? Similar\n\u003e to the carve-out rule we could put limits on the child size). \n\nA parent transaction near the limit of 100,000 vbytes could have almost\n10,000 outputs paying OP_TRUE (10 vbytes per output). If the children\nwere limited to 10,000 vbytes each (the current max carve-out size),\nthat allows relaying 100 mega-vbytes or nearly 400 MB data size (larger\nthan the default maximum mempool size in Bitcoin Core).\n\nAs Matt noted in discussion on #lightning-dev about this issue, it's\npossible to increase second-child carve-out to nth-child carve-out but\nwe'd need to be careful about choosing an appropriately low value for n.\n\nFor example, BOLT2 limits the number of HTLCs to 483 on each side of the\nchannel (so 966 + 2 outputs total), which means the worst case free\nrelay to support the current LN protocol would be approximately:\n\n (100000 + 968 * 10000) * 4 = ~39 MB\n\nEven if the mempool was empty (as it sometimes is these days), it would\nonly cost an attacker about 1.5 BTC to fill it at the default minimum\nrelay feerate[1] so that they could execute this attack at the minimal\ncost per iteration of paying for a few hundred or a few thousand vbytes\nat slightly higher than the current mempool minimum fee.\n\nInstead, with the existing rules (including second-child carve-out),\nthey'd have to iterate (39 MB / 400 kB = ~100) times more often to\nachieve an equivalent waste of bandwidth, costing them proportionally\nmore in fees.\n\nSo, I think these rough numbers clearly back what Matt said about us\nbeing able to raise the limits a bit if we need to, but that we have to\nbe careful not to raise them so far that attackers can make it\nsignificantly more bandwidth expensive for people to run relaying full\nnodes.\n\n-Dave\n\n[1] Several developers are working on lowering the default minimum in\nBitcoin Core, which would of course make this attack proportionally\ncheaper.",
"sig": "06f11308279aaed7df2625d6877a7521c6c8e20692d6f3be6bb84e8d60ad1540b12b998c080d95d861532308ee5c615483b89314889fbb438473199f4c7e0181"
}