What is Nostr?
Gregorio Guidi [ARCHIVE] /
npub15y8ā€¦l0cx
2023-06-09 12:55:52
in reply to nevent1qā€¦35px

Gregorio Guidi [ARCHIVE] on Nostr: šŸ“… Original date posted:2019-08-14 šŸ“ Original message: On August 13, 2019 ...

šŸ“… Original date posted:2019-08-14
šŸ“ Original message:
On August 13, 2019 6:23:31 AM GMT+02:00, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>Good morning Gregorio,
>
>
>> We argue that in such scenario, in a network of n connected nodes,
>there is a tendency towards a state where exactly n-1 channels have
>perfectly balanced flows in the two directions ("self-balancing"
>channels), while all other channels are either unused, or have a
>permanent tendency towards imbalance: the channel balance accumulates
>at one end and the channel is only intermittently available in one
>direction ("stuttering" channels). We note that the "self-balancing"
>channels form a spanning tree of the network graph, which we call the
>"core spanning tree" of the payment network.
>
>I have observed this as well in my armchair.
>Indeed, the worst-case scenario for this would be a single central hub
>with n-1 channels to n-1 client nodes, with the hub itself as the nth
>node.
>
>Fortunately, it seems to me that such a steady state will mildly shift
>and additional channels will still be used intermittently.
>(I have not read your paper in completeness yet, only the abstract
>above, so if my ramblings have already been considered in your paper,
>do feel free to ignore me).

Indeed even in the abstract steady-state scenario described in the paper, more than n-1 channels are expected to be used (although intermittently).

But the more general point, anyway, is that no steady state will ever exist in practice. Thinking in terms of black and white in this case helped to clarify my thoughts around the problem (and makes for more elegant math :) ), and as sometimes happens it lets some useful knowledge emerge: this is in the end the spirit of the paper. I would say that your intuition about the continuously shifting equilibrium is in line with mine.

>For instance, consider a world where Lamborghini production experiences
>a paradigm shift that massively reduces the cost of production while
>increase quality.
>Inevitably, Lambo prices in terms of Bitcoin will decline, as a
>consequence of this improvement.
>Thus, capacity in channels going Lamborghini producers becomes
>underutilized as demand for the product saturates while supply
>increases.
>
> [...]
>
>Thus, I think that the minimum of n-1 channels would not remain stable
>for long, given an actual real-world where change *is* the
>steady-state.
>Assuming a continuously thriving and innovating global economy, we will
>expect that there will be transient situations where demand and supply
>for various products changes wildly.
>In such situations, any "extra, unneeded" channels would end up
>catching the additional capacity need as various innovations and
>improvements in the economy occur and create change in demand and
>supply.
>I believe the overall steady state will have c*n channels rather than
>merely n-1, where c is some constant greater than 1, due to various
>local transient demand/supply shocks.

I would put it simply in this way: the always-shifting patterns of demand and supply in a dense web of channels will naturally cause agents to add traffic to channels that were previously not used, and remove traffic from channels previously used, resulting in a continuous shift in equilibrium.

In this case I would not say it is a matter of "additional capacity needs", though. I think it could be misleading... a hypothetical Lambo dealer could have just one channel used for inflows/outflows of funds, and immediately send back through the channel all the received income (to buy some store of value). In such case the capacity would not matter much even with a big shift in demand.

(... and not included in the paper are a whole bunch of considerations about how having many channels helps the general resilience and flexibility of the network, but those should also be kept in mind.)

Thanks for the feedback!

Regards,
Gregorio

>Regards,
>ZmnSCPxj
Author Public Key
npub15y8mughfnssr7z763l72ma8pvntpemgp6zzfsw2sde2sazrzqyaq7ll0cx