Devrandom [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-28 📝 Original message: On Thu, Feb 27, 2020 at ...
📅 Original date posted:2020-02-28
📝 Original message:
On Thu, Feb 27, 2020 at 8:42 PM Gleb Naumenko <naumenko.gs at gmail.com> wrote:
>
> In this email, myself (gleb) and ariard want to discuss some aspects of the LN implementations when it comes to massive channel closing.
>
> [...]
> - how many nodes implement dynamic bumping
I think it's important to distinguish time-sensitive and
non-time-sensitive tx broadcasts
>From a game theoretic point of view, for non-time-sensitive txs (e.g.
normal closing) you just want to bump fees in a non-aggressive way, to
optimize tx inclusion vs time-value of money. So you mostly want to
track the global fee situation. The expected fee is less than 1% in
most situations.
For time-sensitive txs (mostly penalty broadcast), you stand to lose
your balance after the deadline, so you want to bump in an aggressive
way to keep the chance of losing your balance relatively low. Another
complication is that your estimate of the global state of fees might
be wrong because of fast changes in the global situation. So I would
expect that the game theoretic response would be to smoothly escalate
the fee to a significant % of the balance (maybe 50%+) as you get
close to the deadline.
Hopefully an attacker cannot trigger the time-sensitive case globally.
> Bounding dynamic-fees engine may be viewed as a game-theoretic aspect between LN parties (burn the maximum in fee rate to avoid an attacker to make any profit) and macro-considerations (prevent miner to exploit the whole LN network, conservative mempool/resources usage).
I'm not sure it makes sense to manage macro considerations with local
policies, if those policies end up contrary to self-interest of the
node operators. The rational response of the operator would be to
modify the software to conform to their local self-interest. The
magic of Bitcoin is that there are no selfish local modifications that
result in fatal global dynamics. If it ends up that LN has such
potential local modifications, we should be looking at protocol
changes to fix the local incentives.
📝 Original message:
On Thu, Feb 27, 2020 at 8:42 PM Gleb Naumenko <naumenko.gs at gmail.com> wrote:
>
> In this email, myself (gleb) and ariard want to discuss some aspects of the LN implementations when it comes to massive channel closing.
>
> [...]
> - how many nodes implement dynamic bumping
I think it's important to distinguish time-sensitive and
non-time-sensitive tx broadcasts
>From a game theoretic point of view, for non-time-sensitive txs (e.g.
normal closing) you just want to bump fees in a non-aggressive way, to
optimize tx inclusion vs time-value of money. So you mostly want to
track the global fee situation. The expected fee is less than 1% in
most situations.
For time-sensitive txs (mostly penalty broadcast), you stand to lose
your balance after the deadline, so you want to bump in an aggressive
way to keep the chance of losing your balance relatively low. Another
complication is that your estimate of the global state of fees might
be wrong because of fast changes in the global situation. So I would
expect that the game theoretic response would be to smoothly escalate
the fee to a significant % of the balance (maybe 50%+) as you get
close to the deadline.
Hopefully an attacker cannot trigger the time-sensitive case globally.
> Bounding dynamic-fees engine may be viewed as a game-theoretic aspect between LN parties (burn the maximum in fee rate to avoid an attacker to make any profit) and macro-considerations (prevent miner to exploit the whole LN network, conservative mempool/resources usage).
I'm not sure it makes sense to manage macro considerations with local
policies, if those policies end up contrary to self-interest of the
node operators. The rational response of the operator would be to
modify the software to conform to their local self-interest. The
magic of Bitcoin is that there are no selfish local modifications that
result in fatal global dynamics. If it ends up that LN has such
potential local modifications, we should be looking at protocol
changes to fix the local incentives.