Ariel Luaces [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-29 📝 Original message: > I am forking this ...

📅 Original date posted:2019-03-29
📝 Original message:
> I am forking this thread as my reply is not at all related to the JIT-Routing.

Sorry I think my last reply was also getting off subject as well.
Thank you for forking the thread

> Nonexistent channels (i.e. channels that do not have some backing UTXO in the Bitcoin blockchain) are not safe to propagate on the network since they are trivially spammable (i.e. can generate a large number of fake channels to waste network bandwidth).

I hadn't considered the effect this gossip would have on the network.
Definitely nodes should not trust one another to tell the truth about
nonexistent channels.

The source node could blindly allow intermediate nodes to create
sub-routes to the next hop.
But I wouldn't favor this blind routing idea because fee calculations
would be a complete guesses.

> A good pruning heuristic is "channel capacity", which can be checked onchain (the value of the UTXO backing the channel is the channel capacity).
> It is good to keep channels with large capacity in the routemap, because such large channels are more likely to successfully route a payment than smaller channels.
> So it is reasonable to delete channels with low capacity when the routemap memory is becoming close to full.

I'm generally concerned about these heuristics because any time nodes
can game a heuristic they will be expected to do so.
Gaming a heuristic can be good or bad depending on the side-effects.
One side effect of the "channel capacity" heuristic is more reliable
payments but another side effect is that low capacity (but possibly
reliable) channels are neglected.

> It seems to me that s/aggregate-channel/high-capacity-channel/g in your idea would still work.
> In effect, the high-capacity channel is very likely to successfully route in either direction.
> But if by chance it falls into a state where it is unable to route in one direction or other, the intermediate node has other, lower-capacity channels that it can use JIT-Routing with to improve the directionality of the high-capacity channel.
> Nothing in the JIT-Routing idea requires that the rebalancing loop is small, only that a loop exists.
>
> Nodes still need to track their direct channels (so they are implicitly always in the routemap).
> But payee nodes making BOLT1 invoices could also provide `r` routes in the invoice, with the given routes being from nodes with high-capacity channels, so that even if the intermediate channels are pruned due to low capacity, it is possible to get paid.

Without low capacity channels spontaneous payments would not work. Or
they would depend on asking for an invoice under the hood.
It feels to me that at some point, someone with complete knowledge of
the network needs to be employed.

Cheers
Ariel Lorenzo-Luaces