{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-15\n📝 Original message:\nHi Joost,\n\nThanks for your proposal, please find my following opinion which is\ndeliberately on a high-level as IMO defining better threats model and\nagreeing on expected network dynamics resulting from any solution\ntrade-offs sounds required before to work on any solution.\n\n\u003e We've looked at all kinds of trustless payment schemes to keep users\n\n\u003e honest, but it appears that none of them is satisfactory. Maybe it is\neven\n\u003e theoretically impossible to create a scheme that is trustless and has all\n\n\u003e the properties that we're looking for. (A proof of that would also be\n\n\u003e useful information to have.)\n\nI don't think anyone has drawn yet a formal proof of this, but roughly a\nrouting peer Bob, aiming to prevent resource abuse at HTLC relay is seeking\nto answer the following question \"Is this payment coming from Alice and\ngoing to Caroll will compensate for my resources consumption ?\". With the\ncurrent LN system, the compensation is conditional on payment settlement\nsuccess and both Alice and Caroll are distrusted yet discretionary on\nfailure/success. Thus the underscored question is undecidable for a routing\npeer making relay decisions only on packet observation.\n\nOne way to mitigate this, is to introduce statistical observation of\nsender/receiver, namely a reputation system. It can be achieved through a\nscoring system, web-of-trust, or whatever other solution with the same\nproperties.\nBut still it must be underscored that statistical observations are only\nprobabilistic and don't provide resource consumption security to Bob, the\nrouting peer, in a deterministic way. A well-scored peer may start to\nsuddenly misbehave.\n\nIn that sense, the efficiency evaluation of a reputation-based solution to\ndeter DoS must be evaluated based based on the loss of the reputation\nbearer related to the potential damage which can be inflicted. It's just\nreputation sounds harder to compute accurately than a pure payment-based\nDoS protection system.\n\n\u003e Perhaps a small bit of trust isn't so bad. There is trust in Lightning\n\n\u003e already. For example when you open a channel, you trust (or hope) that\nyour\n\u003e peer remains well connected, keeps charging reasonable fees, doesn't\n\n\u003e force-close in a bad way, etc.\n\nThat's a good recall, obviously we should avoid getting stuck in a false\ntrust-vs-trustlessness dichotomy but always bound the discussion to a\nspecific situation. Even the base layer involved some trust assumptions,\nlike fetching your initial p2p peers from DNS seeds, all the matter is how\ndo you minimize this assumption. You might not have the same expectation\nwhen it's miners which might completely screw up the safety of your coin\nstack than routing nodes which might only make your loss a tiny routing\nfee, a minor nuisance.\n\n\u003e What I can see working is a system where peers charge each other a hold\nfee\n\u003e for forwarded HTLCs based on the actual lock time (not the maximum lock\n\n\u003e time) and the htlc value. This is just for the cost of holding and\nseparate\n\u003e from the routing fee that is earned when the payment settles\n\nYes I guess any solution will work as long as it enforces an asymmetry\nbetween the liquidity requester and a honest routing peer. This asymmetry\ncan be defined as guaranteeing that the routing peer's incoming/outgoing\nbalance is always increasing, independently of payment success. Obviously\nthis increase should be materialized by a payment, while minding it might\nbe discounted based on requester reputation (\"pay-with-your-reputation\").\nThis reputation evaluation can be fully delegated to the routing node\npolicy, without network-wise guidance.\n\nThat said, where I'm skeptical on any reputation-heavy system is on the\nlong-term implications.\n\nEither, due to the wants of a subset of actors deliberately willingly to\ntrade satoshis against discounted payment flow by buying well-scored\npubkeys, we see the emergence of a reputation market. Thus enabling\nreputation to be fungible to satoshis, but with now a weird \"reputation\"\ntoken to care about.\n\nOr, reputation is too hard to make liquid (e.g hard to disentangle pubkeys\nfrom channel ownership or export your score across routing peers) and thus\nyou now have reputation scarcity which is introducing a bias from a \"purer\"\nmarket, where agents are only routing based on advertised fees. IMO, we\nshould strive for the more liquid Lightning market we can, as it avoids\nbias towards past actors and thus may contain centralization inertia. I'm\ncurious about your opinion on this last point.\n\nMoving forward, I think t-bast is working on gathering materials to\ncheckbox the first step, establishing a fully-fledged threat model.\n\nCheers,\n\nAntoine\n\nLe lun. 12 oct. 2020 à 07:04, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e Hello list,\n\u003e\n\u003e Many discussions have taken place on this list on how to prevent undesired\n\u003e use of the Lightning network. Spamming the network with HTLCs (for probing\n\u003e purposes or otherwise) or holding HTLCs to incapacitate channels can be\n\u003e done on today's network at very little cost to an attacker. So far this\n\u003e doesn't seem to be happening in practice, but I believe that it is only a\n\u003e matter of time before it will become a real issue.\n\u003e\n\u003e Rate limits and other limits such as the maximum number of in-flight HTLCs\n\u003e increase the cost of an attack, but may also limit the capabilities of\n\u003e honest users. It works as a mitigation, but it doesn't seem to be the ideal\n\u003e solution.\n\u003e\n\u003e We've looked at all kinds of trustless payment schemes to keep users\n\u003e honest, but it appears that none of them is satisfactory. Maybe it is even\n\u003e theoretically impossible to create a scheme that is trustless and has all\n\u003e the properties that we're looking for. (A proof of that would also be\n\u003e useful information to have.)\n\u003e\n\u003e Perhaps a small bit of trust isn't so bad. There is trust in Lightning\n\u003e already. For example when you open a channel, you trust (or hope) that your\n\u003e peer remains well connected, keeps charging reasonable fees, doesn't\n\u003e force-close in a bad way, etc.\n\u003e\n\u003e What I can see working is a system where peers charge each other a hold\n\u003e fee for forwarded HTLCs based on the actual lock time (not the maximum lock\n\u003e time) and the htlc value. This is just for the cost of holding and separate\n\u003e from the routing fee that is earned when the payment settles.\n\u003e\n\u003e This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).\n\u003e fee_base is in there to compensate for the usage of an htlc slot, which is\n\u003e a scarce resource too.\n\u003e\n\u003e I think the implementation of this is less interesting at this stage, but\n\u003e some ideas are:\n\u003e\n\u003e A. Prepayment: node pays an amount to its channel peer (for example via\n\u003e keysend) and the channel peer deducts the hold fees from that prepaid\n\u003e balance until it is at zero. At that point it somehow (in the htlc fail\n\u003e message?) communicates Lightning's version of http 402 to ask for more\n\u003e money.\n\u003e\n\u003e B. Tightly integrated with the htlc add/fail/settle messages. When an htlc\n\u003e is added, the maximum cost (based on maximum lock time) for holding is\n\u003e deducted from the sender's channel balance. When the htlc settles, a refund\n\u003e is given based on the actual lock time. An additional `update_fee`-like\n\u003e message is added for peers to update their hold fee parameters (fee_base\n\u003e and fee_rate).\n\u003e\n\u003e In both cases the sender needs to trust its peer to not steal the payment\n\u003e and/or artificially delay the forwarding to inflate the hold fee. I think\n\u003e that is acceptable given that there is a trust relation between peers\n\u003e already anyway.\n\u003e\n\u003e A crucial thing is that these hold fees don't need to be symmetric. A new\n\u003e node for example that opens a channel to a well-known, established routing\n\u003e node will be forced to pay a hold fee, but won't see any traffic coming in\n\u003e anymore if it announces a hold fee itself. Nodes will need to build a\n\u003e reputation before they're able to command hold fees. Similarly, routing\n\u003e nodes that have a strong relation may decide to not charge hold fees to\n\u003e each other at all.\n\u003e\n\u003e This asymmetry is what is supposed to prevent channel jamming attacks. The\n\u003e attacker needs to pay hold fees to send out the payment, but when it comes\n\u003e back to the attacker after traversing a circular route, they won't be able\n\u003e to charge a hold fee to cancel out the hold fee paid at the start of the\n\u003e route. (Assuming the attacker node is not trusted.)\n\u003e\n\u003e A consequence for honest users is that payment attempts are no longer\n\u003e free. The cost should however be negligible for fast-failing attempts. Also\n\u003e senders will have to be a lot more selective when building a route.\n\u003e Selecting a 'black hole' hop (hop that doesn't forward nor fail) can be\n\u003e costly.\n\u003e\n\u003e The hold fee scheme is a bit looser compared to previously proposed\n\u003e schemes (as far as I know...). It is purely an arrangement between channel\n\u003e peers and doesn't try to exactly compensate every hop for its costs.\n\u003e Instead trust relations that arguably exist already are leveraged to\n\u003e present a bill to the actor who deserves it.\n\u003e\n\u003e Interested to hear opinions about this proposal.\n\u003e\n\u003e I'd also like to encourage everyone to prioritize this spam/jam issue and\n\u003e dedicate more time to solving it. Obviously there is a lot more to do in\n\u003e Lightning, but I am not sure if we can afford to wait for the real\n\u003e adversaries to show up on this one.\n\u003e\n\u003e Cheers,\n\u003e Joost\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/20201015/75e1091b/attachment.html\u003e"}