Hi Bastien, >Greg already has a draft design that addresses your concerns Thanks, that is very nice. In that case I currently have no outstanding objections. >I'm curious why you would need more than one such output My reasoning was actually to allow only one OP_TRUE output per transaction, so I think we agree. Apologies if that wasn't clear. To summarize: 1. OP_TRUE output must be spent 2. Only one child allowed per transaction This ensures there is no scenario where a child is propagated that does not spend the OP_TRUE output. Cheers, Ruben On Fri, Sep 30, 2022 at 2:17 PM Greg Sanders wrote: > It's likely better if the ephemeral output can be any value, including > dust. This lets contract designers put "trimmed output" value indirectly > towards CPFP fees without making the parent tx have fees itself. > > On Fri, Sep 30, 2022, 8:08 AM Bastien TEINTURIER wrote: > >> Hey Ruben, >> >> I discussed this further over IRC, and I now agree that this particular >> change would be very desirable and can likely fit in the initial release >> (even though I'm not the one writing that code, but I'd be happy to >> review it and test it). >> >> Greg already has a draft design that addresses your concerns: if there is >> an "ephemeral output" (0-value, OP_TRUE) in an unconfirmed v3 transaction, >> it MUST be spent by any child v3 transaction. This way, you ensure that >> any child transaction spending the unconfirmed parent spends the ephemeral >> output(s). @Greg, correct me if I misunderstood something here. Note that >> we will need to precisely define the criteria for those "ephemeral >> outputs" >> (it can probably simply be "outputs that are 0 sats"). >> >> Coupled with transactions that pay no fees (and thus require a child to >> CPFP in order to be included in a block), this ensures those outputs can >> never leak into the utxo set. How does that sound? >> >> I'm curious why you would need more than one such output, can you detail? >> I believe we only ever need one, spendable by anyone. >> >> Cheers, >> Bastien >> >> Le ven. 30 sept. 2022 à 02:14, Ruben Somsen a écrit : >> >>> Hi Bastien, >>> >>> >The other change mentioned (making OP_TRUE standard and allowing outputs >>> that are below dust) can be added later, as those won't be standard until >>> we start allowing them, so there shouldn't be any backwards-compatibility >>> issue with postponing this change. But maybe it's still worth having from >>> the get-go, even though it may take a bit more time? Again, I'm curious >>> to >>> have other people's opinion here >>> >>> I'm sensitive to not wanting to overload the current discussion but this >>> also interests me, provided it can be done in a way that is acceptable >>> (i.e. minimizing the potential UTXO set impact). It would solve a big cost >>> issue in my spacechains design if transactions could be 0 fees and have a 0 >>> sat output that could be used in order to pay all the fees with CPFP. >>> >>> My current view is that a tx containing a single 0 sat OP_TRUE output >>> should only get relayed if it is a package where the OP_TRUE output is >>> currently being spent in a way that increases the overall fee rate. But >>> even then, one theoretical edge case remains: >>> - Another CPFP tx can feebump the package on a different (non-OP_TRUE) >>> output with an even higher fee rate >>> - Subsequently, the tx that is spending the OP_TRUE might fall out of >>> the mempool if the mempool fee rate rises >>> - This could cause the 0 sat output to enter the UTXO set (specifically, >>> rational miners wouldn't refuse to mine such a tx) >>> >>> It doesn't seem like this would happen much in practice (nor is there an >>> incentive to do it on purpose), but the chance isn't 0. >>> >>> Cheers, >>> Ruben >>> >>> >>> >>> On Thu, Sep 29, 2022 at 4:50 PM Greg Sanders via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>>> > Right, good catch, this does require new logic to handle this case. >>>> As Gloria points out, this should be doable, and is definitely worth >>>> adding (those CSV 1 on every other output are really hacky, glad to >>>> find a way to get rid of them). >>>> >>>> For the record, it turns out ephemeral anchors + v3 solves this >>>> already, as the anchor must be spent, and the parent tx may only have one >>>> child. Somehow I missed this implication for a few months. It's great news >>>> if we can directly source fees from any output claimable, including HTLCs! >>>> >>>> On Thu, Sep 29, 2022 at 5:15 AM Bastien TEINTURIER >>>> wrote: >>>> >>>>> Hi Gloria, Greg, >>>>> >>>>> > I interpret most of the discussion around limitations as ideas for >>>>> > future improvements rather than criticisms of the proposal >>>>> >>>>> As far as I'm concerned, definitely! >>>>> >>>>> My current understanding is that the main change/improvement that would >>>>> make sense here is restricting the whole v3 package's size (instead of >>>>> just the child) via committing to a specific value in the taproot annex >>>>> (also note that it's probably not just the v3 package's size, it should >>>>> be the whole unconfirmed package including potential v2 unconfirmed >>>>> ancestors). >>>>> >>>>> While I think this would be very valuable and would like to see this >>>>> happen, I believe that can be done in a second, separate step since >>>>> this >>>>> would make relay policy stricter (some v3 transactions that previously >>>>> propagated wouldn't propagate under this new rule). As long as you are >>>>> able to find a path to miners through upgraded peers that use this >>>>> annex >>>>> approach, you should be able to resolve ACP pinning issues? >>>>> >>>>> I'm curious to know how other people feel about that: is it ok to do >>>>> later or should we try to implement this for the first release of v3 >>>>> transactions? >>>>> >>>>> The other change mentioned (making OP_TRUE standard and allowing >>>>> outputs >>>>> that are below dust) can be added later, as those won't be standard >>>>> until >>>>> we start allowing them, so there shouldn't be any >>>>> backwards-compatibility >>>>> issue with postponing this change. But maybe it's still worth having >>>>> from >>>>> the get-go, even though it may take a bit more time? Again, I'm >>>>> curious to >>>>> have other people's opinion here, I'd be happy to get all of those >>>>> directly >>>>> in the first release of v3 transactions, but I don't know how much >>>>> implementation will have to go into that. >>>>> >>>>> > For clarification, package RBF is ParentTx*s*(plural), and >>>>> ChildTx(singular), >>>>> > so it might be a bit more complicated than we're thinking >>>>> >>>>> Right, good catch, this does require new logic to handle this case. >>>>> As Gloria points out, this should be doable, and is definitely worth >>>>> adding (those CSV 1 on every other output are really hacky, glad to >>>>> find a way to get rid of them). >>>>> >>>>> Thanks, >>>>> Bastien >>>>> >>>>> Le lun. 26 sept. 2022 à 18:48, Gloria Zhao a >>>>> écrit : >>>>> >>>>>> Hi Greg, Antoine, Bastien, >>>>>> >>>>>> Thanks very much for the feedback! I interpret most of the discussion >>>>>> around limitations as ideas for future improvements rather than criticisms >>>>>> of the proposal (please correct me if I'm wrong). I'll try to respond to as >>>>>> much as possible. >>>>>> >>>>>> Also I realize that I didn't contextualize this proposal clearly >>>>>> enough; it is very tailored for LN Penalty and definitely doesn't close all >>>>>> pinning attacks possible (sorry for confusing anyone). I also agree that >>>>>> some bits can be a little ugly or tack-on; I would definitely prefer a >>>>>> comprehensive RBF revamp to fix all our problems and enable other >>>>>> fee-bumping strategies such as >>>>>> sign-ANYONECANPAY-then-bring-your-own-fees-by-adding-inputs-at-broadcast. I >>>>>> was hoping to get some ideas with the "RBF Improvements" post in January, >>>>>> but it doesn't seem like we're much closer to a workable proposal. I think >>>>>> this is a minimally-invasive step that works for Lightning today, a small >>>>>> fix similar to CPFP carve out. >>>>>> >>>>>> > As you likely know from previous discussions the biggest scenario >>>>>> this does not fix in my estimation is ANYONECANPAY situations. If the >>>>>> parent transaction can be "inflated" by tacking on additional inputs, this >>>>>> means the total weight of the parent tx lowers the effective feerate of the >>>>>> package. >>>>>> >>>>>> (For more context to other readers I wrote an explanation for this in >>>>>> "SIGHASH_ANYONECANPAY Pinning" section of RBF ML post). Yes, this >>>>>> unfortunately doesn't fix any of the existing pinning attacks for single >>>>>> transaction RBF but also doesn't make them worse. This boils down to adding >>>>>> an incentive compatibility rule that ensures you can't replace a >>>>>> transaction with something that will confirm slower. Package RBF has an >>>>>> ancestor feerate-based rule for this (note it is quite conservative and not >>>>>> perfect). >>>>>> >>>>>> So in the scenario above with the "inflated" parent that was signed >>>>>> ACP, the replacement would be rejected because the package ancestor feerate >>>>>> is lower than the feerate of what is being replaced. But it is imperfect >>>>>> (explained below) and thus I wouldn't recommend it for single transaction >>>>>> replacement. So that attack still exists for single transactions, yes. >>>>>> >>>>>> The strategy of using ACP to bring-your-own-fees has its own >>>>>> challenges but hopefully has no current use cases as you say. AFAIK LN >>>>>> Penalty is not affected by this since it doesn't use ACP, though obviously >>>>>> I agree we should fix it for the future. >>>>>> >>>>>> So when I said "this is intended for fee-bumping presigned txns in >>>>>> contracting protocols," I should have said "this is intended for >>>>>> fee-bumping presigned txns specifically using CPFP and anchor outputs." >>>>>> Apologies for forgetting to contextualize, I've been sitting on this for >>>>>> too long. >>>>>> >>>>>> > The other scenario it doesn't really fix is where >>>>>> HTLC/commitment-like transactions are being resolved in a batch, but due to >>>>>> relative time constraints, you may want to accelerate some and not others. >>>>>> Now you must pay higher rates to replace all of the transaction bumps. This >>>>>> is a "self-pin" and "get good at utxos noob" type problem, but it's >>>>>> something that axing rule#3 in favor of a Replace-by-ancestor-feerate >>>>>> system would get us. >>>>>> >>>>>> I understand you to mean "if you don't have enough UTXOs and you're >>>>>> forced to batch-bump, you over-pay because you need to bring them all to >>>>>> the highest target feerate." Isn't this kind of separate, wallet-related >>>>>> problem? Contracting or not, surely every wallet needs to have enough UTXOs >>>>>> to not batch transactions that shouldn't be batched... I don't see how a >>>>>> replace-by-ancestor-feerate policy would make any difference for this? >>>>>> >>>>>> Also in general I'd like to reiterate that ancestor feerate is not a >>>>>> panacea to all our RBF incentive compatibility concerns. Like individual >>>>>> feerate, unless we run the mining algorithm, it cannot tell us exactly how >>>>>> quickly this transaction would be mined. >>>>>> >>>>>> We're estimating the incentive compatibility of the original >>>>>> transaction(s) and replacement transaction(s), with the goal of not letting >>>>>> a transaction replace something that would have been more incentive >>>>>> compatible to mine. As such, we don't want to overestimate how good the >>>>>> replacement is, and we don't want to underestimate how good the original >>>>>> transactions are. This rule "The minimum between package feerate and >>>>>> ancestor feerate of the child is not lower than the individual feerates of >>>>>> all directly conflicting transactions and the ancestor feerates of all >>>>>> original transactions" is a conservative estimate. >>>>>> >>>>>> > Would kind of be nice if package RBF would detect a "sibling output >>>>>> spend" conflict, and knock it out of the mempool via the other replacement >>>>>> rules? Getting rid of the requirement to 1 block csv lock every output >>>>>> would be quite nice from a smart contracting composability point of view. >>>>>> >>>>>> Interesting, so when a transaction hits a mempool tx's descendant >>>>>> limit, we consider evicting one of its descendants in favor of this >>>>>> transaction, based on the RBF rules. >>>>>> Cool idea! After chewing on this for a bit, I think this *also* just >>>>>> boils down to the fact that RBF should require replacements to be better >>>>>> mining candidates. As in, if we added this policy and it can make us evict >>>>>> the sibling and accept a transaction with a bunch of low-feerate ancestor >>>>>> junk, it would be a new pinning vector. >>>>>> >>>>>> > If you're a miner and you receive a non-V3, second descendant of an >>>>>> unconfirmed V3 transaction, if the offered fee is in the top mempool >>>>>> backlog, I think you would have an interest to accept such a transaction. >>>>>> >>>>>> > So I'm not sure if those two rules are compatible with miners >>>>>> incentives... >>>>>> >>>>>> The same argument can be made for the 26th descendant of a mempool >>>>>> transaction; it's also not entirely incentive-compatible to reject it, but >>>>>> that is not the *only* design goal in mempool policy. Of course, the >>>>>> difference here is that the 25-descendant limit rule is a sensible DoS >>>>>> protection, while this 1-descendant limit rule is more of a "help the >>>>>> Bitcoin ecosystem" policy, just like CPFP carve-out, dust limit, etc. I can >>>>>> of course understand why not everyone would be in favor of this, but I do >>>>>> think it's worth it. >>>>>> >>>>>> > > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be >>>>>> >>>>>> > > larger than 1000 virtual bytes. >>>>>> >>>>>> > If I understand correctly the 1000 vb upper bound rational, it >>>>>> would be to constraint the pinning counterparty to attach a high fee to a >>>>>> child due to the limited size, if they would like this transaction to be >>>>>> stuck in the network mempools. By doing so this child has high odds to >>>>>> confirm. >>>>>> >>>>>> Yeah exactly, the "Rule 3 pin" is done by adding a child that's >>>>>> high-fee (so you have to pay that much to evict it). Because they *don't* >>>>>> want this tx to confirm, normally, this child would be really large. If >>>>>> they only have 1000vB for the child, they can't increase the replacement >>>>>> cost without also fee-bumping the transaction to make it confirm faster. >>>>>> >>>>>> > As of today, I think yes you can already fingerprint LN >>>>>> transactions on the spec-defined amount value of the anchor outputs, 330 >>>>>> sats. There is always one of them on post-anchor commitment transactions. >>>>>> And sadly I would say we'll always have tricky fingerprints leaking from >>>>>> unilateral LN closures such as HTLC/PTLC timelocks... >>>>>> >>>>>> > I agree with you, this isn't worse than today, unilateral closes >>>>>> will >>>>>> probably always be identifiable on-chain. >>>>>> >>>>>> Great to hear that there is no privacy worsening! >>>>>> >>>>>> Best, >>>>>> Gloria >>>>>> >>>>>> On Mon, Sep 26, 2022 at 5:02 PM Greg Sanders >>>>>> wrote: >>>>>> >>>>>>> Bastien, >>>>>>> >>>>>>> > This may be already covered by the current package RBF logic, in >>>>>>> that >>>>>>> scenario we are simply replacing [ParentTx, ChildTx1] with >>>>>>> [ParentTx, ChildTx2] that pays more fees, right? >>>>>>> >>>>>>> For clarification, package RBF is ParentTx*s*(plural), and >>>>>>> ChildTx(singular), so it might be a bit more complicated than we're >>>>>>> thinking, and currently the V3 proposal would first de-duplicate the >>>>>>> ParentTx based on what is in the mempool, then look at the "rest" of the >>>>>>> transactions as a package, then individually. Not the same, not sure how >>>>>>> different. I'll defer to experts. >>>>>>> >>>>>>> Best, >>>>>>> Greg >>>>>>> >>>>>>> On Mon, Sep 26, 2022 at 11:48 AM Bastien TEINTURIER via bitcoin-dev < >>>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>>>>> >>>>>>>> Thanks Gloria for this great post. >>>>>>>> >>>>>>>> This is very valuable work for L2 contracts, and will greatly >>>>>>>> improve >>>>>>>> their security model. >>>>>>>> >>>>>>>> > "Only 1 anchor output? What if I need to bump counterparty's >>>>>>>> commitment tx in mempool?" >>>>>>>> > You won't need to fee-bump a counterparty's commitment tx using >>>>>>>> CPFP. >>>>>>>> > You would just package RBF it by attaching a high-feerate child to >>>>>>>> > your commitment tx. >>>>>>>> >>>>>>>> Note that we can also very easily make that single anchor spendable >>>>>>>> by >>>>>>>> both participants (or even anyone), so if you see your >>>>>>>> counterparty's >>>>>>>> commitment in your mempool, you can bump it without publishing your >>>>>>>> own commitment, which is quite desirable (your own commitment tx has >>>>>>>> CSV delays on your outputs, whereas your counterparty's commitment >>>>>>>> tx >>>>>>>> doesn't). >>>>>>>> >>>>>>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN >>>>>>>> transactions based on nVersion?" >>>>>>>> >>>>>>>> I agree with you, this isn't worse than today, unilateral closes >>>>>>>> will >>>>>>>> probably always be identifiable on-chain. >>>>>>>> >>>>>>>> > Would kind of be nice if package RBF would detect a "sibling >>>>>>>> output spend" >>>>>>>> > conflict, and knock it out of the mempool via the other >>>>>>>> replacement rules? >>>>>>>> > Getting rid of the requirement to 1 block csv lock every output >>>>>>>> would be >>>>>>>> > quite nice from a smart contracting composability point of view. >>>>>>>> >>>>>>>> +1, that would be very neat! >>>>>>>> >>>>>>>> This may be already covered by the current package RBF logic, in >>>>>>>> that >>>>>>>> scenario we are simply replacing [ParentTx, ChildTx1] with >>>>>>>> [ParentTx, ChildTx2] that pays more fees, right? >>>>>>>> >>>>>>>> > 1) I do think that we should seriously consider allowing OP_TRUE >>>>>>>> to become >>>>>>>> > a standard script type as part of this policy update. If pinning >>>>>>>> is solved, >>>>>>>> > then there's no reason to require all those extra bytes for >>>>>>>> "binding" an >>>>>>>> > anchor to a specific wallet/user. We can save quite a few bytes >>>>>>>> by having >>>>>>>> > the input be empty of witness data. >>>>>>>> > 2) If we allow for a single dust-value(0 on up) output which is >>>>>>>> immediately >>>>>>>> > spent by the package, anchors become even easier to to design. No >>>>>>>> value has >>>>>>>> > to be "sapped" from contract participants to make an anchor >>>>>>>> output. There's >>>>>>>> > more complications for this, such as making sure the parent >>>>>>>> transaction is >>>>>>>> > dropped if the child spend is dropped, but maybe it's worth the >>>>>>>> squeeze. >>>>>>>> >>>>>>>> I also think both of these could be quite useful. This would >>>>>>>> probably always >>>>>>>> be used in combination with a parent transaction that pays 0 fees, >>>>>>>> so the >>>>>>>> 0-value output would always be spent in the same block. >>>>>>>> >>>>>>>> But this means we could end up with 0-value outputs in the utxo >>>>>>>> set, if for >>>>>>>> some reason the parent tx is CPFP-ed via another output than the >>>>>>>> 0-value one, >>>>>>>> which would be a utxo set bloat issue. But I'd argue that we're >>>>>>>> probably >>>>>>>> already creating utxo set bloat with the 330 sat anchor outputs >>>>>>>> (especially >>>>>>>> since we use two of them, but only one is usually spent), so it >>>>>>>> would >>>>>>>> probably be *better* than what we're doing today. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Bastien >>>>>>>> >>>>>>>> Le lun. 26 sept. 2022 à 03:22, Antoine Riard via bitcoin-dev < >>>>>>>> bitcoin-dev@lists.linuxfoundation.org> a écrit : >>>>>>>> >>>>>>>>> Hi Gloria, >>>>>>>>> >>>>>>>>> Thanks for the progress on package RBF, few early questions. >>>>>>>>> >>>>>>>>> > 2. Any descendant of an unconfirmed V3 transaction must also be >>>>>>>>> V3. >>>>>>>>> >>>>>>>>> > 3. An unconfirmed V3 transaction cannot have more than 1 >>>>>>>>> descendant. >>>>>>>>> >>>>>>>>> If you're a miner and you receive a non-V3, second descendant of >>>>>>>>> an unconfirmed V3 transaction, if the offered fee is in the top mempool >>>>>>>>> backlog, I think you would have an interest to accept such a transaction. >>>>>>>>> >>>>>>>>> So I'm not sure if those two rules are compatible with miners >>>>>>>>> incentives... >>>>>>>>> >>>>>>>>> > 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be >>>>>>>>> > larger than 1000 virtual bytes. >>>>>>>>> >>>>>>>>> If I understand correctly the 1000 vb upper bound rational, it >>>>>>>>> would be to constraint the pinning counterparty to attach a high fee to a >>>>>>>>> child due to the limited size, if they would like this transaction to be >>>>>>>>> stuck in the network mempools. By doing so this child has high odds to >>>>>>>>> confirm. >>>>>>>>> >>>>>>>>> I still wonder if this compatible with miner incentives in period >>>>>>>>> of empty mempools, in the sense that if you've already a V3 transaction of >>>>>>>>> size 100Kvb offering 2 sat/vb, it's more interesting than a V3 replacement >>>>>>>>> candidate of size 1000 vb offering 10 sat/vb. It could be argued the former >>>>>>>>> should be conserved. >>>>>>>>> >>>>>>>>> (That said, the hard thing with any replacement strategy we might >>>>>>>>> evict a parent transaction *now* to which is attached a high-feerate child >>>>>>>>> *latter* making for a utxo considered the best ancestor set. Maybe in the >>>>>>>>> long-term miners should keep every transaction ever accepted...) >>>>>>>>> >>>>>>>>> > (Lower bound) the smaller this limit, the fewer UTXOs a child >>>>>>>>> may use >>>>>>>>> > to fund this fee-bump. For example, only allowing the V3 child >>>>>>>>> to have >>>>>>>>> > 2 inputs would require L2 protocols to manage a wallet with >>>>>>>>> high-value >>>>>>>>> > UTXOs and make batched fee-bumping impossible. However, as the >>>>>>>>> > fee-bumping child only needs to fund fees (as opposed to >>>>>>>>> payments), >>>>>>>>> > just a few UTXOs should suffice. >>>>>>>>> >>>>>>>>> Reminder for L2 devs, batched fee-bumping of time-sensitive >>>>>>>>> confirmations of commitment transactions is unsafe, as the counterparty >>>>>>>>> could enter in a "cat-and-mouse" game to replace one of the batch element >>>>>>>>> at each block to delay confirmation of the remaining elements in the batch, >>>>>>>>> I think. >>>>>>>>> >>>>>>>>> On the other hand, I wonder if we wouldn't want a higher bound. LN >>>>>>>>> wallets are likely to have one big UTXO in their fee-bumping reserve pool, >>>>>>>>> as the cost of acquiring UTXO is non-null and in the optimistic case, you >>>>>>>>> don't need to do unilateral closure. Let's say you close dozens of channels >>>>>>>>> at the same time, a UTXO pool management strategy might be to fan-out the >>>>>>>>> first spends UTXOs in N fan-out outputs ready to feed the remaining >>>>>>>>> in-flight channels. >>>>>>>>> >>>>>>>>> > 1. The rule around unconfirmed inputs was >>>>>>>>> > originally "A package may include new unconfirmed inputs, but the >>>>>>>>> > ancestor feerate of the child must be at least as high as the >>>>>>>>> ancestor >>>>>>>>> > feerates of every transaction being replaced." >>>>>>>>> >>>>>>>>> Note, I think we would like this new RBF rule to also apply to >>>>>>>>> single transaction package, e.g second-stage HTLC transactions, where a >>>>>>>>> counterparty pins a HTLC-preimage by abusing rule 3. In that case, the >>>>>>>>> honest LN node should be able to broadcast a "at least as high ancestor >>>>>>>>> feerate" HTLC-timeout transaction. With `option_anchor_outputs" there is no >>>>>>>>> unconfirmed ancestor to replace, as the commitment transaction, whatever >>>>>>>>> the party it is originating from, should already be confirmed. >>>>>>>>> >>>>>>>>> > "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN >>>>>>>>> transactions based on nVersion?" >>>>>>>>> >>>>>>>>> As of today, I think yes you can already fingerprint LN >>>>>>>>> transactions on the spec-defined amount value of the anchor outputs, 330 >>>>>>>>> sats. There is always one of them on post-anchor commitment transactions. >>>>>>>>> And sadly I would say we'll always have tricky fingerprints leaking from >>>>>>>>> unilateral LN closures such as HTLC/PTLC timelocks... >>>>>>>>> >>>>>>>>> > "Can a V2 transaction replace a V3 transaction and vice versa?" >>>>>>>>> >>>>>>>>> IIUC, a V3 package could replace a V2 package, with the benefit of >>>>>>>>> the new package RBF rules applied. I think this would be a significant >>>>>>>>> advantage for LN, as for the current ~85k of opened channels, the old V2 >>>>>>>>> states shouldn't be pinning vectors. Currently, commitment transactions >>>>>>>>> signal replaceability. >>>>>>>>> >>>>>>>>> Le ven. 23 sept. 2022 à 11:26, Gloria Zhao via bitcoin-dev < >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org> a écrit : >>>>>>>>> >>>>>>>>>> Hi everyone, >>>>>>>>>> >>>>>>>>>> I'm writing to propose a very simple set of mempool/transaction >>>>>>>>>> relay >>>>>>>>>> policies intended to aid L2/contract protocols. I realized that >>>>>>>>>> the previously proposed Package Mempool Accept package RBF [1] >>>>>>>>>> had a few remaining problems after digging into the RBF logic >>>>>>>>>> more [2]. >>>>>>>>>> This additional set of policies solves them without requiring a >>>>>>>>>> huge RBF overhaul. >>>>>>>>>> >>>>>>>>>> I've written an implementation (and docs) for Bitcoin Core: >>>>>>>>>> https://github.com/bitcoin/bitcoin/pull/25038 >>>>>>>>>> >>>>>>>>>> (You may notice that this proposal incorporates feedback on the >>>>>>>>>> PR - thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony >>>>>>>>>> Towns, and others.) >>>>>>>>>> >>>>>>>>>> If you are interested in using package RBF/relay to bump presigned >>>>>>>>>> transactions, I think you may be interested in reviewing this >>>>>>>>>> proposal. >>>>>>>>>> This should solve Rule 3 pinning and perhaps allow us >>>>>>>>>> to get rid of CPFP carve-out (yay!). I'm keen to hear if people >>>>>>>>>> find >>>>>>>>>> the 1-anchor-output, 1000vB child limit too restrictive. Also, if >>>>>>>>>> you find a >>>>>>>>>> pinning attack or something that makes it unusable for you, I >>>>>>>>>> would >>>>>>>>>> really really like to know. >>>>>>>>>> >>>>>>>>>> Note that transactions with nVersion=3 ("V3 transactions") are >>>>>>>>>> currently non-standard in Bitcoin Core. That means **anything >>>>>>>>>> that was >>>>>>>>>> standard before this policy change would still be standard >>>>>>>>>> afterwards.** If you don't want your transactions to be subject to >>>>>>>>>> these rules, just continue whatever you're doing and don't use >>>>>>>>>> nVersion=3. AFAICT this shouldn't break anything, but let me know >>>>>>>>>> if >>>>>>>>>> this would be disruptive for you? >>>>>>>>>> >>>>>>>>>> **New Policies:** >>>>>>>>>> >>>>>>>>>> This includes: >>>>>>>>>> - a set of additional policy rules applying to V3 transactions >>>>>>>>>> - modifications to package RBF rules >>>>>>>>>> >>>>>>>>>> **V3 transactions:** >>>>>>>>>> >>>>>>>>>> Existing standardness rules apply to V3 (e.g. min/max tx weight, >>>>>>>>>> standard output types, cleanstack, etc.). The following additional >>>>>>>>>> rules apply to V3: >>>>>>>>>> >>>>>>>>>> 1. A V3 transaction can be replaced, even if it does not signal >>>>>>>>>> BIP125 >>>>>>>>>> replaceability. (It must also meet the other RBF rules around >>>>>>>>>> fees, >>>>>>>>>> etc. for replacement to happen). >>>>>>>>>> >>>>>>>>>> 2. Any descendant of an unconfirmed V3 transaction must also be >>>>>>>>>> V3. >>>>>>>>>> >>>>>>>>>> *Rationale*: Combined with Rule 1, this gives us the property of >>>>>>>>>> "inherited" replaceability signaling when descendants of >>>>>>>>>> unconfirmed >>>>>>>>>> transactions are created. Additionally, checking whether a >>>>>>>>>> transaction >>>>>>>>>> signals replaceability this way does not require mempool >>>>>>>>>> traversal, >>>>>>>>>> and does not change based on what transactions are mined. It also >>>>>>>>>> makes subsequent rules about descendant limits much easier to >>>>>>>>>> check. >>>>>>>>>> >>>>>>>>>> *Note*: The descendant of a *confirmed* V3 transaction does not >>>>>>>>>> need to be V3. >>>>>>>>>> >>>>>>>>>> 3. An unconfirmed V3 transaction cannot have more than 1 >>>>>>>>>> descendant. >>>>>>>>>> >>>>>>>>>> *Rationale*: (Upper bound) the larger the descendant limit, the >>>>>>>>>> more >>>>>>>>>> transactions may need to be replaced. This is a problematic >>>>>>>>>> pinning >>>>>>>>>> attack, i.e., a malicious counterparty prevents the transaction >>>>>>>>>> from >>>>>>>>>> being replaced by adding many descendant transactions that aren't >>>>>>>>>> fee-bumping. >>>>>>>>>> >>>>>>>>>> (Lower bound) at least 1 descendant is required to allow CPFP of >>>>>>>>>> the >>>>>>>>>> presigned transaction. The contract protocol can create presigned >>>>>>>>>> transactions paying 0 fees and 1 output for attaching a CPFP at >>>>>>>>>> broadcast time ("anchor output"). Without package RBF, multiple >>>>>>>>>> anchor >>>>>>>>>> outputs would be required to allow each counterparty to fee-bump >>>>>>>>>> any >>>>>>>>>> presigned transaction. With package RBF, since the presigned >>>>>>>>>> transactions can replace each other, 1 anchor output is >>>>>>>>>> sufficient. >>>>>>>>>> >>>>>>>>>> 4. A V3 transaction that has an unconfirmed V3 ancestor cannot be >>>>>>>>>> larger than 1000 virtual bytes. >>>>>>>>>> >>>>>>>>>> *Rationale*: (Upper bound) the larger the descendant size limit, >>>>>>>>>> the >>>>>>>>>> more vbytes may need to be replaced. With default limits, if the >>>>>>>>>> child >>>>>>>>>> is e.g. 100,000vB, that might be an additional 100,000sats (at >>>>>>>>>> 1sat/vbyte) or more, depending on the feerate. >>>>>>>>>> >>>>>>>>>> (Lower bound) the smaller this limit, the fewer UTXOs a child may >>>>>>>>>> use >>>>>>>>>> to fund this fee-bump. For example, only allowing the V3 child to >>>>>>>>>> have >>>>>>>>>> 2 inputs would require L2 protocols to manage a wallet with >>>>>>>>>> high-value >>>>>>>>>> UTXOs and make batched fee-bumping impossible. However, as the >>>>>>>>>> fee-bumping child only needs to fund fees (as opposed to >>>>>>>>>> payments), >>>>>>>>>> just a few UTXOs should suffice. >>>>>>>>>> >>>>>>>>>> With a limit of 1000 virtual bytes, depending on the output >>>>>>>>>> types, the >>>>>>>>>> child can have 6-15 UTXOs, which should be enough to fund a >>>>>>>>>> fee-bump >>>>>>>>>> without requiring a carefully-managed UTXO pool. With 1000 virtual >>>>>>>>>> bytes as the descendant limit, the cost to replace a V3 >>>>>>>>>> transaction >>>>>>>>>> has much lower variance. >>>>>>>>>> >>>>>>>>>> *Rationale*: This makes the rule very easily "tacked on" to >>>>>>>>>> existing >>>>>>>>>> logic for policy and wallets. A transaction may be up to 100KvB >>>>>>>>>> on its >>>>>>>>>> own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants >>>>>>>>>> (`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 >>>>>>>>>> transaction >>>>>>>>>> in the mempool is 100KvB, its descendant can only be 1000vB, even >>>>>>>>>> if >>>>>>>>>> the policy is 10KvB. >>>>>>>>>> >>>>>>>>>> **Package RBF modifications:** >>>>>>>>>> >>>>>>>>>> 1. The rule around unconfirmed inputs was >>>>>>>>>> originally "A package may include new unconfirmed inputs, but the >>>>>>>>>> ancestor feerate of the child must be at least as high as the >>>>>>>>>> ancestor >>>>>>>>>> feerates of every transaction being replaced." >>>>>>>>>> >>>>>>>>>> The package may still include new unconfirmed inputs. However, >>>>>>>>>> the new rule is modified to be "The minimum between package >>>>>>>>>> feerate >>>>>>>>>> and ancestor feerate of the child is not lower than the individual >>>>>>>>>> feerates of all directly conflicting transactions and the ancestor >>>>>>>>>> feerates of all original transactions." >>>>>>>>>> >>>>>>>>>> *Rationale*: We are attempting to ensure that the replacement >>>>>>>>>> transactions are not less incentive-compatible to mine. However, a >>>>>>>>>> package/transaction's ancestor feerate is not perfectly >>>>>>>>>> representative >>>>>>>>>> of its incentive compatibility; it may overestimate (some subset >>>>>>>>>> of >>>>>>>>>> the ancestors could be included by itself if it has other >>>>>>>>>> high-feerate >>>>>>>>>> descendants or are themselves higher feerate than this >>>>>>>>>> package/transaction). Instead, we use the minimum between the >>>>>>>>>> package >>>>>>>>>> feerate and ancestor feerate of the child as a more conservative >>>>>>>>>> value >>>>>>>>>> than what was proposed originally. >>>>>>>>>> >>>>>>>>>> 2. A new rule is added, requiring that all package transactions >>>>>>>>>> with >>>>>>>>>> mempool conflicts to be V3. This also means the "sponsoring" >>>>>>>>>> child transaction must be V3. >>>>>>>>>> >>>>>>>>>> *Note*: Combined with the V3 rules, this means the package must be >>>>>>>>>> a child-with-parents package. Since package validation is only >>>>>>>>>> attempted if the transactions do not pay sufficient fees to be >>>>>>>>>> accepted on their own, this effectively means that only V3 >>>>>>>>>> transactions can pay to replace their ancestors' conflicts, and >>>>>>>>>> only >>>>>>>>>> V3 transactions' replacements may be paid for by a descendant. >>>>>>>>>> >>>>>>>>>> *Rationale*: The fee-related rules are economically rational for >>>>>>>>>> ancestor packages, but not necessarily other types of packages. >>>>>>>>>> A child-with-parents package is a type of ancestor package. It >>>>>>>>>> may be fine to allow any ancestor package, but it's more difficult >>>>>>>>>> to account for all of the possibilities. For example, it gets much >>>>>>>>>> harder to see that we're applying the descendant limits correctly >>>>>>>>>> if >>>>>>>>>> the package has a gnarly, many-generation, non-tree shape. I'm >>>>>>>>>> also >>>>>>>>>> not sure if this policy is 100% incentive-compatible if the >>>>>>>>>> sponsor >>>>>>>>>> is not a direct descendant of the sponsee. >>>>>>>>>> >>>>>>>>>> Please see doc/policy/version3_transactions.md and >>>>>>>>>> doc/policy/packages.md in the PR for the full set of rules. >>>>>>>>>> >>>>>>>>>> **Intended usage for LN:** >>>>>>>>>> >>>>>>>>>> Commitment transactions should be V3 and have 1 anchor output. >>>>>>>>>> They >>>>>>>>>> can be signed with 0 fees (or 1sat/vbyte) once package relay is >>>>>>>>>> deployed >>>>>>>>>> on a significant portion of the network. If the commitment tx must >>>>>>>>>> be broadcast, determine the desired feerate at broadcast time and >>>>>>>>>> spend the anchor output in a high feerate transaction. I'm going >>>>>>>>>> to >>>>>>>>>> call the broadcasted commitment tx "the parent" and the attached >>>>>>>>>> fee-bumping tx "the child." >>>>>>>>>> >>>>>>>>>> - This child must be V3. >>>>>>>>>> - This child must be at most 1000vB. Note this restricts the >>>>>>>>>> number of inputs you can use to fund the fee bump. Depending >>>>>>>>>> on the output types, this is around 6-15. >>>>>>>>>> - One child may fund fees for multiple commitment tx ("batched >>>>>>>>>> fee-bumping"). >>>>>>>>>> - To do a second fee-bump to add more fees, replace the >>>>>>>>>> *child* with a higher-feerate tx. Do not try to attach a >>>>>>>>>> grandchild. >>>>>>>>>> >>>>>>>>>> Otherwise, never try to spend from an unconfirmed V3 transaction. >>>>>>>>>> The >>>>>>>>>> descendant limits for V3 transactions are very restrictive. >>>>>>>>>> >>>>>>>>>> **Expected Questions:** >>>>>>>>>> >>>>>>>>>> "Does this fix Rule 3 Pinning?" >>>>>>>>>> Yes. The V3 descendant limit restricts both you and your >>>>>>>>>> counterparty. >>>>>>>>>> Assuming nodes adopted this policy, you may reasonably assume >>>>>>>>>> that you >>>>>>>>>> only need to replace the commitment transaction + up to 1000vB. >>>>>>>>>> >>>>>>>>>> "Only 1 anchor output? What if I need to bump counterparty's >>>>>>>>>> commitment tx in mempool?" >>>>>>>>>> You won't need to fee-bump a counterparty's commitment tx using >>>>>>>>>> CPFP. >>>>>>>>>> You would just package RBF it by attaching a high-feerate child to >>>>>>>>>> your commitment tx. >>>>>>>>>> >>>>>>>>>> "Is this a privacy issue, i.e. doesn't it allow fingerprinting LN >>>>>>>>>> transactions based on nVersion?" >>>>>>>>>> Indeed it may be unrealistic to assume V3 transactions will be in >>>>>>>>>> widespread use outside of L2. IIUC, unilateral closes are already >>>>>>>>>> obvious LN transactions because of the HTLC inputs. For e.g. >>>>>>>>>> cooperative closes and opens, I think it makes sense to continue >>>>>>>>>> using >>>>>>>>>> V2. So, unless I'm missing something, this shouldn't make it >>>>>>>>>> worse. >>>>>>>>>> >>>>>>>>>> "So a V3 transaction that doesn't signal BIP125 replaceability is >>>>>>>>>> replaceable? Is that a backward compatibility issue?" >>>>>>>>>> Yes it's replaceable. It's not an issue AFAICT because, >>>>>>>>>> under previous policy, the V3 transaction wouldn't have been >>>>>>>>>> in the mempool in the first place. >>>>>>>>>> >>>>>>>>>> "Can a V2 transaction replace a V3 transaction and vice versa?" >>>>>>>>>> Yes, otherwise someone can use V3 transactions to censor V2 >>>>>>>>>> transactions spending shared inputs. Note if the >>>>>>>>>> original V3 transaction has an unconfirmed V3 parent, this would >>>>>>>>>> violate the "inherited V3" rule and would be rejected. >>>>>>>>>> >>>>>>>>>> Thanks for reading! Feedback and review would be much appreciated. >>>>>>>>>> >>>>>>>>>> [1]: >>>>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html >>>>>>>>>> [2]: >>>>>>>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> Gloria >>>>>>>>>> _______________________________________________ >>>>>>>>>> bitcoin-dev mailing list >>>>>>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> bitcoin-dev mailing list >>>>>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> bitcoin-dev mailing list >>>>>>>> bitcoin-dev@lists.linuxfoundation.org >>>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>>>>> >>>>>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>