Open ariard opened 4 years ago
This could also allow live-rebalancing on the client's end, which would be cool.
Also fix current bug : https://github.com/rust-bitcoin/rust-lightning/pull/633#discussion_r485199875
Note that the bug at https://github.com/rust-bitcoin/rust-lightning/pull/633#discussion_r485199875 has been fixed in #690.
Might serve to address few timing attacks : https://github.com/rust-bitcoin/rust-lightning/pull/975#discussion_r661896452
Might serve as iptables for routing nodes : https://github.com/rust-bitcoin/rust-lightning/pull/975#discussion_r661903063
Maybe also addressing that at the same time : https://github.com/rust-bitcoin/rust-lightning/pull/1119#discussion_r732304989
May need to rely on #1302
Turns out we're not gonna rely on this for #1302, so there's no reason for this to have a very-soon milestone.
Currently, we apply both BOLT-2 incoming channels settings checks and BOLT-4 relay checks at
update_add_htlc
reception. We should split relay checks and get incoming HTLC acceptance generate aEvent::PendingHTLCsRelayable
. This event could be consumed byprocess_pending_htlc_relayable
and should generate aPendingHTLCsForwardable
. In between any kind of client custom function can be implemented support for stricter relay policy, on-the-flight generated outgoing zero-conf channel, delayed relay, trampoline-style of routing, ...See further https://github.com/rust-bitcoin/rust-lightning/pull/670 and http://gnusha.org/rust-bitcoin/.