Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...
Good morning Matt, > On 10/13/21 02:58, ZmnSCPxj wrote: > > > Good morning Matt, > > > > > The Obvious (tm) solution here is PTLCs - just have the sender > > > always add some random nonce * G to > > > the PTLC they're paying and send the recipient a random nonce in the > > > onion. I'd generally suggest we > > > just go ahead and do this for every PTLC payment, cause why not? Now > > > the sender and the lnurl > > > endpoint have to collude to steal the funds, but, like, the sender > > > could always just give the lnurl > > > endpoint the money. I'd love suggestions for fixing this short of > > > PTLCs, but its not immediately > > > obvious to me that this is possible. > > > > > > > Use two hashes in an HTLC instead of one, where the second hash is from a > > preimage the sender generates, and which the sender sends (encrypted via > > onion) to the receiver. > > You might want to do this anyway in HTLC-land, consider that we have a > > `payment_secret` in invoices, the second hash could replace that, and > > provide similar protection to what `payment_secret` provides (i.e. > > resistance against forwarding nodes probing; the information in both cases > > is private to the ultimate sender and ultimate reeceiver). > > Yes, you could create a construction which does this, sure, but I'm not sure > how you'd do this > without informing every hop along the path that this is going on, and > adapting each hop to handle > this as well. I suppose I should have been more clear with the requirements, > or can you clarify > somewhat what your proposed construction is? Just that: two hashes instead of one. Make *every* HTLC on LN use two hashes, even for current "online RPi user pays online RPi user" --- just use the `payment_secret` for the preimage of the second hash, the sender needs to send it anyway. > > If you're gonna adapt every node in the path, you might as well just use PTLC. Correct, we should just do PTLCs now. (Basically, my proposal was just a strawman to say "we should just do PTLCs now") Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...
On 10/13/21 02:58, ZmnSCPxj wrote: Good morning Matt, The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately obvious to me that this is possible. Use two hashes in an HTLC instead of one, where the second hash is from a preimage the sender generates, and which the sender sends (encrypted via onion) to the receiver. You might want to do this anyway in HTLC-land, consider that we have a `payment_secret` in invoices, the second hash could replace that, and provide similar protection to what `payment_secret` provides (i.e. resistance against forwarding nodes probing; the information in both cases is private to the ultimate sender and ultimate reeceiver). Yes, you could create a construction which does this, sure, but I'm not sure how you'd do this without informing every hop along the path that this is going on, and adapting each hop to handle this as well. I suppose I should have been more clear with the requirements, or can you clarify somewhat what your proposed construction is? If you're gonna adapt every node in the path, you might as well just use PTLC. Matt ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...
Good morning Matt, > The Obvious (tm) solution here is PTLCs - just have the sender always add > some random nonce * G to > the PTLC they're paying and send the recipient a random nonce in the > onion. I'd generally suggest we > just go ahead and do this for every PTLC payment, cause why not? Now the > sender and the lnurl > endpoint have to collude to steal the funds, but, like, the sender could > always just give the lnurl > endpoint the money. I'd love suggestions for fixing this short of PTLCs, > but its not immediately > obvious to me that this is possible. Use two hashes in an HTLC instead of one, where the second hash is from a preimage the sender generates, and which the sender sends (encrypted via onion) to the receiver. You might want to do this anyway in HTLC-land, consider that we have a `payment_secret` in invoices, the second hash could replace that, and provide similar protection to what `payment_secret` provides (i.e. resistance against forwarding nodes probing; the information in both cases is private to the ultimate sender and ultimate reeceiver). In addition, I suspect (but have not worked out yet) that this would allow some kind of Barrier Escrow-like mechanism while still in HTLC-land. Otherwise, just PTLC, man, everyone wants PTLC. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Deriving channel keys deterministically from seed, musig, and channel establishment v2
Hi SomberNight, I started a similar discussion less than a year ago on the list. The idea I put forward works fine with MuSig and taproot. https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html The idea was considered for channel establishment v2 but in the end there were various objections to it becoming specified as it forces implementations to handle keys in a certain way. You can still do it informally though by fixing your funding pubkey to be derived from the Diffie-Hellman key of the two node ids. This makes the funding public keys a (secret) deterministic function of the two node ids without making a privacy leak. FWIW I still think this is a good idea but in hindsight I think the objections to it being mandatory are valid. Cheers, LL On Sat, 18 Sept 2021 at 02:14, SomberNight via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Hi all, > > TL;DR: an approach is described how to derive channel keys > deterministically that allows certain forms of recovery from just > a seed, that works today. This approach however will no longer work > with e.g. MuSig key aggregation in the future. An idea for a proposal > is given how the channel-open flow (e.g. as part of channel v2) could be > changed to make a similar approach work independent of key aggregation. > > - > > While implementing anchor output support in Electrum, we have realised > one difficulty is to do with the remote-force-close case where the > to_remote output is no longer a simple p2wpkh. > > Currently, pre-anchor-support, Electrum sets option_static_remotekey > to required (feature bit 12), and we restrict lightning usage to wallets > that derive p2wpkh addresses, and payment_basepoint is set > to a bip32-derived pubkey that corresponds to a wallet address. > Hence, if a user were to restore from seed words, and their channel > counterparty force closed their channel, the to_remote output of the > broadcast commitment tx would directly pay to the user's wallet. > That is, in many typical scenarios, funds are not lost when restoring > from seed. > > (Also, if we are the channel-funder/opener, it is easy to find the > funding transaction, just by testing txs in the wallet history. > Further, for the cases we are the channel-funder/opener, > there is a setting to put an OP_RETURN in the funding tx, which stores > the nodeid of the counterparty, allowing us to identify who to contact > to get the channel closed. > Also, we are (ab)using dataloss_protect to ask the remote > to force-close when restoring from seed, so the user does not even have > to wait for an arbitrarily long time.) > > With anchors, the to_remote is now a p2wsh that involves a CSV, > and we cannot easily make this script correspond to a wallet address, > i.e. we lose the property that the remote-force-close pays directly > to a wallet address. > > So, the problem we would like to solve, is: > - having seed words > - having access to blockchain data > - somehow having identified our channel counterparties (node IDs), > and our channels with them (funding outpoints) > - and assuming we can get the remote to do a force-close > --> we would like to be able to spend the to_remote output > > Solutions: > > 1) Naively, we could just derive a static key to be used as > payment_basepoint, reused between all our channels, and watch the > single resulting p2wsh script on-chain. > Clearly this has terrible privacy implications. > > 2) Or, we could derive a new bip32 chain/sequence of pubkeys > used as payment_basepoint for channels, and watch these p2wsh scripts, > with a gap limit. > Particularly the gap limit part makes this undesirable though > (just consider having more than "gap limit" channels open and restoring > from seed). > > Instead, it seems desirable to see whether we can extract some entropy > from the blockchain, and use that as a nonce to be combined with a > static private secret derived from our seed. > We could extract data either from the funding tx, or from the > remote-commitment-transaction that spent the funding output. > > 3) We exploit the fact that the funding output uses a > 2of2 OP_CHECKMULTISIG script composed of the funding pubkeys of > each party. The funding pubkey itself can be used as a nonce, and > it can be recovered from the witness of the commitment tx. > The privkey for payment_basepoint can then be derived as e.g. > hash(bip32_derive(seed, HARDCODED_PATH) + funding_pubkey). > > In fact (3) is not novel at all: eclair has been deriving > all their channel keys like this [0] for some time, from > a static seed-based secret combined with the funding_pubkey as nonce, > and generating the funding_privkey from ~os.urandom. > > Electrum will likely use (3) at least for the payment_basepoint, > as part of adapting to anchors. > > - > > Note that the idea (3) relies on recovering the funding_pubkey from > the witness of the spending transaction, which will break in the future > if the funding
