Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
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 Yes, but on the other hand --- as pointed out, the seller could be lying and just made up the "other node" in the channel. Proof that the "other node" is in fact the actual "other node" on that channel is relatively worthless if there is no proof that the "other node" is at all something other than the seller. On the other other hand --- if the buyer has additional information that the "other node" here is "of interest" (i.e. it has other data about the "other node" that makes it focus its attention on this "other node", and it suspects the seller is not a sockpuppet of the "other node" here) then this kind of proof just became very valuable. -- Another thought is that this approach potentially makes the LN gossip network a monolithic database that is only weakly consistent. The Bitcoin blockchain layer is an existing monolithic database with strong consistency guarantees. Because of weak consistency, it is possible for a node to exist in your gossip map, you make a channel to that node, then you get amnesia, then that node is no longer in your gossip map. Do we need to find ways to increase the consistency of node gossip? Regards, ZmnSCPxj ___ 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
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 --- ___ 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
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. 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. 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. On the other hand, it might not be possible (as you note about PTLCs). > > > 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. > > > 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. 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? > > 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. "Peer selling private information" is always going to be an issue with unpublished channels, and this seems to be an inherent
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
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. If we allow HTLCs to keep going on even while we are in recovery, we need to be able to "bind" as well incoming and outgoing HTLCs if our node was a forwarding node. In particular, consider this situation: * We are a forwarding node. * We forward a payment whose outgoing expires in 1 day and whose incoming expires in 2 days. * This means we have at least two channels, one with the incoming HTLC and another with the outgoing HTLC. * We hit our head and get amnesia. * It takes us a day to realize we were formerly a Lightning Network forwarding node. * The peer with the outgoing HTLC knows or learns the preimage. * Since we were unresponsive (i.e. still recovering from whatever gave us amnesia) that peer has dropped the channel onchain. * The peer has resolved the onchain HTLC with the hashlock branch. * Because the outgoing peer has resolved everything it cares about, it forgets about the channel. * We call all public nodes and ask about channels we might have with them. * The incoming peer claims we have a channel with them containing an HTLC going to us. * The outgoing peer has forgotten about us and does not tell us about the channel. Thus, we cannot recover the outgoing channel, since the peer has already closed it and resolved everything it is interested in. (let us suppose that the `to_self_delay` is smaller than our `cltv_delta` setting) 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. 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. * An unpublished node could use a faked node id, by combining the payment hash/point with its privkey to generate a new keypair to use as faked node id (I AM NOT A CRYPTOGRAPHER AND THIS TECHNIQUE IS POTENTIALLY GOING TO LOSE ALL YOUR FUNDS AND PRIVACY AND KILL YOUR DOG). On receiving an unparseable onion, it could try combining its privkey with the payment hash/point and try to open the onion that way, in case it is an incoming payment with the faked node id. Regards, ZmnSCPxj ___ 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
I don't think it's so clear that any party refusing to go go first can be assumed to have lost data. If the rule is that the party receiving the connection is the one that must send the oblivious signatures then a party that has both lost data and is receiving a connection can just ignore the connection request. There is plausible denyability because knowingly not answering a request can't be distinguished from just having connection issues or distinguished from a machine is just turned off. This reasoning should work well into the future because as long as machine failures are common, the node with data loss can hide in that anonymity set. And if human kind resolves all machine failures then by definition there shouldn't be lightning channel data loss. Cheers Ariel Lorenzo-Luaces On Dec 13, 2020, 10:12 AM, at 10:12 AM, "David A. Harding" wrote: >On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote: >> 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. > >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. For example, it seems to me that both of the following >protocols provide identical utility: > >1. On every reconnection, request the plain text unsigned commitment > transaction, send a pedersen commitment, and receive the encrypted > signature(s). If c=1, verify the encrypted signature(s) and (on > success) send the blinding factor or (on failure) fail the channel > and ban the peer. If c=0, decrypt the signature(s), apply them to > the commitment transaction, and broadcast. > >2. On every reconnection, request the plain text unsigned commitment > transaction with all of its signatures, also in plain text. If our > database is intact, verify the commitment transaction and its > signatures are valid and (on success) continue or (on failure) fail > and ban. If we lost data, broadcast the commitment transaction. > >Unless I'm forgetting something, there's no reason a node shouldn't >send >its latest commitment transaction to its counterparty in plain text >(over the regular BOLT8 P2P encrypted and authenticated link). > >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. > >-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] 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
Re: [Lightning-dev] Covert channel recovery with Oblivious Signatures
On Fri, Dec 11, 2020 at 01:02:04PM +1100, Lloyd Fournier wrote: > 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. 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. For example, it seems to me that both of the following protocols provide identical utility: 1. On every reconnection, request the plain text unsigned commitment transaction, send a pedersen commitment, and receive the encrypted signature(s). If c=1, verify the encrypted signature(s) and (on success) send the blinding factor or (on failure) fail the channel and ban the peer. If c=0, decrypt the signature(s), apply them to the commitment transaction, and broadcast. 2. On every reconnection, request the plain text unsigned commitment transaction with all of its signatures, also in plain text. If our database is intact, verify the commitment transaction and its signatures are valid and (on success) continue or (on failure) fail and ban. If we lost data, broadcast the commitment transaction. Unless I'm forgetting something, there's no reason a node shouldn't send its latest commitment transaction to its counterparty in plain text (over the regular BOLT8 P2P encrypted and authenticated link). 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. -Dave signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
