{"type":"rich","version":"1.0","title":"Nadav Kohen [ARCHIVE] wrote","author_name":"Nadav Kohen [ARCHIVE] (npub1ge…rtua0)","author_url":"https://yabu.me/npub1geqdlge6ysz9qlq3w758422flnkgqklpu9veu80ehjprcd04ugyqkrtua0","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-04-02\n📝 Original message:\nGood morning ZmnSCPxj,\n\n\u003e The consideration is that much of the cost of a channel is with the setup\nand teardown --- E could always just reopen the CE channel again later.\n\u003e Thus, the cost that E bears in setting up EE and tearing down EE would be\nstill similar to the cost of losing CE and reestablishing it again.\n\u003e Further, any amount it places in the EE channel would be an amount it\ncould have been using as liquidity on Lightning, but which it cannot use\nfor forwarding (because it is a channel to nowhere).\n\u003e Ultimately, proof-of-closure is an economic mechanism, not an\ninformation-theoretic one.\n\nOkay, I see what you mean now but I'm still a bit worried due to the\nfollowing: although it is true that the same nominal penalty is incurred,\nthe real economic value for the attacker in channel E-E' is significantly\nless than that in A-E, which can be used for routing. As such, a rich\nattacker who wishes to crowd out their competition might occasionally open\nchannels with themselves equal to the value needed to lock up a\ncompetitor's channels, then do such a payment to themselves (with a high\n\"hard\" locktime) and close their temporary channel, but still hold their\ncompetitor's funds hostage, and still have enough liquidity in the channels\nthey didn't have to close in order to facilitate all routing that was done\nby their competitor. Furthermore this route (for self-payment) could attack\nmultiple competitors at the same time (likely leaving some funds to all but\nthe least liquid competitor).\n\nI could be missing something, but it seems to me like the proposal to close\nchannels after a soft timeout unless non-cooperation can be proven upstream\nadds a cost to the attacker of two on-chain transactions, which they can\nimmediately revoke (as they know both pieces to the revocation priv key),\nbut still allows very long lock-ups of other's funds (with a 10x multiplier\nif they choose a long route). I do think that this is certainly an\nimprovement on what we have now but I'm not sure it properly punishes the\nattacker in its current form.\n\n\u003e Since this is a proof-of-***closure***, this is indeed an actual closing\nof the channel.\n\nAh I see, I was misunderstanding a couple things, but I get it now, makes\nsense :)\n\nBest,\nNadav\n\nOn Wed, Apr 1, 2020 at 7:43 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Nadav,\n\u003e\n\u003e\n\u003e \u003e Love the idea! I have a couple questions though:\n\u003e \u003e\n\u003e \u003e I'm not convinced that \"Purely Falsified Proof-Of-Closure\" aren't\n\u003e effective. Consider a similar network to the one you described where we\n\u003e have channels A - B - C and A - E - C but where we add a \"fake\" channel E -\n\u003e E'. Now if the attacker sets up a payment from E to E' using the route E -\n\u003e C - B - A - E - E', then the attacker can successfully lock up all of B's\n\u003e channels (as is desirable to get rid of competition) and also generate a\n\u003e false proof of closure for the E - E' channel. Even if this false proof\n\u003e (which is a commitment tx) ends up being published on chain, E has lost no\n\u003e ability to route and has successfully made B unable to route between A and\n\u003e C. If my understanding of the proposal is correct, and it may not be, then\n\u003e the punishment for grieving payments is the threat of closing channels that\n\u003e would benefit from the grieving attack. But adding a new channel on the end\n\u003e to be closed seems to invalidate this punishment?\n\u003e\n\u003e The consideration is that much of the cost of a channel is with the setup\n\u003e and teardown --- E could always just reopen the CE channel again later.\n\u003e Thus, the cost that E bears in setting up EE and tearing down EE would be\n\u003e still similar to the cost of losing CE and reestablishing it again.\n\u003e Further, any amount it places in the EE channel would be an amount it\n\u003e could have been using as liquidity on Lightning, but which it cannot use\n\u003e for forwarding (because it is a channel to nowhere).\n\u003e Ultimately, proof-of-closure is an economic mechanism, not an\n\u003e information-theoretic one.\n\u003e\n\u003e So the mere existence of EE, to be later sacrificed, is enough punishment\n\u003e on E.\n\u003e I think.\n\u003e\n\u003e \u003e\n\u003e \u003e A second question I have is if you think that it would be advisable to\n\u003e use up-front payments (pay for attempt, not just success) on payments with\n\u003e abnormally high soft timeouts? If all this works, this combination seems to\n\u003e be a way to enable hodl invoices under the proof of closure proposal.\n\u003e\n\u003e Possibly, though this increases the complexity of the proposal even more.\n\u003e\n\u003e \u003eI just thought of a potentially more serious problem, at least for\n\u003e Poon-Dryja channels, isn't it true that giving a proof of closure is\n\u003e equivalent to actually closing the channel since once other parties have\n\u003e copies of the fully signed commitment transaction, it cannot be safely\n\u003e revoked since other parties now have the ability to publish an old state? I\n\u003e might be missing something but this seems like a big problem.\n\u003e\n\u003e Since this is a proof-of-***closure***, this is indeed an actual closing\n\u003e of the channel.\n\u003e It would not be proof-of-closure if the channel was not being closed, but\n\u003e proof-of-something-else.\n\u003e\n\u003e What is desired is simply that C can plausibly say \"I punished somebody\n\u003e else by closing on them, please do not punish me for punishing them\".\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200402/b6b6749a/attachment.html\u003e"}