Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2018-01-03 📝 Original message: Yes, that's what I'm ...
📅 Original date posted:2018-01-03
📝 Original message:
Yes, that's what I'm suggesting, but I don't know if it's right or not.
I was assuming many small channels would be partially self regulating
because people would have to pay for more on chain transaction fees for
the opening and closing of the channels.
Andy Schroder
On 01/02/2018 08:11 AM, Christian Decker wrote:
> 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 <info at 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 <info at 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
>>>
Published at
2023-06-09 12:48:19Event JSON
{
"id": "e43876f594f59072004c3332cc5447978af339a76c2fd583245f279fb60ee32a",
"pubkey": "1c7d4637a4686939cc8b4a759caace11bb63bafb75b73b6f57d7ba81f9bd6a6c",
"created_at": 1686314899,
"kind": 1,
"tags": [
[
"e",
"c3be1db8263e66ee649d65e8c7919258d51350509bbff4385734c67e84754a40",
"",
"root"
],
[
"e",
"51af0c1e13f74fd0ccdf9878049f1d252e8537a1df815a01755289f1f5b371f7",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2018-01-03\n📝 Original message:\nYes, that's what I'm suggesting, but I don't know if it's right or not.\n\nI was assuming many small channels would be partially self regulating \nbecause people would have to pay for more on chain transaction fees for \nthe opening and closing of the channels.\n\n\nAndy Schroder\n\nOn 01/02/2018 08:11 AM, Christian Decker wrote:\n\u003e I see, are you suggesting that large channels could be an indicator of a\n\u003e large actor trying to attract a lot of payment traffic? Not sure whether\n\u003e that is really a good measure, since it is trivial for a large node to\n\u003e masquerade as any number of smaller nodes, thus hiding its size.\n\u003e\n\u003e We definitely want to discourage this kind of masquerades since it\n\u003e causes a lot more transactions on-chain and results in UTXO\n\u003e fragmentation. In addition what we actually try to guard against are\n\u003e hubs, which have a lot of channels open, not large ones :-)\n\u003e\n\u003e Cheers,\n\u003e Christian\n\u003e\n\u003e Andy Schroder \u003cinfo at AndySchroder.com\u003e writes:\n\u003e\u003e What you are saying makes perfect sense for the short term.\n\u003e\u003e\n\u003e\u003e What I am talking about could promote a big picture healthier network\n\u003e\u003e long term by discouraging \"super nodes\" in the network from existing, if\n\u003e\u003e you avoid making connections to nodes that have large channel capacities\n\u003e\u003e with other parties.\n\u003e\u003e\n\u003e\u003e Does this make sense?\n\u003e\u003e\n\u003e\u003e Andy Schroder\n\u003e\u003e\n\u003e\u003e On 01/01/2018 12:47 PM, Christian Decker wrote:\n\u003e\u003e\u003e Andy Schroder \u003cinfo at AndySchroder.com\u003e writes:\n\u003e\u003e\u003e\u003e I understand that you have to be in agreement with your direct peers. So\n\u003e\u003e\u003e\u003e you don't really care about what agreements others in your route may\n\u003e\u003e\u003e\u003e have in place? I would think that you would choose not to route through\n\u003e\u003e\u003e\u003e hops that violate your capacity limit.\n\u003e\u003e\u003e I'm failing to see why I'd care about a remote channel's capacity, aside\n\u003e\u003e\u003e from it being large enough to cover the amount I want to transfer. As a\n\u003e\u003e\u003e participant routing through a channel that has a higher capacity I do\n\u003e\u003e\u003e not incur any additional risk than from a smaller channel, since the\n\u003e\u003e\u003e payment is guaranteed to be atomic. In the contrary one could argue that\n\u003e\u003e\u003e a higher capacity channel has a higher probability of having sufficient\n\u003e\u003e\u003e capacity in the desired direction to forward my transfer.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Maybe I'm failing to see something? I always interpreted the limit as\n\u003e\u003e\u003e purely self-defense on how much value I'm confident enough to keep in a\n\u003e\u003e\u003e channel.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Cheers,\n\u003e\u003e\u003e Christian\n\u003e\u003e\u003e",
"sig": "9f52a760ab5aa429229511fa3b04ee03e0269a5ebbedc912ba1850d820844172953e1b17a64d072c2c0bf86815397c4710a6e6ad12d1f5c84750ebdabc62cfba"
}