Why Nostr? What is Njump?
2023-07-27 00:22:34

Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-25 🗒️ Summary of this message: Proposal to use ...

đź“… Original date posted:2023-07-25
🗒️ Summary of this message: Proposal to use a tapscript branch instead of MuSig2 signing for unilateral closes in the Lightning Network. Discusses dynamic fees and Bitcoin as a universal clock.
đź“ť Original message:
Hi Zeeman,

> A proposal I made in the Signal group after the summit would be to not
use MuSig2 signing for commitment transactions (== unilateral closes).
> Instead, we add a tapscript branch that is just `<A> OP_CHECKSIGVERIFY
<B> OP_CHECKSIG` and use that for unilateral closes.
> We only sign with MuSig2 on mutual closes, after we have negotiated
closing fees (whether that is the current long closing conversation, or
simplified closing) so that only mutual closes require nonce
> storage.
>
> As mutual closes assume continuous connectivity anyway, we can keep
counterparty nonces in volatile RAM and not store nonces in persistent
storage; if a disconnection occurs, we just remove it from
> volatile RAM and restart the mutual close negotiation on reconnection.
>
> This is more palatable as even with a very restrictive hardware device
you do not have to store the peer nonce in persistent storage.
> The hope is that mutual closes dominate over unilateral closes.

Hardware devices with reasonable persistent storage sounds cheaper than the
additional fee-bumping reverse one (locally or a third-party), must
conserve to pay for the probabilistic worst-case `<A> OP_CHECKSIGVERIFY <B>
OP_CHECKSIG` satisfying witness.

> Conditinoal fees already on the Lightning Network are already dynamic,
with many people (including myself) writing software that measures demand
and changes price accordingly.
> Why would unconditional fees be necessarily static, when there is no
mention of it being static?

While I'm in sync with you on the Lightning Network being a system driven
by demand and charge price accordingly, some of the recent jamming
mitigation proposals where build on the proposal of "static fees" or
unconditional fees, e.g https://eprint.iacr/2022/1454.pdf. As soon as you
start to think in terms of dynamic fees, you start to have issues w.r.t
gossip convergence delays and rate-limitation of your local unconditional
fees updates.

> Given a "stereotypical" forwarding node, what is the most likely
subjective valuation?
> If a node is not a stereotypical forwarding node, how does it deviate
from the stereotypical one?

Answer is a function of your collection of historical forwarding HTLC
traffic and secondary source of information.
Somehow the same as for base-layer fee-estimation, the more consistent your
mempool data-set, the better will be your valuation.

> The problem is that the Bitcoin clock is much too coarsely grained, with
chain height advances occasionally taking several hours in the so-called
"real world" I have heard much rumor about.

Sure, I still think Bitcoin as a universal clock is still the most costly
for a Lightning counterparty to game on, if it has to be used as a
mechanism to arbitrate the fees / reputation paid for the in-flight
duration of a HTLC. Even relying on timestamp sounds to offer some margin
of malleation (e.g advance of max 2h, consensus rule) if you have hashrate
capabilities.

> Would not the halt of the channel progress be considered worthy of a
reputation downgrade by itself?

That's an interesting point, rather than halting channel progress being
marked as a strict reputation downgrade, you could negotiate a "grace
delay" during which channel progress must be made forward (to allow for
casualties like software upgrade or connectivity issue).

Best,
Antoine

Le lun. 24 juil. 2023 Ă  09:14, ZmnSCPxj <ZmnSCPxj at protonmail.com> a Ă©crit :

>
>
> > > - For taproot/musig2 we need nonces:
> > > - Today we store the commitment signature from the remote party. We
> don’t need to store our own signature - we can sign at time of broadcast.
> > > - To be able to sign you need the verification nonce - you could
> remember it, or you could use a counter:
> > > - Counter based:
> > > - We re-use shachain and then just use it to generate nonces.
> > > - Start with a seed, derive from that, use it to generate nonces.
> > > - This way you don’t need to remember state, since it can always be
> generated from what you already have.
> > > - Why is this safe?
> > > - We never re-use nonces.
> > > - The remote party never sees your partial signature.
> > > - The message always stays the same (the dangerous re-use case is
> using the same nonce for different messages).
> > > - If we used the same nonce for different messages we could leak our
> key.
> > > - You can combine the sighash + nonce to make it unique - this also
> binds more.
> > > - Remote party will only see the full signature on chain, never your
> partial one.
> > > - Each party has sign and verify nonces, 4 total.
> > > - Co-op close only has 2 because it’s symmetric.
> >
> > (I don't know when mailing list post max size will be reached)
> >
> > Counter-based nonces versus stateful memorization of them from a user
> perspective depends on the hardware capabilities you have access to.
> >
> > The taproot schnorr flow could be transparent from the underlying
> signature scheme (FROST, musig2, TAPS in the future maybe).
>
> A proposal I made in the Signal group after the summit would be to not use
> MuSig2 signing for commitment transactions (== unilateral closes).
>
> Instead, we add a tapscript branch that is just `<A> OP_CHECKSIGVERIFY <B>
> OP_CHECKSIG` and use that for unilateral closes.
> We only sign with MuSig2 on mutual closes, after we have negotiated
> closing fees (whether that is the current long closing conversation, or
> simplified closing) so that only mutual closes require nonce storage.
>
> As mutual closes assume continuous connectivity anyway, we can keep
> counterparty nonces in volatile RAM and not store nonces in persistent
> storage; if a disconnection occurs, we just remove it from volatile RAM and
> restart the mutual close negotiation on reconnection.
>
> This is more palatable as even with a very restrictive hardware device you
> do not have to store the peer nonce in persistent storage.
> The hope is that mutual closes dominate over unilateral closes.
>
>
>
> > > - We run into the same pricing issues.
> > > - Why these combinations?
> > > - Since scarce resources are essentially monetary, we think that
> unconditional fees are the simplest possible monetary solution.
> > > - Unconditional Fees:
> > > - As a sender, you’re building a route and losing money if it doesn’t
> go through?
> > > - Yes, but they only need to be trivially small compared to success
> case fee budgets.
> > > - You can also eventually succeed so long as you retry enough, even if
> failure rates are very high.
> > > - How do you know that these fees will be small? The market could
> decide otherwise.
> >
> > Static unconditional fees is a limited tool in a world where rational
> economic actors are pricing their liquidity in function of demand.
>
> Conditinoal fees already on the Lightning Network are already dynamic,
> with many people (including myself) writing software that measures demand
> and changes price accordingly.
> Why would unconditional fees be necessarily static, when there is no
> mention of it being static?
>
>
> > > - We have to allow some natural rate of failure in the network.
> > > - An attacker can still aim to fall just below that failure threshold
> and go through multiple channels to attack an individual channel.
> > > - THere isn’t any way to set a bar that an attacker can’t fall just
> beneath.
> > > - Isn’t this the same for reputation? We have a suggestion for
> reputation but all of them fail because they can be gamed below the bar.
> > > - If reputation matches the regular operation of nodes on the network,
> you will naturally build reputation up over time.
> > > - If we do not match reputation accumulation to what normal nodes do,
> then an attacker can take some other action to get more reputation than the
> rest of the network. We don’t want attackers to be able to get ahead of
> regular nodes.
> > > - Let’s say you get one point for success and one for failure, a
> normal node will always have bad reputation. An attacker could then send 1
> say payments all day long, pay a fee for it > and gain reputation.
> > > - Can you define jamming? Is it stuck HTLCs or a lot of 1 sat HTLCS
> spamming up your DB?
> >
> > Jamming is an economic notion, as such relying on the subjectivism of
> node appreciation of local ressources.
>
> Given a "stereotypical" forwarding node, what is the most likely
> subjective valuation?
> If a node is not a stereotypical forwarding node, how does it deviate from
> the stereotypical one?
>
>
> > > - The dream solution is to only pay for the amount of time that a HTLC
> is held in flight.
> > > - The problem here is that there’s no way to prove time when things go
> wrong, and any solution without a universal clock will fall back on
> cooperation which breaks down in the case of > an attack.
> >
> > There is a universal clock in Bitcoin called the chain height advances.
>
> The problem is that the Bitcoin clock is much too coarsely grained, with
> chain height advances occasionally taking several hours in the so-called
> "real world" I have heard much rumor about.
>
>
> > > - What NACK says is: I’ve ignored all of your updates and I’m
> progressing to the next commitment.
> >
> > If resource bucketing or link-level liquidity management starts to be
> involved, one can mask behind "NACK" to halt the channel progress, without
> the reputation downgrade. Layer violation issue.
>
> Would not the halt of the channel progress be considered worthy of a
> reputation downgrade by itself?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230726/4858e570/attachment-0001.html>;
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd