Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-10 📝 Original message: PING, It seems like ...

📅 Original date posted:2018-11-10
📝 Original message:
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