{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-18\n📝 Original message:\n\u003e\n\u003e \u003e We've looked at all kinds of trustless payment schemes to keep users\n\u003e\n\u003e \u003e honest, but it appears that none of them is satisfactory. Maybe it is\n\u003e even\n\u003e \u003e theoretically impossible to create a scheme that is trustless and has\n\u003e all\n\u003e \u003e the properties that we're looking for. (A proof of that would also be\n\u003e\n\u003e \u003e useful information to have.)\n\u003e\n\u003e I don't think anyone has drawn yet a formal proof of this, but roughly a\n\u003e routing peer Bob, aiming to prevent resource abuse at HTLC relay is seeking\n\u003e to answer the following question \"Is this payment coming from Alice and\n\u003e going to Caroll will compensate for my resources consumption ?\". With the\n\u003e current LN system, the compensation is conditional on payment settlement\n\u003e success and both Alice and Caroll are distrusted yet discretionary on\n\u003e failure/success. Thus the underscored question is undecidable for a routing\n\u003e peer making relay decisions only on packet observation.\n\u003e\n\u003e One way to mitigate this, is to introduce statistical observation of\n\u003e sender/receiver, namely a reputation system. It can be achieved through a\n\u003e scoring system, web-of-trust, or whatever other solution with the same\n\u003e properties.\n\u003e But still it must be underscored that statistical observations are only\n\u003e probabilistic and don't provide resource consumption security to Bob, the\n\u003e routing peer, in a deterministic way. A well-scored peer may start to\n\u003e suddenly misbehave.\n\u003e\n\u003e In that sense, the efficiency evaluation of a reputation-based solution to\n\u003e deter DoS must be evaluated based based on the loss of the reputation\n\u003e bearer related to the potential damage which can be inflicted. It's just\n\u003e reputation sounds harder to compute accurately than a pure payment-based\n\u003e DoS protection system.\n\u003e\n\nI can totally see the issues and complexity of a reputation-based system.\nWith 'trustless payment scheme' I meant indeed a trustless pure\npayment-based DoS protection system and the question whether such a system\ncan be proven to not exist. A sender would pay an up-front amount to cover\nthe maximum cost, but with the guarantee that nodes can only take a fair\npart of the deposit (based on actual lock time). Perhaps the taproot\nupgrade offers new possibilities with adaptor signatures to atomically swap\npart of the up-front payment with htlc-received-in-time-signatures from\nnodes downstream (random wild idea).\n\n\n\u003e \u003e What I can see working is a system where peers charge each other a hold\n\u003e fee\n\u003e \u003e for forwarded HTLCs based on the actual lock time (not the maximum lock\n\u003e\n\u003e \u003e time) and the htlc value. This is just for the cost of holding and\n\u003e separate\n\u003e \u003e from the routing fee that is earned when the payment settles\n\u003e\n\u003e Yes I guess any solution will work as long as it enforces an asymmetry\n\u003e between the liquidity requester and a honest routing peer. This asymmetry\n\u003e can be defined as guaranteeing that the routing peer's incoming/outgoing\n\u003e balance is always increasing, independently of payment success. Obviously\n\u003e this increase should be materialized by a payment, while minding it might\n\u003e be discounted based on requester reputation (\"pay-with-your-reputation\").\n\u003e This reputation evaluation can be fully delegated to the routing node\n\u003e policy, without network-wise guidance.\n\u003e\n\u003e That said, where I'm skeptical on any reputation-heavy system is on the\n\u003e long-term implications.\n\u003e\n\u003e Either, due to the wants of a subset of actors deliberately willingly to\n\u003e trade satoshis against discounted payment flow by buying well-scored\n\u003e pubkeys, we see the emergence of a reputation market. Thus enabling\n\u003e reputation to be fungible to satoshis, but with now a weird \"reputation\"\n\u003e token to care about.\n\u003e\n\u003e Or, reputation is too hard to make liquid (e.g hard to disentangle pubkeys\n\u003e from channel ownership or export your score across routing peers) and thus\n\u003e you now have reputation scarcity which is introducing a bias from a \"purer\"\n\u003e market, where agents are only routing based on advertised fees. IMO, we\n\u003e should strive for the more liquid Lightning market we can, as it avoids\n\u003e bias towards past actors and thus may contain centralization inertia. I'm\n\u003e curious about your opinion on this last point.\n\u003e\n\nI am in favor of more liquidity and less centralization, but as far as I\nknow the reality is that we don't have a good solution yet to achieve this\nwithout being vulnerable to DoS attacks. If those attacks would happen on a\nlarge scale today, what would we do?\n\nAlso peers can implement these trusted upfront payments without protocol\nchanges. Just stop forwarding when the prepaid forwarding budget is used up\nand require a top-up. It may have been implemented already in parts of the\nnetwork, I don't think there is a way to know. I've experimented a bit with\nthe fee model myself (\nhttps://twitter.com/joostjgr/status/1317546071984427009). Node operators\ndon't need to wait for permission.\n\nTo me it seems that the longer it takes to come up with a good anti-DoS\nsystem for Lightning, the further the outside world will have developed\ntheir trust-based systems and established that potential bias towards\ncentralization.\n\nThat might be another reason to prioritize this issue. Not just because we\nwant the network to be safe, but also to be able to implement the preferred\nsolution while the opportunity window is still open.\n\n- Joost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201018/6af64b5a/attachment.html\u003e"}