PING, It seems like ensuring reliability is going to involve nodes taking active measures like probing routes fairly regularly. Maybe it would be worth making that more efficient? For example, a risk of probing is that if the probe discovers a failing node/channel, the probe HTLC will get stuck, and have to gradually timeout, which at least uses up HTLC slots and memory for each of the well-behaved nodes, but if the probe has a realistic value rather than just a few (milli)satoshis, it might lock up real money too.
It might be interesting to allow for cancelling stuck probes from the sending direction as well as the receiving direction. eg if the payment hash wasn't generated as SHA256("something") but rather as SHA256("something") XOR 0xFF..FF or similar, then everyone can safely drop the incoming transaction because they know that even if they forwarded the tx, it will be refunded eventually anyway (or otherwise sha256 is effectively broken and they're screwed anyway). So all I have to do is send a packet saying this was a probe, and telling you the "something" to verify, and I can free up the slot/funds from my probe, as can everyone else except for the actual failing nodes. >From the perspective of the sending node: generate 128b random number X calculate H=bitwise-not(SHA256(X)) make probe payment over path P, hash H, amount V wait for response: - success: Y, s.t. SHA256(Y)=H=not(SHA256(X)) -- wtf, sha is broken - error, unknown hash: path works - routing failed: mark failing node, reveal X cancelling HTLC - timeout: mark path as failed (?), reveal X cancelling HTLC Cheers, aj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev