I see, are you suggesting that large channels could be an indicator of a large actor trying to attract a lot of payment traffic? Not sure whether that is really a good measure, since it is trivial for a large node to masquerade as any number of smaller nodes, thus hiding its size.
We definitely want to discourage this kind of masquerades since it causes a lot more transactions on-chain and results in UTXO fragmentation. In addition what we actually try to guard against are hubs, which have a lot of channels open, not large ones :-) Cheers, Christian Andy Schroder <i...@andyschroder.com> writes: > What you are saying makes perfect sense for the short term. > > What I am talking about could promote a big picture healthier network > long term by discouraging "super nodes" in the network from existing, if > you avoid making connections to nodes that have large channel capacities > with other parties. > > Does this make sense? > > Andy Schroder > > On 01/01/2018 12:47 PM, Christian Decker wrote: >> Andy Schroder <i...@andyschroder.com> writes: >>> I understand that you have to be in agreement with your direct peers. So >>> you don't really care about what agreements others in your route may >>> have in place? I would think that you would choose not to route through >>> hops that violate your capacity limit. >> I'm failing to see why I'd care about a remote channel's capacity, aside >> from it being large enough to cover the amount I want to transfer. As a >> participant routing through a channel that has a higher capacity I do >> not incur any additional risk than from a smaller channel, since the >> payment is guaranteed to be atomic. In the contrary one could argue that >> a higher capacity channel has a higher probability of having sufficient >> capacity in the desired direction to forward my transfer. >> >> Maybe I'm failing to see something? I always interpreted the limit as >> purely self-defense on how much value I'm confident enough to keep in a >> channel. >> >> Cheers, >> Christian >> _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
