Good morning Christian, First:
> Like mentioned above the entire job of trampolines is to provide base > routing capability, and we should not make special provisions for myopic > trampoline nodes, since routing is their entire reason for existence :-) The point of providing this special provision is to increase the anonymity set of full-routemap nodes. Suppose we were to require that myopic routing nodes fail if they are unable to see the next trampoline. Then it becomes possible to profile the network and identify full-routemap vs. myopic routing nodes. Myopic routing nodes are more likely to fail than full-routemap nodes. In particular, full-routemap nodes are particularly juicy targets for attackers who wish to disrupt the Lightning Network once the LN grows in size. This is even worse if we end up proposing that full-routemap nodes announce themselves as such on gossip. Then attackers do not even need to profile the network; listening to gossip is enough to identify full-routemap targets to attack. In a world where we allow myopic routing nodes to delegate instead of fail, then it becomes much harder for a third party to profile the network. Myopic routing nodes would only have slightly higher failure rate than full-routemap nodes, possibly within the noise level, making it hard for third parties to definitely differentiate full-routemap nodes from myopic routing nodes. Anonymity loves company, and the protection of the deity Anonymous is a tremendous boon in sustaining systems from attack and censure. Another advantage of allowing myopic routing nodes to delegate is that it allows myopia to be a relative condition rather than a binary "either I know the whole routemap or not". That is, I can have 90%, 75%, 50%, 25%, 10$, or 1% of the routemap, and still I can participate in supporting the network by at least helping route to those nodes that I can route to, or delegating to someone else who might know that part of the network better than I do. This provides more graceful degradation of service than the binary "full-routemap or not" you propose. In particular, as the LN grows, fewer and fewer nodes will be able to have a full routemap, and they will have larger and larger targets painted on their back as points of attack. Another point: > I think we should not try to recover from a node not finding the next > hop in the trampoline, and rather expect trampolines to have reasonable > uptime (required anyway) and have an up to date routing table But with myopic trampoline nodes, the only requirement is high uptime; completeness of the routing table becomes unimportant. This means that selecting good trampoline nodes only requires one desiderata (high uptime). In particular, high uptime can be easily measured (just attempt to connect or ping), but completeness of routing table is not. Then: > (that's > what we're paying them for after all). This contradicts your position in the other sub-thread of this topic: > This is not an issue. Like we discussed for the multi-part payments the HTLCs > still resolve correctly, though node B might chose to short circuit the > payment it'll also clear the HTLCs through E And D (by failing them instead > of settling them) but the overall payment remains atomic and end-to-end > secure. The skipped nodes (which may include the trampoline) may lose a bit > of fees, but that is not in any way different than a failed payment attempt > that is being retried from the sender :-) In that case, E is a full-routemap node, while B may or may not be a full-routemap node, but B gets paid (more!) while E does not. E took the effort to find a route while all B did was pass the onion to the next. What gives? But regardless --- I would like to point out that it is still incentive-compatible to support myopic trampoline nodes, and that full-routemap nodes will be paid much more than a myopic trampoline node. Suppose a trampoline node is a full-routemap node. In exchange for the service of providing routes, it expects to be allocated a higher fee. Then the routing fee of nodes between it and the next trampoline node are deducted from the fee allocated to it. In particular, it will refuse to continue payment if it does not get a higher-than-normal fee for its own hop. After all, it must be paid for this service, as you insist. Suppose a trampoline node is a myopic node, that knows the next trampoline is not in its routemap, but considers that another node (the delegatee) is more likely to know the next trampoline that it does. In such a case, that myopic node would consider it more optimal to allocate only a small amount of fee for its own hop and to devote most of the fee to the delegatee. This increases the chance that the delegatee, if it knows the route to the next trampoline, will accept and continue routing. Its alternative would be to allocate too low a fee to the delegatee, leading the delegatee to reject the routing, which means the myopic node itself earns nothing as the payment fails. Thus the myopic node is paid, but the full-routemap node can demand to be paid more. The myopic nodes are paid, not for routing, but for the ***increased anonymity set*** that protects the full-routemap node from attack. The full-routemap node is paid for the actual effort of routing (once we switch to payment points/scalars to prevent short-circuits that can prevent full-routemap node from being paid). Let me espouse the "peer-to-peer" principle: Nodes should treat other nodes uniformly, regardless of the resources available to that node (including memory space available for routemaps), in order to prevent divisions of the network that may be used to enable targeted attacks. Or: the nail that sticks out gets DDoS'ed down. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
