Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
BOLT 04: document non-strict forwarding #503
This PR documents the allowance of non-strict
It also includes recommendations for fee schedules
I understand this will increase the complexity but I am wondering weather it would make sense to allow for local base AMP at this point. Let us assume I am supposed to forward 0.1 BTC I have two channels to the same node each with 0.15 BTC capacity and 0.075 on my side of the channel.
How ever if the node was allowed to fragment the payment to make a base AMP for only the next hope (as far as I understand not compatible with our current Base AMP proposal (c.f.: #511 since the next hope is not the final node and we can also not alter the rest of the onion package to be cloned for two paths)
still if locally we were able to fragment it would be nice.
in particular the fragmentation could be extended. Let us assume I have only one chanel with capacity of 0.15 and are supposed to forward 0.1 BTC but my balance says 0.075. In that case I could make a local AMP to the next hop with .05 BTC and try myself to find another route with 0.05 to forward to the next hope on a best effort base. This would actually mean that while routing nodes that run into capacity issues will try to locally solve the issue.
One issue with this suggestion is that There are probably not enough fees to send part of the htlcs to be forwarded through a different path. This issue could probably be mitigated by putting higher fees at every onion hop if fragmentation was allowed. (similar issues exist with htlc time delays for the entire package)
I guess that a complete local "allow fragmentation and best effort routing protocol will involve to many changes. I still think that In the case described above where I have 2 channels and I could do a local split where as by selecting either channel I could not forward the payment would be a nice and feasible addtion to what we have agreed on in Australia.
It appears that all implementations forward non-strictly, so that would make a feature bit obsolete.