{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-10-22\n📝 Original message:\nGood morning list,\n\nSorry in advance for the lengthy email, but I think it's worth detailing my\nhybrid proposal\n(bidirectional upfront payments), it feels to me like a workable solution\nthat builds on\nprevious proposals. You can safely ignore the details at the end of the\nemail and focus only on\nthe high-level mechanism at first.\n\nLet's consider the following route: A -----\u003e B -----\u003e C -----\u003e D\n\nWe add a `hold_grace_period_delta` field to `channel_update` (in seconds).\nWe add two new fields in the tlv extension of `update_add_htlc`:\n\n* `hold_grace_period` (seconds)\n* `hold_fees` (msat)\n\nWe add an `outgoing_hold_grace_period` field in the onion per-hop payload.\n\nWhen nodes receive an `update_add_htlc`, they verify that:\n\n* `hold_fees` is not unreasonable large\n* `hold_grace_period` is not unreasonably small or large\n* `hold_grace_period` - `outgoing_hold_grace_period` \u003e=\n`hold_grace_period_delta`\n\nOtherwise they immediately fail the HTLC instead of relaying it.\n\nFor the example we assume all nodes use `hold_grace_period_delta = 10`.\n\nWe add a forward upfront payment of 1 msat (fixed) that is paid\nunconditionally when offering an HTLC.\nWe add a backwards upfront payment of `hold_fees` that is paid when\nreceiving an HTLC, but refunded\nif the HTLC is settled before the `hold_grace_period` ends (see footnotes\nabout this).\n\n* A sends an HTLC to B:\n* `hold_grace_period = 100 sec`\n* `hold_fees = 5 msat`\n* `next_hold_grace_period = 90 sec`\n* forward upfront payment: 1 msat is deduced from A's main output and added\nto B's main output\n* backwards upfront payment: 5 msat are deduced from B's main output and\nadded to A's main output\n* B forwards the HTLC to C:\n* `hold_grace_period = 90 sec`\n* `hold_fees = 6 msat`\n* `next_hold_grace_period = 80 sec`\n* forward upfront payment: 1 msat is deduced from B's main output and added\nto C's main output\n* backwards upfront payment: 6 msat are deduced from C's main output and\nadded to B's main output\n* C forwards the HTLC to D:\n* `hold_grace_period = 80 sec`\n* `hold_fees = 7 msat`\n* `next_hold_grace_period = 70 sec`\n* forward upfront payment: 1 msat is deduced from C's main output and added\nto D's main output\n* backwards upfront payment: 7 msat are deduced from D's main output and\nadded to C's main output\n\n* Scenario 1: D settles the HTLC quickly:\n* all backwards upfront payments are refunded (returned to the respective\nmain outputs)\n* only the forward upfront payments have been paid (to protect against\n`uncontrolled spam`)\n\n* Scenario 2: D settles the HTLC after the grace period:\n* D's backwards upfront payment is not refunded\n* If C and B relay the settlement upstream quickly (before\n`hold_grace_period_delta`) their backwards\nupfront payments are refunded\n* all the forward upfront payments have been paid (to protect against\n`uncontrolled spam`)\n\n* Scenario 3: C delays the HTLC:\n* D settles before its `grace_period`, so its backwards upfront payment is\nrefunded by C\n* C delays before settling upstream: it can ensure B will not get refunded,\nbut C will not get\nrefunded either so B gains the difference in backwards upfront payments\n(which protects against\n`controlled spam`)\n* all the forward upfront payments have been paid (to protect against\n`uncontrolled spam`)\n\n* Scenario 4: the channel B \u003c-\u003e C closes:\n* D settles before its `grace_period`, so its backwards upfront payment is\nrefunded by C\n* for whatever reason (malicious or not) the B \u003c-\u003e C channel closes\n* this ensures that C's backwards upfront payment is paid to B\n* if C publishes an HTLC-fulfill quickly, B may have his backwards upfront\npayment refunded by A\n* if B is forced to wait for his HTLC-timeout, his backwards upfront\npayment will not be refunded\nbut it's ok because B got C's backwards upfront payment\n* all the forward upfront payments have been paid (to protect against\n`uncontrolled spam`)\n\nIf done naively, this mechanism may allow intermediate nodes to deanonymize\nsender/recipient.\nIf the base `grace_period` and `hold_fees` are randomized, I believe this\nattack vector disappears,\nbut it's worth exploring in more details.\n\nThe most painful part of this proposal will be handling the `grace_period`:\n\n* when do you start counting: when you send/receive `update_add_htlc`,\n`commit_sig` or\n`revoke_and_ack`?\n* what happens if there is a disconnection (how do you account for the\ndelay of reconnecting)?\n* what happens if the remote settles after the `grace_period`, but refunds\nhimself when sending his\n`commit_sig` (making it look like from his point of view he settled before\nthe `grace_period`)?\nI think in that case the behavior should be to give your peers some leeway\nand let them get away\nwith it, but record it. If they're doing it too often, close channels and\nban them; stealing\nupfront fees should never be worth losing channels.\n\nI chose to make the backwards upfront payment fixed instead of scaling it\nbased on the time an HTLC\nis left pending; it's slightly less penalizing for spammers, but is less\ncomplex and introduces less\npotential griefing against honest nodes. With the scaling approach, an\nhonest node that has its\nchannel unilaterally closed is too heavily penalized IMHO (because it has\nto pay for the maximum\nhold duration).\n\nI also chose to make the forward upfront payment constant (1 msat). Is it\ngoing to be a pain to\nbikeshed this constant? Do we need to add a mechanism to upgrade it? We\ndon't want to make this\nmore complex than it should.\n\nBefore we dive into the specifics (addressing the implementation concerns),\ncan you all please take\na bit of time to figure out whether the proposed mechanisms would mitigate\nspam or not, and whether\nit introduces griefing attacks against honest nodes. I think it would be a\nwaste of your time to\nbikeshed the nuts and bolts details if the proposal is fundamentally\nbroken...\n\nAnswering to previous emails below.\n\nYour proposal to add a small upfront payment, wouldn't that allow the\n\u003e (arbitrary) grace period to be removed?\n\n\nI think we need a `grace_period` for the backwards upfront payment, to\nencourage nodes to settle\nquickly (otherwise I believe it's too easy to grief honest nodes because\nthe backwards upfront payment\nwill be bigger than the forward one - because `uncontrolled spam` is based\non volume so it doesn't\nneed a huge fee to mitigate).\n\nWould my inane incremental routing idea also be in scope here?\n\n\nIt could potentially be easier to integrate spam mitigation inside\nincremental routing, indeed.\nBut I think this proposal is unfortunately very costly in terms of\nlatency...\n\nThanks everyone,\nBastien\n\nLe mer. 21 oct. 2020 à 05:21, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning t-bast,\n\u003e\n\u003e \u003e\n\u003e \u003e I've started summarizing proposals, attacks and threat models on github\n\u003e [1].\n\u003e \u003e I'm hoping it will help readers get up-to-speed and avoid falling in the\n\u003e same pitfalls we already\n\u003e \u003e fell into with previous proposals.\n\u003e\n\u003e Would my inane incremental routing idea also be in scope here?\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002811.html\n\u003e\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201022/4a7c0856/attachment.html\u003e"}