Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-29 📝 Original message:> Right, good catch, this ...
📅 Original date posted:2022-09-29
📝 Original message:> 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 <bastien at acinq.fr> 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 <gloriajzhao at gmail.com> 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 <gsanders87 at gmail.com>
>> 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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220929/fa260464/attachment-0001.html>;
📝 Original message:> 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 <bastien at acinq.fr> 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 <gloriajzhao at gmail.com> 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 <gsanders87 at gmail.com>
>> 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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>>
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220929/fa260464/attachment-0001.html>;