Re: [Lightning-dev] PTLCs early draft specification
Hi thread, I was indeed mistaken. It does require four rounds for both parties to fully transition to the next comimit tx and I don't think there is any easy way around this. As you've pointed out there it's still only three rounds before the message is forwarded so no performance decrease for forwarding. I wanted to add a theoretical note that you might be aware of. The final message "Bob -> Alice: revoke_and_ack" is not strictly necessary. Alice does not care about Bob revoking a commit tx that gives her strictly more coins. Bob's new commit tx can use the same revocation key as the previous one i.e. only the offerer of the PTLC/HTLC does a revocation and increments their revocation key. Not sending messages you don't need to is usually both more performant and simpler but given that it introduces some asymmetry so I'm not sure if it's worth it. It's also worth noting that with fast forwards + symmetric commit tx you will need to do the full four rounds always I think. Cheers, LL On Thu, 9 Dec 2021 at 02:03, Bastien TEINTURIER wrote: > Hi again AJ and list, > > I have slightly re-worked your proposal, and came up with the following > (I also added the musig2 nonces for completeness): > > Alice -> Bob: commitment_proposed > channel id > adaptor sigs for PTLCs to Bob in Alice's next commitment > musig nonces for Alice to spend funding tx > musig nonces for Bob to spend funding tx > > Bob -> Alice: commitment_proposed > channel id > adaptor sigs for PTLCs to Alice in Bob's next commitment > musig nonces for Alice to spend funding tx > musig nonces for Bob to spend funding tx > > Bob -> Alice: commitment_signed > channel id > signature for Alice to spend funding tx > sigs for Alice to spend HTLCs and PTLCs from her next commitment > > Alice -> Bob: revoke_and_ack > channel id > reveal previous commitment secret > next commitment point > > Alice -> Bob: commitment_signed > channel id > signature for Bob to spend funding tx > sigs for Bob to spend HTLCs and PTLCs from his next commitment > > Bob -> Alice: revoke_and_ack > channel id > reveal previous commitment secret > next commitment point > > I believe it's exactly the same flow of data between peers as your > proposal, but I simply split the data into several messages. Let me > know if that's incorrect or if I missed a subtlety in your proposal. > > This has some small advantages: > > * commitment_signed and revoke_and_ack are mostly unchanged, we just > add a new message before the commit / revoke dance. The only change > happens in commitment_signed, where the signatures for PTLC-success > transactions will actually become adaptor signatures. > * the new adaptor signatures are in commitment_proposed instead of being > in commitment_signed, which ensures that we can still have 2*483 > pending (H|P)TLCs: since the message size is limited to 65kB, we would > otherwise decrease our maximum to ~2*335 with your proposal (very rough > calculation) > * the messages are now symmetrical, which may be easier to reason about > > One thing to note is that we reversed the order in which participants > sign new commitments. We previously had Alice sign first, whereas now > if Alice initiates, Bob will sign the updated commitment first. This is > why we add only 0.5 RTT instead of 1 RTT compared to the current protocol. > I don't think this is an issue, but if someone sees a way to maliciously > exploit this, please share it! > > I updated my article [0], people jumping on the thread now may find it > helpful to better understand this discussion. > > Thanks, > Bastien > > [0] https://github.com/t-bast/lightning-docs/pull/16 > > Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER a > écrit : > >> Hi AJ, >> >> I think the problem t-bast describes comes up here as well when you >>> collapse the fast-forwards (or, anytime you update the commitment >>> transaction even if you don't collapse them). >> >> >> Yes, exactly. >> >> I think doing a synchronous update of commitments to the channel state, >>> something like: >> >> >> >> Alice -> Bob: propose_new_commitment >>> channel id >>> adaptor sigs for PTLCs to Bob >> >> >>> Bob -> Alice: agree_new_commitment >>> channel id >>> adaptor sigs for PTLCs to Alice >>> sigs for Alice to spend HTLCs and PTLCs to Bob from her own >>> commitment tx >>> signature for Alice to spend funding tx >>> >>> Alice -> Bob: finish_new_commitment_1 >>> channel id >>> sigs for Bob to spend HTLCs and PTLCs to Alice from his own >>> commitment tx >>> signature for Bob to spend funding tx >>> reveal old prior commitment secret >>> new commitment nonce >>> >>> Bob -> Alice: finish_new_commitment_2 >>> reveal old prior commitment secret >>> new commitment nonce >>> >>> would work pretty well. >> >> >> I agree, this is better than my naive addition of a `remote_ptlcs_signed` >> message in both directions, and even though it changes the protocol >> messages >> it stays
Re: [Lightning-dev] PTLCs early draft specification
I was thinking along the same lines as Z. With MuSig2 and pre-sharing of signature nonces it should stay three rounds and share a similar structure. On Tue, 7 Dec 2021 at 11:08, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > > Basically, if my memory and understanding are accurate, in the above, it > is the *PTLC-offerrer* which provides an adaptor signature. > That adaptor signature would be included in the `update_add_ptlc` message. > Isn't it the case that all previous PTLC adaptor signatures need to be re-sent for each update_add_ptlc message because the signatures would no longer be valid once the commit tx changes. I think it's better to put it in `commitment_signed` if possible. This is what is done with pre-signed HTLC signatures at the moment anyway. LL ___ 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
Re: [Lightning-dev] Lightning over taproot with PTLCs
On Tue, 12 Oct 2021 at 14:08, Anthony Towns wrote: > > If you're willing to accept that "worst case" happening more often, I > think you could then retain the low latency forwarding, by having the > transaction structure be: > > commitment tx > input: > funding tx > outputs: > Alice's balance > (others) > > low-latency inflight tx: > input: > Alice's balance > output: > (1) or (2) > Alice's remaining balance > > Bob claim: > input: > (1) [ CSV bob CHECKSIG] > output: > [ checksigverify checksig > ifdup notif csv endif] > > Too-slow: > input: > (2) [ CLTV alice CHECKSIG] > output: > Alice > > The idea being: > > * Alice sends the low-latency inflight tx which Bob then forwards >immediately. > > * Bob then tries to update the base channel state with Alice, so both >sides have a commitment to the new payment, and the low-latency >inflight tx is voided (since it's based on a revoked channel state) >If this succeeds, everything is fine as usual. > > * If Alice is unavailable to confirm that update, Bob closes the >channel prior to (payment-timeout - payment-recover-delay), and posts >"Bob claim". After an additional pyment recovery delay (and prior >to payment-timeout) Bob posts Bob claim, ensuring that the only way >Alice can claim the funds is if he had posted a revoked state. > > * In this case, Alice has at least one payment-recovery-delay period >prior to the payment-timeout to notice the transaction onchain and >recover the preimage. > > * If Bob posted the low-latency inflight tx later than >(payment-timeout - payment-recovery-delay) then Alice will have >payment-recovery-delay time to notice and post the "too-slow" tx and >claim the funds via the timeout path. > > * If Bob posted a revoked state, Alice can also claim the funds via >Bob claim, provided she notices within the channel-recovery-delay > In my mind your "update the base channel state" idea seems to fix everything by itself. So at T - to_self_delay (or a bit before) you say to your counterparty "can we lift this HTLC out of your in-flight tx into the 'balance tx' (which will go back to naming a 'commitment tx' since it doesn't just have balance outputs anymore) so I can use it too? -- otherwise I'll have to close the channel on chain now to force you to reveal it to me on time?". If they agree, after the revocation and new commit tx everything is back to (tx symmetric) Poon-Dryja so no need for extra CSVs. Am I missing something? I realise this kills some of the elegance of your original protocol and adds quite a bit of complexity but I think it retains the important properties. > That only allows one low-latency payment to be inflight though, which I'm > not sure is that interesting... It's also kinda complicated, and doesn't > cover both the low-latency and offline cases, which is disappointing... > > It seems to me lazily lifting the HTLCs into the commitment tx would allow as many low-latency payments as you want to be in-flight. You would probably just lift them all up to the commitment tx if you lift one. I think in the case of nodes that want to keep channel keys offline, having to go on-chain at T - to_self_delay is not a disaster since it will likely only be the payment receiver who has their keys offline i.e. the merchant or end user. So only the last hop would go on chain if the user fails to claim payment as per usual (just to_self_delay earlier than usual). Cheers, LL ___ 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 Mon, 11 Oct 2021 at 9:23 pm, Lloyd Fournier wrote: > > Adjust the protocol so that you reciprocate the in-flight txs. So when I > offer you a HTLC you first forward it and then lazily send me the signature > for the inflight tx. Therefore I dont have to wait to get the HTLC on chain > and don’t have to close the channel early. > > So against a malicious node you have to go on chain to_self_delay earlier > than usual but if both are honest you don’t have to. The problem with eltoo > is that we don’t know how to achieve this even if both parties are honest > iirc. > Err never mind that won’t work. Sending in-flights to both parties makes no sense because they can be stale of course. LL > ___ 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 Mon, 11 Oct 2021 at 17:30, Anthony Towns wrote: > > I don't think the layering here quite works: if Alice forwarded a payment > to Bob, with timeout T, then the only way she can be sure that she can > either reclaim the funds or know the preimage by time T is to close the > channel on-chain at time T-to_self_delay. > > Any time later than that, say T-to_self_delay+x+1, would allow Bob to > post the inflight tx at T+x (prior to Alice being able to claim her > balance directly due to the to_self_delay) and then immediately post the > layered transaction (4, above) revealing the preimage, and preventing > Alice from claiming the refund. > This problem may not be as bad as it seems. Recall that the issue in eltoo is worse because you are delayed both when you are offering and receiving the HTLC. In this one you are only delayed on offered HTLC. Adjust the protocol so that you reciprocate the in-flight txs. So when I offer you a HTLC you first forward it and then lazily send me the signature for the inflight tx. Therefore I dont have to wait to get the HTLC on chain and don’t have to close the channel early. So against a malicious node you have to go on chain to_self_delay earlier than usual but if both are honest you don’t have to. The problem with eltoo is that we don’t know how to achieve this even if both parties are honest iirc. LL ___ 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
Hey aj, This is awesome work. My line of research on "witness asymmetric channels" essentially ended up in a dead end because I couldn't see how they were much better than naive PTLC lightning. The idea I really liked from it was "revocable signatures". I hoped someone would eventually figure out what to do with them. Looks like you've done that! I also didn't make the connection to how revocable signatures actually solves the constant size storage problem. I knew it could make the protocol in "generalized payment channels" [1] only require constant size which was the target of the idea but I hadn't considered that lightning already suffers from this problem so it can be applied more generally. The other big breakthrough you made is showing how you can do concurrent non-interactive payment forwarding by using a refined version of Z's fast forward idea. In my mind the most practical way to make FF work on Poon-Dryja channels was to do it asymmetrically [3] but this meant that if a payment was sent the other way you'd have to do a 3 phase commit first. With your idea as long as you have balance to spare in your balance output you can always forward a payment in one message. A nice speed boost for busy routing nodes. ### Scorched earth punishment Another thing that I'd like to mention is that using revocable signatures enables scorched earth punishments [2]. The key you reveal when you post a revoked state does not have to be limited to your channel -- it could be used in multiple channels allowing the wronged party to take coins from all their channels with the perpetrator. Furthermore, a lightning service provider that offers channels with the same channel key to all their customers is putting up all their coins in all their existing channels as their good behaviour bond rather than just the coins they have in the channels they have with you. For many users this will be sufficient to go without a "watchtower" to do punishments for them. They know if the LSP takes their coins with a revoked state whenever they come back online they can punish the LSP by revealing their static channel key to everyone. They can even do this weeks or months after the theft assuming the LSP is still operating with the same key. Some people feel this idea is too spicy but I prefer it to introducing a trusted third party for people that cannot be online all the time. [1] https://eprint.iacr.org/2020/476.pdf [2] https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003045.html Some queries below: On Sat, 9 Oct 2021 at 12:12, Anthony Towns wrote: > > We will use "i" to represent the number of times a given inflight > transaction has been updated for the nth update to the balance > transaction. > > At any time Alice can update the inflight transaction spending her balance > to transfer funds towards Bob, either by updating the balances directly, > or adding a htlc/ptlc entry to conditionally transfer funds to Bob. (And > conversely for Bob) > > We will define RP=musig(A/2/n/i, RB2(n,i)). > > The inflight transaction spending Alice's balance can have multiple > types of outputs: > > * Alice's remaining balance: pays directly to A/2/n/i > > * Bob's remaining balances: pays to RP/2 with script path >" CHECKSIGVERIFY CSV" > > * An htlc paying to Bob: pays to RP/2/k with script paths: >+ "LENGTH 32 EQUALVERIFY HASH160 EQUALVERIFY > CHECKSIGVERIFY CHECKSIG" >+ " CHECKSIGVERIFY CLTV" > > * A ptlc paying to Bob: pays to RP/2/k with script paths: >+ " CHECKSIG NOTIF CLTV DROP ENDIF CHECKSIG" > > Any outputs that would be zero or dust are not included. > > Note that we number each currently inflight transaction by "k", > starting at 0. The same htlc/ptlc may have a different value for k > between different inflight transactions. > Can you expand on why "k" is needed in addition to "n" and "i". k sounds like the same thing as i to me. Also what does RP/2/k notation imply given the definition of RP you gave above? > * if the inflight transaction contains a ptlc output, then if Alice >has not retained the old ptlc details (the point and the timeout) >she will not trivially be able to reconstruct the script path, >which includes the timeout. However, presuming the timeout was >within 5000 blocks, then the only possible timeouts are the inflight >tx's nlocktime+i with 05000*k cases and match the corresponding scriptPubKeys to exhaustively >enumerate every possible ptlc output, which should take under a minute, >and be easily achievable. In addition, if Bob attempts to claim the >funds, he will reveal the script path, and Alice will be either able >to claim the inflight output directly or the layered output. > What about just doing a scriptless PTLC to avoid this (just CSV input of presigned tx)? The cost is pre-sharing more nonces per PTLC message. This does not
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Hi Z, Thanks again for getting to the bottom of this. I think we are on the same page except for one clarification: On Tue, 8 Jun 2021 at 12:37, ZmnSCPxj wrote: > Thus, in our model, we have the property that Bob can always recover all > signatures sent by Alice, even if Carol is corrupted by Alice --- we model > the signature-deletion attack as impossible, by assumption. > (This is a strengthening of security assumptions, thus a weakening of the > security of the scheme --- if Bob does not take the above mitigations, Bob > ***is*** vulnerable to a signature-deletion attack and might have ***all*** > funds in hostage). > Only where ***all*** refers to the funds in the fast forward -- funds consolidated into the channel balance are not at risk (modulo enforcing correct state on chain). I think it should be easy to get a stream of signatures so they can't be deleted. The user "Bob" is creating and sending the invoices so they can always demand and save the signatures from "Carol the Cashier" that correspond to each payment so the "deletion attack" will be thwarted. LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Hi Z, I agree with your analysis. This is how I pictured eltoo fast forwards working as well. Another interesting thing about this idea is that it could allow a new type of custodial LN provider where the custodian is only in charge of receiving payments to the channel but cannot spend them. With the non-custodial LN phone apps there is this annoying UX where you have to keep the app open to receive a payment (because the pre-image is on my phone). I wouldn't mind letting the provider handle receiving payments on my behalf. Of course this means they would be able to steal the money in the FF state but this is a big reduction in risk from a full custodial solution. In other words, you should be able to get the seamless experience of a fully custodial wallet while only giving them custody of small amounts of coins for a short time. On Wed, 2 Jun 2021 at 13:30, ZmnSCPxj wrote: > > Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do > *not* build up a long chain of HTLC txes. > At the worst case, we have an old update tx that is superseded by a later > update tx instead, thus the overhead is expected to be at most 1 extra > update tx no matter how many HTLCs are offered while Bob has its privkey > offline. > I don't think you need to build up a long chain of HTLC txs for the Poon-Dryja fast forward in the "desync" approach. Each one just replaces the other. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Hi Z, I just went through the presentation which made your thinking very clear. Thanks. I will not be able to match this effort so please bear with me as I try and explain my own thinking. I don't see why fast forwards (FF) need "symmetrically encumbered outputs"? To me the protocol should be asymmetric. This is what I think happens when offering a FF HTLC: 1. The offerer creates and signs a new commitment tx as normal with the HTLC except it has the same revocation key as the last one. 2. The offerer patches their balance output by sending a tx spending from it to a new tx which has the HTLC output and their balance output (unencumbered). The HTLC is now irrevocably committed from the perspective of the receiver. Now the receiver presents the pre-image and the offerer then: 1. The offerer creates and signs a new commitment tx as normal consolidating the funds into the receiver's balance output except once again it has the same revocation key as the last one. 2. The offerer patches their commitment tx balance output again by sending a tx spending from it to a new tx which splits into the receiver's balance (the value of the claimed HTLC) and the offerer's remaining balance. You can repeat the above process without having the receiver's revocation keys online or their commitment tx keys for many HTLCs while the offerer still has balance towards the receiver. The on-chain cost is about the same as before for an uncooperative close. Once the receiver brings their keys on line they can consolidate the FF state into a new commitment txs on both sides and with a proper revocation operate the channel normally. What has been the receiver up until now can finally send funds. Am I missing something? Cheers, LL On Mon, 31 May 2021 at 19:47, ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > > It may be difficult to understand this, so maybe I will make a > convenient presentation of some sort. > > As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp > > The presentation is intended to be seen by semi-technical and technical > people, particular those that have not read (or managed to fully read and > understand) the original writeup in 2019. > Simply "run" the presentation (F5 in LibreOffice), as the presentation > uses callouts extensively for explication. > > Regards, > ZmnSCPxj > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Improving Payment Latency by Fast Forwards
Hey Z, Thanks for your analysis. I agree with your conclusion. I think the most practical approach is the "ask first" 3 round protocol. Another option is to have `remote_penaltyclaimpubkey` owned by the node instead of the hardware device. This allows funds to accrue in the fast forward state which can be swept into the commit tx at the merchants discretion. If a fast forward state needs to be asserted on-chain it can then be done automatically without the hardware device. Of course, the funds in the FF state are more vulnerable than the main channel balance during that time because their keys are not in a secure device but this seems ok. The obvious analogy is to having cash in the till (less secure) that you send to your bank (more secure™) at the end of the day or week. > We ***need*** privkeys to be periodically online more often than `to_self_delay` anyway, ***in case of theft attempts***. > So this is not an ***additional*** requirement at least. This is a really important point. I guess you have to actually do this periodically, only when there is an actual attempt at theft. Quite annoying to UX to require this. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Recovery of Lightning channels without backups
On Mon, 3 May 2021 at 22:58, David A. Harding wrote: > On Mon, May 03, 2021 at 11:01:48AM +1000, Lloyd Fournier wrote: > > 2. It is not easy to figure out whether it worked or not > > Good point. > > > 3. This is incompatible with covert recovery schemes like in [1] [...] > > (3) is also a problem with just doing encrypted backups -- going around > > looking for backups means you tell everyone that you are in recovery > mode. > > Eh, I assume nodes using the backup commons would, each time they're > restarted, go through the steps of downloading some number of backups > even if they haven't lost any data. This tests that the backups are > being stored faithfully (essential to any backup process) and provides > cover for cases where a node does lose data. > Ok this is a fun idea and hadn't thought of it like that before. Here are the thoughts that come to mind: 1. Each time you start up your node you backup you go around to different nodes -- but the obvious question is *which* nodes do you go to? You could try and do something like rendezvous hashing [1] to reduce the set (with some secret data as input so it is not predictable to anyone but yourself) . 2. What do you backup? Full-channel state or just a channel list? Even if you have mostly honest backup nodes you need to make sure you delete old states from your remote backups before revoking them if you do full backups. This slows down sending payments but it might be worth it for users like myself. So perhaps it's still better to avoid full backups here. [1] https://en.wikipedia.org/wiki/Rendezvous_hashing LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Recovery of Lightning channels without backups
On Thu, 29 Apr 2021 at 06:15, David A. Harding wrote: > why can't she sign a message that gets gossiped across the network that > says, "if you have a channel with node_id 0xa11ce, please close it now"? > Hi David, As a user this would be an improvement. There are a few downsides though: 1. It creates a new gossip message that can be spammed. 2. It is not easy to figure out whether it worked or not (maybe the person I had my channel with is offline?). 3. This is incompatible with covert recovery schemes like in [1] whereas what I propose here builds towards making such schemes possible in the future. (3) is also a problem with just doing encrypted backups -- going around looking for backups means you tell everyone that you are in recovery mode. [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002912.html LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Recovery of Lightning channels without backups
On Wed, 28 Apr 2021 at 09:36, Lloyd Fournier wrote: > I wonder if it is even necessary to bump the generation until a funding > tx is confirmed -- I can't think of a good reason why you would want to > open two channels to the same node at the same time (why not put all your > funds into the same funding). > Nevermind I've thought of a few -- ignore this point! LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Recovery of Lightning channels without backups
Hey Rusty, Thoughts on each point below. On Fri, 23 Apr 2021 at 14:29, Rusty Russell wrote: > OK, I'm now leaning *against* this method. > > 1. It removes the ability to update a channel without access to the node's >secret key. At the moment the node secret key is only needed for >gossip and to DH to set up a new peer connection. c-lightning does >not use this for now (we keep the per-channel keys in the HSM too), >but it would be a perfectly acceptable tradeoff not to do this. > Don't you also need the node secret key for onion routing? i.e. every time you update your channel to forward a payment. I am not familiar with lightning HSM designs and security goals but to me it doesn't sound like much of a cost to keep the key on the HSM and to include doing channel updates as well seeing as it's already doing so much work. If it is desirable to have different keys for DH and channel updates then a simple solution is to have two static public keys -- one for each task. >From my perspective it is worth making the necessary sacrifices to include this feature. For me and many people, lost data without backups is the biggest risk to my funds in lightning. Certainly much more threatening than whether certain keys are on a HSM or not. Anecdotally I've heard stories like "I put my lnd on autopilot and then lost my disk died -- all my funds are gone!?" more than once. 2. It doesn't get rid of temporary_channel_id, since we don't know >the generation_number until both sides have sent it. We have a >workaround for this already in dual-funding anyway. > Why did you decide to send this rather than just look up in your own database what "generation" should be? I think that it's easy to make sure that you and the other node are on the same page about this number without communicating it. If someone is opening a channel with data that appears to be invlaid because they are using the wrong generation then sending an error back indicating what you are up to should be sufficient to recover? > 3. Because we need a generation counter, it's not quite as easily >scannable as you'd hope (the "gap" problem). > This doesn't seem to be a big issue. You are trying to recover your funds after all so you can afford to scan over very large gaps i.e. leave the node on for days. I mean my Bitcoin wallet manages to handle this so why wouldn't it work here? I wonder if it is even necessary to bump the generation until a funding tx is confirmed -- I can't think of a good reason why you would want to open two channels to the same node at the same time (why not put all your funds into the same funding). > I think the "encrypted blob served by peers", even in a very naive way, > offers another way to do this, though it requires the assumption that at > least one peer is honest. > I see encrypted backups as complementary. With this scheme you can at least find a peer that you've had a channel with. From the encrypted backup you left with them you can then find others and check against them. LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Recovery of Lightning channels without backups
Hi Rusty, On Tue, 20 Apr 2021 at 10:55, Rusty Russell wrote: > Lloyd Fournier writes: > > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell > wrote: > > > >> > >> Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)? > >> > >> Nice work. This would be a definite recovery win. We should add this > >> to the DF spec, because Lisa was almost finished implmenting it, so it's > >> clearly due for a change! > >> > > > > Yes that's certainly a fine way to do it. > > I was also thinking you could eliminate all "basepoints" (not just > funding > > pubkey) using something like this. i.e. just use the node pubkey as the > > "basepoint" for everything and randomize it using the shared secret for > > each purpose. > > OK, I tried to spec this out, to implement it. One issue is that you > now can't sign the commitment_tx (or htlc_tx) without knowing the node's > secret key (or, equivalently, knowing the tweaked key and being able to > use the derivation scheme to untweak it). > Using node secret key to sign the commitment_tx seems like something you will have to accept to introduce this feature. For the idea to work it has to be some public key that is known by others and gossiped through the network. Of course you could extend the information that is gossiped about a node to include a "commit_tx_point" but the nodeid seems the more natural choice. > c-lightning currently does a round-trip to the signing daemon for this > already, but it'd be nice to avoid requiring it. > > So I somewhat reluctantly added `commit_basepoint` from which the others > are derived: an implementation can use some hardened derivation from its > privkey (e.g. SHA256(node_privkey || ss || counter)) to create > this in a deterministic but still private manner. > > Or we could just leave all the other points in and just replace > funding_pubkey. > Another approach is to do things in "soft-fork" like manner. Each node that wants to offer this feature sets their funding_pubkey to a specified DH tweak of the nodeid. Nodes that want backup-free channel recovery can just refuse to carry on the funding protocol if the funding_pubkey is not set the way it wanted. >From my pruisit crypto point of view having only one public key is nice but I'm not sure how it impacts things architecturally and other protocols like watchtowers. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Questions on lightning chan closure privacy
Hi Lee, You are touching on some very relevant privacy challenges for lightning. To your questions: 1. Is it possible to identify which node funded a lightning channel? (this tells you who owns the change output) 2. Is it possible to identify who owns which channel close output? I think that the answer to both these questions hinges on whether you exclusively use private channels. If you fund private and public channels with the same wallet then it may be possible to identify your private channels and the owner of the channel and channel close outputs[1]. I've recently tried to describe what I think needs to happen to turn lightning into an effective layer-1 privacy tool in the "Removing cross-layer links" problem on bitcoin-problems.github.io[2]. Cheers LL [1] https://arxiv.org/pdf/2003.12470.pdf (section 3.2).[2] https://bitcoin-problems.github.io/problems/removing-cross-layer-links.html [2] https://bitcoin-problems.github.io/problems/removing-cross-layer-links.html On Sat, 17 Apr 2021 at 12:22, Mr. Lee Chiffre wrote: > > > Two, if the balances of each side of a > > channel are different when closing vs. opening, can someone determine > > which output from the 2 of 2 multisig belongs to who? > > > A thought to add to my last email. In theory it could be determined if the > output belonging to a certain node later uses that as an input for a non > private chan opening right? But that would also look the same if it was > also the same user opening a new chan to that node? > > This brings to another question. Not just chan closure but on chan opening > is it possible to determine which input came from who? > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Pay-for-Elgamal-decryption-key and its application to Anonymous Credentials
Hi Miyamoto,
Very interesting idea :)
Usually when dealing with anonymous credentials you are necessarily dealing
with a trusted third party so it's fine to just make a normal payment and
then receive the credential after successfully paying.
But I see the advantage of your idea. If a malicious credential server is
able to identify you somehow at the point of payment then they might want
to selectively steal your money while being honest with everyone else.
In your scheme, if you pay you get the credential and then since it is
anonymous it can't be distinguished from others when you go to claim
whatever it entails.
Is this the idea?
Cheers,
LL
On Thu, Feb 4, 2021 at 1:04 PM 宮本丈 via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
>
> Hi all.
>
> I want to point out another application of Discrete-Log selling on PTLC
> lightning since I could not find anyone else mentioning it (in particular,
> I could not find in the Nadav Kohen's list here. [1] )
>
> The protocol may be obvious to most of the members here, but I believe its
> application has some impact on the way people make anonymity-focused
> applications with LN, so I want to have some feedback.
>
> In short, by using ElGamal encryption, we can sell not only a discrete-log
> but also an elliptic curve point which satisfies some requirements. This
> includes KVAC [2] which is used for WabiSabi [3] and Signal app [4].
>
> > disclaimer: I'm not a cryptography or math major, the following
> reasoning might be wrong at the fundamental level. Please correct me if I'm
> wrong.
>
> ## Notations
>
> * G ... Elliptic curve base point.
> * H ... some additional NUMS
> * x, X = x * G ... secret and public key
>
> For ZKPoK, I will use Camenisch-Stadler like notation
> PK{ (secret values) : statements about secret values to prove. }
> e.g. For DLEQ proof. assume the verifier already have some points P_1, P_2
> PK{ (x, y) : P_1 = x * G and P_2 = y * H and x = y }
>
> # Protocols
>
> ## pay-for ElGamal decryption key
>
> Quick recap, ElGamal encryption for message M (= m * G) is
> (r * G, M + r * P)
> where r is some blinding factor and P is a shared secret (P = p * G)
>
> Imagine the Buyer knows some point (X_h = x * H), and he wants another
> point (X_g = x * G).
> The Seller knows x and he wants to sell the point X_g but he does NOT want
> to reveal its discrete log x to the buyer.
> (There is not much of a situation like this, but I will explain it later.)
>
> In this case, the Seller can send its elgamal encryption and sell its
> decryption key.
> Seller:
> * Generate ephemeral encryption key S = s * G
> * Encrypt X_g with random blinding r ... (c1, c2) := (r * G, X_g + r * S)
> * Send (c1, c2) and S to the Buyer.
> * Also, send PK{(x, r, s) : c1 = r * G and c2 = x * G + r * S and X_h = x
> * H }
>
> Buyer
> * Verifies the ZKPoK, he can be sure that the plaintext will be X_g that
> he wants.
> * Make a payment offer to the Seller with S.
>
> Seller
> * Receive the payment by revealing s
>
> Buyer
> * Decrypt the ciphertext by s to get the X_g ... (X_g := c2 - c1 * s)
>
> ## Pay for Keyed Verification Anonymous Credential. (KVAC)
>
> We assume MAC_{GGM} scheme for the KVAC. [2]
>
> * attributes encoded in the credential is m_1, ... m_n
> * secret keys for the issuer=verifier is r, x_0, x_1, ... x_n
> * Public params for the issuer is (C_x0 = x_0 * G + r * H), (X_1 = x_1 *
> G, ... X_n = x_n * G)
>
> The credential is of the form (U, U') where U' = U * (x_0 + x_1 * m_1 +
> ... + x_n * m_n)
>
> Issuer:
> * get random point `U`
> * compute U' = U * (x_0 + x_1 * m_1 + ... + x_n + m_n)
> * sends U and ElGamal encryption of U' to the Buyer with blinding factor k
> and ephemeral encryption key S.
> * (c1, c2) = (k * G, U' + k * S)
> * Also send ZKPoK to tell the ciphertext is for correct U'
> * PK{(x_0, ... x_n, x_0, r, k, s) : U' = U * (x_0 + x_1 * m_1 + ... +
> x_n * m_n) and C_x0 = G * x_0 + H * r and X_1 = x_1 * G and ... and X_n =
> x_n * G and c1 = k * G and c2 = U' + k * S }
>
> Then Buyer can buy s as the same as above.
>
> # Why this matters
>
> I believe that KVAC has great potential as a building block of anonymous
> web apps.
> Its MAC-based construction is more performant and easy to prove the
> security compared to the similar system for the PKI based anonymous
> credentials (e.g. U-Prove [5] and ACL [6]).
> And it's a great fit for commercial purpose applications which do not have
> to cooperate with other entities when defining the protocol. (Which is not
> the case for an Attribute based credential system in general.)
>
> The reason so far it has not been used widely is, IMHO, it's because there
> is no way to charge its users anonymously. [7]
> Another problem is Sybil attack. In general, the DoS protection is a great
> concern for anonymous applications.
> So we need users to commit something "scarce" to prevent it.
> It is why Signal requires its users to register their telephone number
> (Maybe I'm wrong about this,
Re: [Lightning-dev] PoDLEs revisited
On Fri, Jan 29, 2021 at 10:51 AM Rusty Russell wrote: > Less true after taproot though? > The heuristic from [1] is not affected by Taproot. Taproot will be helpful for keeping private channels private against the method in [2] though. > [1] https://arxiv.org/abs/2007.00764 > > [2] https://arxiv.org/pdf/2003.12470.pdf > > [3] https://graphsense.info/ > > > > I am told there is a new revision of [1] coming out any day now that will > > present a few more tricks and have contributions directly from a > scientist > > at Chainalsysis (the company). > > I'll add to my reading list (or wait for one of my colleagues to provide > the TL;DR!). > > Let me TL;DR quickly the core idea quickly as it's not too difficult to grasp. 1. You are node n_1 2. You fund a public channel to node n_2 called c1 3. You use the change to fund a public channel to node n_3 called c2 4. The network sees that n_1 is involved in both c_1 and c_2. They're both public channels so the channel_id gives away the on-chain funding utxo. Everyone can conclude that the owner of n_1 was also the funder of both and therefore owns the change output of the funding of c_2. Consider a variant of this heuristic where instead of using funding change they use the output of a cooperative close of c_1 to to fund c_2. By the same reasoning you can identify the owner of n_1 funded the channel but you can also now know that n_2 is the owner of the other utxo of the close of c_1. The point of this is if you are a node that is churning UTXOs from the funding change or the closing UTXO into other public channels you necessarily associate those UTXOs with your node id and any descendent utxos. This is the point of UTXO probing too but with this you get the info for free by just passively observing the new channel gossip. I think this makes UTXO probing useless as long we can assume that public nodes that accept dual funding requests from random people on the internet (and therefore vulnerable to probing) are also likely to use their wallet funds to fund channels in the future. LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] PoDLEs revisited
On Wed, Jan 20, 2021 at 12:34 PM Rusty Russell wrote: > > > Yes, sorry. I assumed immediate broadcast + 60 second wait for > conflicts. It's this scheme I was trying to shoehorn into the mempool > (broadcast signalling tx, wait, try to RBF it with a real open). But > there are three problems with doing that: > > 1. Everyone knows what you're doing, as they see the signalling tx (and >it needs to commit to a challenge, such as using OP_RETURN, so you >can't simply reuse the same tx). > 2. Bitcoind doesn't tell you if it encounters a conflicting tx from a >peer, so we'd probably need to gossip this via lightning instead. > 3. If tx fees are low, the signalling tx might get mined. > I think immediate broadcast of signaling TX is a bad idea even if it's done over lightning since it leaks that the UTXO associated with the signaling TX is creating a channel (even if the channel was meant to be private). You could argue that the signaling TX need not be associated with a UTXO but I find this awkward. Lazily broadcast, signaling txs are a good way to protect against sequential attacks but are weak against parallel attacks. Unfortunately I think protection of the former means very little without the latter. > > > There are several (perhaps addressable) downsides to this scheme but it > at > > least has better protection against parallel attacks than the others. > > Since it is effective it would also break the "middleman" idea unless > Alice > > funds with two utxos (a different h2 for each party) or there is some way > > for all parties involved in the funding to distinguish gossiped h2s from > > their funding session from others. > > Yes, every initiator needs to provide an h2, and it has to be their own. > But you don't care (and can't know) that there's an h2 for another > input, too. If Alice wants to initialte an open with Carol while Bob is > initiating an opening with her, she's got to provide her own UTXO & > PoDLE. > > Another point: the idea was that the accepting node would sign the > gossip msg, and only known nodes (i.e. ones with a public channel) would > be allowed to do so. This gives easy anti-spam: if Alice starts > spamming a giant pile of h2s, we start randomly dropping them. That > doesn't degrade the protection much: a single UTXO reuse might slip > through, but a larger number would still be detected with P approaching > 1. > > Ok since it appears eagerly broadcasted PoDLEs are the only proposal that can protect against parallel attacks let's try and put the best version of it forward. Here's my shot. Let H0 and H1 be 32-byte output hash functions. 1. In any of the `tx_add_input` messages the initiator may attach a PoDLE which contains the public key for an input as well as a P2 (the public key projected onto a different generator). 2. Upon receiving the PoDLE, the peer checks its validity and creates a "claim" message claiming the UTXO which contains. i) H0(P2) ii) A MAC (e.g. Poly1305) produced with the H1(P2) as the key and claimer_node_id as the message -- required so conflicting claim messages can only be produced by someone who actually knows P2. iii) The claimer_node_id and a BIP340 signature under it over the rest of the message data -- required to stop spam: only accept and re-broadcast these messages from nodes who have real channels. The peer broadcasts this claim message if they haven't before received a valid claim message with H0(P2) and a valid MAC. 3. Any node receiving the claim message checks whether it has seen it already (same H0(P2) and MAC). If not, checks the signature against claimer_node_id and checks whether that node is valid (or perhaps blacklisted because it has spammed too many claim messages recently), stores (H0(P2), MAC, claimer_node_id) it and re-broadcasts the message to its peers. 4. The claiming node waits ~60 seconds to see if it receives a conflicting claim message where the H0(P2) is the same and the MAC is different and valid. If they don't receive that then they carry on to add their own utxos. I believe this does guarantee what we wanted: an attacker will only be able to do the attack once per UTXO. This is better than I expected to find at the beginning of entering into this subject! This certainly seems to be the strongest in the class of solutions. Now I'd like to make the strongest possible argument against it in favor of just doing nothing (for now) at the protocol level about this problem. Consider the following propositions: 1. The public nodes that will offer dual funding and are susceptible to this attack will be the kind that have a lot of churn i.e. they dual fund a channel, when that closes they use the remaining funds to fund another channel. 2. Chainalysis already works very well at identifying the UTXOs these kinds of nodes. If the change output of a funding or the closing output are reused in another public channel it is easy to identify which node was funding what with the techniques in
Re: [Lightning-dev] PoDLEs revisited
On Wed, Jan 13, 2021 at 11:54 AM Rusty Russell wrote: > Lloyd Fournier writes: > > Rusty, Zman, > > > > A concern I have with only doing one signaling transaction out of the > whole > > group of inputs is that it means you don't prove ownership of the other > > inputs. > > But that's by design. You can contact two peers and middleman between > them to produce a single tx. > Ah. I missed this motivation. So you actually want to have sessions where you use the same signaling transaction in all of them. That's a cool idea. > > The practical problem with a signalling tx is that it's hard to tell if > it's conflicting. Mallory uses a single UTXO to probe for everyone's > UTXO at once. Poor Bob wants to both wait 60 seconds to see if a > conflicting tx ends up in his mempool, *and* broadcast it ASAP to signal > to others. He wants to do both of these *before* revealing his own > UTXOs. > > I think this is a problem with all three schemes I mentioned. You will always have to wait for things to be gossiped in some way to catch attempts at parallel sessions. Of course there could be faster mediums than the mempool but it does seem a convenient one to use. Note that you should not wait a predictable amount of time but rather a randomly sampled amount from e.g. 0-60 seconds (or longer). If everyone is waiting the same predictable amount of time it does nothing to protect you. But the "middleman" idea you mentioned above makes this all the more complicated: If you are meant to have parallel sessions then this is a problem for an honest Alice who initiates a funding with Bob and Carol. Bob decides to wait 24s and Carol decides to wait 55s to check the mempool for the signaling before revealing their utxos. After Bob wakes up from his 24s he will add his own utxos and demand that Alice complete the transaction by signing it. But since Alice is trying to also add Carol's UTXOs to the transaction she will have to wait until Carol becomes responsive again. To Bob this will look like Alice has become unresponsive through no fault of her own and Bob will broadcast the signaling tx. In other words, if parallel sessions are legal then you shouldn't try and catch parallel sessions. But if parallel sessions are legal there will always be an effective dual funding UTXO discovery attack by using one UTXO to hit many targets. I think this is true for all three schemes I mentioned. It seems the really difficult question is: is it even worth trying to stop sequential attacks if parallel attacks are unstoppable? Not sure how to square this, but I do prefer this approach over PoDLE. > I think PoDLE might actually have an advantage in parallel attacks if the scheme was changed a bit. A weakness of the lightning proposal as compared to the joinmarket idea is that the `h2` point is not broadcast immediately -- rather you wait for failure and then broadcast it. Instead, a peer should broadcast h2 as soon as they have agreed to create a transaction with the initiator. Then if at any time during the tx creation protocol they receive the same h2 from someone else, they cancel and don't reveal their UTXOs (let's say they wait ~10s after broadcasting before revealing any utxos). Note that here you don't have to randomly select the time you wait. There are several (perhaps addressable) downsides to this scheme but it at least has better protection against parallel attacks than the others. Since it is effective it would also break the "middleman" idea unless Alice funds with two utxos (a different h2 for each party) or there is some way for all parties involved in the funding to distinguish gossiped h2s from their funding session from others. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] PoDLEs revisited
Rusty, Zman, A concern I have with only doing one signaling transaction out of the whole group of inputs is that it means you don't prove ownership of the other inputs. I am not exactly sure what you could do by adding inputs from the chain you don't own but it does feel a bit risky. Perhaps it would allow you to add whale output from the chain to trick the peer's algorithm for deciding how much they want to add to the funding. Perhaps regulators of the future might check whether the LN node is following their directive to ban certain inputs on a blacklist -- If you carry on after the funding_add_input from a blacklisted input you must not be running our gov approved node! If that is not a concern, then I agree a single 1-input-1-output signaling transaction should be fine, otherwise requiring 1-input-1-output signaling tx for each input the opener adds may be prudent (as Z suggested). > [2] Which Lisa promises she'll publish RSN, so we can add your derived points proposal to it. Looking forward to seeing this :) Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
On Sat, Dec 19, 2020 at 6:48 PM ZmnSCPxj wrote: > Good morning LL, > > > > I suspect part of the proof-of-discrete-log-equivalance can be gated > as well by a ZKCP on payment point+scalar the proof is provided only on > payment. > > > The selling node operator does not even need to reveal `z`. > > > > Actually no -- the fact that you were able to create a secure > conditional payment for the proof would always prove the proof existed. > > You wouldn't need to pay for the proof then! > > That depends on the proof. > > For example, one pay-for-proof scheme would be somebody to provide you an > `(R, S)` for a public key `P = p * G`, where `S = s * G` (i.e. a > signature, or a proof that you know `p` where `P = p * G`), and it would > not prove anything until you pay for the scalar `s` and the prover can > provide `s`, since `S` is computable from public information that anyone > can have. > So it really depends on what you want to prove; a mere ZKCP is not always > enough. > > Regards, > ZmnSCPxj > > PS I am dabbling in BTRFS now though, so --- > You're right. I stand corrected. It is possible to construct ZKCP payments where the messages sent by the prover up until the point the prover claims the payment (and reveals the witness) could have been simulated by someone who doesn't know the witness. You give a good example of this. After thinking about your post I recalled that I used a similar argument about the security of my protocol for buying an opening of a Pedersen commitment with Bitcoin [1]. [1] https://github.com/LLFourn/buying-pedersen-commitment/blob/master/main.pdf LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
> I suspect part of the proof-of-discrete-log-equivalance can be gated as well by a ZKCP on payment point+scalar the proof is provided only on payment. > The selling node operator does not even need to reveal `z`. Actually no -- the fact that you were able to create a secure conditional payment for the proof would always prove the proof existed. You wouldn't need to pay for the proof then! LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj wrote: > A common occurrence is that hardware failure is not detected until when the hardware is used, especially when used by casual users. > > Consider the sequence of events: > > * Part of the storage device fails. > * Due to being a casual user, the user does not use state-of-the-art checksumming filesystems like ZFS and does not monitor disk health by S.M.A.R.T. > * A high-onchain-fee condition exists. > * The casual user attempts to send out a payment consisting of almost all funds in their LN channels via several HTLCs on MPP or other multipath. > * Because of the activity generated, the filesystem assigns the LN database to the failing part. > * Storage fails with most funds in outgoing HTLCs. Note that this is fine if the payment goes through. Their counterparty will have to go on-chain to claim the payment (since your node is down due to data-loss) and then you claim whatever is left from your seed. The main risk here is for routing nodes which are hopefully only using this technique as a very poor last resort. If you actually manage to get online and try to restore before the on-chain settlement then just attaching outgoing HTLCs to the mutual close would be fine -- that way the peer can still claim the money from you if the payment goes through and you can get the refund if not. The same could apply to incoming HTLCs as long as you can reproduce your HTLC pre-image deterministically. PS good to hear you are a ZFS user too > > Thus, merely activating the wallet and using HTLCs may result in a *detectable* failure of the hardware (which was already failing before, just not noticed by the casual user). > > On the other hand, we can consider this situation as having a complexity penalty. > > As someone who has seen a lot of storage devices slowly fail in unique and interesting (and data-losing) ways, I am always going to assume that storage devices are going to fail at any time, including a few hours after installation. > > It would be preferable if HTLCs and PTLCs are not gifted. Yes I am convinced. > > > > > Using static-key channels (i.e. channel keys are our node keys) allows us to recover even the outgoing channel with outgoing HTLC that has been forgotten by the outgoing peer. > > > > Right. I think this doesn't work with PTLCs though. > > Yes, loss of the adaptor signature means we cannot recover in this case. Let's think about this again. There is no reason why the oblivious mutual close has to be the only thing the peer sends you upon connection. They can also send you the necessary signatures for each PTLC output on the mutual close because you can't do anything with this unless you choose to receive the mutual close signature. You verify these each time you connect without data loss so optimistically you should be able to recover both incoming and outgoing PTLCs > Right, that would work. > > How about just using a multiplicative tweak of your own privkey and the pubkey of the other node (i.e. just use the "raw" ECDH point), that would work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be signable using MuSig/MuSig2 under taproot? I think multiplicative combination of keys does *not* work for Schnorr multisignatures. > > "Peer selling private information" is always going to be an issue with unpublished channels, and this seems to be an inherent issue with that model. > > Note that due to the existence of proof-of-discrete-log-equivalence, a node operator can *prove* to someone buying private information that a particular outpoint onchain is actually an unpublished channel. > If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my node pubkey), `L` (your "unpublished" (ha, ha) node pubkey), and `z * L` (our ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in `z * G` is the same `z` in `z * L`, in order to convice them of the ECDH secret. > I suspect part of the proof-of-discrete-log-equivalance can be gated as well by a ZKCP on payment point+scalar the proof is provided only on payment. > The selling node operator does not even need to reveal `z`. > > As the ECDH secret is what tweaks the channel keys, that is enough to convince any surveilling buyer. > Further, `z` is not revealed, and channel funds cannot be stolen by just knowledge of the ECDH secret, thus protecting the interests of the selling forwarding node. > > Now of course, I could just be making up `L` (i.e. LL could be a sockpuppet of mine). > However, between these two choices: > > * I lock up a set number of millisatoshi in a Z + L channel where L is a sockpuppet, and sell this fake information to surveillors. > * I lock up a set number of millisatoshi in a Z + L channel where L is a genuine user node that thinks unpublished channels are private, and sell this genuine information to surveillors. > > Which is more lucrative for me? > The latter case would be more lucrative for me, as I not only earn from selling your
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
Hey Z, On Tue, Dec 15, 2020 at 9:21 PM ZmnSCPxj wrote: > > Good morning LL, > > > > - What do you do if the channel state has HTLCs in flight? I don't know -- > > I guess you can just put them onto the settlement tx? That way it's > > possible the payment could still go through. Alternatively you could just > > gift the money to the party offering the recovery settlement. > > Gifting the money is not a good option --- we allow HTLCs to be almost as > high as the total channel value minus fees and reserve. > Thus all the claimable value could potentially be in an outgoing HTLC. > Worse, if our node is a forwarding node, it would be easy for a third party > to arrange to have our funds in various HTLCs. Hopefully this recovery system is used by people whose channels are in a HTLC free state 99.% of the time (and hopefully hardware failures do not somehow coincide with HTLCs!). As a user, it would be cool to be able to just lock up all my Bitcoin into channels with well-established lightning nodes. That way if fees go ballistic I can still move money around cheaply. One of the main concerns for this pattern of user behaviour is the recovery story I think. The first line of defence for routing nodes (people who are taking their role in LN seriously) has to be redundant data storage. This would be a poor last-resort solution for routing nodes. > Using static-key channels (i.e. channel keys are our node keys) allows us to > recover even the outgoing channel with outgoing HTLC that has been forgotten > by the outgoing peer. Right. I think this doesn't work with PTLCs though. > Using static-key channels does have slightly weaker privacy: > > * Published nodes reveal all their channels with other published nodes on the > blockchain. > * While it is true that published nodes already reveal their channels with > published nodes, they are currently only revealed on the LN gossip network, > which is not archived; historical channels that are now closed are not > informed to current surveillors. > * On the other hand, all it takes is one "LN wayback machine" to record > all LN gossip, which are self-attesting and include a signature from the node. > * Unpublished nodes risk revealing their channels with published nodes via > the blockchain. > * Invoices created by unpublished nodes currently reveal their public key. > Payers can then uncover all the channels of that node. I don't think so? You need to know the private key of the node to discover its channels! The points actually used in the channels would be randomized with shared secret from Diffie-Hellman so are unlinkable to the public keys of the two nodes under decisional Diffie-Hellman assumption. There is more minor but still real concern of "deniability" of unpublished closed channels if a large node operator later becomes corrupted or coerced by a malicious actor. Since the node operator still knows their secret key (obviously) they can still do a scan (same as you would do in recovery) on the whole chain and find any past channels they had with any nodes. A mitigation of this problem would be for users who want unpublished channels to turn the use-node-key-as-channel-key feature off for their keys in the channel so they would still be able to do a backup-free channel scan but the well-established node would lose the ability to do so. This means that after the channel is closed there would be no way for the large node to find the channel again assuming they honestly delete the data. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
Errr please replace 5 with 4 in the previous post. Thanks to devrandom. LL On Tue, Dec 15, 2020 at 2:43 PM Lloyd Fournier wrote: > > > It seems difficult to recommend YOLO commitment transactions becoming the > > standard way to recover funds. It could be preferable to the current system > > but even that is up for debate I guess. > > I feel like I can recommend oblivious settlements because (i) it's covert > > (like YOLO commitments txs unlike current system) and (ii) it's "what you > > see is what you get" -- you are guaranteed to recover the funds that you > > are presented with once you finally trigger the recovery > > Off list Dave correctly pointed out to me that this wasn't a very clear > picture of the situation. > After some thought, I came up with these claims that I think I can make > strongly: > > 1. Before you reveal that you are doing recovery you are guaranteed to have a > tx in hand that: > i. You can broadcast first > ii. You can choose the fee to be as high as you like > iii. Is not replaceable. > 2. If the malicious party is *not* willing to risk broadcasting a revoked tx > then you are guaranteed to recover the face value of the transaction(s) you > have in hand. > 3. An honest party is never at risk of broadcasting a revoked commitment tx. > 4. You never have to reveal that you were doing a recovery i.e. the channel > can continue (strictly preferable to 1) > > Current system has: 3 > Oblivious mutual close has: 1,2,3 > YOLO commitments has: 1,5 > > So I think the question of YOLO commitments vs oblivious mutual close is > whether paying the price of losing (2,3) is worth the upgrade from (1) to (5). > The concern with (1) is that once you broadcast to the network the > obliviously transferred "mutual close" transaction, the malicious party then > has a hint that you have lost data and they can try and broadcast a > favourable revoked transaction. > This should be very hard since in (1) you broadcast first, can choose as > large a fee as you like and the tx does not signal replaceability whereas the > revoked tx *will* signal replaceability. > I'm also personally trying to avoid losing (3) because to keep [1] applicable. > > As a side note: in YOLO commitment transactions you have to recover some > additional metadata from the other party -- in particular the compressed > revocation keys that you *should* know otherwise the channel cannot continue > to operate. So a signature on the compressed revocation keys must be given to > the other party before you lose data and returned to you when you are given > the commitment transaction upon reconnection. > This should be easy enough to do though. > > [1] > https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments > > On Tue, Dec 15, 2020 at 12:13 AM David A. Harding wrote: >> >> > The idea I'm working with in revocable signature based channels [1] is >> > to make the node lose its static secret key if it posts a revoked >> > commitment tx. This means they could lose ALL funds from ALL their >> > channels with ALL their peers if they ever broadcast a single revoked >> > commitment transaction. This would be a very bad thing to happen while >> > you're trying to recover funds. >> >> Yikes! A very bad thing indeed. I'll have to re-read about witness >> asymmetric channels; I don't think I realized that was a consequence of >> using them. > > > It's an optional feature -- see link[1] above where I just added an > explanation of it. > I actually see no reason why you couldn't apply revocable signatures to > transaction asymmetric channels (LN as it is today) you just have to overhaul > the revocation mechanism. > > In general I agree with your points that side-channels may be effective tools > to reveal whether a node has had data loss or not. > I think in both YOLO commitments and oblivious mutual close it is easy enough > to simulate data-loss up to a point to try and catch malicious peers using > side channels. > At least you don't have to ask the peer to broadcast a tx to find out! > > Cheers, > > LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
> It seems difficult to recommend YOLO commitment transactions becoming the standard way to recover funds. It could be preferable to the current system but even that is up for debate I guess. > I feel like I can recommend oblivious settlements because (i) it's covert (like YOLO commitments txs unlike current system) and (ii) it's "what you see is what you get" -- you are guaranteed to recover the funds that you are presented with once you finally trigger the recovery Off list Dave correctly pointed out to me that this wasn't a very clear picture of the situation. After some thought, I came up with these claims that I think I can make strongly: 1. Before you reveal that you are doing recovery you are guaranteed to have a tx in hand that: i. You can broadcast first ii. You can choose the fee to be as high as you like iii. Is not replaceable. 2. If the malicious party is *not* willing to risk broadcasting a revoked tx then you are guaranteed to recover the face value of the transaction(s) you have in hand. 3. An honest party is never at risk of broadcasting a revoked commitment tx. 4. You never have to reveal that you were doing a recovery i.e. the channel can continue (strictly preferable to 1) Current system has: 3 Oblivious mutual close has: 1,2,3 YOLO commitments has: 1,5 So I think the question of YOLO commitments vs oblivious mutual close is whether paying the price of losing (2,3) is worth the upgrade from (1) to (5). The concern with (1) is that once you broadcast to the network the obliviously transferred "mutual close" transaction, the malicious party then has a hint that you have lost data and they can try and broadcast a favourable revoked transaction. This should be very hard since in (1) you broadcast first, can choose as large a fee as you like and the tx does not signal replaceability whereas the revoked tx *will* signal replaceability. I'm also personally trying to avoid losing (3) because to keep [1] applicable. As a side note: in YOLO commitment transactions you have to recover some additional metadata from the other party -- in particular the compressed revocation keys that you *should* know otherwise the channel cannot continue to operate. So a signature on the compressed revocation keys must be given to the other party before you lose data and returned to you when you are given the commitment transaction upon reconnection. This should be easy enough to do though. [1] https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments On Tue, Dec 15, 2020 at 12:13 AM David A. Harding wrote: > > The idea I'm working with in revocable signature based channels [1] is > > to make the node lose its static secret key if it posts a revoked > > commitment tx. This means they could lose ALL funds from ALL their > > channels with ALL their peers if they ever broadcast a single revoked > > commitment transaction. This would be a very bad thing to happen while > > you're trying to recover funds. > > Yikes! A very bad thing indeed. I'll have to re-read about witness > asymmetric channels; I don't think I realized that was a consequence of > using them. > It's an optional feature -- see link[1] above where I just added an explanation of it. I actually see no reason why you couldn't apply revocable signatures to transaction asymmetric channels (LN as it is today) you just have to overhaul the revocation mechanism. In general I agree with your points that side-channels may be effective tools to reveal whether a node has had data loss or not. I think in both YOLO commitments and oblivious mutual close it is easy enough to simulate data-loss up to a point to try and catch malicious peers using side channels. At least you don't have to ask the peer to broadcast a tx to find out! Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
Hi Dave, Thanks for taking a read. You brought up really good points that need addressing. This is really cool! However, I don't understand why it's needed. Your > goal seems to be for the sender to provide the commitment transaction > and signatures before he learns whether the receiver actually needs > them. That's just as easily accomplished by sending the data upfront in > plain text. > To be clear: The goal is to offer a cooperative settlement transaction up front to the (possibly) recovering party -- *not a commitment transaction*. Note we cannot send a cooperative settlement tx up front for each connection since they are not revocable -- the channel is over once it has been received. I admit I didn't properly consider just sending commitment transactions over. This is probably because it exposes the recovering party to the punishment mechanism and in my most recent line of research you *really* don't want to do this. The idea I'm working with in revocable signature based channels [1] is to make the node lose its static secret key if it posts a revoked commitment tx. This means they could lose ALL funds from ALL their channels with ALL their peers if they ever broadcast a single revoked commitment transaction. This would be a very bad thing to happen while you're trying to recover funds. I agree with your core point that in LN as it exists today the security assumption of both methods is that the adversary will be unable to distinguish a connection attempt after data loss from an ordinary one. If they can reliably do this then both methods can lead to loss of funds so why bother with the wonky crypto? I think there is a subtle reason why oblivious settlement signatures are still preferable: it is difficult to provide a coherent UX for recovery when just sending YOLO commitment transactions. It would be best if the recovery UX was "hey user I've found 0.367 Bitcoin across these three channels would you like to recover them?". The user can then accept this or cancel the recovery process and go through some extra trouble to recover their data (in practice, data is often not completely lost but recoverable with some effort). This is how it could work using the oblivious settlement txs I proposed. Using YOLO commitment transactions this becomes "hey user I've found 0.523 Bitcoin across three channels" which may actually be more than you are owed to entice you to shoot yourself in the foot. Even if it's exactly what you are owed, when you confirm the recovery your next message might be "nd it's gone" because one of the commit txs was revoked. It seems difficult to recommend YOLO commitment transactions becoming the standard way to recover funds. It could be preferable to the current system but even that is up for debate I guess. I feel like I can recommend oblivious settlements because (i) it's covert (like YOLO commitments txs unlike current system) and (ii) it's "what you see is what you get" -- you are guaranteed to recover the funds that you are presented with once you finally trigger the recovery. Although I do think oblivious settlement txs is a good idea I am working on yet *another* recovery idea for doing peer provided encrypted backup and full channel restoration in a way that provides another guarantee: If the peer sends you an outdated encrypted backup (perhaps in the hope that it has a revoked commitment tx in it) -- you can punish them immediately upon receiving the backup (if you haven't actually had data loss). Unfortunately, It looks like this will use more heavy cryptographic primitives. I think the challenge in either protocol above is deciding which peer > goes first, because whoever sends the commitment transaction reveals > what they think the current state is. Any node that refuses to go first > can then be suspected of having lost data. BOLT2 > option_static_remotekey has this same problem, which is reasonably > mitigated IMO by LN's penalty mechanism forcing any would-be thief to > risk their own funds; this doesn't work for basic eltoo, though. > What is the story with option_static_remotekey? I am interested to know how the negotiation of that option has a security issue but I don't see how it could. [1]: https://github.com/LLFourn/witness-asymmetric-channel Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Covert channel recovery with Oblivious Signatures
Hi list, Currently, if your lightning node has data loss there are two ways of recovering your funds once you have established which channels you had with which peers: 1. Wait until your peer closes the channel. The downside is that you have no control over when this happens. 2. Connect to your peer and ask them to close it. The downside is that to a malicious actor this request reads like "now is a good time to steal my money or extort me". What if instead we could somehow covertly get a signed cooperative settlement transaction for the most recent state without your peer knowing that you've received it? Luckily this mystical and almost incoherent requirement is provided by one of the oldest and well developed cryptographic primitives: the so called "Oblivious Transfer" (OT). https://en.wikipedia.org/wiki/Oblivious_transfer The idea might go something like this: every time you connect to your peer they present you with an unsigned cooperative settlement transaction for all channels you have with them. You and your peer then do an oblivious transfer where they send you their signatures on the transaction or nothing (whichever you choose). If you want to carry on with the channel you reveal to the sender that you chose nothing. If you are recovering funds you choose the signatures and broadcast the transaction. For this to be useful we have an extra requirement over typical OT which is that we can verify the contents of the message we didn't choose. i.e. even if we are not doing a recovery we have to be able to verify that the signatures we were offered were valid (wihout actually ever being able to use them!). Otherwise a malicious party could just be sending us invalid signatures in the OT the whole time. The name for this oblivious signatures. ## Constructing Oblivious signatures can be created using any verifiable encrypted signature scheme where the encryption key is a group element (this includes adaptor signatures). In [1] they actually use adaptor signatures without calling them that to create a Schnorr oblivious signature scheme that is similar to what you would do with BIP340 Schnorr in practice. I used this in [2] to create scriptless lotteries in Bitcoin. To start assume that you have three functions (which can be instantiated with adaptor signatures): - `encrypted_sign(x, m, Y) -> e` - `encrypted_signature_verify(X, m, Y) -> true/false` - `decrypt_signature(e, y) -> s` Where X is the public signing key Y is the encryption key and (x,y) are their corresponding secret keys. In our case x can be thought of as a secret key on a funding output. First, the party receiving the offer decides whether they want to receive the settlement tx signature by setting c = 0 or otherwise c = 1 and then creates a pedersen commitment Y to c by choosing a random y: Y = y *G + c * H and sends the commitment Y to its peer. The peer then sends `e = encrypted_sign(x, settlement_tx, Y)` back. If c = 0 (i.e. it is doing a covert recovery) it does `s = decrypt_signature(e, y)` and attaches to the settlement transaction and broadcasts it. The channel is now successfully closed assuming the encrypted signature was valid. If c = 1 (i.e. the node is fine and it wants to continue the channel) then it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes it sends the commitment blinding y back to prove that it doesn't have the signature (i.e. prove c = 1). If verification fails then the node is malicious and it fails the channel. Note that it is not possible to decrypt the signature if c = 1 since the discrete logarithm of H with respect to G is unknown. ## Misc Q - Does this require crazy crypto magic? No with the exception of Pedersen commitments it only requires what is being planned to be included in lightning anyway i.e. adaptor signatures. - Who is receiver and who is sender? In my imagination this works by the peer that is opening the connection being the receiver. This seems more useful since users who are likely to not have redundant storage and generally mess things up and need to recover are often behind NAT or on phone networks without a public ip. There are cases where a public node may want to recover by having people connect to them but I don't know what to do about that. It looks like you have to choose one or the other. - Can't they still steal money? Yes but this is still a strictly better than the current situation. The attacker has to guess precisely which connection you make is after data loss. This is tricky task especially because if they ever guess wrongly you close your channel with them and block them. Right now you are the one who tells them you've lost data! - Are these oblivious signatures secure? Yes. Sender security (receiver only gets the signature if c = 0) is based on discrete log assumption. Hint: if you instantiate the above algorithms with adaptor signatures we can extract the discrete log of H from a receiver who knows an opening of Y where c = 1
Re: [Lightning-dev] Recovery of Lightning channels without backups
On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell wrote: > > Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)? > > Nice work. This would be a definite recovery win. We should add this > to the DF spec, because Lisa was almost finished implmenting it, so it's > clearly due for a change! > Yes that's certainly a fine way to do it. I was also thinking you could eliminate all "basepoints" (not just funding pubkey) using something like this. i.e. just use the node pubkey as the "basepoint" for everything and randomize it using the shared secret for each purpose. Note that in practice you can have nodes reconnecting to you. > Hmm, this is a good point. I was incorrectly assuming the best way to implement "recovery mode" would be to never accept incoming connections. We've long thought about peers supplying some storage for each other, so > you can spray out (encrypted) backups that way. It's actually a fairly > trivial addition; your scheme makes for much less data to store. > I've also been thinking about the best way to go about this. If you're able to encrypt some backups to different places then all you have to do is find one of your honest channel partners using this method and then get encrypted hints to find them all. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Recovery of Lightning channels without backups
> Create a static channel backup after the fact. I have dubbed this a > synthetic static channel backup. I only use it to trigger the data loss > protection protocol. > By restoring this synthetic SCB a `channel_reestablish` is being sent to > the remote peer. This `channel_reestablish`contains the > `next_commitment_number`and the `next_revocation_number` both set to zero. > This triggers the remote peer to force close the channel dropping its > current commitment transaction to the chain. Using the > `per_commitment_point` received from the remote peer you can now derive the > private key needed for sweeping your funds, using > privkey = basepoint_secret + SHA256(per_commitment_point || basepoint) > Thanks Gijs for describing how this works I wasn't quite sure. The thing I dream of is being able to securely restore my layer 1 and 2 funds with just my seed. There was discussion of this idea in last lightning dev meeting: https://github.com/lightningnetwork/lightning-rfc/issues/821#issuecomment-740161185 A few of the concerns were: 1. You have to remember the counter The intention here is to not have to remember any counter. Just as in BIP32 you just scan with some allowance for gaps. roasbeef correctly points out that this may be more or less difficult depending on your node setup and whether you can ballpark how long ago your funding transactions were put down. However since you are using this when you have lost your channel states with no static channel backups I think it still provides a very realistic chance of recovering a significant chunk of your funds. Another point ariard made is that you only have to find one of the channels with a peer to find all of them with a peer if there was some kind of "list channels" message request. 2. It only works for public nodes who can be discovered Correct. For my use of LN so far I am always connecting to public nodes so it would likely work well for me. I think this is true for most unsophisticated users who are most likely to lose their channels with no backups. If each peer allowed you to store some encrypted data with them then finding one honest public peer through the chain could potentially let you find all other peers (even the private ones). 3. We might not want to encourage doing channel recovery by asking the node to force close channel I agree. "PLEASE BLACKMAIL ME" is not a bad characterization of the channel backup interaction Gijs describes above. I believe there is a lot of room for improvement here. First you have to find the channels though! LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
> Loop attacks are not about loops, it only requires that the start and end of a payment are controlled by the same entity Thanks for clearing that up. I was referring to cycles in the payment paths where you get honest parties to forward your HTLC between themselves over and over again as part of a single paryment. I have just realized that it's easy to prevent by just looking for duplicate payment hashes. This will be a problem for randomized PTLCs though. > * There are two griefing attacks: > * Loop attacks, which are deliberate malicious attacks to lock up funds of competitors in order to redirect forwarding towards the attacker. > * Accidental "attacks", which are accidental due to incompetence, where a forwarding node accidentally goes offline and causes payments to be locked up for long periods and making everyone on the network cry when HTLCs time out and things have to be dropped onchain Another one recently pointed out in [1] is to jam a channels towards a competing merchant. Users who are trying to buy from the merchant will give up because of technical failure and instead come to your site where you will sell successfully for a higher price. This seems more plausible to me than completing for fees. Back to the general topic. Perhaps a way of refining the proposal is the following: 1. Drop idea of "stake certificates" in favor of a chaumian e-cash kind of design. 2. The owner (owners?) of leach LN UTXO can go to any node in the network and request a kind of token for their UTXO (i.e. channel id). 3. When making a payment you present a randomized version of the token to each node (it is not linkable to the UTXO) and prove that the UTXO it represents is large enough to support the payment (the token and proof protocol can hopefully be non-interactive so it can fit in the onion). 4. If your HTLC fails your token is deleted (and have to wait some period before requesting a new one). 5. If your payment succeeds your token is renewed on the spot (and maybe forwarded back along the path covertly). Not saying this will be easy (or even totally coherent) but I feel the direction is a bit more plausible. The benefit here is that you avoid the complicated ZKPs about UTXOs and are treading on a more well worn path of anonymous credentials and ecash. [1]: https://github.com/t-bast/lightning-docs/issues/7#issuecomment-736713076 LL On Tue, Dec 1, 2020 at 11:11 PM ZmnSCPxj wrote: > Good morning LL, and list, > > > > That's a very interesting point. If we were to be able to prevent loop > attacks by the sender proving the path is well formed (without revealing > who they are or any of the other hops) would this be an alternative > solution? > > It seems to me that disabling loop attacks might be much easier than > stake certificates. > > Loop attacks are not about loops, it only requires that the start and end > of a payment are controlled by the same entity. > > Multiple nodes on the LN may be owned by the same entity. > Nodes, individually as nodes, are trivially cheap and just need 32 bytes > of entropy from a `/dev/random` near you. > It is the channels themselves, requiring actual funds, high uptime, and > not being a dick to your counterparty, that are fairly expensive. > > Thus, a "loop attack" need not involve a loop per se --- a single entity > can run any number of nodes with small numbers of channels each, and > thereby grief the network. > > Stake certificates make the node itself expensive, so a single entity > running a number of nodes cannot perform such loop attacks, since it would > require entities expensively allocating funds for each node. > > > > > On the other hand, if channels are expensive, then a node with channels is > expensive. > > In > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002890.html > , which contains the "Z consideration" you were alluding to, I note that > the "point-to-point property" is already proven by the ***existing*** > Lightning network without an additional ZK cryptographic proof. > > So let me invert that logic and present an even more extreme position: > > * There are two griefing attacks: > * Loop attacks, which are deliberate malicious attacks to lock up funds > of competitors in order to redirect forwarding towards the attacker. > * Accidental "attacks", which are accidental due to incompetence, where > a forwarding node accidentally goes offline and causes payments to be > locked up for long periods and making everyone on the network cry when > HTLCs time out and things have to be dropped onchain. > * The point-to-point property, which is already proven by the > ***existing*** Lightning network, is already sufficient to prevent loop > attacks, leaving only accidental incompetence-based "attacks". > * Or: the ***existing*** Lightning Network ***already*** proves the > point-to-point property presented by t-bast, and that property is > ***already*** sufficient to prevent the loop attacks. > > So, maybe we should
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
On Mon, Nov 30, 2020 at 7:34 PM Gleb Naumenko wrote: > Hi Lloyd, > > > I agree with Z that this proposal is missing a strong argument as to why > this is a better “proof-of-stake” than channel balances themselves. > > I think Z’s consideration is about the alternative Stake Certificates > proposed by t-bast, where every link in the route proves something to the > next hop. > For the context see this post, specifically “point-to-point property”: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002888.html > Thanks for the correction. > > I think you managed to apply the same argument to our original proposal as > well :) > > > In order to send a jamming HTLC you have to have to lock up funds to do > it (they need outgoing balance for the sender and incoming balance for the > receiver). > > I think the issue here is with loop attacks ( > https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-August/000135.html)? > This restriction with locking funds doesn’t really work… > After getting past their intermediate hop, an attacker can make arbitrary > loops and lock 100 BTC channels even by just having 1 BTC locked in the > initial hop. > > Stake Certificates allow for a node in the middle of the route to > distinguish where the payment is coming from (in a privacy-preserving > manner of course), to distinguish heavy channel users from normal. > They also allow to force an attacker to distribute jamming in time and > across many channels. > That's a very interesting point. If we were to be able to prevent loop attacks by the sender proving the path is well formed (without revealing who they are or any of the other hops) would this be an alternative solution? It seems to me that disabling loop attacks might be much easier than stake certificates. > Perhaps, alternative restrictions may take place by restricting based on > from which immediate channel/node they are coming (one-hop). But that > sounds like a mess, as a payment sender doesn’t have any control, and > gossiping that would probably be a privacy leak, also it still allows free > jamming I think (just a bit different). > The big deal here is to distinguish the flows, to better control them. > We can discuss this separately. > > It’s true that any token might achieve the same goal here, but how to make > it Sybil-resistant and prevent generating new tokens? Stake Certificates, I > don’t know what else we can commit to. > > > If we are talking about non-economic adversaries who simply wish to > destroy LN then that’s another game altogether. > > I was thinking about this scenario all the way, but maybe I should think > about the other one as well. > > But if we are talking about large holders of Bitcoin that just want to destory LN this seems like a very weak mitigation since they will be able to produce stake certificates galore and lock up channels anyway. I don't see much of a way around this other than reputation systems. LL > > – gleb > On Nov 30, 2020, 6:39 AM +0200, Lloyd Fournier , > wrote: > > Hi Gleb et al, > > I really appreciate the out-of-the-box thinking of this proposal. > I will put to the side the very difficult task of creating a cryptosystem > that efficiently achieves what's necessary for this to work because that > seems not to be the main concern. > > I agree with Z that this proposal is missing a strong argument as to why > this is a better "proof-of-stake" than channel balances themselves. > In order to send a jamming HTLC you have to have to lock up funds to do it > (they need outgoing balance for the sender and incoming balance for the > receiver). > Why would stake certificates be more powerful than this? I get that you > decrement the UTXO's credit even if they fail. This increases the cost of > sending spam (but it also increases the cost of sending normal payments > since you now may be honest but have all your UTXOs run out of credit.) > Does this increased cost (it was not zero before) actually prevent the > attack without inhibiting normal usage? > > In general there seems to be an open question about whether these channel > jamming attacks are actually economic. > If I want to get more payments routed through me would it really be > optimal to do channel jamming? > Suppose that the nodes react to the jamming by adding extra capacity by > splicing out from somewhere else. Then I have jammed up my own coins and > got nothing for it. > What if instead of attacking I allocated the coins instead to creating > more valuable channels. Couldn't this be more profitable? > I just posed this question in [1]. > > If we are talking about non-economic adversaries who simply wish to > destroy LN then that's another
Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates
Hi Gleb et al, I really appreciate the out-of-the-box thinking of this proposal. I will put to the side the very difficult task of creating a cryptosystem that efficiently achieves what's necessary for this to work because that seems not to be the main concern. I agree with Z that this proposal is missing a strong argument as to why this is a better "proof-of-stake" than channel balances themselves. In order to send a jamming HTLC you have to have to lock up funds to do it (they need outgoing balance for the sender and incoming balance for the receiver). Why would stake certificates be more powerful than this? I get that you decrement the UTXO's credit even if they fail. This increases the cost of sending spam (but it also increases the cost of sending normal payments since you now may be honest but have all your UTXOs run out of credit.) Does this increased cost (it was not zero before) actually prevent the attack without inhibiting normal usage? In general there seems to be an open question about whether these channel jamming attacks are actually economic. If I want to get more payments routed through me would it really be optimal to do channel jamming? Suppose that the nodes react to the jamming by adding extra capacity by splicing out from somewhere else. Then I have jammed up my own coins and got nothing for it. What if instead of attacking I allocated the coins instead to creating more valuable channels. Couldn't this be more profitable? I just posed this question in [1]. If we are talking about non-economic adversaries who simply wish to destroy LN then that's another game altogether. For example if the CCP with its 1% of all Bitcoin it seized from the plustoken scam were to try and attack lightning they would likely succeed even if we had this system in place simply because they have a lot of "stake". As David points out I don't think you can make a distinction between real LN outputs and fake ones. It seems unavoidable that any coins you own could be used to produce a certificate to give you spam bandwidth (especially if you actually manage to guarantee privacy through ZKPs). [1] https://github.com/t-bast/lightning-docs/issues/7 Cheers, LL On Sun, Nov 29, 2020 at 5:25 AM David A. Harding wrote: > On Thu, Nov 26, 2020 at 11:40:46PM +0200, Gleb Naumenko wrote: > > > > Hello list, > > Gleb and Antoine, > > This is an interesting idea! Thank you for working on it. > > I had difficulty with one part of the proposal: > > > Should we allow holding *any* Bitcoins (not just LN channels) for > Stake Certificates? > > > > [...] we believe that allowing any UTXO would give an attacker more > > opportunities to use their cold funds for this attack, or even have a > > secondary market where holders sell their proofs (they have nothing to > > loose). > > Can't a malicious user get around this restriction by opening channels > with themself? (Also, aren't current channel open outputs just P2WSH > 2-of-2 multisigs, and in the future won't they be generic P2TR outputs? > How would a stake certificate prove that the UTXO was generated for LN > rather than just belonging to a user with a 2-of-2 multisig wallet or > any key-path-spendable taproot wallet?) > > According to some random website, the current total channel balance of > the public LN is about 1,000 BTC. Although I'm sure this will grow with > time, it seems to me that an attacker who can rent access to stake > certificates for a one-week attack at, say, a 5% annual interest rate > would only need to pay 1 BTC to acquire stake certificates equal to all > honest users at present. That cost doesn't seem high enough to me to > effectively prevent attacks. Am I missing something? > > Thanks, > > -Dave > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] two-round MuSig less dangerous than it seems
After posting I was tapped on the shoulder and informed that it is very likely that we will have an enhanced secure parallel composition 2 round MuSig in the future. This is really good news. This makes much of the post moot but I think the conclusion about being able to do "pure scriptless" lightning with the same number of rounds as today before forwarding the payment is correct. Cheers, LL On Fri, Oct 9, 2020 at 3:31 PM Lloyd Fournier wrote: > Hi list, > > tl;dr: I think can use two round MuSig safely in the context of lightning. > > As a recap, Zeeman did a good evaluation of "purely scriptless" lightning > channels after taproot/schnorr.[1] > Z concluded that even in the most optimized case the 3 round MuSig > protocol leads to an extra round of communication before you can forward a > payment. > I think this is correct but perhaps you could just use 2 round MuSig > (without MuSig-DN magic[4]). > > === 2 round MuSig === > > (from memory) The original MuSig paper suggested the following signing > algorithm once two keys A and B have already been established for Alice and > Bob > > Alice Bob > pick ra randomly > Ra = ra * G > - Ra > > pick rb randomly > Rb = rb * G > let c = H(Ra + Rb || A + B > || m) > sb = rb + cb > <--Rb, sb > s = sb + ra + ca > R = Ra + Rb > X = A + B > verify(X, (R, s), m)? > output: (R,s) > > This was insecure under *parallel composition* because the proof cannot > work (from my memory because having open signing sessions makes the > rewinding argument in the proof incoherent) and led to actual attacks which > have recently improved in efficiency.[3] > > === My insight === > > 2 round MuSig *is secure* under sequential composition and in a lightning > channel we are essentially arranging sequential state updates so perhaps > we're ok here? > > It should be easy to require that you can't open another signing session > until we've finished the current session. > Also if Alice has sent Ra there is no reason that Bob can't send multiple > (Rb, sb) pairs for different messages for the same Ra while he wants for > Alice to respond. > Alice doesn't have to finish the signature yet she can just store the most > recent one and finish if/when she needs to. > This preserves the current update communication structure of lightning > without breaking the security requirements of 2 round MuSig. > > === How could PTLCs work === > > Updating states is more than just signing the commitment transaction. > Let's assume we do PTLCs with both a PTLC-success and PTLC-timeout > pre-signed transaction (I don't see how else to do it) on *both* sides of > the channel. > This means you have to pre-share the following: > > - A fresh pair of nonces for every existing PTLC in the state plus one > extra (must be done every update) > - A key for every existing PTLC in the state plus one extra (can be fixed > at the start of the channel or updated as you go along). > > After pre-sharing this data Bob starts the communication with: > > (the postfix *-alice and *-bob means that they are in the tree of > transactions on alice or bob's side, not necessarily that alice or bob is > the one broadcasting it). > > Bob sends: > - new PTLC details > - (Rb,sb)-success(s)-bob (uses pre-shared nonce) > - (Rb,sb)-success(s)-alice (uses pre-shared nonce) > - (Rb)-commit-bob > - (Rb)-timeout(s)-bob > - (Rb)-timeout(s)-alice > > Alice sends back: > - (Ra,sa)-timeout(s)-bob > - (Ra,sa)-timeout(s)-alice > - (Ra,sa)-commit-bob > - (Ra)-commit-alice > Bob sends: > - (Rb,sb)-commit-alice > - revocation key for last commitment > > **Note that Alice still hasn't revoked her last state but at this point > she can safely forward the PTLC since Bob has revoked his last state.** > > Other notes: > - This is and looks convoluted but it is simpler if you use witness > asymmetry[2] because it removes duplicating the party's transactions across > both sides. > - Although you are doing parallel signing on the PTLC output key (you are > signing both a timeout and success) a different party is receiving the > signature and the nonces are communicated in reverse so it actually > sidesteps the flaw of two round MuSig (where the adversary is always > declaring his nonce second and second). > - For protocols such as DLCs you will have to do proper three round MuSig >
[Lightning-dev] two-round MuSig less dangerous than it seems
Hi list, tl;dr: I think can use two round MuSig safely in the context of lightning. As a recap, Zeeman did a good evaluation of "purely scriptless" lightning channels after taproot/schnorr.[1] Z concluded that even in the most optimized case the 3 round MuSig protocol leads to an extra round of communication before you can forward a payment. I think this is correct but perhaps you could just use 2 round MuSig (without MuSig-DN magic[4]). === 2 round MuSig === (from memory) The original MuSig paper suggested the following signing algorithm once two keys A and B have already been established for Alice and Bob Alice Bob pick ra randomly Ra = ra * G - Ra > pick rb randomly Rb = rb * G let c = H(Ra + Rb || A + B || m) sb = rb + cb <--Rb, sb s = sb + ra + ca R = Ra + Rb X = A + B verify(X, (R, s), m)? output: (R,s) This was insecure under *parallel composition* because the proof cannot work (from my memory because having open signing sessions makes the rewinding argument in the proof incoherent) and led to actual attacks which have recently improved in efficiency.[3] === My insight === 2 round MuSig *is secure* under sequential composition and in a lightning channel we are essentially arranging sequential state updates so perhaps we're ok here? It should be easy to require that you can't open another signing session until we've finished the current session. Also if Alice has sent Ra there is no reason that Bob can't send multiple (Rb, sb) pairs for different messages for the same Ra while he wants for Alice to respond. Alice doesn't have to finish the signature yet she can just store the most recent one and finish if/when she needs to. This preserves the current update communication structure of lightning without breaking the security requirements of 2 round MuSig. === How could PTLCs work === Updating states is more than just signing the commitment transaction. Let's assume we do PTLCs with both a PTLC-success and PTLC-timeout pre-signed transaction (I don't see how else to do it) on *both* sides of the channel. This means you have to pre-share the following: - A fresh pair of nonces for every existing PTLC in the state plus one extra (must be done every update) - A key for every existing PTLC in the state plus one extra (can be fixed at the start of the channel or updated as you go along). After pre-sharing this data Bob starts the communication with: (the postfix *-alice and *-bob means that they are in the tree of transactions on alice or bob's side, not necessarily that alice or bob is the one broadcasting it). Bob sends: - new PTLC details - (Rb,sb)-success(s)-bob (uses pre-shared nonce) - (Rb,sb)-success(s)-alice (uses pre-shared nonce) - (Rb)-commit-bob - (Rb)-timeout(s)-bob - (Rb)-timeout(s)-alice Alice sends back: - (Ra,sa)-timeout(s)-bob - (Ra,sa)-timeout(s)-alice - (Ra,sa)-commit-bob - (Ra)-commit-alice Bob sends: - (Rb,sb)-commit-alice - revocation key for last commitment **Note that Alice still hasn't revoked her last state but at this point she can safely forward the PTLC since Bob has revoked his last state.** Other notes: - This is and looks convoluted but it is simpler if you use witness asymmetry[2] because it removes duplicating the party's transactions across both sides. - Although you are doing parallel signing on the PTLC output key (you are signing both a timeout and success) a different party is receiving the signature and the nonces are communicated in reverse so it actually sidesteps the flaw of two round MuSig (where the adversary is always declaring his nonce second and second). - For protocols such as DLCs you will have to do proper three round MuSig but you are not forwarding payments so it's not as time sensitive. - I am completely avoiding revocation mechanisms here but from my own ideas and what I've seen from others this is compatible. === Claim Summary === Given the above, I claim there is a protocol using two-round MuSig for fully scriptless lightning that incurs no extra rounds of communication to get to the irrevocably committed state. It does incur extra storage for each PTLC in the present commitment transaction. It includes an extra round to "fully" update the state between two parties (but this does not delay payment forwarding). I don't claim that this is the optimal path forward but just wanted to make this observation to see what others thought. LL [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html [2] https://github.com/LLFourn/witness-asymmetric-channel [3] https://eprint.iacr.org/2020/945.pdf (thanks @n1cklr) [4] https://eprint.iacr.org/2020/1057.pdf
Re: [Lightning-dev] Witness asymmetric payment channels
For those interested I've recently integrated the above refinements and tried to coherently package the whole idea together here: https://github.com/LLFourn/witness-asymmetric-channel The main difference is that the protocol now uses what I am calling "revocable signatures" as the main primitive. This allows for O(1) storage complexity in both key aggregated and "multisig" constructions. LL On Thu, Sep 10, 2020 at 1:56 PM Lloyd Fournier wrote: > > >> >> >> Fortunately, I am wrong. At least in the case of non-aggregated 2-of-2 you >> can deterministically produce the encrypted signature by yourself for any >> commitment transaction as long as you use a deterministic nonce. >> But I think if using MuSig you would need to store each two party generated >> encrypted signature. >> Seeing as the likely way forward would be to use MuSig on an output which >> has a taproot which hides a discrete 2-of-2 this may not be a problem. > > > Upon further reflection I was missing something obvious when I came to this > conclusion. You can't produce the adaptor signature for a commitment > transaction deterministically without the encryption key (the other party's > publication point). > As long as we have to store the other party's per-commitment publication > point we still need O(n) storage where n is the number of commitment > transactions. Sorry for the confusion. > > Fortunately I had a bit of a breakthrough which allows us to eliminate > publication points altogether and enables O(1) storage when 2-of-2 > multi-signatures are instantiated with or without key aggregation (i.e. MuSig > or OP_CHECKMULTISIG). > > ### Eliminating Publication Points In favor of "revocable signatures" (for > OP_CHECKMULTISIG) > > I propose replacing the publication point with a static key that remains the > same with each commitment transaction. > The encryption key for each commitment transaction adaptor signature is (Ra + > A) for Alice and (Rb + B) for Bob. > Therefore, Alice broadcasting her commitment transaction would reveal the > discrete log of Ra + A (and Bob Rb + B). > Note that if Alice has not revealed her recvocation key (Ra) for this > commitment transaction she is not in trouble since her static key A is > blinded by Ra. If she has then Bob will learn her static secret key for A. > The intuition here is that the revocation key acts as a blinding factor for > the static key in the same way a nonce blinds your secret key in a schnorr > signature (more on that later). > If you haven't revealed your revocation key then you are free to use that > signature. If you have revealed the revocation key then you have in effect > "revoked" the signature. > > Now we need to make sure that if a party learns the secret key of the other > they can efficiently punish them so make the following changes to my original > proposal: > > Balance output for Alice is 2-of-2(A , Rb + B) > Balance output for Bob is 2-of-2(Ra + A, B) > > The implication of the above structure is that if you broadcast a commitment > transaction the other party can take their balance immediately. > If you broadcasted a revoked commitment transaction then they can take their > output and yours immediately. > > PTLC outputs and all subsequent transaction outputs then simplify to > 2-of-2(A,B) on every output. Yay! > Consider a PTLC paying to Alice. The PTLC-success output can be 2-of-2(A,B). > If Alice broadcasted it and it has been revoked then Bob knows A and B so he > can punish her. > The converse is true for the PTLC-timeout. > This elegant uniformity extends to other off-chain protocols hosted in these > channels e.g. DLCs > > Since A and B are static per channel and the secret keys for Ra and Rb can be > incrementally derived from subsequent values (as in the present lightning > spec) we have O(1) communication. > In practice each 2-of-2(A,B) should be randomized so they don't all look the > same. > > ### Revoking key aggregated schnorr signatures (for MuSig) > > Even with the above improvement there is still O(n) storage if using key > aggregation (MuSig) on the funding transaction output. > Key aggregation may be desirable here since you may want to not use a taproot > spend to broadcast a commitment transaction. > Since the two party adaptor signature scheme needs randomness from both > parties, you would have to store the other party's nonce and retrieve it to > deterministically produce the adaptor signature so you can extract Ra + A (if > Alice broadcasts) from the witness of the commitment transaction. > > Fortunately, there is a natural way to revoke a key aggregated signature you > helped p
Re: [Lightning-dev] Witness asymmetric payment channels
> > > Fortunately, I am wrong. At least in the case of non-aggregated 2-of-2 you > can deterministically produce the encrypted signature by yourself for any > commitment transaction as long as you use a deterministic nonce. > But I think if using MuSig you would need to store each two party > generated encrypted signature. > Seeing as the likely way forward would be to use MuSig on an output which > has a taproot which hides a discrete 2-of-2 this may not be a problem. > Upon further reflection I was missing something obvious when I came to this conclusion. You can't produce the adaptor signature for a commitment transaction deterministically without the encryption key (the other party's publication point). As long as we have to store the other party's per-commitment publication point we still need O(n) storage where n is the number of commitment transactions. Sorry for the confusion. Fortunately I had a bit of a breakthrough which allows us to eliminate publication points altogether and enables O(1) storage when 2-of-2 multi-signatures are instantiated with or without key aggregation (i.e. MuSig or OP_CHECKMULTISIG). ### Eliminating Publication Points In favor of "revocable signatures" (for OP_CHECKMULTISIG) I propose replacing the publication point with a static key that remains the same with each commitment transaction. The encryption key for each commitment transaction adaptor signature is (Ra + A) for Alice and (Rb + B) for Bob. Therefore, Alice broadcasting her commitment transaction would reveal the discrete log of Ra + A (and Bob Rb + B). Note that if Alice has not revealed her recvocation key (Ra) for this commitment transaction she is not in trouble since her static key A is blinded by Ra. If she has then Bob will learn her static secret key for A. The intuition here is that the revocation key acts as a blinding factor for the static key in the same way a nonce blinds your secret key in a schnorr signature (more on that later). If you haven't revealed your revocation key then you are free to use that signature. If you have revealed the revocation key then you have in effect "revoked" the signature. Now we need to make sure that if a party learns the secret key of the other they can efficiently punish them so make the following changes to my original proposal: Balance output for Alice is 2-of-2(A , Rb + B) Balance output for Bob is 2-of-2(Ra + A, B) The implication of the above structure is that if you broadcast a commitment transaction the other party can take their balance immediately. If you broadcasted a revoked commitment transaction then they can take their output and yours immediately. PTLC outputs and all subsequent transaction outputs then simplify to 2-of-2(A,B) on every output. Yay! Consider a PTLC paying to Alice. The PTLC-success output can be 2-of-2(A,B). If Alice broadcasted it and it has been revoked then Bob knows A and B so he can punish her. The converse is true for the PTLC-timeout. This elegant uniformity extends to other off-chain protocols hosted in these channels e.g. DLCs Since A and B are static per channel and the secret keys for Ra and Rb can be incrementally derived from subsequent values (as in the present lightning spec) we have O(1) communication. In practice each 2-of-2(A,B) should be randomized so they don't all look the same. ### Revoking key aggregated schnorr signatures (for MuSig) Even with the above improvement there is still O(n) storage if using key aggregation (MuSig) on the funding transaction output. Key aggregation may be desirable here since you may want to not use a taproot spend to broadcast a commitment transaction. Since the two party adaptor signature scheme needs randomness from both parties, you would have to store the other party's nonce and retrieve it to deterministically produce the adaptor signature so you can extract Ra + A (if Alice broadcasts) from the witness of the commitment transaction. Fortunately, there is a natural way to revoke a key aggregated signature you helped produce without using adaptor signatures at all: just reveal the nonce you used for it to the other party. This prevents you from broadcasting it since the other party can now extract your secret key from it! Explicitly, two party signature generate two Schnorr signatures for the key A + B in the form: sa = ra + rb' + H(Ra + Rb' || A + B || m)(a + b) sb = ra' + rb + H(Ra' + Rb || A + B || m)(a + b) - (ra,rb) are the revocation secret keys, - (ra', rb') are typical deterministically produced[1] nonces with Ra' = ra' * G etc. - (a,b) are the static secret keys Only Alice knows sa and only Bob knows sb but they are both signatures on the same commitment transaction. This is the witness asymmetry in the protocol. When revoking the commitment transaction associated with sa Alice reveals ra to Bob and vice versa. If Alice uses sa after that, Bob can deterministically produce rb' and ra (because each revocation key can be derived from the last) and
Re: [Lightning-dev] Witness asymmetric payment channels
> Unfortunately, while thinking about the above statement I realised > there is worse storage complexity. > In order to punish a revoked commitment transaction efficiently you > need to extract the publication secret. > But in order to do that you need to keep around the encrypted > signature (a.k.a adaptor signature) **for that particular commitment > transaction**. > This means you have O(n) storage, unlike the present spec which has > O(1) by deriving the previously revealed revocation secret from the > present one (this can't be done with adaptor signatures). > This doesn't seem to be addressed in the original work. > > Yikes! This might be a fatal flaw to this proposal unless it can be addressed. > Fortunately, I am wrong. At least in the case of non-aggregated 2-of-2 you can deterministically produce the encrypted signature by yourself for any commitment transaction as long as you use a deterministic nonce. But I think if using MuSig you would need to store each two party generated encrypted signature. Seeing as the likely way forward would be to use MuSig on an output which has a taproot which hides a discrete 2-of-2 this may not be a problem. LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Witness asymmetric payment channels
Hi Z, Thanks as usual for your thoughtful comments I agree with you that there is no improvement in complexity in the formal sense. I do believe it is an improvement in conceptual complexity. At least, I am able to keep all the moving parts in my head at the same time whereas I struggle sometimes with the current BOLT spec. Unfortunately, while thinking about the above statement I realised there is worse storage complexity. In order to punish a revoked commitment transaction efficiently you need to extract the publication secret. But in order to do that you need to keep around the encrypted signature (a.k.a adaptor signature) **for that particular commitment transaction**. This means you have O(n) storage, unlike the present spec which has O(1) by deriving the previously revealed revocation secret from the present one (this can't be done with adaptor signatures). This doesn't seem to be addressed in the original work. Yikes! This might be a fatal flaw to this proposal unless it can be addressed. > When we have "the same" transaction on both sides, however, we need to > synchronize between the two sides. Can you elaborate on this? I think you can carry on using the same BOLT 2 update protocol within this channel system. The txids being the same for both parties sometimes seems to be incidental. It may be advantageous to use an alternative protocol that forces a synchronization of the commitment transactions but I don't *think* it is a requirement. I guess you would need to sync in Decker-Russell-Osuntokun because it needs an objective ordering of commitment transactions. That is seemingly not the case here though LL On Tue, Aug 25, 2020 at 10:45 PM ZmnSCPxj wrote: > > Good morning Lloyd, > > I think this is excellent work overall. > > With that said... > > > > - It is more elegant as there are half the number of possible > > transactions. I > > expect this will follow through to reduced implementation complexity > > and maybe > > make it easier to explain as well. > > I am not sure the complexity will be reduced all that much. > > Currently: > > * We provide a partial signature for the other side for their commitment > transaction. > * We keep our own commitment transaction and the partial signature we receive > from the other side. > > The node never has to retain the commitment transaction of the other side. > > With this setup: > > * We provide a partial signature for the other side for their asymmetric > signature. > * We keep a copy of the shared commitment transaction and the partial > signature we received for our own asymmetric signature from the other side. > > So storage complexity is still the same. > > An issue is that with asymmetric transactions, it is fairly easy to use TCP > to communicate changes to the commitment txes. > We send a bunch of HTLC changes we want to apply to the other side commitment > tx, then send a signature for those changes. > Since what we send applies to *their* transaction only, we do not have to > consider what they sent to us, we just have to consider what we sent to them. > Conversely, when keeping track of what our commitment transaction is, we only > have to consider what they sent to us, in order, and then when we receive a > signature we know it is for the commitment transaction with all the updates > the other side sent. > > (This arguably just moves the complexity higher, however: we cannot forward > an HTLC until both us and the other side have revoked the transactions that > do not contain it i.e. the "irrevocably committed" state.) > > When we have "the same" transaction on both sides, however, we need to > synchronize between the two sides. > Suppose both participants want to forward HTLCs to one another. > Without any kind of locking, both participants could send network packets > containing the HTLCs they want to add to each other, and it becomes ambiguous > whether the signature they *should* send contains one, or both. > > Basically, TCP only assures a global order for *one* direction of the > communications, once we have two network nodes talking simultaneously, the > order in which one writes and then reads is a lot more ambiguous. > > This issue also exists for Decker-Russell-Osuntokun, incidentally. > > One way to solve this would be to have a "token" that is passed alternately > between the participants. > At initial connection, they run a secure multiparty coinflip that indicates > which one gets the token. > Then, the one that holds the token can add more HTLCs, then tell the other > "okay, now we sign" and they exchange signatures for a new version that > involves only the HTLCs from the token-holder. > Then the token-holder passes the token to the other side. > > If the current token-holder does not have any HTLCs it wants to send, it can > wait for some time (in case it receives a request to forward), then if there > are still no HTLCs, it can pass the token to the other side by sending a >
[Lightning-dev] Witness asymmetric payment channels
# Abstract This is a proposal for a new channel symmetric channel construction that uses the key idea from a recent paper called "Generalized Bitcoin-Compatible Channels"[1] and tries to practically apply it to lightning. If you prefer, you can read the rendered markdown version here: https://github.com/LLFourn/witness-asymmetric-channel The purpose of this post is to get feedback to see if it's worth doing a PoC implementation. # Background As presently specified the two parties in a lightning channel are assigned different commitment transactions. This _transaction asymmetry_ is logically necessary for the protocol to identify which party broadcasted a commitment transaction and potentially punish them if the other party provides proof it has been revoked (i.e. knows the revocation key). Wouldn't it be nice if we could identify the broadcasting party without assigning them different transactions? Riard first considered this problem in [8] while trying to add a punishment mechanism to eltoo[9] style channel updates. They proposed that you could identify the broadcasting party using _witness asymmetry_ i.e. both parties broadcast the same transaction but have different witnesses. Unfortunately, the solution proposed is rather convoluted. More recently in [1], Aumayr et al. introduced a much more elegant witness asymmetric solution using adaptor signatures. Instead of being assigned different transactions, the parties are assigned different adaptor signatures as witnesses for the _same_ transaction. The adaptor signatures force the party broadcasting a commitment transaction to reveal a "publishing secret" to the other party. The honest party can then use this publishing secret along with knowledge of the usual revocation secret to punish the malicious party for broadcasting an old commitment transaction. Aumayr et al. combine this idea with a "punish-then-split" mechanism similar to the original eltoo proposal. Unfortunately, it therefore inherits the same issue with staggering time-locks. BOLT 3 [4] describes why it avoids this problem as a design choice: > The reason for the separate transaction stage for HTLC outputs is so that > HTLCs can timeout or be fulfilled even though they are within the > to_self_delay delay. Otherwise, the required minimum timeout on HTLCs is > lengthened by this delay, causing longer timeouts for HTLCs traversing the > network. There is further background discussion to this choice in [2] and Towns proposes a solution for eltoo in [3]. In short, the problem is that it creates a risk for the party that needs to fulfill an HTLC with the secret in time. The only known way of accounting for this risk is to increase the difference between the time-locks on each hop. There could be situations where this trade off makes sense but it seems undesirable for a general purpose payment channel network. # Proposal I propose a channel protocol which steals the main idea from Aumayr et al. while retaining the time-lock precedence of BOLT 3 transactions. That is, absolute time-locks are settled before relative time-locks to avoid having to account for relative time-locks when calculating absolute time-locks. The guiding principle is to keep commitment transactions symmetric but to use the asymmetric knowledge of the parties to simulate the way lightning works right now. The main benefits of this seem to be: - It is more elegant as there are half the number of possible transactions. I expect this will follow through to reduced implementation complexity and maybe make it easier to explain as well. - Every output can just be a 2-of-2 multi-sig (which could be a single key with MuSig or OP_CHECKMULTISIG with ECDSA etc). This makes the transactions a little smaller even when using 2-of-2 with ECDSA on balance, The space saving comes from avoiding explicit revocation keys in the commitment transaction outputs and using PTLCs rather than HTLCs. - The design works today and easily transitions into a post-taproot world although there is still a bit to explore there [5]. ## Notation I describe the protocol with respect to two parties Alice and Bob. 2-of-2(Xa,Xb) refers to a multi-signature output that supports adaptor signatures and requires the owners of Xa (Alice) and Xb (Bob) to authorize it (e.g. `OP_CHECKMULTISIG` with ECDSA [6], or MuSig with Schnorr etc [7]). ## The Fund transaction The structure of channel funding does not change from the current BOLT spec. The Fund transaction spends from the funding party's (or funding _parties_) outputs to an output of 2-of-2(Fa,Fb) where Fa and Fb are public keys owned by Alice and Bob respectively. These keys are generated and exchanged once per channel. ## Commitment transactions All commitment transactions spend from the 2-of-2 on the Fund transaction and each represents a "state" of the channel. A commitment transaction has two balance outputs and zero or more PTLC outputs. Before creating a commitment transaction the
Re: [Lightning-dev] [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev < bitcoin-...@lists.linuxfoundation.org> wrote: > On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: > > Trust-minimization of Bitcoin security model has always relied first and > > above on running a full-node. This current paradigm may be shifted by LN > > where fast, affordable, confidential, censorship-resistant payment > services > > may attract a lot of adoption without users running a full-node. > > No, it cannot be shifted. This would compromise Bitcoin itself, which for > security depends on the assumption that a supermajority of the economy is > verifying their incoming transactions using their own full node. > Hi Luke, I have heard this claim made several times but have never understood the argument behind it. The question I always have is: If I get scammed by not verifying my incoming transactions properly how can this affect anyone else? It's very unintuative. I've been scammed several times in my life in fiat currency transactions but as far as I could tell it never negatively affected the currency overall! The links you point and from what I've seen you say before refer to "miner control" as the culprit. My only thought is that this is because a light client could follow a dishonest majority of hash power chain. But this just brings me back to the question. If, instead of BTC, I get a payment in some miner scamcoin on their dishonest fork (but I think it's BTC because I'm running a light client) that still seems to only to damage me. Where does the side effect onto others on the network come from? Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] DLC channels and integration in the Lightning Network
Hi Thibaut, Thanks for carrying out this research. I have not finished reading the paper but have a question about what you call the "straw man" proposal early on: "At the end of this protocol, both Alice and Bob have the set of signed transactions for the second DLC, and the transactions for the previous one are revoked. However, there is an issue at step 6. After sending her revocation secret to Bob, Alice cannot anymore enforce the result from the first contract. However, as Bob has not yet revealed his secret, he still has the ability to do so, in addition to having the ability to enforce the second one. If Bob is dishonest, he could thus choose not to reveal his revocation key, and wait until just before the maturity of the second contract to execute the one that is most favorable to him (he could also potentially use the previous refund transaction if the time lock expired)." Since Alice has the signed transactions for the new state, if Bob refuses to revoke the old state why can't she just post the new state on chain immediately? This limits Bob's "option" and I thought is the optimal solution whenever this problem occurs. Cheers, LL On Tue, Apr 28, 2020 at 5:43 PM LE GUILLY THIBAUT < thib...@cryptogarage.co.jp> wrote: > Hi list, > > > First let me introduce myself as this is my first time posting. My name is > Thibaut and I’ve been working at Crypto Garage for some time, mainly > focusing on DLC. With my colleagues Ichiro Kuwahara and Takatoshi Nakagawa > , we have been researching on how to construct DLC channels, and how such > channels could be integrated in the Lightning network. As there are > currently quite some discussions around DLC, we thought that it was a > good time to share the result of this research. You can find the paper on > github ( > https://github.com/p2pderivatives/offchain-dlc-paper/blob/master/offchaindlc.pdf > ) , and I’ll try to summarize it here (if you’re not familiar with DLC I > recommend going for the paper as I’ll assume some knowledge in the > following, also it has nice figures and everything so nice to skim > through as a support for the description here). We’d be happy to hear > feedback from the community on the feasibility of the approach we propose, > both > theoretically and practically. > > > Motivation > > == > > > At the moment, once a DLC expires, both parties need to close and open a > new one in order to re-enter in a contract. This is wasteful as it requires > at the minimum two extra on-chain transactions (one for mutual closing, and > a new funding tx). So one would like to have a way to have actual DLC > channels, where two parties can keep establishing contracts between > themselves as long as the balance in the channel allows it. Creating such > channels is less trivial than it may seem at first glance, as one tricky > part is to ensure that no party can ever have the possibility of both > enforcing the outcome of a previous contract or that of the latest contract > (so they could pick the most favorable to them). I’ll refer to this issue > as the “free option” problem hereafter, but it shouldn’t be confused with > the free option problem of atomic swaps. > > > In addition, if we are to implement such DLC channels, we would like to > avoid having to re-do all the work and instead take advantage of the > existing Lightning Network infrastructure. Note that the integration > solution we propose is generic and would work to integrate other types of > layer 2 protocol in LN. It also permits the existence of multiple > concurrent channels, so two parties could have multiple DLC at the same > time using a single fund transaction. > > > Note that one of our motivation was also to come up with something that > doesn’t require any changes to the Bitcoin transaction structure or > SIGHASH or any new cryptographic operation, as it is rather trivial to > implement in an eltoo context for example. > > > Related Work > > == > > > Juraj Bednár and René Pickhardt previously proposed Lightning DLC channels > [1]. Their construction works by adding an output to a LN commitment > transaction, from which the regular set of DLC transactions can be > attached. Our approach differs in two ways: > >1. Our DLC channel construction can be made standalone, meaning they >could be deployed outside (or alongside) of the LN >2. The integration with LN that we propose allow for more separation >of concerns between the channels, as they can be updated separately >without influencing each others (their construction requires >re-building all transactions for any update, we only require this for >opening/closing and re-balancing). > > > Bednár and Pickhardt approach is similar to the one briefly described by > Ben Carman of Suredbit in the first section of [2]. He then proposes > routed DLC that require PTLC and barrier escrow. While our proposal only > works for direct channels (so
Re: [Lightning-dev] An update on PTLCs
Hi Laolu, >From my PoV, new technologies aren't what has held back DLC deployment to > this date since the paper was originally released. Tadge has had working > code than can be deployed today for some time now, and other parties like > DG-Lab have created full-fledge demos with the system working end to end. > Instead, the real impediment has been the bootstrapping of the oracles > which the scheme critically depends upon. > Oracles certainly require a huge bootstrapping effort but I think that some of the limitations of the original also hurt the progress of DLCs. The original protocol requires three on-chain transactions, asymmetric state and punishment transactions (i.e. you have to run a node to watch the chain). The original DLC is also easy to get wrong: https://github.com/mit-dci/dlcspec/issues/5. The PTLC based DLC on the other hand is rather straightforward with only two transactions, symmetric state and no penalty transactions. Even more importantly, it has no liveness requirement after the funding transaction is down (assuming there are no refund transactions) -- you can wait as long as you want before claims funds. For me, this makes the whole idea far more attractive both as a user and developer. Self plugs: I wrote a short paper on how to optimise the DLCs so they could get more adoption: https://github.com/LLFourn/two-round-dlc/blob/master/main.pdf. I am also working on a framework for oracle deployment which will be ready soon™. LL > > On Thu, Apr 23, 2020 at 7:52 AM Nadav Kohen wrote: > >> Hi Laolu, >> >> Thanks for the response :) >> >> I agree that some more framing probably would have been good to have in >> my update. >> >> First, I want to clarify that my intention is not to implement a >> PTLC-based lightning network on top of ECDSA adaptor signatures, as I do >> believe that using Schnorr will be superior, but rather I wish to get some >> PoC sandbox with which to start implementing and testing out the long list >> of currently theoretical proposals surrounding PTLCs, most of which are >> implementation agnostic (to a degree anyway). I think it would be super >> beneficial to have more fleshed out with respect to what some challenges of >> a Payment Point LN are going to be than we understand now, before Schnorr >> is implemented and it is time to commit to some PTLC scheme for real. >> >> Second, I agree that I've probably understated somewhat the changes that >> will be needed in most implementations as I was mostly thinking about what >> would need to change in the BOLTs, which does actually seem relatively >> minimal (although as you mention, these minimal changes to the BOLTs do >> trigger large changes in many implementations). Also, good point on how >> BOLT 11 (invoicing) will have to be altered as well, must've slipped my >> mind. >> >> Best, >> Nadav >> >> On Wed, Apr 22, 2020 at 8:17 PM Olaoluwa Osuntokun >> wrote: >> >>> Hi Nadav, >>> >>> Thanks for the updates! Super cool to see this concept continue to evolve >>> and integrate new technologies as they pop up. >>> >>> > I believe this would only require a few changes to existing nodes: >>> >>> Rather than a "few changes", this would to date be the largest >>> network-level >>> update undertaken to the Lightning Network thus far. In the past, we >>> rolled >>> out the new onion blob format (which enables changes like this), but >>> none of >>> the intermediate nodes actually need to modify their behavior. New >>> payment >>> types like MPP+AMP only needed the _end points_ to update making this an >>> end-to-end update that has been rolled out so far in a de-synchronized >>> manner. >>> >>> Re-phrasing deploying this requires changes to: the core channel state >>> machine (the protocol we use to make commitment updates), HTLC scripts, >>> on-chain HTLC handling and resolution, path finding algorithms (to only >>> see >>> out the new PTLC-enabled nodes), invoice changes and onion blob >>> processing. >>> I'd caution against underestimating how long all of this will take in >>> practice, and the degree of synchronization required to pull it all off >>> properly. >>> >>> For a few years now the question we've all been pondering is: do we wait >>> for >>> scnhorr to roll out multi-hop locks, or just use the latest ECDSA based >>> technique? As dual deployment is compatible (we can make the onion blobs >>> for >>> both types the same), a path has always existed to first roll out with >>> the >>> latest ECDSA based technique then follow up later to roll out the schnorr >>> version as well. However there's also a risk here as depending on how >>> quickly things can be rolled out, schnorr may become available >>> mid-development, which would possibly cause us to reconsider the ECDSA >>> path >>> and have the network purely use scnhorr to make things nice and uniform. >>> >>> Zooming out for a bit, the solution space of "how channels can look post >>> scriptless-scripts + taproot" is rather large [1], and the addition
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
> Why do we need another HTLC to be established from B to A ? We don't. This wasn't what I was saying. The atomic swap example was just to show that your idea does exist in a different context. An atomic swap can be viewed as a payment A -> B -> A where B switches the currency. > Pardon me if I am wrong but I am still confused why situation 1 will not be possible ? It is possible. In A -> B, A is able to punish B for not revealing secret. The problem is with A -> B -> C, the HTLCs need to be set up from left to right, A can't punish B for not revealing secret because he doesn't know it. B cannot set up the HTLC to C before having the HTLC from A. So it doesn't work -- or at least that's the conventional conclusion. To summarise: A -> B : punishment works A -> B -> A: punishment works A -> B -> C: it can't work (we think) LL On Fri, Mar 6, 2020 at 6:03 PM Subhra Mazumdar < subhra.mazumdar1...@gmail.com> wrote: > Can you send the draft on fair atomic swap? Also the scenario stated in > the pdf you have shared is based on exchange of asset. But here I am not > trying to work on different ledger A to B and B to A. Here it deals with > just simple transfer of funds from A to B. So whatever HTLC A establishes > with B, is it not the case where just one HTLC from A to B is enough? Why > do we need another HTLC to be established from B to A ? To clarify this, > we have two situation - > 1. HTLC A & B (on channel AB): both A and B lock say 0.1 BTC each i.e. 0.2 > BTC > 2. HTLC A (on channel AB) : A locks 0.1 BTC, HTLC B (on channel BA): B > locks 0.1 BTC > > Pardon me if I am wrong but I am still confused why situation 1 will not > be possible ? > > On Fri, Mar 6, 2020 at 12:00 PM Lloyd Fournier > wrote: > >> Hi Subhra, >> >> Afaik, the only problem is the one you identified, it doesn't work across >> multiple hops but only for the final hop. This penalty idea is the basis >> for doing atomc swaps fairly: >> https://coblox.tech/docs/financial_crypto19.pdf >> >> LL >> On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar < >> subhra.mazumdar1...@gmail.com> wrote: >> >>> Hi, >>> I was reading the paper by Poon and Dryja on Bitcoin Lightning >>> Network and was going through the construction of HTLC. Suppose 2 parties A >>> and B have a channel with each party locking 0.5 BTC. Suppose A wants to >>> transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced >>> within a locktime of say t days. So the script output for A is - >>> 1. 0.4 BTC to A >>> 2. 0.5 BTC to B >>> 3. 0.1 BTC locked in HTLC between A & B. >>> Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 >>> BTC to HTLC, where HTLC output can follow either of the paths - If B >>> produces R within t days then it gets back 0.4 BTC else after t days A can >>> broadcast with 0.4 BTC going to the A? This prevents B from not responding >>> (and induce possibly griefing attack across a longer path by withholding >>> the solution) since it will lose out 0.3 BTC. What can be the problem if >>> the terms of HTLC itself tries to enforce a penalty on the counterparty? >>> >>> -- >>> Yours sincerely, >>> Subhra Mazumdar. >>> >>> ___ >>> Lightning-dev mailing list >>> Lightning-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> > > -- > Yours sincerely, > Subhra Mazumdar. > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
If you can atomically set up both those penalties atomically then that would be a big breakthrough. It looks impossible. The problem is one will be set up before the other and it is only fair if both are set up at the same time. LL On Fri, Mar 6, 2020 at 5:34 PM Subhra Mazumdar < subhra.mazumdar1...@gmail.com> wrote: > But wont the decision of penalty be based on what incoming contract > expects from a node ? Suppose there is a contract between A and B and then > B and C, where A wants to transfer money to C. So if it is the case that A > impose penalty on B using its local HTLC, won't B put the same clause on C > as well so that in case C misbehaves it is able to spool out the penalty > for the rest of the path from C itself ? > > On Fri, Mar 6, 2020 at 12:00 PM Lloyd Fournier > wrote: > >> Hi Subhra, >> >> Afaik, the only problem is the one you identified, it doesn't work across >> multiple hops but only for the final hop. This penalty idea is the basis >> for doing atomc swaps fairly: >> https://coblox.tech/docs/financial_crypto19.pdf >> >> LL >> On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar < >> subhra.mazumdar1...@gmail.com> wrote: >> >>> Hi, >>> I was reading the paper by Poon and Dryja on Bitcoin Lightning >>> Network and was going through the construction of HTLC. Suppose 2 parties A >>> and B have a channel with each party locking 0.5 BTC. Suppose A wants to >>> transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced >>> within a locktime of say t days. So the script output for A is - >>> 1. 0.4 BTC to A >>> 2. 0.5 BTC to B >>> 3. 0.1 BTC locked in HTLC between A & B. >>> Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 >>> BTC to HTLC, where HTLC output can follow either of the paths - If B >>> produces R within t days then it gets back 0.4 BTC else after t days A can >>> broadcast with 0.4 BTC going to the A? This prevents B from not responding >>> (and induce possibly griefing attack across a longer path by withholding >>> the solution) since it will lose out 0.3 BTC. What can be the problem if >>> the terms of HTLC itself tries to enforce a penalty on the counterparty? >>> >>> -- >>> Yours sincerely, >>> Subhra Mazumdar. >>> >>> ___ >>> Lightning-dev mailing list >>> Lightning-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> > > -- > Yours sincerely, > Subhra Mazumdar. > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
Hi Subhra, Afaik, the only problem is the one you identified, it doesn't work across multiple hops but only for the final hop. This penalty idea is the basis for doing atomc swaps fairly: https://coblox.tech/docs/financial_crypto19.pdf LL On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar < subhra.mazumdar1...@gmail.com> wrote: > Hi, > I was reading the paper by Poon and Dryja on Bitcoin Lightning > Network and was going through the construction of HTLC. Suppose 2 parties A > and B have a channel with each party locking 0.5 BTC. Suppose A wants to > transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced > within a locktime of say t days. So the script output for A is - > 1. 0.4 BTC to A > 2. 0.5 BTC to B > 3. 0.1 BTC locked in HTLC between A & B. > Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 BTC > to HTLC, where HTLC output can follow either of the paths - If B produces R > within t days then it gets back 0.4 BTC else after t days A can broadcast > with 0.4 BTC going to the A? This prevents B from not responding (and > induce possibly griefing attack across a longer path by withholding the > solution) since it will lose out 0.3 BTC. What can be the problem if the > terms of HTLC itself tries to enforce a penalty on the counterparty? > > -- > Yours sincerely, > Subhra Mazumdar. > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning in a Taproot future
Hi ZmnSCPxj and Aj, Thanks for starting this discussion ZmnSCPxj. Although transactions with relative lock times are easily distinguishable today, couldn't this situation be improved? Even just a few wallets changing their behaviour to set relative time locks on normal payments would weaken the heuristic. From a design perspective it feels like leaving the improvement vector open would be better. Aj's model of scriptless lightning is more or less what I had in my mind (but with much better detail). On the question of "script based payment points" or "fully scriptless": Why not just do both? Since the tapscript version is faster to the "irrevocably committed" state, you first do that so you can forward the payment as fast as possible. Now that both parties have a commitment tx with a tapscript PTLC, they can (in no hurry) sign the scriptless spending transactions from the PTLC output. I think once they have signatures on their scriptless PTLC transactions they can forget all the tapscript data (to minimize the data they have to store per commitment tx). > But with taproot you can have a script path as well, so you could have a > script: >A CHECKSIGVERIFY B CHECKSIG > and supply a partial signature: >R+X,s,X where s = r + H(R+X,A,m)*a > to allow them to satisfy "A CHECKSIGVERIFY" if they know the discrete > log of X, and of course they can sign with B at any time. This is only > half a round trip, and can be done at the same time as sending the "I > want to do a PTLC for X" message to setup the (ultimately cheaper) MuSig > spend. It's an extra signature on the sender's side and an extra verification > on the receiver's side, but I think it works out fine. This is exactly how I thought the "script based payment point" would work where you just replace the hashing with an CHECKSIG and an adaptor sig. Like Z, I don't see how you can get away with just that though. I think you need to do a full tapscript PTLC and revocation (1.5 round trips) before you can forward a payment. Cheers, LL ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Hi ZmnSCPxj, > I think, it is possible to make, a miniscript-like language for such things. > Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s and Lightning, would be the requirement to reveal scalars rather than prove your knowledge of them. I've thought about this too. I've been pitching the language name as "Improv" (since it's scriptless!). I think it would allow you to specify the rules by which each output on each transaction can be spent and would compile those rules into a protocol that does the secure key and signature exchange for all the transactions in the scaffold. In other words, a protocol compiler. I think this could be really useful for formal specification of layer-2 protocols. LL On Thu, Oct 10, 2019 at 3:31 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Nadav, > > Thank you very much for this framework! > It seems very good idea, kudos to making this framework. > > I think, it is possible to make, a miniscript-like language for such > things. > Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s > and Lightning, would be the requirement to reveal scalars rather than prove > your knowledge of them. > > > > Idea 2: DLCs Routed over Lightning > > Say that some DLC oracle will either broadcast s_A or s_B whose public > points are S_A and S_B (which can be computed from public information as > per the DLC scheme). Then say that Alice and Bob enter into a contract > under which Alice wins some amount if s_A is broadcasted and Bob if s_B is > broadcasted. Say Alice has a point A and Bob has a point B. They each send > the other a payment with the amount that party must receive if they win > with the payment point A + S_A for Bob's payment to Alice and B + S_B for > Alice's payment to Bob. And this is it! If s_A is broadcasted then Alice > gets paid (and Bob gets proof of payment a, which is the scalar to A), > otherwise s_B is broadcasted and Bob gets paid (with Alice receiving b as > PoP). An interesting note is that under this scheme neither party is forced > to pay extra on-chain fees in the case of a counter-party who doesn't > cooperate whilst in the wrong. > > One wrinkle with this scheme is that setup isn't trustless. Although it > is generally true that one party must sign the funding transaction for a > DLC before the other party for on-chain DLCs, at least there is the > mitigation that when your counter-party goes silent, you can move your > input funds invalidating the funding transaction you signed (at a cost > because fees). So what can we do here to ensure that both payments are > setup at the same time in the case that Alice and Bob don't trust each > other? > > Say that although they don't trust each other, they're both willing to > trust some escrow entity who generates some point E for their payment. > Alice's payment point to Bob becomes B + S_B + E and Bob's to Alice becomes > A + S_A + E. The escrow now waits to hear from Alice and Bob that they have > incoming payments setup and only once both of them attest to this (using > signatures, for example) does the escrow release the scalar to E to them > both. The escrow can also have a timeout at which it will never reveal the > scalar to E: forcing both parties to commit to the contract well before the > DLC event. In this way, trust has been moved from counter-party to > trustworthy (hopefully) escrow in such a way that the Escrow learns nothing > about the contract itself (other than that there is one of some kind). > > I think we can call this a "barrier escrow". > > * It is similar to the concept of synchronization barriers for multithread > coordination: https://en.wikipedia.org/wiki/Barrier_(computer_science) > * In effect, each sub-transaction of the entire arrangement is a "thread" > of operation, and the "barrier escrow" ensures that all the threads have > reached it before letting them continue to claim the payments. > > > I seem, this is applicable to *not only* DLC, but others as well. > Instead, it seems to me to also provide an alternate solution to the > Premium-free American Call Option Problem. > > Let us introduce our characters: > > * B, a supposed buyer, holding some Bitcoin. > * S, a supposed seller, who wishes to be paid in another asset. > * X, a cross-currency exchange Lightning node. > * E, a tr\*sted escrow. > > X would like to facilitate exchanges across different assets, but wants to > be paid a premium in order to prevent the Premium-free American Call Option > Problem. > B would like to swap its Bitcoin for another asset to pay S, and would be > willing to pay the above premium, but only conditional on S actually > getting the asset it wants to be paid in. > X and B are non-trusting to each other, but are willing to tr\*st escrow E. > > This again is another "two transactions" setup, where we move tr\*st from > X and B and transfer it to E. > > * B forwards the payment to be exchanged through X
Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)
Hi Nadav, I've thought about similar problems before. Essentially you are trying to create an "access structure" on discrete logarithm (the completion of the adaptor signature in "pay-to-point"). I think the term for arbitrary combinations of AND and ORs and even N-of-M is called a *monotone access structure*. > Essentially the idea is to use the point S + ECDH(B, E) where S is the seller's point, B is the buyer's point and E is the escrow's point I can't see how you can create an access structure like this with ECDH. Neither B nor E know the discrete log of ECDH(B,E). I can see that you can hash it and use it as a scalar but then you have to make a heavy zkp to prove the validity (or interact with the escrow which violates the premise). Fortunately, I think it is possible to create any monotone access structure on a discrete logarithm using *verifiable encryption*. Applying this to the Escrow payment problem, the buyer decides on the payment point B and verifiably encrypts the discrete logarithm of B under the Escrow's public key E and sends the encryption to the seller. If there's a dispute, the seller sends the encryption to the Escrow. If the Escrow resolve the dispute in favour of the seller they just decrypt the ciphertext and send the discrete log of B to the seller. The seller can now redeem the payment. If we want to create more complex access structures then we use verifiable secret sharing where the discrete log of B is split up into shares and distributed according the the desired structure. So how do we do this verifiable encryption/secret sharing? Well it's not really straight forward. In the case of Escrow, Camenisch-Shoup [1] verifiable encryption might be attractive since the Escrow can be trusted to produce the Paillier modulus properly. Otherwise there's Camenisch-Damgaard [2] which is much less efficient but only relies on CDH assumption. As far as I know there are no usable implementations of either of these schemes but Camenisch-Damgaard is relatively straightforward and I think it's practical. [1] https://www.shoup.net/papers/verenc.pdf [2] https://eprint.iacr.org/1999/008 LL On Thu, Oct 10, 2019 at 10:43 AM Nadav Kohen wrote: > Hi list, > > I'm back again with another idea about Payment Points and fun things to do > with them! Hopefully this time I'm not entirely just hashing out old ideas > in public like an out-of-the-loop person :) > > *TLDR: Adding and ECDH-ing points gives us AND and OR functionality which > we can compose to make cool lightning contracts like Multisig, Escrow, and > DLCs* > > So when looking at the following (likely incomplete) list of things you > can do with payment points: > > 1) Payment De-correlation > 2) "Stuckless" Payments > 3) High AMP > 4) Selling Signatures > 5) Selling Pedersen De-commitment > 6) Escrow Contracts > > I started of trying to classify what kind of thing these new features are > in hopes of coming across new ones. The first three I clumped into a group > I called "Payment point addition allows us to do cool things while > maintaining the Proof of Payment (PoP) property". The next two (4 and 5) I > called "Commitment applications where point is public". But ZmnSCPxj's > proposal for lightning escrow contracts ( > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html) > struck me as something different that might somehow be made more general. > > Essentially the idea is to use the point S + ECDH(B, E) where S is the > seller's point, B is the buyer's point and E is the escrow's point. This > means that the scalar can be discovered by the seller in collaboration with > the buyer or the escrow, that is, S AND (B OR E). I propose that under > certain circumstances (such as the parties involved being able to > interact), this can be generalized to have payments conditioned on > arbitrary AND/OR circuits. > > I believe that AND is very straightforward as you simply take two > conditions A and B and add them together to get a point that requires both > of their scalars are discoverable (except maybe under certain bad > circumstances that can be avoided where like B = C - A, this must be > guarded against). > > OR is harder but I think that it can be achieved in the two party case by > ECDH and in the n-party case by multi-party key exchanges (which I know > pretty much nothing about other than that they exist). Given some key > exchange protocol (preferably non-interactive), KE, KE(A_1, ..., A_n) > should result in a number known only to those who know any scalar a_1, ..., > a_n and no one else. Assuming this exists and we can manage to trustlessly > (in some possibly stretched sense of the word) compute shared keys > (including such things as KE(A+B, C)), then KE(A, B) acts as A OR B in our > payment condition contract. > > To restate the escrow contract idea in this setting, the payment is > conditioned on S + KE(B, E). Important to note is that not all parties must > know about the details of the
Re: [Lightning-dev] Selling timestamps (via payment points and scalars + Pedersen commitments ) [try2]
This is a nice scheme. Pedersen commitments + pay to point seems to be the most practical way to do it but you can generalise this paying for a decommitment idea to any commitment scheme. For example, you could do this in a payment channel with hashes if we had something like OP_CAT. e.g HTLC unlocks based on whether you can provide an r such that H(r || x) == C. > Unfortunately that zkp already proves that C was generated based on x, so you get your timestamp for free. Ooops. :( I haven't studied zkp for circuits in general but I guess the non-interactive proofs are fiat-shamir transformations of an interactive protocol. Maybe you could just use the interactive zero knowledge protocol which doesn't have the side effect of the verifier with a proof they can give to others. LL On Thu, Sep 26, 2019 at 5:30 AM Anthony Towns wrote: > On Wed, Sep 25, 2019 at 01:30:39PM +, ZmnSCPxj wrote: > > > Since it's off chain, you could also provide R and C and a zero > knowledge > > > proof that you know an r such that: > > > R = SHA256( r ) > > > C = SHA256( x || r ) > > > > in which case you could do it with lightning as it exists today. > > I can insist on paying only if the server reveals an `r` that matches > some known `R` such that `R = SHA256(r)`, as currently in Lightning network. > > However, how would I prove, knowing only `R` and `x`, and that there > exists some `r` such that `R = SHA256(r)`, that `C = SHA256(x || r)`? > > If you know x and r, you can generate C and R and a zero knowledge proof > of the relationship between x,C,R that doesn't reveal r (eg, I think > you could do that with bulletproofs). Unfortunately that zkp already > proves that C was generated based on x, so you get your timestamp for > free. Ooops. :( > > Cheers, > aj > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Selling Signatures: Another Reason to Move to Payment Points
Hi Nadav, Interesting. Is there a writeup anywhere of this CET idea that I can add to my reading list. I feel like I am missing some background. LL On Thu, Jul 18, 2019 at 2:56 AM Nadav Kohen wrote: > Hi Lloyd, > > Glad you like it :) And to address your concern, I think that although > certainly it is possible for oracles to sell options contracts, it is also > possible to have a more decentralized setup with normal DLC oracles (that > can be used for all kinds of things as all they do is schnorr sign messages > with pre-commited R values), and then have the CETs be 3-of-3 multisig > outputs. In this way the oracle is still not learning about the contract, > just like normal DLCs. > > Best, > Nadav > > On Wed, Jul 17, 2019 at 11:23 AM Lloyd Fournier > wrote: > >> Hi Nadav, >> >> This is cool idea. I always imagined oracles would either give their DLC >> signatures away for free or work via a subscription model. >> >> The downside to this proposal is that the seller of the signature knows >> which signature they're selling and therefore learns what kind of contract >> the buyer must be involved in. >> >> LL >> >> >> On Thu, Jul 18, 2019 at 1:37 AM Nadav Kohen wrote: >> >>> Hi All, >>> >>> I recently posted a proposal here for a scheme through which a trusted >>> data provider can utilize the Lightning Network to privately sell data >>> where data is received atomically with purchase. >>> >>> I've more recently been thinking about situations where a party, that is >>> *not* trusted, is attempting to sell its signature to a known message. One >>> example of a situation where this would be useful is if someone is trying >>> to offer a DLC-like Option contract where they are essentially >>> collateralizing themselves in a funding transaction and then selling their >>> signatures to Contract Execution Transactions (CETs). In this example, we >>> must ensure that the buyer of the signatures pays if and only if they >>> receive valid signatures for the CETs which are known. >>> >>> I believe that this is achievable in a relatively straightforward way if >>> we were to use ZmnSCPxj's proposed payment points with scalars (as opposed >>> to payment hashes with pre-images). The (Schnorr) signature seller could >>> give the buyer their one-time public key, `R = k*G`, through which the >>> buyer could compute the payment point whose scalar is the seller's >>> signature: `sig*G = R + h(m, R)*A` where `A` is the seller's public key. >>> Using this value as the payment point, the buyer could be assured that they >>> pay if and only if they receive `sig` from the seller, where `sig` is the >>> desired valid signature of `m`! >>> >>> Best, >>> Nadav >>> ___ >>> Lightning-dev mailing list >>> Lightning-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> >> ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Paper: A Composable Security Treatment of the Lightning Network
Hi Orfeas, Thanks for formally modelling lightning and posting your paper here. I've taken a brief look at the paper so far. I am a UC novice and have no academic background so please take that into account when interpreting my comments. In general, I am glad that you are taking the approach to model the protocol relative to the G_ledger functionality which seems like the right thing to do (from my amateurish view). The questions/comments I have are: 1. When modelling things in UC the ideal functionalities should be as simple and intuitive as possible. I found F_PayNet to be rather difficult to follow as compared to the Sprites paper [1]. For example, "F_PayNet checks that for each payment the charged party was one of the following: (a) the one that initiated the payment, (b) a malicious party or (c) an honest party that is negligent" Why not assume that (b) never happens because a malicious party never wants to lose the funds from a party they've corrupted and (c) never happens because honest parties follow the protocol and check each ledger update for malicious channel closes. Real world protocols always realise ideal functionalities under some assumptions and these two things seem like pretty reasonable things to include in your assumptions rather than cluttering up your ideal functionality. 2. In both your paper and [1] I am not convinced that the ideal and real worlds aren't easily distinguishable from each other by an Environment that just looks at the transactions in the blockchain (G_ledger). For example, the lightning protocol makes heavy use of pay-to-script-hash where as ideal functionalities have no need for this. F_PayNet can just send normal transactions. I think it would be a great idea to describe how you ensure that the transactions that make it onto the blockchain after an execution in the real world are indistinguishable from the ideal world. 3. On a related note, I don't understand this "receipt" mechanism. In your protocol description of OpenChannel, Alice uses her private key which owns UTXO(s) with x coins to create the funding transaction. This means she received that private key as input to the execution of the protocol so that she is able to do this (why don't you explicitly include this private key in the OpenChannel message?). In the ideal world, the ideal functionality should be the one with the private key signing the funding transaction directly (in the ideal world the parties are dummy ITMs which just send their input to the ideal functionality). But instead there is this receipt thing which I don't understand. Cheers LL [1] https://arxiv.org/pdf/1702.05812.pdf On Wed, Jul 10, 2019 at 6:44 PM Orfeas Stefanos Thyfronitis Litos < o.thyfroni...@ed.ac.uk> wrote: > Hi all, > > The promise for fast, scalable, user-friendly and trustless use of > bitcoin that the Lightning Network offers motivated us to author a paper > where we formalize LN in the cryptographic framework of Universal > Composition and prove its security. It can be found here: > https://eprint.iacr.org/2019/778 > > We believe that a formal proof of security was needed to specify the > exact operating parameters that safeguard the funds and transactions of > users against arbitrary attackers, to abstract, modularize and validate > the underlying cryptography that is used in LN, to incorporate LN in the > body of cryptographic protocols that have been abstracted within the > Universal Composition framework (and thus can be safely composed and run > in parallel) and to increase the trust of the wider community to LN. We > view this work as a small contribution to the amazing effort that the > Lightning community has expended both on the theoretical and the > practical front throughout the last years. > > The paper is authored by my PhD supervisor Prof. Aggelos Kiayias and me. > Any feedback will be greatly appreciated. > > Best regards, > Orfeas Stefanos Thyfronitis Litos > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Selling Signatures: Another Reason to Move to Payment Points
Hi Nadav, This is cool idea. I always imagined oracles would either give their DLC signatures away for free or work via a subscription model. The downside to this proposal is that the seller of the signature knows which signature they're selling and therefore learns what kind of contract the buyer must be involved in. LL On Thu, Jul 18, 2019 at 1:37 AM Nadav Kohen wrote: > Hi All, > > I recently posted a proposal here for a scheme through which a trusted > data provider can utilize the Lightning Network to privately sell data > where data is received atomically with purchase. > > I've more recently been thinking about situations where a party, that is > *not* trusted, is attempting to sell its signature to a known message. One > example of a situation where this would be useful is if someone is trying > to offer a DLC-like Option contract where they are essentially > collateralizing themselves in a funding transaction and then selling their > signatures to Contract Execution Transactions (CETs). In this example, we > must ensure that the buyer of the signatures pays if and only if they > receive valid signatures for the CETs which are known. > > I believe that this is achievable in a relatively straightforward way if > we were to use ZmnSCPxj's proposed payment points with scalars (as opposed > to payment hashes with pre-images). The (Schnorr) signature seller could > give the buyer their one-time public key, `R = k*G`, through which the > buyer could compute the payment point whose scalar is the seller's > signature: `sig*G = R + h(m, R)*A` where `A` is the seller's public key. > Using this value as the payment point, the buyer could be assured that they > pay if and only if they receive `sig` from the seller, where `sig` is the > desired valid signature of `m`! > > Best, > Nadav > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
t; payment!" to all intermediate nodes; also, it still allows a short time > duration for American Option shenanigans. > > The Route Maker solution by CJP is plausible, to me, only if the exchange > and the Route Maker are the same, which is effectively what is done here, > but now requires multiple secrets to be revealed. > > I was thinking it might be possible, to use point/scalar and require the > sum of the payment scalar and the exchange scalar, and thereby hide from > intermediate nodes that multiple secrets are needed, but now the payer > receives the sum of scalars instead of two separate preimages; this can > make it difficult for protocols requiring proof-of-payment secrets (such as > the offline vending machine discussed before) from working correctly. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, May 4, 2019 4:28 AM, Lloyd Fournier > wrote: > > > Hi ZmnSCPxj, > > > > I'm glad you pointed this out. I think this protocol is practical. That > talk was actually given by my colleague :). > > My post in the December thread was trying to explain the same idea but > as a [A -> Exchange -> A] on-chain trade (rather than a [A -> Exchange -> > B] cross chain L2 payment). For reference: > https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def. > > > > I mentioned it was possible to do it in a channel. Although looking back > at it now it seems I was somewhat confused at the time. I said: > > > > > As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and > the other party receiving it as asset B with some exchange node in the > middle doing a conversion is unsound given what we are able to construct in > Lightning. > > > > As you just showed, this is wrong. [A -> Exchange -> B] with the > collateral on the last hop works fine. After all, [A -> Exchange -> A] is > just a special case of [A -> Exchange -> B]. I agree that extending this > idea across multiple hops after the exchange securely looks impossible. > > > > Note, the Exchange should watch carefully for their counter-party > delaying in signing the channel update on the final hop (to gain value from > the option this gives them). If they notice this they should close the > channel and avoid doing business with this party. > > Despite this, it's still a far better protocol than the vanilla atomic > swap because the delaying party has a far less time to realise any gains > from the option. The exchange can put an end to it by closing the channel > within 1 on chain tx. > > > > On naming. I think it's better to call it *collateral* rather than an > *option premium* because it is only paid on a failure to execute the trade. > > I was thinking we can call them collateralized HTLCs. > > > > It's possible to modify the protocol slightly so that the party > receiving the option pays the *premium* regardless of whether they release > x or not. This makes it a proper cross chain option with guaranteed premium. > > We made a poster describing this idea here: > https://coblox.tech/docs/financial_crypto19.pdf. > > > > Cheers, > > > > Lloyd > > On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > > > > > Good morning list, > > > > > > Reviving an old thread, but I saw this just recently: > http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ > > > > > > Suppose you are a BTC to WJT exchange. > > > I want to pay 1 BTC to send 10 WJT to YAIjbOJA. > > > I have a BTC channel to you. > > > You have a WJT channel to YAIjbOJA. > > > > > > In order to create a properly-incentivized American Call Option with a > premium, you insist that 10% of the WJT value be the premium that is paid > if the exchange does not pull through. > > > > > > We perform this ritual: > > > > > > 1. YAIjbOJA generates a secret x and gives h(x) to me. > > > 2. On my channel to you, I get 1 BTC from my side and create an HTLC. > > > Hash is h(x) payable to you, timelock is 2 days payable to me. > > > 3. On your channel to YAIjbOJA, you get 10 WJT from you, and > 1 WJT (10%, the premium) from YAIjbOJA and create an HTLC. > > > Hash is h(x) payable to YAIjbOJA, timelock is 1 days payable to > you. > > > > > > The above also forms an American Call Option, but with a premium if > the payment does not push through. > > > > > > However, extending this to beyond on
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Hi ZmnSCPxj, I'm glad you pointed this out. I think this protocol is practical. That talk was actually given by my colleague :). My post in the December thread was trying to explain the same idea but as a [A -> Exchange -> A] on-chain trade (rather than a [A -> Exchange -> B] cross chain L2 payment). For reference: https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def. I mentioned it was possible to do it in a channel. Although looking back at it now it seems I was somewhat confused at the time. I said: > As ZmnSCPxj demonstrated, the idea of sending a payment in asset A and the other party receiving it as asset B with some exchange node in the middle doing a conversion is unsound given what we are able to construct in Lightning. As you just showed, this is wrong. [A -> Exchange -> B] with the collateral on the last hop works fine. After all, [A -> Exchange -> A] is just a special case of [A -> Exchange -> B]. I agree that extending this idea across multiple hops after the exchange securely looks impossible. Note, the Exchange should watch carefully for their counter-party delaying in signing the channel update on the final hop (to gain value from the option this gives them). If they notice this they should close the channel and avoid doing business with this party. Despite this, it's still a far better protocol than the vanilla atomic swap because the delaying party has a far less time to realise any gains from the option. The exchange can put an end to it by closing the channel within 1 on chain tx. On naming. I think it's better to call it *collateral* rather than an *option premium* because it is only paid on a failure to execute the trade. I was thinking we can call them collateralized HTLCs. It's possible to modify the protocol slightly so that the party receiving the option pays the *premium* regardless of whether they release x or not. This makes it a proper cross chain option with guaranteed premium. We made a poster describing this idea here: https://coblox.tech/docs/financial_crypto19.pdf. Cheers, Lloyd On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > Reviving an old thread, but I saw this just recently: > http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ > > Suppose you are a BTC to WJT exchange. > I want to pay 1 BTC to send 10 WJT to YAIjbOJA. > I have a BTC channel to you. > You have a WJT channel to YAIjbOJA. > > In order to create a properly-incentivized American Call Option with a > premium, you insist that 10% of the WJT value be the premium that is paid > if the exchange does not pull through. > > We perform this ritual: > > 1. YAIjbOJA generates a secret x and gives h(x) to me. > 2. On my channel to you, I get 1 BTC from my side and create an HTLC. > Hash is h(x) payable to you, timelock is 2 days payable to me. > 3. On your channel to YAIjbOJA, you get 10 WJT from you, and > 1 WJT (10%, the premium) from YAIjbOJA and create an HTLC. > Hash is h(x) payable to YAIjbOJA, timelock is 1 days payable to you. > > The above also forms an American Call Option, but with a premium if the > payment does not push through. > > However, extending this to beyond one hop after the exchange node is > difficult. > Problems in communicating with the next hop may cause the current hop > after the exchange node to become liable for the premium without being able > to forward the liability to the final payee, which is an avenue for attack. > And if the payee must be the hop after the exchange node, the exchange > node now knows exactly how much and when that node receives payment, and > can sell this information and/or selectively disrupt/censor some payments. > > Putting the premium before the exchange node is possible with an > additional transaction spending the HTLC (the timelock branch is payable to > a 2-of-2 with a pre-signed transaction that sends the premium to the > exchange and returns the rest of the value to the payer). > But this is unsafe, since the exchange (and any node between the payer and > the exchange) can stall the protocol deliberately and refuse to forward, > extracting the premium via the timelock branch. > This is effectively forcing fees even in a route failure, which does not > incentivize intermediate nodes to actually forward when they can do nothing > and receive fees anyway for not routing. > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Happy new year lightning-dev! This topic is my main area of research at moment so I'm really happy to see a thread about it. In general I agree with ZmnSCPxj's analysis and conclusions. I'd like to add a couple of ideas to this discussion and would greatly appreciate some early peer review on them :) HTLCs as American call options = I think the "option problem" is actually caused by protocols using HTLCs in a naive way rather than the use of HTLCs themselves. Consider the atomic swap protocol described in the OP: >1. You provide me a hash of some secret preimage that only you know. >2. You make an HTLC on the Bitcoin blockchain. >The value of this HTLC is `P`, the hash is the hash you gave above, and the timelock is `E` + 1 day. >3. I make an HTLC on the WJT blockchain. >The value of this HTLC is 1, the hash is the hash you gave, and the timelock is `E`. If we take this protocol and draw out its abstract functionality we get: 1. *Up for sale* Alice puts Asset `A` up for sale to Bob for some time period `Eb` + `Ea` 2. *Make expiring offer* Bob makes an offer of asset `B` which expires at time `Eb` 3. *Take offer* Alice may take the offer up until time `Eb` As has been pointed out, Alice has an "option" for the duration of `Eb` (and she didn't pay a premium). This is because Bob made her an offer he cannot cancel (an offer you can't cancel but has an expiration is basically the definition of being short an option contract). In order to remedy this, the party that makes the offer must be able to cancel their offer at any point after they have made it (before the counterparty has taken it). This should be intuitive because it's how centralised exchanges work. Therefore, the ideal abstract functionality we want is: 1. *Make Offer* Alice makes an offer to Bob to trade `A` for `B` 2. *Take Offer* Bob can take the offer (if Alice hasn't already cancelled it) and get `A` in exchange for `B`. 3. *Cancel Offer* If Bob hasn't taken the offer, Alice may get back `A` by cancelling the offer I developed the protocol below which comes pretty close to realising this. Let - α and β and be two bitcoin-like blockchains - Alice own asset `A` on the α blockchain and `C` on the β blockchain - Bob own asset `B` on the β blockchain 1. Alice puts the HTLC for `A` on α and waits for it to confirm (as per usual) 2. Alice creates a partial β blockchain transaction by signing one input and one output (using SIGHASH_SINGLE for example): - The input is the asset `C` - The output is a HTLC which gives `B` and `C` to herself with the secret or gives them both to Bob on timeout She sends this partial transaction to Bob. (This gives us the "Make Offer" functionality) 3. If Bob wants to accept the offer, he adds asset `B` to another input of the transaction and posts it to β. (This gives us "Take Offer" functionality) 4. If Alice wishes to cancel the trade before Bob has confirmed this transaction she double spends the `C` output and then reclaims `A` on α after the timeout. (This gives us the "Cancel Offer" functionality) 5. If the "Take Offer" transaction is confirmed on β, Alice must unlock the HTLC before the timeout or Bob will gain `C` AND get back `B`. 6. Once she reveals the secret, she both gets back `C` and gains `B` on β. 7. Bob can now take `A` on α in the usual manner now that he has learned the secret. Bob is not guaranteed to get `A` after he "takes" the offer but he is guaranteed to get `A` (in exchange for `B`) or `C` (for free). Obviously, `C` is Alice's collateral for the trade. Bob should only take the offer if he wants `A` more than `B` and if he is sure that the value of gaining `C` will be greater than any loss he could experience from `B` depreciating relative to `A` during the execution of the protocol. I believe this shows that HTLCs do not in cause options but rather uncancelable offers + uncollateralized HTLCs cause the option problem. I think this protocol works in payment channels in the case that Alice and Bob have direct channels to each other. The issue is that if Alice decides she wants to cancel at the same time Bob decides he wants to take it you have to go to the blockchain to resolve the issue (which will be rather arbitrary). CJP's idea of having a 3rd party who is trusted simply to compute the outcome of a offer (cancelled or taken) in layer 2 networks seems like a promising direction because this would avoid on-chain resolution in this case. Cross Asset Payments Don't Make Sense As ZmnSCPxj demonstrated, the idea of sending a payment in asset `A` and the other party receiving it as asset `B` with some exchange node in the middle doing a conversion is unsound given what we are able to construct in Lightning. But this doesn't necessarily mean that Lightning has to be single asset. Theoretically, a single two-party channel could record multiple asset types with a state transaction that has distinct outputs for
Re: [Lightning-dev] An Argument For Single-Asset Lightning Network
Hi David and ZmnSCPxj, ZmnSCPxj, Thanks for your response. I messed something up with my response so my original post didn't get into the archive. I put it in a gist: https://gist.github.com/LLFourn/d0afa6b37207aed7cd73f6b9203c0def for reference. > I agree. > When I was developing American Call Options on top of onchain HTLCs, I came up with a similar construction for ensuring that the premium is paid before the HTLCs setting up the option appear onchain. I would be interested to see how your construction worked. You can actually modify the construction I gave before (in the gist) to create a fair option too. You just change it so the asset `C` is paid on both branches of the HTLC. This changes `C` from collateral to a premium. This sounds a bit different to what you describe as the premium isn't paid before the HTLCs go onto the chain. The only other proposal for options I've seen is: https://www.ics.uci.edu/~jamesal1/Swaptions.pdf. I could be missing something, but this seems to give Alice a free option on an option in this one. The premium payment has the option problem: Bob cannot cancel his offer of an option but Alice can take her time to accept it. > However, can such a scheme scale on-Lightning? The scalability issue with the scheme in payment channels is the lack of objective ordering of events in layer 2. If Alice and Bob disagree on whether "Take Offer" or "Cancel Offer" happened first, they will have to close their channel and resolve their dispute on the blockchain. This means that channels may have to go to the blockchain much more often than if you were just doing payments. In practice, this problem might not be so severe. Parties that have frequent disputes will just tend to stop opening channels with each other. It still guarantees that in the worst case there are no long options for either party. --- David, > Instead of Alice's node just locally constructing this path and trying > to pay it like normal, she first sends a special probe to Charlie > requesting a new hash for which only he knows the preimage. With this > hash plus the hash Alice received from Eliza, Alice sends a payment that > requires both hashlocks be unlocked before anyone can claim the payment. Moving the option from the random anonymous person (Alice) to the exchange node is a good improvement. If participants become good at identifying exchange nodes that delay in revealing the secret that might be enough to make the cross asset payment idea practical. As you hinted at, I think there is a simpler construction that is more compatible with today's lightning: 1. Alice given `A` wants to send `B` to Bob with Charlie doing the exchange. 2. Charlie generates a secret `s` and makes a payment of `B` to Bob locked under H(s) 3. Once Bob has the locked payment of `B` he sends H(s) to Alice 4. Alice then makes the payment of `A` under H(s) to Charlie. 5. Charlie now unlocks Alice's payment with `s` and receives `A` 6. Alice then learns `s` and sends it to Bob 7. Bob unlocks Charlie's payment with `s` and receives `B` > In ZmnSCPxj's terminology, the option is now no longer > free because Charlie must decide between potential routing income and > potential option income I didn't really get why the exchange would get any routing income from this? The exchange is the receiver of a payment of BTC on one leg and the sender of WJT on another. I'd expect the exchange would gain profit from spreads rather than fees in these protocols. Lloyd \n On Sat, Jan 5, 2019 at 6:01 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning David, > > What happens if the exchange node only sends its preimage towards the > payer and not towards the payee? > > If the payer and payee do not coordinate, then it becomes possible for the > exchange node to take the funds without the payee gaining the ability to > claim the payment. > This might be used by a node to take proofs of payment without paying, by > simulating the payer and exchange nodes. > This may be important if the proof of payment is valuable, such as, the > mentioned offline Lightning vending machines, or if the preimage is the > decryption key for valuable data (e.g. ransomware; now the ransomware > author may find it is scammed off their potential earnings). > > Regards, > ZmnSCPxj > > > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, January 5, 2019 5:05 AM, David A. Harding > wrote: > > > On Thu, Dec 27, 2018 at 05:43:51AM +, ZmnSCPxj via Lightning-dev > wrote: > > > > > We can try to mitigate this, but the solutions below all have > significant drawbacks. > > > > An alternative is to give the person making the exchange the ability to > > cancel the payment if they think the exchange rate has changed > > unfavorably for them. I think you could do that by adding an extra > > hashlock to the HTLC that's controlled by the exchanger. For example, > > here's what we'd expect a cross-asset
