Hi Laolu and Fabrice, > I think HORNET would address this rather nicely!
HORNET sounds awesome, but does it really address the specific issue Fabrice is describing though? IIUC, HORNET would operate at a lower layer and it could be possible to have a valid circuit and still indefinitely waiting for a revocation. OTOH it certainly would address the case where the peer is completely unresponsive. For example, I have already seen peers which don't send revocations, but e.g. respond to pings just fine. Actually, re-reading Fabrice's proposal I wonder if one could make the same comment about it. Would the 0-satoshi payment require the commit_sig/revoke_and_ack dance? If not, would we really gain more confidence in the availability of the peers in the route? >> It is already possible to partially mitigate this by disconnecting from a node that is taking too long to send a revocation (after 30 seconds for example) Actually I think this would substantially improve the issue at hand. I believe we should probably add this to BOLT 2 in the form of a "SHOULD" clause. I feel bad because in [1] I suggested doing just that in lnd, but we don't actually do it in eclair :-/ Will eat my own dog food asap! Cheers, Pierre [1] https://github.com/lightningnetwork/lnd/issues/2045#issuecomment-429561637 _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
