Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
> > By my calculations, at minfee it will cost you ~94 satoshis to spend. > Dust limit is 294 for Segwit outputs (basically assuming 3x minfee). > > So I'm actually happy to say "anchor outputs are 294 satoshi". These > are simply spendable, and still only $3 each if BTC is $1M. Lower is > better (as long as we stick with funder-pays), as long as they do > eventually get spent. > Quick note here: the anchor outputs are P2WSH and for those the default dust limit is 330 satoshis. Joost ___ 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
On Thu, Nov 14, 2019 at 10:56:05AM +0100, Joost Jager wrote: > Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is > `dustRelayFee` really never going to change? It even is a (hidden) cmd line > parameter that can be set easily. > > If the fee market would rise and stay high for an extended period of time, > why wouldn't people use this flag to raise the dust relay fee? If feerates are reliably high, then there's less need for the dust limit and I wouldn't expect it to be increased. The dust limit exists to prevent people from filling the UTXO set with non-economical UTXOs when feerates are low. For example, at the current minimum relay fee of 1 sat/vbyte and price of $8,500 USD/BTC, the cost to create a zero-value[1] P2WPKH output is about 30 vbytes = 30 sat = $0.0025 (1/4 cent). The current UTXO set has about 64 million entries, so the cost to double its size would be $160,000---a tidy sum, but probably less than some people spend spreading anti-Bitcoin propaganda on a regular basis. The dust limit helps prevent that by making the minimum cost per created P2WPKH UTXO 30 sat + 294 sat = $0.0275, or about $1,760,000 per UTXO set doubling. If feerates increase, the cost of a UTXO-filling attack rises proportionally. Somewhere around sustained minimum feerates of 11 sat/vbyte, feerates alone become more expensive than the current level of protection provided by the dust limit at 1 sat/vbyte. Additionally, it's worth noting that the dust limit is not incentive-aligned with short-term miner interests. If there's actual legitimate demand to create transactions paying reasonable feerates and containing uneconomical-to-spend outputs, then miners are going to start accepting those transactions no matter what policies are implemented on the P2P transaction relay network. In short, I don't expect dust limits to rise unless the BTC/fiat price drops so far that UTXO-filling attacks become much more affordable than they are with today's limits. Dust limits may instead decrease (or be removed), but I don't think that's a problem for anchor outputs. That said, I think it'd be a nice thing for LN implementations to strive to create anchor outputs that are economical to spend and that may require using a negotiable output amount to compensate for rises in feerates making small-value outputs less economical, especially if you're using different anchor outputs for each channel party. -Dave [1] I believe consensus rules allow creating zero-value outputs. If not, making this a 1 sat output doesn't significantly change any calculations. P.S. Perhaps see also Gregory Maxwell's take: > I suspect that if feerates hadn't tanked after the introduction of > segwit, implementations probably would have removed the dust limit > policy rules in any case: they're a kludge that compensates for fees > being too low to dissuade various antisocial behaviors like spamming > for advertising purposes or de-anonymizing users and don't serve much > purpose if feerates are consistently high enough to discourage these > attacks. Source: https://bitcoin.stackexchange.com/a/85696/21052 ___ 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
Regarding the dust relay limit, there may be a little bit of a misunderstanding as to a few important details. The purpose of it (much like the dust output values in the anchor outputs) is to discourage outputs which are not ever economically spendable, not short-term uneconomically spendable. This value is, thus, *not* connected to the mempool's min relay fee (except for the purposes of calculating the constant, which may be part of the disconnect here). The min relay fee represents a short-term DoS limit, and, thus, can float wildly (though, since 2017, and even in general, we largely have not seen it go up much in absolute value at all). Further, and, critically, there are a number of issues with *any* policy change that makes several bits of the P2P network less efficient, and, thus, they are generally avoided where possible. These include, compact block relay, feerate estimation, relay-DoS-resistance, etc. While none of this is to say that the dust limit will *never* change, I really don't think its unreasonable to hard code it - there's no pressure *to* change it, and if there's an additional reason not to (ie that deployed software relies on that value, which other software, more than lightning already does), then it almost certainly wont be. Matt On 11/14/19 9:56 AM, Joost Jager wrote: >> So then because unilateral close is the only way to resolve atm, it is >> correct also in theory that there will never be a commitment tx >where the >> non-initiator pays fees? But the point is clear, channels can get >stuck. > >Yeah. Generally, it doesn't happen because we insist on a reasonable >balance in the channel, but it's theoretically possible. > > > Ok, summarizing just for clarity: > > - there will never be a commitment tx where the non-initiator pays fees > - generally a unilateral close doesn't happen because we insist on a > reasonable > balance in the channel > > 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. >>> Note that we can't adapt to dustRelayFee *today*, since we can't >change >>> it after funding (another thing we probably need to fix). >> You can't for an existing channel, but at least for a new channel >you can >> pick a different value. Which wouldn't be possible if we'd put a fixed >> (anchor) amount in the spec. > >That's not really much consolation though for the existing network. > >Still Matt assures me that the relay dust limit is not going to change, >so I think we're best off cutting down our test matrix by choosing a >value and putting it directly into the spec. > >By my calculations, at minfee it will cost you ~94 satoshis to spend. >Dust limit is 294 for Segwit outputs (basically assuming 3x minfee). > >So I'm actually happy to say "anchor outputs are 294 satoshi". These >are simply spendable, and still only $3 each if BTC is $1M. Lower is >better (as long as we stick with funder-pays), as long as they do >eventually get spent. > > > Looking at https://github.com/bitcoin/bitcoin/commit/9022aa3, is > `dustRelayFee` really never going to change? It even is a (hidden) cmd > line parameter that can be set easily. > > If the fee market would rise and stay high for an extended period of > time, why wouldn't people use this flag to raise the dust relay fee? If > we then have our hard coded 294 sat anchors, no force close transactions > can be broadcast anymore. It would be risky to open new channels at that > point, because they can only be coop closed. > > Maybe Lightning is relevant enough by that time to keep people from > touching `dustRelayFee`, but what if not? The fix at that point would be > to introduce a new commitment format, which given our process takes a > long time. > > I'd think that having at least an option to adapt to `dustRelayFee` > changes for new channels makes Lightning more robust. The two options > that I know of are: > > - Reuse `dust_limit_satoshis` on the `open_channel`/`accept_channel` > messages as the anchor size. This ignores that an anchor does not need > to be net positive after sweeping (because it's purpose is to get the > commit tx confirmed), while we generally do want htlcs to be net > positive. It may however be not such a big deal in practice. Suppose > we'd just set this to 294 sat to get the desired anchor output value > (and make it a soft requirement for channel acceptance). The worst that > can happen is that there is a force close with one or more pending htlcs > that aren't economical to sweep. Which can happen anyway because this is > a channel open parameter and it is impossible to know what is economical > for the lifetime of the channel. Instead of burning to fees, the htlc > output will sit there waiting for fees to
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
Joost Jager writes: >> >> > 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? >> >> Because I didn't fight hard enough for simplicity :( >> > > But the people you were fighting with, what reason did they have? Just > flexibility in general, or was there an actual use case? Maybe these people > are reading this email and can comment? Compromise among the committee meant adding everything to the spec if there was a conceivable reason for it; the simplicity argument was less strong then (maybe because we hadn't implemented it all yet!). > So then because unilateral close is the only way to resolve atm, it is > correct also in theory that there will never be a commitment tx where the > non-initiator pays fees? But the point is clear, channels can get stuck. Yeah. Generally, it doesn't happen because we insist on a reasonable balance in the channel, but it's theoretically possible. >> > 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. >> >> Note that we can't adapt to dustRelayFee *today*, since we can't change >> it after funding (another thing we probably need to fix). >> > > You can't for an existing channel, but at least for a new channel you can > pick a different value. Which wouldn't be possible if we'd put a fixed > (anchor) amount in the spec. That's not really much consolation though for the existing network. Still Matt assures me that the relay dust limit is not going to change, so I think we're best off cutting down our test matrix by choosing a value and putting it directly into the spec. By my calculations, at minfee it will cost you ~94 satoshis to spend. Dust limit is 294 for Segwit outputs (basically assuming 3x minfee). So I'm actually happy to say "anchor outputs are 294 satoshi". These are simply spendable, and still only $3 each if BTC is $1M. Lower is better (as long as we stick with funder-pays), as long as they do eventually get spent. >> If we really want to make it adjustable, could we make each side pay for >> its own; if you can't afford it, you don't get one? There's no point >> the funder paying for a fundee-anchor if the fundee has no skin in the >> game. >> >> That reduces the pressure somewhat, I think? >> > > If you can't afford you don't get one, not sure about that. I could open a > channel, send out the total capacity an in htlc to myself via some other > hops, force close with a very low commit fee, then pull in the htlc (one > time the money). The victim then needs to get the commit confirmed to claim > the money, but there is no anchor unfortunately. I wait for the htlc to > expire, then anchor down the commit tx and time out the htlc (twice the > money). Excellent point. And the complexity of some "you can only use a little bit of capacity until I have an anchor too" is worse, so let's stick with your proposal as the simplest: funder pays for two, always. >> Or what about we rotate the anchors and nothing else, which (assuming we >> make it anyone-can-spend-after-N-blocks) reduces the amount of onchain >> spam if someone completely loses their keys? >> >> That's a bigger change, but maybe it's worth it? > We now have David's great proposal to reuse the funding keys for the anchor > output. That allows us to always let anyone spend after confirmation, > because they can reconstruct the spend script. But I think this also means > that we cannot do rotation on the anchor keys. We need to use the funding > pubkey as is. I missed that proposal, thanks! It's stronger than my scheme, in that it works even if neither anchor is spent; which, if we keep update_fee, is a distinct possibility. And makes the script shorter (my fee calc above assume this). We *could* tweak both anchors by the same amount, but then you'd still need to see one of them to spend the other. Cheers, Rusty. ___ 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
> > > 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? > > Because I didn't fight hard enough for simplicity :( > But the people you were fighting with, what reason did they have? Just flexibility in general, or was there an actual use case? Maybe these people are reading this email and can comment? There is no "negotiation" on opening; it's accept or error. That leads > to a situation where every implementation MUST accept what every > implementation offers. > Agreed that the verb negotiate is a bit misleading. Although the open/accept sequence could be repeated several times to make it more of a negotiation. > The unification proposal was to use the max of the two settings. That's > fair; if you want me to suffer a 2 week delay, you should too. > Yes, we could do that as part of this new commitment format. Make that an implicit consequence of `option_anchor_outputs` (or whatever its name will be). The semantics need to change anyway, because we want that CSV lock on every output. > >> * 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. > > Unfortunately, this is not correct (in theory). > > We can always get into a case where fees are insufficient (simultanous > HTLC adds), but it's unusual. We used to specify that the non-funder > would pay the remaining fee, but we dropped this in favor of allow > unilateral close if this ever happened. > So then because unilateral close is the only way to resolve atm, it is correct also in theory that there will never be a commitment tx where the non-initiator pays fees? But the point is clear, channels can get stuck. > > With anchor outputs > > there should never be a commitment tx in which the initiator cannot pay > the > > fee and the anchors. > > There can be, but I think we can simply modify this so you have to pay > the anchors *first* before fees. > That way it seems that adding the anchors doesn't make the stuck channel problem that you described above worse? > > 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. > > Note that we can't adapt to dustRelayFee *today*, since we can't change > it after funding (another thing we probably need to fix). > You can't for an existing channel, but at least for a new channel you can pick a different value. Which wouldn't be possible if we'd put a fixed (anchor) amount in the spec. > If we really want to make it adjustable, could we make each side pay for > its own; if you can't afford it, you don't get one? There's no point > the funder paying for a fundee-anchor if the fundee has no skin in the > game. > > That reduces the pressure somewhat, I think? > If you can't afford you don't get one, not sure about that. I could open a channel, send out the total capacity an in htlc to myself via some other hops, force close with a very low commit fee, then pull in the htlc (one time the money). The victim then needs to get the commit confirmed to claim the money, but there is no anchor unfortunately. I wait for the htlc to expire, then anchor down the commit tx and time out the htlc (twice the money). > > In the light of this forgotten insight, is there a reason why the anchor > > output would need key rotation? Having no rotation makes it easier to let > > those anchors go straight into the wallet, which may mitigate the dust > utxo > > problem a bit. At least then they can be easily coin-selected for any > > on-chain spent, if the market fees are low enough. > > Or what about we rotate the anchors and nothing else, which (assuming we > make it anyone-can-spend-after-N-blocks) reduces the amount of onchain > spam if someone completely loses their keys? > > That's a bigger change, but maybe it's worth it? > We now have David's great proposal to reuse the funding keys for the anchor output. That allows us to always let anyone spend after confirmation, because they can reconstruct the spend script. But I think this also means that we cannot do rotation on the anchor keys. We need to use the funding pubkey as is. Joost ___ 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: >> >> > * 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? Because I didn't fight hard enough for simplicity :( There is no "negotiation" on opening; it's accept or error. That leads to a situation where every implementation MUST accept what every implementation offers. The unification proposal was to use the max of the two settings. That's fair; if you want me to suffer a 2 week delay, you should too. >> 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. Indeed :( >> 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. I think you're right, but I don't *like* it... >> * 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. Unfortunately, this is not correct (in theory). We can always get into a case where fees are insufficient (simultanous HTLC adds), but it's unusual. We used to specify that the non-funder would pay the remaining fee, but we dropped this in favor of allow unilateral close if this ever happened. > With anchor outputs > there should never be a commitment tx in which the initiator cannot pay the > fee and the anchors. There can be, but I think we can simply modify this so you have to pay the anchors *first* before fees. > 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). This is true; I forgot we fixed that, sorry. push_msat is a red herring. >> 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). True, and spec should note this BTW! I've added an issue. https://github.com/lightningnetwork/lightning-rfc/issues/696 > 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. Note that we can't adapt to dustRelayFee *today*, since we can't change it after funding (another thing we probably need to
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
Matt Corallo writes: > 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). The original design IIRC was a single anyone-can-spend anchor output. If we need two anchor outputs, and want the other to turn into an anyone-can-spend after it's mined, it's possible by gratuitously mentioning the other key in the script, I think: # If they provide a signature, they can push this: OP_DEPTH OP_IF OP_CHECKSIG OP_ELSE # Reveal the other key so you can spend the other anchor, too. OP_DROP # Now, anyone can spend after 1 block. 1 OP_CHECKSEQUENCEVERIFY OP_TRUE OP_ENDIF The other anchor output reverses and . Cheers, Rusty. ___ 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
> > 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. > Ok, so this is always possible because the commitment transaction is signaling opt-in rbf and therefore any child txes are too? From bip125: "Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed." But yes, it can get unnecessarily expensive to replace everything that the attacker added. > 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). > What script would this be exactly? While still unconfirmed, the anchor needs to be protected from being spent by anyone for the carve-out to work. This also means that anyone spending after the csv needs to know that script too. But how can they know if there is something like a pubkey (that protected it during the unconfirmed phase) in it? Joost. ___ 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
(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
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] [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
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
> > * 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 offline > 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. > Ok, this 'attack' scenario doesn't make sense. Of course with a csv lock, this spend path is closed when the commitment tx is unconfirmed. But it is still a question whether user A would appreciate their anchor output being taken by someone else when they are offline for more than 10 blocks. If we do like this utxo set clean up path, one could also argue that this should then be applied to every near-dust output on the commitment tx (eg small htlcs). ___ 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
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 add 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. * 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 offline 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. * For the keys to use for `to_remote_anchor` and `to_local_anchor`, we’d like to introduce new addresses that both parties communicate in the `open_channel` and `accept_channel` messages. We don’t want to reuse the main commitment output addresses, because those may (at some point) be cold storage addresses and the cpfp is likely to happen from a hot wallet. * Within each version of the commitment transaction, both anchors always have equal values and are paid for by the initiator. 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. It means that the definitive balance of an endpoint is dependent on which version of the commitment transaction confirms. This however is nothing new. In the current commitment format, there are always two or three valid versions of the commitment transaction (local, remote and sometimes the not yet revoked previous remote tx) which can have slightly different balances. For the initiator, it is important to validate the other party's dust limit. The initiator pays for it and doesn't want to give away more free money than necessary. Furthermore, there doesn’t seem to be a compelling reason anymore for tweaking the keys (new insights into watchtower designs, encrypt by txid). Therefore we think we can remove them entirely in this new commitment format and require less channel state data to sweep the outputs. Joost On Wed, Nov 21, 2018 at 3:17 AM Rusty Russell wrote: > I'm also starting to implement this, to see what I missed! > > Original at https://github.com/lightningnetwork/lightning-rfc/pull/513 > > Pasted here for your reading convenience: > > - Option is sticky; it set at open time, it stays with channel > - I didn't want to have to handle penalty txs on channels which switch > - We could, however, upgrade on splice. > - Feerate is fixed at 253 > - `feerate_per_kw` is still in open /accept (just ignored): multifund > may want it. > - closing tx negotiates *upwards* not *downwards* > - Starting from base fee of commitment tx = 282 satoshi. > - to_remote output is always CSV delayed. > - pushme outputs are paid for by funder, but only exist if the matching > to_local/remote output exists. > - After 10 blocks, they become anyone-can-spend (they need to see the > to-local/remote witness script though). > - remotepubkey is not rotated. > - You must spend your pushme output; you may sweep for others. > > Signed-off-by: Rusty Russell > > diff --git a/02-peer-protocol.md b/02-peer-protocol.md > index 7cf9ebf..6ec1155 100644 > --- a/02-peer-protocol.md > +++ b/02-peer-protocol.md > @@ -133,7 +133,9 @@ node can offer. > (i.e. 1/4 the more normally-used 'satoshi per 1000 vbytes') that this > side will pay for commitment and HTLC transactions, as described in > [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted > -later with an `update_fee` message). > +later with an `update_fee` message). Note that if > +`option_simplified_commitment` is negotiated, this `feerate_per_kw` > +is treated as 253 for all transactions. > > `to_self_delay` is the number of blocks that the other node's to-self > outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this > @@ -208,7 +210,8 @@ The receiving node MUST fail the channel if: >- `push_msat` is greater than
Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment
For the low low cost of 3 witness bytes, I think the simplification of analysis/separation of concerns is worth it, though I agree it is probably not strictly required. On 11/26/18 3:12 AM, Rusty Russell wrote: Matt Corallo writes: Hmm, are we willing to consider CLTV sufficient? In case you have two HTLCs, one of medium-small value that has a low CLTV and one of high value that has a higher CLTV, you could potentially use the soon-CLTV to delay the commitment transaction somewhat further if you broadcast it right as the sooner HTLC expires. I think you haven't got the commitment tx onchain by the time the HTLC expires, you're already in trouble. But since there's no script length difference, it *is* simpler to prepend `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the start of each script. Cheers, Rusty. ___ 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
Matt Corallo writes: > Hmm, are we willing to consider CLTV sufficient? In case you have two > HTLCs, one of medium-small value that has a low CLTV and one of high > value that has a higher CLTV, you could potentially use the soon-CLTV to > delay the commitment transaction somewhat further if you broadcast it > right as the sooner HTLC expires. I think you haven't got the commitment tx onchain by the time the HTLC expires, you're already in trouble. But since there's no script length difference, it *is* simpler to prepend `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the start of each script. Cheers, Rusty. ___ 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
Indeed, this change assumes (a) the change in relay policy around CPFP that is discussed on this thread, and (b) some kind of (at least very basic) package relay in Bitcoin Core. (a) requires some discussion, but people seem at least not entirely against it when I've discussed it with people, and should be easy to implement, (b) requires a bunch more work, but has been a longstanding goal for a while. Matt On 11/25/18 6:47 PM, David A. Harding wrote: On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote: I'm also starting to implement this, to see what I missed! - Feerate is fixed at 253 [satoshis per 1,000 weight] IIUC, this is just over Bitcoin Core's default minimum relay fee of 0.1000 BTC/vByte. That works right now, as mempools are nowhere near full, but if they fill up again and the BIP133 feefilters are increased by any amount, nodes will no longer relay transactions with minimum feerates. In that case, how does the commitment transaction get relayed in order for its `to_*_pushme` outputs to be spent for CPFP fee bumping?[1] There's currently some text in the PR about using sighash_single|sighash_anyonecanpay for use with RBF, but I don't think that can apply to spending the commitment transaction, as that would allow not just adding new inputs and outputs, but also removing all but the 'singled' output (allowing theft of its value). -Dave [1] I don't think Bitcoin Core currently relays transaction packages consisting of parents below the relay fee limit and children sufficiently above the limit to pay for their parents. This has certainly been discussed, so maybe I'm wrong and it is available or maybe it'll be available in the future. ___ 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] [PATCH] First draft of option_simplfied_commitment
On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote: > I'm also starting to implement this, to see what I missed! > > - Feerate is fixed at 253 [satoshis per 1,000 weight] IIUC, this is just over Bitcoin Core's default minimum relay fee of 0.1000 BTC/vByte. That works right now, as mempools are nowhere near full, but if they fill up again and the BIP133 feefilters are increased by any amount, nodes will no longer relay transactions with minimum feerates. In that case, how does the commitment transaction get relayed in order for its `to_*_pushme` outputs to be spent for CPFP fee bumping?[1] There's currently some text in the PR about using sighash_single|sighash_anyonecanpay for use with RBF, but I don't think that can apply to spending the commitment transaction, as that would allow not just adding new inputs and outputs, but also removing all but the 'singled' output (allowing theft of its value). -Dave [1] I don't think Bitcoin Core currently relays transaction packages consisting of parents below the relay fee limit and children sufficiently above the limit to pay for their parents. This has certainly been discussed, so maybe I'm wrong and it is available or maybe it'll be available in the future. signature.asc Description: PGP signature ___ 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
Matt Corallo writes: > Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(. OK, let's walk through this: Locally offered HTLC: - Local HTLC-Timeout tx is CLTV delayed, but remote can fulfill without delay. Remote offered HTLC: - Local HTLC-Success tx can be done without delay, but remote timeout is CLTV. IOW: - HTLC output scripts get a `1 OP_CSV OP_DROP` in the non-revoked branch: OP_DUP OP_HASH160 OP_EQUAL OP_IF OP_CHECKSIG OP_ELSE + 1 OP_CHECKSEQUENCEVERIFY OP_DROP ... - HTLC-Success tx needs nSequence = 1. - Similarly any self-generated fulfullment tx needs nSequence = 1. Yech. I still want a new RBF rule where if you pay twice the current package *feerate* your tx is accepted, overriding RBF rules 3, 4 & 5. Probably need to increase the effective minrelay feerate for any txs adding to that package, similarly (using that double-previous-package-feerate). That would mean we're back to a single P2WSH(OP_TRUE) with less blockchain spam, and life is simple. But I'll debate this on bitcoin-dev :) Cheers, Rusty. ___ 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
Not sure if others already realized this, but in thinking about our RBF policy hack from Adelaide a bit more, to allow the carve-out exception of "last tx in a package, which has only one unconfirmed ancestor" to always be available for the "honest party" when broadcasting a commitment transaction, we also need at least a CSV delay of 1 block on the HTLC transaction outputs (as otherwise those transactions could count as the carve-out tx). Matt On 11/21/18 2:17 AM, Rusty Russell wrote: I'm also starting to implement this, to see what I missed! Original at https://github.com/lightningnetwork/lightning-rfc/pull/513 Pasted here for your reading convenience: - Option is sticky; it set at open time, it stays with channel - I didn't want to have to handle penalty txs on channels which switch - We could, however, upgrade on splice. - Feerate is fixed at 253 - `feerate_per_kw` is still in open /accept (just ignored): multifund may want it. - closing tx negotiates *upwards* not *downwards* - Starting from base fee of commitment tx = 282 satoshi. - to_remote output is always CSV delayed. - pushme outputs are paid for by funder, but only exist if the matching to_local/remote output exists. - After 10 blocks, they become anyone-can-spend (they need to see the to-local/remote witness script though). - remotepubkey is not rotated. - You must spend your pushme output; you may sweep for others. Signed-off-by: Rusty Russell diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 7cf9ebf..6ec1155 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -133,7 +133,9 @@ node can offer. (i.e. 1/4 the more normally-used 'satoshi per 1000 vbytes') that this side will pay for commitment and HTLC transactions, as described in [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted -later with an `update_fee` message). +later with an `update_fee` message). Note that if +`option_simplified_commitment` is negotiated, this `feerate_per_kw` +is treated as 253 for all transactions. `to_self_delay` is the number of blocks that the other node's to-self outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this @@ -208,7 +210,8 @@ The receiving node MUST fail the channel if: - `push_msat` is greater than `funding_satoshis` * 1000. - `to_self_delay` is unreasonably large. - `max_accepted_htlcs` is greater than 483. - - it considers `feerate_per_kw` too small for timely processing or unreasonably large. + - if `option_simplified_commitment` is not negotiated: +- it considers `feerate_per_kw` too small for timely processing or unreasonably large. - `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, or `delayed_payment_basepoint` are not valid DER-encoded compressed secp256k1 pubkeys. - `dust_limit_satoshis` is greater than `channel_reserve_satoshis`. @@ -228,7 +231,7 @@ The *channel reserve* is specified by the peer's `channel_reserve_satoshis`: 1% The sender can unconditionally give initial funds to the receiver using a non-zero `push_msat`, but even in this case we ensure that the funder has sufficient remaining funds to pay fees and that one side has some amount it can spend (which also implies there is at least one non-dust output). Note that, like any other on-chain transaction, this payment is not certain until the funding transaction has been confirmed sufficiently (with a danger of double-spend until this occurs) and may require a separate method to prove payment via on-chain confirmation. -The `feerate_per_kw` is generally only of concern to the sender (who pays the fees), but there is also the fee rate paid by HTLC transactions; thus, unreasonably large fee rates can also penalize the recipient. +The `feerate_per_kw` is generally only of concern to the sender (who pays the fees), but there is also the fee rate paid by HTLC transactions; thus, unreasonably large fee rates can also penalize the recipient. It is ignored for `option_simplified_commitment`. Separating the `htlc_basepoint` from the `payment_basepoint` improves security: a node needs the secret associated with the `htlc_basepoint` to produce HTLC signatures for the protocol, but the secret for the `payment_basepoint` can be in cold storage. @@ -340,6 +343,12 @@ This message introduces the `channel_id` to identify the channel. It's derived f Requirements +Both peers: + - if `option_simplified_commitment` was negotiated: +- `option_simplified_commitment` applies to all commitment and HTLC transactions + - otherwise: +- `option_simplified_commitment` does not apply to any commitment or HTLC transactions + The sender MUST set: - `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created` message. - `signature` to the valid signature, using its `funding_pubkey` for the initial commitment transaction, as defined in [BOLT
[Lightning-dev] [PATCH] First draft of option_simplfied_commitment
I'm also starting to implement this, to see what I missed! Original at https://github.com/lightningnetwork/lightning-rfc/pull/513 Pasted here for your reading convenience: - Option is sticky; it set at open time, it stays with channel - I didn't want to have to handle penalty txs on channels which switch - We could, however, upgrade on splice. - Feerate is fixed at 253 - `feerate_per_kw` is still in open /accept (just ignored): multifund may want it. - closing tx negotiates *upwards* not *downwards* - Starting from base fee of commitment tx = 282 satoshi. - to_remote output is always CSV delayed. - pushme outputs are paid for by funder, but only exist if the matching to_local/remote output exists. - After 10 blocks, they become anyone-can-spend (they need to see the to-local/remote witness script though). - remotepubkey is not rotated. - You must spend your pushme output; you may sweep for others. Signed-off-by: Rusty Russell diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 7cf9ebf..6ec1155 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -133,7 +133,9 @@ node can offer. (i.e. 1/4 the more normally-used 'satoshi per 1000 vbytes') that this side will pay for commitment and HTLC transactions, as described in [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted -later with an `update_fee` message). +later with an `update_fee` message). Note that if +`option_simplified_commitment` is negotiated, this `feerate_per_kw` +is treated as 253 for all transactions. `to_self_delay` is the number of blocks that the other node's to-self outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this @@ -208,7 +210,8 @@ The receiving node MUST fail the channel if: - `push_msat` is greater than `funding_satoshis` * 1000. - `to_self_delay` is unreasonably large. - `max_accepted_htlcs` is greater than 483. - - it considers `feerate_per_kw` too small for timely processing or unreasonably large. + - if `option_simplified_commitment` is not negotiated: +- it considers `feerate_per_kw` too small for timely processing or unreasonably large. - `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, or `delayed_payment_basepoint` are not valid DER-encoded compressed secp256k1 pubkeys. - `dust_limit_satoshis` is greater than `channel_reserve_satoshis`. @@ -228,7 +231,7 @@ The *channel reserve* is specified by the peer's `channel_reserve_satoshis`: 1% The sender can unconditionally give initial funds to the receiver using a non-zero `push_msat`, but even in this case we ensure that the funder has sufficient remaining funds to pay fees and that one side has some amount it can spend (which also implies there is at least one non-dust output). Note that, like any other on-chain transaction, this payment is not certain until the funding transaction has been confirmed sufficiently (with a danger of double-spend until this occurs) and may require a separate method to prove payment via on-chain confirmation. -The `feerate_per_kw` is generally only of concern to the sender (who pays the fees), but there is also the fee rate paid by HTLC transactions; thus, unreasonably large fee rates can also penalize the recipient. +The `feerate_per_kw` is generally only of concern to the sender (who pays the fees), but there is also the fee rate paid by HTLC transactions; thus, unreasonably large fee rates can also penalize the recipient. It is ignored for `option_simplified_commitment`. Separating the `htlc_basepoint` from the `payment_basepoint` improves security: a node needs the secret associated with the `htlc_basepoint` to produce HTLC signatures for the protocol, but the secret for the `payment_basepoint` can be in cold storage. @@ -340,6 +343,12 @@ This message introduces the `channel_id` to identify the channel. It's derived f Requirements +Both peers: + - if `option_simplified_commitment` was negotiated: +- `option_simplified_commitment` applies to all commitment and HTLC transactions + - otherwise: +- `option_simplified_commitment` does not apply to any commitment or HTLC transactions + The sender MUST set: - `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created` message. - `signature` to the valid signature, using its `funding_pubkey` for the initial commitment transaction, as defined in [BOLT #3](03-transactions.md#commitment-transaction). @@ -351,6 +360,12 @@ The recipient: - on receipt of a valid `funding_signed`: - SHOULD broadcast the funding transaction. + Rationale + +We decide on `option_simplified_commitment` at this point when we first have to generate the commitment +transaction. Even if a later reconnection does not negotiate this parameter, this channel will honor it. +This simplifies channel state, particularly penalty transaction handling. + ### The `funding_locked` Message
