Re: [Lightning-dev] asynchronous Lightning network payments
[Resending in Plain Text. Sorry for the spam] Hello Konstantin, In asynchronous payments we want to be sure that there are only two states: 1) Before B received the payment. 2) After B received the payment. In state 1), we want A to still have the control of the amount, and at the same time we want to let B decide (until a certain timeout) to receive the payment. In this state, S can only help B to be paid, or cancel the whole transfer, but in this case, A cannot lose the amount. In state 2), we want to be sure that no money is lost by S (and consequently that the amount in A wallet is decremented by amt). As ZmnSCPxj wrote in https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002260.html (as I understand the last sentences), there is no way to do that without locking the amount. In order to increase the privacy, we are improving the specification to be be able to use several Rod nodes: a list of nodes chosen by the payer and another list by the payee. The Rod nodes are supposed to be almost always online, so standard https can be used to communicate with them and between them. --yas On 29/10/2019 22:46, Konstantin Ketterer wrote: > ## Problem > Currently, both parties have to be online at the same time to send/ > receive money. This can be avoided by using something like the > Lightning Rod Protocol by Breez > (https://github.com/breez/LightningRod). However, funds have to be > locked up longer than usual. We can do better than that. > > ## Solution > The payer A pre-signs a transaction handing over money to their local > channel partner S and sends the transaction to the payee B in an end > to end encrypted communication channel. B can then sell the signature > for the transaction to S using pay-for-signature made possible by > payment points and scalars. > (https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002077.html) > > > We will be using eltoo because we don't have to worry about toxic > channel states. > > A and S are online, A and S have a channel > 1. A contacts S: they commit and exchange the R (= k*G) part of the > Schnorr Signature for the update and settlement transaction > 2. A and S sign the settlement transaction increasing the balance > between them by amt + fee in favor of S and exchange the signatures > 3. A signs the corresponding update transaction but does not give it so S > 4. A sends the update transaction to B using an end to end encrypted > asynchronous communication channel > > A can go offline > B comes online > > 4. Decrypts the update transaction and sells the signature s to S for amt > > When A comes back online S gives A the invoice (with the payment point > s*G) signed by B, the corresponding scalar s (the signature from A for > the update transaction) and signature from S for the update > transaction. They can now proceed as normal. > > In addition to enabling asynchronous payments, this outsources the > routing to S. > > ### Potential issues > > Privacy > S currently knows both the sender and the receiver of the payment. If > we split the payment from S to B into two payments between S and a > public routing node P and P and B by still using the same scalar + > payment point, S now only knows the sender and P only knows the > receiver. To further increase privacy we can split the payment > multiple times but all nodes involved must support this feature. > > Locked up capital > While B hasn't yet claimed its money, the funds in the channel between > A and S are essentially locked up. However, A and S could simply > overwrite the payment (new update + settlement transaction), then A > could send multiple payments with the remaining balance and before > going offline A would do the procedure again. If A has sufficient > inbound capacity in other channels it can also re-balance its channel > A-S so that the outbound capacity - (amt + fees) in this channel is > zero and then do the procedure. > > Communication channel > Obviously, the communication channel must be end to end encrypted > otherwise this is highly insecure. Hopefully, we will have a sort of > decentralized paid mail server system which is compatible across all > LN wallets and part of BOLT. > > Proof of payment > The invoice by B with the payment point s*G and s are not sufficient > as a PoP because S can simply give A the invoice and A already knows s. > > ## the other way around > We can also do it in a way that A can instantly send B (who is > offline) money but now A is in charge of enforcing the channel state > if S cheats. Because it has more issues like who pays the transaction > fees if S cheats and because I believe Lightning is generally not > designed for people who are offline for a long time I prefer the first > one. But here is the other one: > > B and S are online, B and S have a channel > > 1. B and S sign a new settlement transaction increasing balance in > favor of B by amt > 2. B signs the corresponding update transaction, encrypts i
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
(resend from the right src) >> On Oct 30, 2019, at 06:04, Joost Jager wrote: >> > For the anchor outputs we consider: >> > >> > * Output type: normal P2WKH. At one point, an additional spending path was >> > proposed that was unconditional except for a 10 block csv lock. The >> > intention of this was to prevent utxo set pollution by allowing anyone to >> > clean up. This however also opens up the possibility for an attacker to >> > 'use up' the cpfp carve-out after those 10 blocks. If the user A is offli= >> ne >> > for that period of time, a malicious peer B may already have broadcasted >> > the commitment tx and pinned down user A's anchor output with a low fee >> > child. That way, the commitment tx could still remain unconfirmed while an >> > important htlc expires. >> >> Agreed, this doesn't really work. We actually needed a bitcoin rule >> that allowed a single anyone-can-spend output. Seems like we didn't get >> that. > > With the mempool acceptance carve-out in bitcoind 0.19, we indeed won't be > able to safely produce a single OP_TRUE output for anyone to spend. An > attacker could attach low fee child transactions, reach the limits and block > further fee bumping. Quick correction. This is only partially true. You can still RBF the sub-package, the only issue I see immediately is you have to pay for the otherwise-free relay of everything the attacker relayed. Why not stick with the original design from Adelaide with a spending path with a 1CSV that is anyone can spend (or that is revealed by spending another output). >> > * For the keys to use for `to_remote_anchor` and `to_local_anchor`, we=E2= >> =80=99d >> > like to introduce new addresses that both parties communicate in the >> > `open_channel` and `accept_channel` messages. We don=E2=80=99t want to re= >> use the >> > main commitment output addresses, because those may (at some point) be co= >> ld >> > storage addresses and the cpfp is likely to happen from a hot wallet. >> >> This is horribly spammy. At the moment we see ~ one unilateral close >> every 3 blocks. Hopefully that will reduce, but there'll always be >> some. > > It seems there isn't another way to do the anchor outputs given the mempool > limitations that exist? Each party needs to have their own anchor, protected > by a key. Otherwise it would open up these attack scenarios where an attacker > blocks the commitment tx confirmation until htlcs time out. Even with the > script OP_DEPTH OP_IF OP_CHECKSIG OP_ELSE 10 OP_CSV OP_ENDIF, the > "anyones" don't know the pubkey and still can't sweep after 10 blocks. > >> > * Within each version of the commitment transaction, both anchors always >> > have equal values and are paid for by the initiator. >> >> Who pays if they can't afford it? What if they push_msat everything to >> the other side? > > Similar to how it currently works. There should never be a commitment > transaction in which the initiator cannot pay the fee. With anchor outputs > there should never be a commitment tx in which the initiator cannot pay the > fee and the anchors. Also currently you cannot push everything to the other > side with push_msat. The initiator still needs to have enough balance to pay > for the on-chain costs (miner fee and anchors). > >> > The value of the >> > anchors is the dust limit that was negotiated in the `open_channel` or >> > `accept_channel` message of the party that publishes the transaction. >> >> Now initiator has to care about the other side's dust limit, which is >> bad. And as accepter I now want this much higher, since I get those >> funds instantly. I don't think we gain anything by making this >> configurable at all; just pick a number and be done. >> >> Somewhere between 1000 and 10,000 sat is a good idea. > > Yes, it is free money. Therefore we need to validate the dust limit in the > funding flow. Check whether it is reasonable. That should also be done in the > current implementation. Otherwise your peer can set a really high dust limit > that lets your htlc disappear on-chain (although that is only free money for > the miner). > > If we hard-code a constant, we won't be able to adapt to changes of > `dustRelayFee` in the bitcoin network. And we'd also need to deal with a peer > picking a value higher than that constant for its regular funding flow dust > limit parameter. > >> There are several design constraints in the original watchtowers: >> >> 1. A watchtower shouldn't be able to guess the channel history. >> 2. ... even if it sees a unilateral tx. >> 3. ... even if it sees a revoked unilateral tx it has a penalty for. >> 4. A watchtower shouldn't be able to tell if it's being used for both >>parties in the same channel. >> >> If you don't rotate keys, a watchtower can brute-force the HTLCs for all >> previous transactions it was told about, and previous channel balances. >> >> We removed key rotation on the to-remote output because you can simply >> not tell t
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
> On Oct 30, 2019, at 03:04, Rusty Russell wrote: > > Joost Jager writes: >> * Add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of >> the HTLC outputs. > >> For the anchor outputs we consider: >> >> * Output type: normal P2WKH. At one point, an additional spending path was >> proposed that was unconditional except for a 10 block csv lock. The >> intention of this was to prevent utxo set pollution by allowing anyone to >> clean up. This however also opens up the possibility for an attacker to >> 'use up' the cpfp carve-out after those 10 blocks. If the user A is offli= > ne >> for that period of time, a malicious peer B may already have broadcasted >> the commitment tx and pinned down user A's anchor output with a low fee >> child. That way, the commitment tx could still remain unconfirmed while an >> important htlc expires. > > Agreed, this doesn't really work. We actually needed a bitcoin rule > that allowed a single anyone-can-spend output. Seems like we didn't get > that. Hmm? If you have a CSV lock, it can’t be used for carve-out/CPFP period. I don’t see why this doesn’t work. We definitely should stick to this. >> * For the keys to use for `to_remote_anchor` and `to_local_anchor`, we=E2= > =80=99d >> like to introduce new addresses that both parties communicate in the >> `open_channel` and `accept_channel` messages. We don=E2=80=99t want to re= > use the >> main commitment output addresses, because those may (at some point) be co= > ld >> storage addresses and the cpfp is likely to happen from a hot wallet. > > This is horribly spammy. At the moment we see ~ one unilateral close > every 3 blocks. Hopefully that will reduce, but there'll always be > some. > >> * Within each version of the commitment transaction, both anchors always >> have equal values and are paid for by the initiator. > > Who pays if they can't afford it? What if they push_msat everything to > the other side? > >> The value of the >> anchors is the dust limit that was negotiated in the `open_channel` or >> `accept_channel` message of the party that publishes the transaction. > > Now initiator has to care about the other side's dust limit, which is > bad. And as accepter I now want this much higher, since I get those > funds instantly. I don't think we gain anything by making this > configurable at all; just pick a number and be done. > > Somewhere between 1000 and 10,000 sat is a good idea. > >> Furthermore, there doesn=E2=80=99t seem to be a compelling reason anymore= > for >> tweaking the keys (new insights into watchtower designs, encrypt by txid). > > That's not correct. This seems more like "forgotten insights" than "new > insights", which isn't surprising how long ago Tadge and I did the > watchtower design (BTW: I was the one who came up with encrypt by > txid for that!). > > There are several design constraints in the original watchtowers: > > 1. A watchtower shouldn't be able to guess the channel history. > 2. ... even if it sees a unilateral tx. > 3. ... even if it sees a revoked unilateral tx it has a penalty for. > 4. A watchtower shouldn't be able to tell if it's being used for both > parties in the same channel. > > If you don't rotate keys, a watchtower can brute-force the HTLCs for all > previous transactions it was told about, and previous channel balances. > > We removed key rotation on the to-remote output because you can simply > not tell the watchtower about txs which don't have anything but an > output to you. > > Here are the options I see: > > 1. Abandon privacy from watchtowers and don't rotate keys. Watchtowers > will be able to brute-force your history if they see a unilateral > close. > > 2. Remove HTLC output key rotation, and assume watchtowers don't handle > HTLCs (so you don't tell them about early txs where the peer has no > output but there are HTLCs pending). This seems less useful, since > HTLC txs require metadata anyway. > > 3. Change to-local key rotation to use BIP32 (unhardened). We could > also take some of the 48 bits (maybe 24?) we currently use to encode > the commitment number, to encode a BIP32 sub-path for this channel. > This would make it easier for hardware wallets to reconstruct. > > Cheers, > Rusty. > ___ > 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] asynchronous Lightning network payments
Hello Konstantin, In asynchronous payments we want to be sure that there are only two states: 1) Before B received the payment. 2) After B received the payment. In state 1), we want A to still have the control of the amount, and at the same time we want to let B decide (until a certain timeout) to receive the payment. In this state, S can only help B to be paid, or cancel the whole transfer, but in this case, A cannot lose the amount. In state 2), we want to be sure that no money is lost by S (and consequently that the amount in A wallet is decremented by amt). As ZmnSCPxj wrote in https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002260.html (as I understand the last sentences), there is no way to do that without locking the amount. In order to increase the privacy, we are improving the specification to be be able to use several Rod nodes: a list of nodes chosen by the payer and another list by the payee. The Rod nodes are supposed to be almost always online, so standard https can be used to communicate with them and between them. --yas On 29/10/2019 22:46, Konstantin Ketterer wrote: ## Problem Currently, both parties have to be online at the same time to send/ receive money. This can be avoided by using something like the Lightning Rod Protocol by Breez (https://github.com/breez/LightningRod). However, funds have to be locked up longer than usual. We can do better than that. ## Solution The payer A pre-signs a transaction handing over money to their local channel partner S and sends the transaction to the payee B in an end to end encrypted communication channel. B can then sell the signature for the transaction to S using pay-for-signature made possible by payment points and scalars. (https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002077.html) We will be using eltoo because we don't have to worry about toxic channel states. A and S are online, A and S have a channel 1. A contacts S: they commit and exchange the R (= k*G) part of the Schnorr Signature for the update and settlement transaction 2. A and S sign the settlement transaction increasing the balance between them by amt + fee in favor of S and exchange the signatures 3. A signs the corresponding update transaction but does not give it so S 4. A sends the update transaction to B using an end to end encrypted asynchronous communication channel A can go offline B comes online 4. Decrypts the update transaction and sells the signature s to S for amt When A comes back online S gives A the invoice (with the payment point s*G) signed by B, the corresponding scalar s (the signature from A for the update transaction) and signature from S for the update transaction. They can now proceed as normal. In addition to enabling asynchronous payments, this outsources the routing to S. ### Potential issues Privacy S currently knows both the sender and the receiver of the payment. If we split the payment from S to B into two payments between S and a public routing node P and P and B by still using the same scalar + payment point, S now only knows the sender and P only knows the receiver. To further increase privacy we can split the payment multiple times but all nodes involved must support this feature. Locked up capital While B hasn't yet claimed its money, the funds in the channel between A and S are essentially locked up. However, A and S could simply overwrite the payment (new update + settlement transaction), then A could send multiple payments with the remaining balance and before going offline A would do the procedure again. If A has sufficient inbound capacity in other channels it can also re-balance its channel A-S so that the outbound capacity - (amt + fees) in this channel is zero and then do the procedure. Communication channel Obviously, the communication channel must be end to end encrypted otherwise this is highly insecure. Hopefully, we will have a sort of decentralized paid mail server system which is compatible across all LN wallets and part of BOLT. Proof of payment The invoice by B with the payment point s*G and s are not sufficient as a PoP because S can simply give A the invoice a
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
> > > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote` > > output. `to_remote_delay` is the csv delay that the remote party accepted > > in the funding flow for their outputs. This not only ensures that the > > carve-out works as intended, but also removes the incentive to game the > > other party into force-closing. If desired, both parties can still agree > = > to > > have different `to_self_delay` values. > > I think we should unify to_self_delay if we're doing this. Otherwise > the game returns. > The game returns, but both parties will be aware of the game they are playing. They agreed to their peer's to_self_delay up front. (This is different from the current situation where both peers are forced to accept a remote_to_self_delay of 0.) With validation on the open/accept_channel message, a node can still enforce both to_self_delays to be equal. We could simplify this to a single to_self_delay that is proposed by the initiator, but what was the original reason to allow distinct values? > > For the anchor outputs we consider: > > > > * Output type: normal P2WKH. At one point, an additional spending path > was > > proposed that was unconditional except for a 10 block csv lock. The > > intention of this was to prevent utxo set pollution by allowing anyone to > > clean up. This however also opens up the possibility for an attacker to > > 'use up' the cpfp carve-out after those 10 blocks. If the user A is > offli= > ne > > for that period of time, a malicious peer B may already have broadcasted > > the commitment tx and pinned down user A's anchor output with a low fee > > child. That way, the commitment tx could still remain unconfirmed while > an > > important htlc expires. > > Agreed, this doesn't really work. We actually needed a bitcoin rule > that allowed a single anyone-can-spend output. Seems like we didn't get > that. > With the mempool acceptance carve-out in bitcoind 0.19, we indeed won't be able to safely produce a single OP_TRUE output for anyone to spend. An attacker could attach low fee child transactions, reach the limits and block further fee bumping. > * For the keys to use for `to_remote_anchor` and `to_local_anchor`, we=E2= > =80=99d > > like to introduce new addresses that both parties communicate in the > > `open_channel` and `accept_channel` messages. We don=E2=80=99t want to > re= > use the > > main commitment output addresses, because those may (at some point) be > co= > ld > > storage addresses and the cpfp is likely to happen from a hot wallet. > > This is horribly spammy. At the moment we see ~ one unilateral close > every 3 blocks. Hopefully that will reduce, but there'll always be > some. > It seems there isn't another way to do the anchor outputs given the mempool limitations that exist? Each party needs to have their own anchor, protected by a key. Otherwise it would open up these attack scenarios where an attacker blocks the commitment tx confirmation until htlcs time out. Even with the script OP_DEPTH OP_IF OP_CHECKSIG OP_ELSE 10 OP_CSV OP_ENDIF, the "anyones" don't know the pubkey and still can't sweep after 10 blocks. > * Within each version of the commitment transaction, both anchors always > > have equal values and are paid for by the initiator. > > Who pays if they can't afford it? What if they push_msat everything to > the other side? > Similar to how it currently works. There should never be a commitment transaction in which the initiator cannot pay the fee. With anchor outputs there should never be a commitment tx in which the initiator cannot pay the fee and the anchors. Also currently you cannot push everything to the other side with push_msat. The initiator still needs to have enough balance to pay for the on-chain costs (miner fee and anchors). > The value of the > > anchors is the dust limit that was negotiated in the `open_channel` or > > `accept_channel` message of the party that publishes the transaction. > > Now initiator has to care about the other side's dust limit, which is > bad. And as accepter I now want this much higher, since I get those > funds instantly. I don't think we gain anything by making this > configurable at all; just pick a number and be done. > > Somewhere between 1000 and 10,000 sat is a good idea. > Yes, it is free money. Therefore we need to validate the dust limit in the funding flow. Check whether it is reasonable. That should also be done in the current implementation. Otherwise your peer can set a really high dust limit that lets your htlc disappear on-chain (although that is only free money for the miner). If we hard-code a constant, we won't be able to adapt to changes of `dustRelayFee` in the bitcoin network. And we'd also need to deal with a peer picking a value higher than that constant for its regular funding flow dust limit parameter. > There are several design constraints in the original watchtowers: > > 1. A watchtower shouldn't be able to guess the channel history. > 2. ...
Re: [Lightning-dev] asynchronous Lightning network payments
Hi ZmnSCPxj, How does S learn that B has come online? > > Presumably there is some kind of polling involved. > What do you imagine the polling rate to be? > One block? > 100 blocks? > One difficulty adjustment? > One halving period? > I imagined that A somehow send the IP address of S or any information to contact S alongside the transaction and then B would connect to S and request the payment. If it had to be a polling rate I would choose something like 6 blocks. > > Locked up capital > > While B hasn't yet claimed its money, the funds in the channel between A > and S are essentially locked up. However, A and S could simply overwrite > the payment (new update + settlement transaction), then A could send > multiple payments with the remaining balance and before going offline A > would do the procedure again. If A has sufficient inbound capacity in other > channels it can also re-balance its channel A-S so that the outbound > capacity - (amt + fees) in this channel is zero and then do the procedure. > > An issue is when the channel is forced onchain by either A or S. > For example, what if S is attacked by an army of shiny robots which > destroys the keys of S? > (Disclaimer: I do not control, nor have I ever controlled, an army of > shiny robots to take over the world. > Shininess does not increase combat capability, thus not useful property of > robots to have.) > Obviously S can no longer participate in the channel update, thus A *must* > force the channel onchain and execute the contract there. > > Thus, the UTXO for this should be claimable in both a secret-revelation > path and a timeout path, both enforceable onchain, else S could hold the > funds hostage by threatening unilateral close of the channel. > i.e. you still need a PTLC for this. > I don't think I understand what you are trying to say. Because we are using eltoo A can at any point in time publish the trigger transaction, the previous update transaction and the corresponding settlement transaction without any repercussions and recover its money after some amount of time. This essentially allows A to cancel the payment to B until B has claimed the payment from S. Because if S has already paid B and has not lost its keys ( or already signed the new update transaction beforehand) it can double spend the older settlement transaction from A with its newer update and settlement transaction. All in all, A can still force the channel to settle on chain even if S does not cooperate anymore and doesn't tell A about the new update + settlement transaction. Regards Konstantin ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
Joost Jager writes: > We started to look at the `push_me` outputs again. Will refer to them as > `anchor` outputs from now on, to prevent confusion with `push_msat` on the > `open_channel` message. > > The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been > merged and for reasons described earlier in this thread, we now need to a= dd > a csv time lock to every non-anchor output on the commitment transaction. > > To realize this, we are currently considering the following changes: > > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote` > output. `to_remote_delay` is the csv delay that the remote party accepted > in the funding flow for their outputs. This not only ensures that the > carve-out works as intended, but also removes the incentive to game the > other party into force-closing. If desired, both parties can still agree = to > have different `to_self_delay` values. I think we should unify to_self_delay if we're doing this. Otherwise the game returns. > * Add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of > the HTLC outputs. > For the anchor outputs we consider: > > * Output type: normal P2WKH. At one point, an additional spending path was > proposed that was unconditional except for a 10 block csv lock. The > intention of this was to prevent utxo set pollution by allowing anyone to > clean up. This however also opens up the possibility for an attacker to > 'use up' the cpfp carve-out after those 10 blocks. If the user A is offli= ne > for that period of time, a malicious peer B may already have broadcasted > the commitment tx and pinned down user A's anchor output with a low fee > child. That way, the commitment tx could still remain unconfirmed while an > important htlc expires. Agreed, this doesn't really work. We actually needed a bitcoin rule that allowed a single anyone-can-spend output. Seems like we didn't get that. > * For the keys to use for `to_remote_anchor` and `to_local_anchor`, we=E2= =80=99d > like to introduce new addresses that both parties communicate in the > `open_channel` and `accept_channel` messages. We don=E2=80=99t want to re= use the > main commitment output addresses, because those may (at some point) be co= ld > storage addresses and the cpfp is likely to happen from a hot wallet. This is horribly spammy. At the moment we see ~ one unilateral close every 3 blocks. Hopefully that will reduce, but there'll always be some. > * Within each version of the commitment transaction, both anchors always > have equal values and are paid for by the initiator. Who pays if they can't afford it? What if they push_msat everything to the other side? > The value of the > anchors is the dust limit that was negotiated in the `open_channel` or > `accept_channel` message of the party that publishes the transaction. Now initiator has to care about the other side's dust limit, which is bad. And as accepter I now want this much higher, since I get those funds instantly. I don't think we gain anything by making this configurable at all; just pick a number and be done. Somewhere between 1000 and 10,000 sat is a good idea. > Furthermore, there doesn=E2=80=99t seem to be a compelling reason anymore= for > tweaking the keys (new insights into watchtower designs, encrypt by txid). That's not correct. This seems more like "forgotten insights" than "new insights", which isn't surprising how long ago Tadge and I did the watchtower design (BTW: I was the one who came up with encrypt by txid for that!). There are several design constraints in the original watchtowers: 1. A watchtower shouldn't be able to guess the channel history. 2. ... even if it sees a unilateral tx. 3. ... even if it sees a revoked unilateral tx it has a penalty for. 4. A watchtower shouldn't be able to tell if it's being used for both parties in the same channel. If you don't rotate keys, a watchtower can brute-force the HTLCs for all previous transactions it was told about, and previous channel balances. We removed key rotation on the to-remote output because you can simply not tell the watchtower about txs which don't have anything but an output to you. Here are the options I see: 1. Abandon privacy from watchtowers and don't rotate keys. Watchtowers will be able to brute-force your history if they see a unilateral close. 2. Remove HTLC output key rotation, and assume watchtowers don't handle HTLCs (so you don't tell them about early txs where the peer has no output but there are HTLCs pending). This seems less useful, since HTLC txs require metadata anyway. 3. Change to-local key rotation to use BIP32 (unhardened). We could also take some of the 48 bits (maybe 24?) we currently use to encode the commitment number, to encode a BIP32 sub-path for this channel. This would make it easier for hardware wallets to reconstruct. Cheers, Rusty. ___ Lightning-dev mailing list Li
Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
On Mon, Oct 28, 2019 at 6:16 PM David A. Harding wrote: > A parent transaction near the limit of 100,000 vbytes could have almost > 10,000 outputs paying OP_TRUE (10 vbytes per output). If the children > were limited to 10,000 vbytes each (the current max carve-out size), > that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger > than the default maximum mempool size in Bitcoin Core). > Thanks, Dave, I wasn't aware the limits would allow this many outputs. And as your calculation shows, this opens up the potential for free relay of large amounts of data. We could start special casing to only allow this for "LN commitment-like" transactions, but this would be application specific changes, and your calculation shows that even with the BOLT2 numbers there still exists cases with a large number of children. We are moving forward with adding a 1 block delay to all outputs to utilize the current carve-out rule, and the changes aren't that bad. See Joost's post in "[PATCH] First draft of option_simplfied_commitment" - Johan ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
