On Thu, Sep 29, 2022 at 12:41:44AM +, ZmnSCPxj wrote:
> > I get what you're saying, but I don't think a "stock of liquidity"
> > is a helpful metaphor/mental model here.
> > "Liquidity" usually means "how easy it is to exchange X for Y" -- assets
> > for cash, etc; but for lightning, liquidity
Good morning aj,
> > Forwarding nodes sell liquidity.
> > If a forwarding node runs out of stock of liquidity (i.e. their channel is
> > unbalanced against the direction a payment request fails) they earn 0
> > profit.
>
>
> I get what you're saying, but I don't think a "stock of liquidity"
>
On Tue, Sep 27, 2022 at 12:23:38AM +, ZmnSCPxj via Lightning-dev wrote:
> All monetisation is fee-based; the question is who pays the fees.
This isn't true. For example, if you can successfully track the payments
you route, you can monetize by selling data about who's buying what
from whom. (U
Good morning aj, Rene, and all,
So let me discuss a little more about how I model the forwarding nodes.
Forwarding nodes want to maximize profit.
Forwarding nodes sell liquidity.
If a forwarding node runs out of stock of liquidity (i.e. their channel is
unbalanced against the direction a payme
Good morning aj,
> > Basically, the intuition "small decrease in `htlc_max_msat` == small
> > decrease in payment volume" inherently assumes that HTLC sizes have a flat
> > distribution across all possible sizes.
>
>
> The intuition is really the other way around: if you want a stable,
> decen
On Mon, Sep 26, 2022 at 01:26:57AM +, ZmnSCPxj via Lightning-dev wrote:
> > > * you're providing a way of throttling payment traffic independent of
> > > fees -- since fees are competitive, they can have discontinuous effects
> > > where a small change to fee can cause a large change to traffic
Good morning again aj, and Rene,
> Good morning aj, and Rene,
>
> > * you're providing a way of throttling payment traffic independent of
> > fees -- since fees are competitive, they can have discontinuous effects
> > where a small change to fee can cause a large change to traffic volume;
> > but
Good morning aj, and Rene,
> * you're providing a way of throttling payment traffic independent of
> fees -- since fees are competitive, they can have discontinuous effects
> where a small change to fee can cause a large change to traffic volume;
> but this seems like it should mostly have a propo
On Thu, Sep 22, 2022 at 08:40:30AM +0200, René Pickhardt via Lightning-dev
wrote:
> While trying to estimate the expected liquidity distribution in depleted
> channels due to drain via Markov Models I realized that we can exploit the
> `htlc_maxium_msat` setting to act as a control valve and regul
Dear Matt and Lightning developers,
those are excellent and important questions that I should probably have
addressed more explicitly in the article / ml-post! Let me add what I
currently know and begin with your second question as I think I think the
answer will be more objective / verifiable whi
Two questions -
a) How much gossip overhead do you expect this type of protocol to generate/is there a useful
outcome for this type of update even if you limit gossip updates to once/twice/thrice per day?
b) What are the privacy implications of the naive "update on drained channel", and have you
Good morning fellow Lightning Developers,
I am pleased to share my most recent research results [1] with you. They
may (if at all) only have a small impact on protocol development /
specification but are actually mainly of concern to node operators and
LSPs. I still thought they may be relevant fo
12 matches
Mail list logo
