š
Original date posted:2020-02-11
š Original message:
Good morning darosior, niftynei, and list,
>
> We could agree on an acceptable number of reuse in case on a non-malicious failure from the initiator after a valid PoDLE exchange ? (credits ZmnSCPxj)
The default of 3 for JoinMarket seems reasonable.
>
> Ok, so knowing where PoDLE originate from mitigates the flood we talked about with ZmnSCPxj.
> However I don't see how the number of utxos in the mempool is useful here, as you cannot distinguish which PoDLE is the real one out of the load you are receiving in case of a flood ?
No idea either, but if we limit accepted `node_id`s to those that we have seen in a `node_announcement` before, then we ride on the fact that `node_announcement` is costly in the sense that somebody has to allocate at least some small amount of funds to a channel that is visible onchain, because `node_announcement` requires a `channel_announcement` with an anchored channel.
Then if nodes on the network can just send PoDLE gossip that they did not sign themselves, but are signed by *some* node that was `node_announcement`ed before, we can identify those nodes that are spamming a lot of their own signed PoDLE gossip, and rate-limit those.
It is likely that announced nodes are the ones who will have such attack attempts performed on them, so they are in the best position to inform others of such attempts and are the most likely to have such data.
At some point we probably also need to have set reconciliation for these as well.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 12:58:43
in reply to nevent1qā¦5ycr
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:58:43Event JSON
{
"id": "5123be4f0ab153f412dc13077e36b86c83549722dabf862dd3de08eecc1e1c83",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315523,
"kind": 1,
"tags": [
[
"e",
"c218110e24b04f0c1c5d2dd6e63487b0dca619f1f570c991ff7f4dc7c65213bd",
"",
"root"
],
[
"e",
"375d211aad4c3709b4eab07c1c6e9741401fbe48ac9819682d4240ffac7b0f2e",
"",
"reply"
],
[
"p",
"0c8af5293ea8c40f3686f22669674e0c116a8e92467163929d736aa891b7ece2"
]
],
"content": "š
Original date posted:2020-02-11\nš Original message:\nGood morning darosior, niftynei, and list,\n\n\n\u003e\n\u003e We could agree on an acceptable number of reuse in case on a non-malicious failure from the initiator after a valid PoDLE exchange ? (credits ZmnSCPxj)\n\nThe default of 3 for JoinMarket seems reasonable.\n\n\n\u003e\n\u003e Ok, so knowing where PoDLE originate from mitigates the flood we talked about with ZmnSCPxj.\n\u003e However I don't see how the number of utxos in the mempool is useful here, as you cannot distinguish which PoDLE is the real one out of the load you are receiving in case of a flood ?\n\nNo idea either, but if we limit accepted `node_id`s to those that we have seen in a `node_announcement` before, then we ride on the fact that `node_announcement` is costly in the sense that somebody has to allocate at least some small amount of funds to a channel that is visible onchain, because `node_announcement` requires a `channel_announcement` with an anchored channel.\n\nThen if nodes on the network can just send PoDLE gossip that they did not sign themselves, but are signed by *some* node that was `node_announcement`ed before, we can identify those nodes that are spamming a lot of their own signed PoDLE gossip, and rate-limit those.\n\nIt is likely that announced nodes are the ones who will have such attack attempts performed on them, so they are in the best position to inform others of such attempts and are the most likely to have such data.\n\nAt some point we probably also need to have set reconciliation for these as well.\n\nRegards,\nZmnSCPxj",
"sig": "88622d027f7bf1b6a27a11ca055f162762fc8d271ccad72463a04bd6713568c4e292fea88288d8d379350121a7ba981dc3132cce3a16811e9761a81e1cbe02af"
}