Re: [Lightning-dev] Lightning over taproot with PTLCs
Good morning aj, > On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote: > > > A transaction is required, but I believe it is not necessary to put it > > onchain (at the cost of implementation complexity in the drop-onchain case). > > The trick with that is that if you don't put it on chain, you need > to calculate the fees for it in advance so that they'll be sufficient > when you do want to put it on chain, and you can't update it without > going onchain, because there's no way to revoke old off-chain funding > transactions. Yes, onchain fees, right? *Assuming* CPFP is acceptable, then fees for the commitment tx on the new scheme (or whatever equivalent in the transitioned-to mechanism is) would pay for the transitioning transaction, so fees paying for the transitioning transaction can still be adjusted at the transitioned-to updatable mechanism. This probably assumes that the transaction package relay problem is fixed at the base layer though. > > > This has the advantage of maintaining the historical longevity of the > > channel. > > Many pathfinding and autopilot heuristics use channel lifetime as a > > positive indicator of desirability, > > Maybe that's a good reason for routing nodes to do shadow channels as > a matter of course -- call the currently established channel between > Alice and Bob "C1", and leave it as bolt#3 based, but establish a new > taproot based channel C2 also between Alice and Bob. Don't advertise C2 > (making it a shadow channel), just say that C1 now supports PTLCs, but > secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx > is buried enough, start advertising C2 instead taking advantage of its > now sufficiently buried funding transaction, and convert C1 to a shadow > channel instead. > > In particular, that setup allows you to splice funds into or out of the > shadow channel while retaining the positive longevity heuristics of the > public channel. Requires two UTXOs, though, I think? How about just adding a gossip message "this new short-channel-id is the same as this old short-channel-id, use the new-short-channel-id to validate it but treat the age as that of the old short-channel-id"? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning over taproot with PTLCs
On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote: > A transaction is required, but I believe it is not necessary to put it > *onchain* (at the cost of implementation complexity in the drop-onchain case). The trick with that is that if you don't put it on chain, you need to calculate the fees for it in advance so that they'll be sufficient when you do want to put it on chain, *and* you can't update it without going onchain, because there's no way to revoke old off-chain funding transactions. > This has the advantage of maintaining the historical longevity of the channel. > Many pathfinding and autopilot heuristics use channel lifetime as a positive > indicator of desirability, Maybe that's a good reason for routing nodes to do shadow channels as a matter of course -- call the currently established channel between Alice and Bob "C1", and leave it as bolt#3 based, but establish a new taproot based channel C2 also between Alice and Bob. Don't advertise C2 (making it a shadow channel), just say that C1 now supports PTLCs, but secretly commit to those PTLCs to C2 instead C1. Once the C2 funding tx is buried enough, start advertising C2 instead taking advantage of its now sufficiently buried funding transaction, and convert C1 to a shadow channel instead. In particular, that setup allows you to splice funds into or out of the shadow channel while retaining the positive longevity heuristics of the public channel. Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning over taproot with PTLCs
Good morning aj, > In order to transition from BOLT#3 format to this proposal, an onchain > transaction is required, as the "revocable signatures" arrangement cannot > be mimicked via the existing 2-of-2 CHECKMULTISIG output. A transaction is required, but I believe it is not necessary to put it *onchain* (at the cost of implementation complexity in the drop-onchain case). An existing channel can "simply" sign a transitioning transaction from the current BOLT3 to your new scheme, and then invalidate the last valid commitment transactions (i.e. exchange revocation secrets) in the BOLT3 scheme. The transitioning transaction can simply be kept offchain and its output used as the funding outpoint of all "internal" (to the two counterparties directly in the channel) states. This general idea would work for all transitions *from* Poon-Dryja, I believe. It may be possible with Decker-Russell-Osuntokun I think (give the transitioning transaction the next sequence `nLockTime` number), but the `SIGHASH_NOINPUT`ness and (maybe?) the `CSV` infects the mechanism being transitioned to, so this technique may be too complicated for transitioning *from* Decker-Russell-Osuntokun to some hypothetical future offchain updatable cryptocurrency system that does not need (or want) `SIGHASH_NOINPUT`. This has the advantage of maintaining the historical longevity of the channel. Many pathfinding and autopilot heuristics use channel lifetime as a positive indicator of desirability, thus an *onchain* transitioning transaction is undesirable as that marks a closure of the previous channel. And the exact scheme of channels between forwarding nodes are not particularly the business of anyone else anyway. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Lightning over taproot with PTLCs
Hi all, Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of taproot and implement PTLCs. It's particularly inspired by ZmnSCPxj's thoughts from Dec 2019 [0], and some of his and Lloyd Fournier's posts since then (which are listed in references) -- in particular, I think those allow us to drop the latency for forwarding a payment *massively* (though refunding a payment still requires roundtrips), and also support receiving via a mostly offline lightning wallet, which seems kinda cool. I somehow hadn't realised it prior to a conversation with @brian_trollz via twitter DM, but I think switching to PTLCs, even without eltoo, means that there's no longer any need to permanently store old payment info in order to recover the entirety of the channel's funds. (Some brute force is required to recover the timeout info, but in my testing I think that's about 0.05 seconds of work per ptlc output via python+libsecp256k1) This doesn't require any soft-forks, so I think we could start work on it immediately, and the above benefits actually seem pretty worth it, even ignoring any privacy/efficiency benefits from doing taproot key path spends and forwarding PTLCs. I've sketched up the musig/musig2 parts for the "balance" transactions in python [1] and tested it a little on signet [2], which I think is enough to convince me that this is implementable. There'll be a bit of preliminary work needed in actually defining specs/BIPs for musig and musig2 and adaptor signatures, I think. Anyway, details follow. They're also up on github as a gist [3] if that floats your boat. [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html [1] https://github.com/ajtowns/bitcoin/blob/202109-ptlc-lnpenalty/test/functional/feature_ln_ptlc.py [2] The balance transaction (spending the funding tx and with outputs being Alice's and Bob's channel balance is at): https://explorer.bc-2.jp/tx/ba58d99dfaad83e105a0de1a9becfcf8eaf897da54bd7b08134ff579997c?input:0 [3] https://gist.github.com/ajtowns/12f58fa8a4dc9f136ed04ca2584816a2/ Goals = 1. Support HTLCs 2. Support PTLCs 3. Minimise long-term data storage requirements 4. Minimise latency when forwarding payments 5. Minimise latency when refunding payments 6. Support offline receiving 7. Minimise on-chain footprint 8. Minimise ability for third-parties to analyse Setup = We have two participants in the channel, Alice and Bob. They each have bip32 private keys, a and b, and share the corresponding xpubs A and B with each other. Musig - We will use musig to combine the keys, where P = musig(A,B) = H(A,B,1)*A + H(A,B,2)*B. We'll talk about subkeys of P, eg P/4/5/6, which are calculated by taking subkeys of the input and then applying musig, eg P/4/5/6 = musig(A/4/5/6, B/4/5/6). (Note that we don't use hardened paths anywhere) Musig2 -- We'll use musig2 to sign for these keys, that is both parties will pre-share two nonce points each, NA1, NA2, NB1, NB2, and the nonce will be calculated as: R=(NA1+NB1)+k(NA2+NB2), where k=Hash(P,NA1,NA2,NB1,NB2,m), where P is the pubkey that will be signing and m is the message to be signed. Note that NA1, NA2, NB1, NB2 can be calculated and shared prior to knowing what message will be signed. The partial sig by A for a message m with nonce R as above is calculated as: sa = (na1+k*na2) + H(R,A+B,m)*a where na1, na2, and a are the secrets generating NA1, NA2 and A respectively. Calculating the corresponding partial signature for B, sb = (nb1+k*nb2) + H(R,A+B,m)*b gives a valid signature (R,sa+sb) for (A+B): (sa+sb)G = R + H(R,A+B,m)*(A+B) Note that BIP340 sepcifies x-only pubkeys, so A+B and R implicitly have even y, however since those values are caluclated via musig and musig2 respectively, this cannot be ensured in advance. Instead, if we find: H(A,B,1)*A + H(A,B,2)*B does not have even y, we calculate: P = (-H(A,B,1))*A + (-H(A,B,2))*B instead, which will have even y. Similarly, if (NA1+NB1+k(NA2+NB2)) does not have even y, when signing, we replace each partial nonce by its negation, eg: sa = -(na1+k*na2) + H(R,A+B,m). Adaptor Sigs An adaptor signature for P for secret X is calculated as: s = r + H(R+X, P, m)*p which gives: (s+x)G = (R+X) + H(R+X, P, m)*P so that (R+X,s+x) is a valid signature by P of m, and the preimage for X can be calculated as the difference between the published sig and the adaptor sig, x=(s+x)-(s). Note that if R+X does not have even Y, we will need to negate both R and X, and the recovered secret preimage will be -x instead of x. Revocable Secrets - Alice and Bob have shachain secrets RA(n) and RB(n) respectively, and second level shachain secrets RA2(n,i) and RB2(n,i), with n and i counting up from 0 to a maximum. Summary === We'll introduce four layers of transactions: 1. The funding transaction - used to establish the channel, provides the utxo backing the
Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit
Good morning Pieter, > Indeed - UTXO set size is an externality that unfortunately Bitcoin's > consensus rules fail to account > for. Having a relay policy that avoids at the very least economically > irrational behavior makes > perfect sense to me. > > It's also not obvious how consensus rules could deal with this, as you don't > want consensus rules > with hardcoded prices/feerates. There are possibilities with designs like > transactions getting > a size/weight bonus/penalty, but that's both very hardforky, and hard to get > right without > introducing bad incentives. Why is a +weight malus *very* hardforky? Suppose a new version of a node adds, say, +20 sipa per output of a transaction (in order to economically discourage the creation of additional outputs in the UTXO set). Older versions would see the block as being lower weight than usual, but as the consensus rule is "smaller than 4Msipa" they should still accept any block acceptable to newer versions. It seems to me that only a -weight bonus is hardforky (but then xref SegWit and its -weight bonus on inputs). I suppose the effect is primarily felt on mining nodes? Miners might refuse to activate such a fork, as they would see fewer transactions per block on average? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Removing lnd's source code from the Lightning specs repository
Hello, When you navigate to https://github.com/lightningnetwork/ you find - the Lightning Network white paper - the Lightning Network specifications - and ... the source code for lnd! This has been an anomaly for years, which has created some confusion between Lightning the open-source protocol and Lightning Labs, one of the companies specifying and implementing this protocol, but we didn't do anything about it. I believe that was a mistake: a few days ago, Arcane Research published a fairly detailed report on the state of the Lightning Network: https://twitter.com/ArcaneResearch/status/1445442967582302213. They obviously did some real work there, and seem to imply that their report was vetted by Open Node and Lightning Labs. Yet in the first version that they published you’ll find this: "Lightning Labs, founded in 2016, has developed the reference client for the Lightning Network called Lightning Network Daemon (LND) They also maintain the network standards documents (BOLTs) repository." They changed it because we told them that it was wrong, but the fact that in 2021 people who took time do do proper research, interviews, ... can still misunderstand that badly how the Lightning developers community works means that we ourselves badly underestimated how confusing mixing the open-source specs for Lightning and the source code for one of its implementations can be. To be clear, I'm not blaming Arcane Research that much for thinking that an implementation of an open-source protocol that is hosted with the white paper and specs for that protocol is a "reference" implementation, and thinking that since Lightning Labs maintains lnd then they probably maintain the other stuff too. The problem is how that information is published. So I'm proposing that lnd's source code be removed from https://github.com/lightningnetwork/ (and moved to https://github.com/lightninglabs for example, with the rest of their Lightning tools, but it's up to Lightning Labs). Thanks, Fabrice ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
