Good morning LL, > Back to the general topic. Perhaps a way of refining the proposal is the > following: > > 1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of > design. > 2. The owner (owners?) of leach LN UTXO can go to any node in the network and > request a kind of token for their UTXO (i.e. channel id).
Not all forwarding nodes have a directly-contactable address published, and many publish only an .onion address; many payers do not bother to run Tor and cannot directly contact .onion addresses. On the other hand, it would be possible to use an onion routing (without an attached HTLC) to remotely contact such forwarding nodes, and presumably other nodes will be willing to provide this almost for free since they would not need to lock up funds. > 3. When making a payment you present a randomized version of the token to > each node (it is not linkable to the UTXO) and prove that the UTXO it > represents is large enough to support the payment (the token and proof > protocol can hopefully be non-interactive so it can fit in the onion). > 4. If your HTLC fails your token is deleted (and have to wait some period > before requesting a new one). > 5. If your payment succeeds your token is renewed on the spot (and maybe > forwarded back along the path covertly). I think it should not be success or failure that matters. I can still mount the same attack by forwarding a payment to another node I control, with the last hop having a large timeout, waiting out the entire timeout, and then *succeeding* the payment just before the payment times out. The funds are still locked for nearly the entire timeout period, during which my competitors (whether as merchant or as forwarder node --- forwarder nodes are really just merchants of liquidity) are unable to use the liquidity during this timeout period. I end up paying fees, but the fees on Lightning are ridiculously tiny and may very well remain so for a good amount of time. Instead, a particular UTXO size provides so many msat-seconds of lockup credit. As a forwarding node, if I have issued a credential for a UTXO of particular size, offering so many msat-seconds of lockup, if I receive the unblinded credential, after I send out the outgoing HTLC, I measure its size and how long before it gets resolved (in either success or failure), multiply those together, and debit that particular credential. (it might be plausible for failure for me to add a little more extra surcharge to the msat-seconds credit of that credential, but nevertheless --- I must still treat a *slow* success as something as bad, or almost as bad, as a *slow* failure) If that credential later reappears on an incoming HTLC and it has been debited to 0 or negative, I just fail it without risking sending out my funds in an outgoing HTLC. This prevents the above trivial variation of the loop attack. However, this exacerbates the effects of accidental incompetence-based failures of other forwarding nodes. Otherwise I largely agree that anonymous credentials seems a better way to build stake certificates. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
