Good morning ZmnSCPxj, > The consideration is that much of the cost of a channel is with the setup and teardown --- E could always just reopen the CE channel again later. > Thus, the cost that E bears in setting up EE and tearing down EE would be still similar to the cost of losing CE and reestablishing it again. > Further, any amount it places in the EE channel would be an amount it could have been using as liquidity on Lightning, but which it cannot use for forwarding (because it is a channel to nowhere). > Ultimately, proof-of-closure is an economic mechanism, not an information-theoretic one.
Okay, I see what you mean now but I'm still a bit worried due to the following: although it is true that the same nominal penalty is incurred, the real economic value for the attacker in channel E-E' is significantly less than that in A-E, which can be used for routing. As such, a rich attacker who wishes to crowd out their competition might occasionally open channels with themselves equal to the value needed to lock up a competitor's channels, then do such a payment to themselves (with a high "hard" locktime) and close their temporary channel, but still hold their competitor's funds hostage, and still have enough liquidity in the channels they didn't have to close in order to facilitate all routing that was done by their competitor. Furthermore this route (for self-payment) could attack multiple competitors at the same time (likely leaving some funds to all but the least liquid competitor). I could be missing something, but it seems to me like the proposal to close channels after a soft timeout unless non-cooperation can be proven upstream adds a cost to the attacker of two on-chain transactions, which they can immediately revoke (as they know both pieces to the revocation priv key), but still allows very long lock-ups of other's funds (with a 10x multiplier if they choose a long route). I do think that this is certainly an improvement on what we have now but I'm not sure it properly punishes the attacker in its current form. > Since this is a proof-of-***closure***, this is indeed an actual closing of the channel. Ah I see, I was misunderstanding a couple things, but I get it now, makes sense :) Best, Nadav On Wed, Apr 1, 2020 at 7:43 PM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > Good morning Nadav, > > > > Love the idea! I have a couple questions though: > > > > I'm not convinced that "Purely Falsified Proof-Of-Closure" aren't > effective. Consider a similar network to the one you described where we > have channels A - B - C and A - E - C but where we add a "fake" channel E - > E'. Now if the attacker sets up a payment from E to E' using the route E - > C - B - A - E - E', then the attacker can successfully lock up all of B's > channels (as is desirable to get rid of competition) and also generate a > false proof of closure for the E - E' channel. Even if this false proof > (which is a commitment tx) ends up being published on chain, E has lost no > ability to route and has successfully made B unable to route between A and > C. If my understanding of the proposal is correct, and it may not be, then > the punishment for grieving payments is the threat of closing channels that > would benefit from the grieving attack. But adding a new channel on the end > to be closed seems to invalidate this punishment? > > The consideration is that much of the cost of a channel is with the setup > and teardown --- E could always just reopen the CE channel again later. > Thus, the cost that E bears in setting up EE and tearing down EE would be > still similar to the cost of losing CE and reestablishing it again. > Further, any amount it places in the EE channel would be an amount it > could have been using as liquidity on Lightning, but which it cannot use > for forwarding (because it is a channel to nowhere). > Ultimately, proof-of-closure is an economic mechanism, not an > information-theoretic one. > > So the mere existence of EE, to be later sacrificed, is enough punishment > on E. > I think. > > > > > A second question I have is if you think that it would be advisable to > use up-front payments (pay for attempt, not just success) on payments with > abnormally high soft timeouts? If all this works, this combination seems to > be a way to enable hodl invoices under the proof of closure proposal. > > Possibly, though this increases the complexity of the proposal even more. > > >I just thought of a potentially more serious problem, at least for > Poon-Dryja channels, isn't it true that giving a proof of closure is > equivalent to actually closing the channel since once other parties have > copies of the fully signed commitment transaction, it cannot be safely > revoked since other parties now have the ability to publish an old state? I > might be missing something but this seems like a big problem. > > Since this is a proof-of-***closure***, this is indeed an actual closing > of the channel. > It would not be proof-of-closure if the channel was not being closed, but > proof-of-something-else. > > What is desired is simply that C can plausibly say "I punished somebody > else by closing on them, please do not punish me for punishing them". > > Regards, > ZmnSCPxj > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
