rich1.0npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mhttps://nostr.ae/npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mnjumphttps://nostr.ae📅 Original date posted:2022-09-26 📝 Original message: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/20220926/7e18188a/attachment-0001.html>