> > - 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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
