Re: [Lightning-dev] Splice Pinning Prevention w/o Anchors
I quickly looked it up and it seems that bitcoind has a function PaysMoreThanConflicts which checks that the tx pays a higher feerate than the replaced tx. This isn't a BIP125 rule AFAICT so I think that's what tripped me up. That means I'm wrong about the ancestor bulking variant as a malicious counterparty can put a high feerate splice tx at the bottom of the mempool, requiring a higher feerate to replace it. On Wed, Aug 10, 2022 at 12:31 PM Greg Sanders wrote: > Your reading is correct. > > My example was that if TxB, size 100vB with feerate 1000 sat/vbyte, has an > 100kvB ancestor paying 1 sat/vbyte. The effective package rate for those > two transactions will be (100*1,000 + 100,000*1)/(100,000 + 100) = ~2 > sat/vybte > > This means TxB will not be picked up if the prevailing rate is > 2 > sat/byte. Let's say it's 4 sat/vbyte prevailing rate. To replace it with > TxB', one still has to pay to evict TxB, at roughly 1000/4=250 times the > normal feerate. > > Sorry if I got the math wrong here, but at least trying to get the idea > across. > > On Wed, Aug 10, 2022 at 12:20 PM Eugene Siegel wrote: > >> Looking it up, rule 3 is "The replacement transaction pays an absolute >> fee of at least the sum paid by the original transactions." but here the >> ancestors aren't getting replaced so I don't think the replacement has to >> pay for them? Or maybe your comment was just generally about how it can >> matter in certain cases >> >> On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders >> wrote: >> >>> > I think the ancestor bulking variant of pinning only matters if you >>> are trying to add a new descendant and can't due to the ancestor/descendant >>> limits. >>> >>> Not quite. It also matters if you want to RBF that transaction, since >>> low feerate ancestor junk puts the transaction at the bottom of the >>> mempool, so to speak, even if it has a high feerate itself. You are forced >>> to pay "full freight" to replace it via bip125 rule#3 even though it's not >>> going to be mined. >>> >>> (I don't know if that applies here, just noting the wrinkle) >>> >>> On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel >>> wrote: >>> >>>> Hi, >>>> >>>> I think the ancestor bulking variant of pinning only matters if you are >>>> trying to add a new descendant and can't due to the ancestor/descendant >>>> limits. In this example, since all of the outputs are locked with `1 >>>> OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking >>>> also shouldn't matter for RBF since you wouldn't be replacing any of the >>>> ancestors, only the splice tx. I think it might matter if the new funding >>>> output isn't encumbered. >>>> >>>> The new funding output can't have `1 OP_CSV` unless we also change the >>>> commit tx format, and I'm not sure if it would work. The commit tx has the >>>> disable bit set in nSequence so it isn't compatible with the sequence lock. >>>> Enabling the bit might be tricky since then the commit tx may have a >>>> time-based or block-based locktime based on the lower bits of the obscured >>>> commitment number, and it must be block-based (and non-zero) for the >>>> sequence lock to work. That means if it's not encumbered, pinning exists >>>> since an attacker can make a junk tree using the anchor output. It is >>>> replaceable using RBF since you have your own commit tx (with anchor) to >>>> broadcast. >>>> >>>> Eugene >>>> ___ >>>> 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] Splice Pinning Prevention w/o Anchors
Looking it up, rule 3 is "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions." but here the ancestors aren't getting replaced so I don't think the replacement has to pay for them? Or maybe your comment was just generally about how it can matter in certain cases On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders wrote: > > I think the ancestor bulking variant of pinning only matters if you are > trying to add a new descendant and can't due to the ancestor/descendant > limits. > > Not quite. It also matters if you want to RBF that transaction, since low > feerate ancestor junk puts the transaction at the bottom of the mempool, so > to speak, even if it has a high feerate itself. You are forced to pay "full > freight" to replace it via bip125 rule#3 even though it's not going to be > mined. > > (I don't know if that applies here, just noting the wrinkle) > > On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel wrote: > >> Hi, >> >> I think the ancestor bulking variant of pinning only matters if you are >> trying to add a new descendant and can't due to the ancestor/descendant >> limits. In this example, since all of the outputs are locked with `1 >> OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking >> also shouldn't matter for RBF since you wouldn't be replacing any of the >> ancestors, only the splice tx. I think it might matter if the new funding >> output isn't encumbered. >> >> The new funding output can't have `1 OP_CSV` unless we also change the >> commit tx format, and I'm not sure if it would work. The commit tx has the >> disable bit set in nSequence so it isn't compatible with the sequence lock. >> Enabling the bit might be tricky since then the commit tx may have a >> time-based or block-based locktime based on the lower bits of the obscured >> commitment number, and it must be block-based (and non-zero) for the >> sequence lock to work. That means if it's not encumbered, pinning exists >> since an attacker can make a junk tree using the anchor output. It is >> replaceable using RBF since you have your own commit tx (with anchor) to >> broadcast. >> >> Eugene >> ___ >> 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] Splice Pinning Prevention w/o Anchors
Hi, I think the ancestor bulking variant of pinning only matters if you are trying to add a new descendant and can't due to the ancestor/descendant limits. In this example, since all of the outputs are locked with `1 OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking also shouldn't matter for RBF since you wouldn't be replacing any of the ancestors, only the splice tx. I think it might matter if the new funding output isn't encumbered. The new funding output can't have `1 OP_CSV` unless we also change the commit tx format, and I'm not sure if it would work. The commit tx has the disable bit set in nSequence so it isn't compatible with the sequence lock. Enabling the bit might be tricky since then the commit tx may have a time-based or block-based locktime based on the lower bits of the obscured commitment number, and it must be block-based (and non-zero) for the sequence lock to work. That means if it's not encumbered, pinning exists since an attacker can make a junk tree using the anchor output. It is replaceable using RBF since you have your own commit tx (with anchor) to broadcast. Eugene ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Interesting thing about Offered HTLCs
I'm not familiar with miniscript besides that it's a subset of script - how would it help avoiding an unintended path being taken? On Fri, Mar 11, 2022 at 8:47 AM darosior wrote: > Also, using Miniscript (whether in Segwit v0 or v1) would prevent this > kind of surprises. And many potential others. :-) > > > I'll post something soon about how we could integrate Miniscript in > Lightning. > Original Message > On Mar 10, 2022, 2:55 PM, Eugene Siegel < elzei...@gmail.com> wrote: > > > Yes I think bip342 should solve it. Maybe splitting up all conditionals > into leaves is a good idea for taproot lightning > > On Mon, Mar 7, 2022 at 5:46 PM Antoine Riard > wrote: > >> Hi Eugene, >> >> > Since the remote party gives them a signature, after the timeout, the >> offering party can >> claim with the remote's signature + preimage, but can only spend with the >> HTLC-timeout transaction because of SIGHASH_ALL. >> >> I've not exercised the witness against our test framework though the >> description sounds to me correct. >> >> The offering counterparty spends the offered HTLC output with a >> HTLC-timeout transaction where the witness is < >> >. SIGHASH_ALL is not committing to the spent Script >> branch intended to be used. As you raised, it doesn't alleviate the >> offering counterparty to respect the CLTV delay and as such the offered >> HTLC timespan cannot be shortened. The implication I can think of, in case >> of competing HTLC race, once the absolute timelock is expired, the offering >> counterparty is able to compete against the receiving one with a more >> feerate-efficient witness. However, from a receiving counterparty safety >> viewpoint, if you're already suffering a contest, it means your HTLC-claim >> on your own local commitment transaction inbound HTLC output has been >> inefficient, and your fee-bumping strategy is to blame. >> >> If we think the issue is relevant, I believe splitting the Script >> branches in two tapleaves and having bip342 signature digest committing to >> the tapleaf_hash solves it. >> >> Antoine >> >> Le lun. 7 mars 2022 à 15:27, Eugene Siegel a écrit : >> >>> I'm not sure if this is known, but I'm pretty sure it's benign and so I >>> thought I'd share since I found it interesting and maybe someone else will >>> too. I'm not sure if this is already known either. >>> >>> >>> https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs >>> Offered HTLCs have three claim paths: the revocation case, the offerer >>> claiming through the HTLC-timeout transaction, and the receiver claiming >>> via their sig + preimage. The offering party can claim via the HTLC-timeout >>> case on their commitment transaction with their signature and the remote's >>> signature (SIGHASH_ALL) after the cltv_expiry timeout. Since the remote >>> party gives them a signature, after the timeout, the offering party can >>> claim with the remote's signature + preimage, but can only spend with the >>> HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the >>> remote party doesn't claim it first. I can't think of any cases where the >>> offering party would know the preimage AND want to force close, so that's >>> why I think it's benign. It does make the witness smaller. The same trick >>> isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY. >>> >>> Eugene (Crypt-iQ on github) >>> ___ >>> 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] Interesting thing about Offered HTLCs
Yes I think bip342 should solve it. Maybe splitting up all conditionals into leaves is a good idea for taproot lightning On Mon, Mar 7, 2022 at 5:46 PM Antoine Riard wrote: > Hi Eugene, > > > Since the remote party gives them a signature, after the timeout, the > offering party can > claim with the remote's signature + preimage, but can only spend with the > HTLC-timeout transaction because of SIGHASH_ALL. > > I've not exercised the witness against our test framework though the > description sounds to me correct. > > The offering counterparty spends the offered HTLC output with a > HTLC-timeout transaction where the witness is < > >. SIGHASH_ALL is not committing to the spent Script > branch intended to be used. As you raised, it doesn't alleviate the > offering counterparty to respect the CLTV delay and as such the offered > HTLC timespan cannot be shortened. The implication I can think of, in case > of competing HTLC race, once the absolute timelock is expired, the offering > counterparty is able to compete against the receiving one with a more > feerate-efficient witness. However, from a receiving counterparty safety > viewpoint, if you're already suffering a contest, it means your HTLC-claim > on your own local commitment transaction inbound HTLC output has been > inefficient, and your fee-bumping strategy is to blame. > > If we think the issue is relevant, I believe splitting the Script branches > in two tapleaves and having bip342 signature digest committing to the > tapleaf_hash solves it. > > Antoine > > Le lun. 7 mars 2022 à 15:27, Eugene Siegel a écrit : > >> I'm not sure if this is known, but I'm pretty sure it's benign and so I >> thought I'd share since I found it interesting and maybe someone else will >> too. I'm not sure if this is already known either. >> >> >> https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs >> Offered HTLCs have three claim paths: the revocation case, the offerer >> claiming through the HTLC-timeout transaction, and the receiver claiming >> via their sig + preimage. The offering party can claim via the HTLC-timeout >> case on their commitment transaction with their signature and the remote's >> signature (SIGHASH_ALL) after the cltv_expiry timeout. Since the remote >> party gives them a signature, after the timeout, the offering party can >> claim with the remote's signature + preimage, but can only spend with the >> HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the >> remote party doesn't claim it first. I can't think of any cases where the >> offering party would know the preimage AND want to force close, so that's >> why I think it's benign. It does make the witness smaller. The same trick >> isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY. >> >> Eugene (Crypt-iQ on github) >> ___ >> 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
[Lightning-dev] Interesting thing about Offered HTLCs
I'm not sure if this is known, but I'm pretty sure it's benign and so I thought I'd share since I found it interesting and maybe someone else will too. I'm not sure if this is already known either. https://github.com/lightning/bolts/blob/master/03-transactions.md#offered-htlc-outputs Offered HTLCs have three claim paths: the revocation case, the offerer claiming through the HTLC-timeout transaction, and the receiver claiming via their sig + preimage. The offering party can claim via the HTLC-timeout case on their commitment transaction with their signature and the remote's signature (SIGHASH_ALL) after the cltv_expiry timeout. Since the remote party gives them a signature, after the timeout, the offering party can claim with the remote's signature + preimage, but can only spend with the HTLC-timeout transaction because of SIGHASH_ALL. This assumes that the remote party doesn't claim it first. I can't think of any cases where the offering party would know the preimage AND want to force close, so that's why I think it's benign. It does make the witness smaller. The same trick isn't possible with the Received HTLC's due to OP_CHECKLOCKTIMEVERIFY. Eugene (Crypt-iQ on github) ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
Lnd counts dust + trimmed HTLCs towards max_accepted_htlcs. We definitely shouldn't be counting dust towards that amount. I would have to think more about the issue where it's not possible to lower the feerate though. That seems like a spec issue? ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
Thanks for replying. I was under the impression that long-term update_fee was going to be removed since second-level HTLC txn's can bring their own fees? On Fri, Apr 23, 2021 at 12:24 PM Bastien TEINTURIER wrote: > Hi Eugene, > > The reason dust HTLCs count for the 483 HTLC limit is because of > `update_fee`. > If you don't count them and exceed the 483 HTLC limit, you can't lower the > fee anymore > because some HTLCs that were previously dust won't be dust anymore and you > may end > up with more than 483 HTLC outputs in your commitment, which opens the > door to other > kinds of attacks. > > This is the first issue that comes to mind, but there may be other > drawbacks if we dig into > this enough with an attacker's mindset. > > Bastien > > Le ven. 23 avr. 2021 à 17:58, Eugene Siegel a écrit : > >> I propose a simple mitigation to increase the capital requirement of >> channel-jamming attacks. This would prevent an unsophisticated attacker >> with low capital from jamming a target channel. It seems to me that this >> is a *free* mitigation without any downsides (besides code-writing), so I'd >> like to hear other opinions. >> >> In a commitment transaction, we trim dust HTLC outputs. I believe that >> the reason for the 483 HTLC limit each side has in the spec is to prevent >> commitment tx's from growing unreasonably large, and to ensure they are >> still valid tx's that can be included in a block. If we don't include dust >> HTLCs in this calculation, since they are not on the commitment tx, we >> still allow 483 (x2) non-dust HTLCs to be included on the commitment tx. >> There could be a configurable limit on the number of outstanding dust >> HTLCs, but the point is that it doesn't affect the non-dust throughput of >> the channel. This raises the capital requirement of channel-jamming so >> that each HTLC must be non-dust, rather than spamming 1 sat payments. >> >> Interested in others' thoughts. >> >> Eugene (Crypt-iQ) >> ___ >> 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
[Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
I propose a simple mitigation to increase the capital requirement of channel-jamming attacks. This would prevent an unsophisticated attacker with low capital from jamming a target channel. It seems to me that this is a *free* mitigation without any downsides (besides code-writing), so I'd like to hear other opinions. In a commitment transaction, we trim dust HTLC outputs. I believe that the reason for the 483 HTLC limit each side has in the spec is to prevent commitment tx's from growing unreasonably large, and to ensure they are still valid tx's that can be included in a block. If we don't include dust HTLCs in this calculation, since they are not on the commitment tx, we still allow 483 (x2) non-dust HTLCs to be included on the commitment tx. There could be a configurable limit on the number of outstanding dust HTLCs, but the point is that it doesn't affect the non-dust throughput of the channel. This raises the capital requirement of channel-jamming so that each HTLC must be non-dust, rather than spamming 1 sat payments. Interested in others' thoughts. Eugene (Crypt-iQ) ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
