* [bitcoindev] OP_Expire mempool behavior
@ 2024-03-13 3:32 Peter Todd
2024-03-16 18:21 ` [bitcoindev] " Antoine Riard
2024-03-19 15:04 ` Peter Todd
0 siblings, 2 replies; 4+ messages in thread
From: Peter Todd @ 2024-03-13 3:32 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]
I got a question re: the following comment on delvingbitcoin with regard to
OP_Expire:
> > nodes should require higher minimum relay fees for transactions close to
> > their expiration height to ensure we don’t waste bandwidth on transactions
> > that have no potential to be mined
>
> This seems insufficient to solve the problem, unless the premium is so high
> that it virtually guarantees that the transaction will be mined before it
> expires. However, if the feerate were that high, wouldn’t OP_EXPIRE simply
> waste blockspace? If however the feerate of the transaction is merely
> competitive, the presence of OP_EXPIRE creates a bandwidth-wasting vector: an
> attacker would submit e.g. OP_EXPIRE transactions at the bottom of the top
> block and push them out of the top block with further OP_EXPIRE transactions.
> This way the attacker could issue a constant stream of transactions, but
> never pay for more than a couple barely sliding in at the bottom of the
> block.
-https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8
This "bandwidth-wasting vector" requires the attacker to create actual
fee-paying transactions, with a fee-rate sufficiently high to get mined in the
next block or so. This of course is very expensive by itself.
If you already have a need to make such transactions, you can argue that the
marginal cost to also use up that bandwidth is low. But that's already the case
with RBF: we allow any transaction to be replaced with RBF for a (by default)
1sat/vB additional cost to "pay for" the bandwidth of that replacement.
OP_EXPIRE does not change this situation: you're still paying for an additional
1sat/vB cost over the replaced transaction, as eventually one of your
replacements will get mined.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZfEeNcX3ebyuYYRi%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread* [bitcoindev] Re: OP_Expire mempool behavior 2024-03-13 3:32 [bitcoindev] OP_Expire mempool behavior Peter Todd @ 2024-03-16 18:21 ` Antoine Riard 2024-03-19 15:04 ` Peter Todd 1 sibling, 0 replies; 4+ messages in thread From: Antoine Riard @ 2024-03-16 18:21 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 9430 bytes --] > > > nodes should require higher minimum relay fees for transactions close to > > their expiration height to ensure we don’t waste bandwidth on transactions > > that have no potential to be mined I think this concern can be raised on _today_ LN second-stage transactions (HTLC-preimage / HTLC-timeout), when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes will automatically go to broadcast an on-chain HTLC-timeout transaction. Probabilistically, we're wasting bandwidth on transactions that _might_ have lower odds to be mined. > If you already have a need to make such transactions, you can argue that the > marginal cost to also use up that bandwidth is low. But that's already the case > with RBF: we allow any transaction to be replaced with RBF for a (by default) > 1sat/vB additional cost to "pay for" the bandwidth of that replacement. > OP_EXPIRE does not change this situation: you're still paying for an additional > 1sat/vB cost over the replaced transaction, as eventually one of your > replacements will get mined. I think yes this is indeed more a replacement issue, nothing new introduced by OP_EXPIRE finality time-bounding semantics. However, I think it's more an issue if we introduce things like altruistic re-broadcasting. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022188.html Certainly, the re-broadcast could favor transactions with higher odds of being mined, which naively should match RBF rules. And by the same way taking time to answer the open questions on this thread from the old mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022224.html > Are you claiming that BIP157 doesn't work well? In my experience it does. I've not checked recently, though from research memory a while back the numbers of BIP157 services offering peers was in the range of ~10 / 100. One can check by collecting nVersions messages from peers with `NODE_COMPACT_FILTERS`. > Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so mempool min fees are very consistent across nodes. I just checked four different long running > nodes I have access to, running a variety of Bitcoin Core versions on different platforms and very different places in the world, and their minfees all agree to well within 1% > In fact, they agree on min fee much *more* closely than the size of their mempools (in terms of # of transactions). Which makes sense when you think about it, as the > slope of the supply/demand curve is fairly flat right now. See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated from diverging mempool min fees from the ground iirc. > From the point of view of a single node, an attacker can not reuse a UTXO in a replacement cycling attack. The BIP125 rules, in particular rule #4, ensure that each > replacement consumes liquidity because each replacement requires a higher fee, at least high enough to "pay for" the bandwidth of the replacement. An attacker trying to > use the same UTXO's to cycle out multiple victim transactions has to pay a higher fee for each victim cycled out. This is because at each step of the cycle, the attacker had > to broadcast a transaction with a higher fee than some other transaction. This does not stay true with nVersion=3, where a package parent can be signed with a feerate under min relay tx fee. See the second test attached in the initial full report email on replacement cycling attacks, one can replace the child of the package and the parent is automatically evicted, without the "pay for" bandwidth of the replacement fully covered. This is correct there is a minimal fee basis for each additional victim cycled out, while one can get a very advantageous scaling effect by RC'ing the child txn. > If I understand correctly, here you are talking about an attacker with connections to many different nodes at once, using the same UTXO(s) to do replacement cycling > attacks against different victim transactions on many different nodes at once. > There is no free lunch in this strategy. By using the same UTXO(s) against multiple victims, > the attacker dramatically reduces the effectiveness of the attack because only a subset of nodes see each "side" of the attack. The attacker assumptions is correct and relies on partitioning mempools. However, I disagree on the reduction in attack effectiveness as traditional LN nodes have only one tx-relay edge access to the tx-relay network (and LN nodes interfaces are a clusterfuck to do it correctly here). > Suppose that Mallory is connected directly or indirectly Alice and Bob's nodes, and attempts to do a replacement cycling attack against both Alice and Bob with the same > UTXO(s). > Both Alice and Bob's victim transactions spend different UTXOs, so every node on the network can add both transactions to their mempool. When Alice and Bob > broadcast their victim transactions, their nodes will tell multiple peers about their respective transactions. Indeed, if alturistic rebroadcasting is to be relevant at all, nodes > other than Alice and Bob's *must* have learned about their transactions! > Mallory on the other hand is creating divergent attack transactions that are mututally > incompatible. When Mallory broadcasts those attack transactions, from the perspective of some nodes, Alice's victim transaction will be replaced out but not Bob's, and > from the perspective of other nodes, the opposite. I'm assuming Mallory is partitioning Alice and Bob's local mempool from the rest of the network by using.2 distinct UTXOs. However their victim transactions won't propagate out of their local mempools due to Mallory's higher / higher feerate conflicting transactions. Mallory won't have to paid the fan-out of 3.125 BTC of concurrent replacement, assuming the partitioning isolation from the rest of the network is well-done. > Indeed, from the perspective of roughly half of the alturistic rebroadcasting nodes, Alice's transaction was never cycled out, and the other half, Bob's was never cycled out! > Even in this case where the attack only used the same UTXO for two targets, each victim transaction gets to roughly 50% of the mining nodes, making the attack > ineffective. And the numbers for Mallory just keep getting worse as he targets more victims at once. I think you can just use one UTXO for each RC target by broadcasting a transaction in the target local mempool's conflicting constantly with the malicious replacement transaction. From my understanding, altruistic rebroadcasting only introduces the encumbrance on the attacker to add 1 UTXO per-victim's local mempool. I believe it's small advance to mitigate replacement cycling attacks, however a very cheap one given the marginal cost of a UTXO. Best, Antoine Le mercredi 13 mars 2024 à 05:10:40 UTC, Peter Todd a écrit : > I got a question re: the following comment on delvingbitcoin with regard to > OP_Expire: > > > > nodes should require higher minimum relay fees for transactions close > to > > > their expiration height to ensure we don’t waste bandwidth on > transactions > > > that have no potential to be mined > > > > This seems insufficient to solve the problem, unless the premium is so > high > > that it virtually guarantees that the transaction will be mined before it > > expires. However, if the feerate were that high, wouldn’t OP_EXPIRE > simply > > waste blockspace? If however the feerate of the transaction is merely > > competitive, the presence of OP_EXPIRE creates a bandwidth-wasting > vector: an > > attacker would submit e.g. OP_EXPIRE transactions at the bottom of the > top > > block and push them out of the top block with further OP_EXPIRE > transactions. > > This way the attacker could issue a constant stream of transactions, but > > never pay for more than a couple barely sliding in at the bottom of the > > block. > -https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8 > > This "bandwidth-wasting vector" requires the attacker to create actual > fee-paying transactions, with a fee-rate sufficiently high to get mined in > the > next block or so. This of course is very expensive by itself. > > If you already have a need to make such transactions, you can argue that > the > marginal cost to also use up that bandwidth is low. But that's already the > case > with RBF: we allow any transaction to be replaced with RBF for a (by > default) > 1sat/vB additional cost to "pay for" the bandwidth of that replacement. > OP_EXPIRE does not change this situation: you're still paying for an > additional > 1sat/vB cost over the replaced transaction, as eventually one of your > replacements will get mined. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/42adedc4-f3b0-4214-8f0d-2a27a3916fcen%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 14719 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoindev] Re: OP_Expire mempool behavior 2024-03-13 3:32 [bitcoindev] OP_Expire mempool behavior Peter Todd 2024-03-16 18:21 ` [bitcoindev] " Antoine Riard @ 2024-03-19 15:04 ` Peter Todd 2024-06-20 23:09 ` Antoine Riard 1 sibling, 1 reply; 4+ messages in thread From: Peter Todd @ 2024-03-19 15:04 UTC (permalink / raw) To: antoine.riard; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 6303 bytes --] (replying manually with a cut-n-paste due to a mailing list delivery issue) > > > > nodes should require higher minimum relay fees for transactions close to > > > their expiration height to ensure we don’t waste bandwidth on transactions > > > that have no potential to be mined > > I think this concern can be raised on _today_ LN second-stage transactions (HTLC-preimage / HTLC-timeout), > when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes will automatically go to broadcast an > on-chain HTLC-timeout transaction. Probabilistically, we're wasting bandwidth on transactions that _might_ have > lower odds to be mined. That's not really a comparable situation. If the HTLC-timeout transaction replaces a HTLC-preimage transaction in a mempool, it will do so under ordinary BIP125 rules, and is thus "paying for" the bandwidth with a higher fee. Equally, in a replace-by-fee-rate scenario, it would be "paying for" its bandwidth with a higher fee-rate. Either way, something will confirm. In the OP_Expire case, we're talking about a transaction that becomes entirely invalid after a point in time. If the transaction isn't mined with reasonably high probability (eg >10%, preferably higher) an attacker may be able to consume bandwidth indefinitely at little to no cost. > > If you already have a need to make such transactions, you can argue that the > > marginal cost to also use up that bandwidth is low. But that's already the case > > with RBF: we allow any transaction to be replaced with RBF for a (by default) > > 1sat/vB additional cost to "pay for" the bandwidth of that replacement. > > OP_EXPIRE does not change this situation: you're still paying for an additional > > 1sat/vB cost over the replaced transaction, as eventually one of your > > replacements will get mined. > > I think yes this is indeed more a replacement issue, nothing new introduced by OP_EXPIRE finality time-bounding semantics. > However, I think it's more an issue if we introduce things like altruistic re-broadcasting. > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022188.html > > Certainly, the re-broadcast could favor transactions with higher odds of being mined, which naively should match RBF rules. Similar to what I wrote above, in altruistic re-broadcasting, the attacker doing the replacement cycling attack has already paid for the bandwidth consumed in broadcasting the replaced transaction because they paid fees for the cycling attack. Nothing more needs to be done beyond existing RBF/RBFR rules to avoid DoS attacks. > And by the same way taking time to answer the open questions on this thread from the old mailing list: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022224.html > > > Are you claiming that BIP157 doesn't work well? In my experience it does. > > I've not checked recently, though from research memory a while back the numbers of BIP157 services offering peers > was in the range of ~10 / 100. > > One can check by collecting nVersions messages from peers with `NODE_COMPACT_FILTERS`. I mean, that's still BIP157 working. It's just not supported by every node. It's easy to learn about lots of addrs from the addr distribution mechanisms, so I don't think that's a serious issue. > > Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so mempool min fees are very consistent across nodes. I just checked four different long running > nodes I have access to, running a variety of Bitcoin Core versions on different platforms and very different places in the world, and their minfees all agree to well within 1% > In fact, they agree on min fee much *more* closely than the size of their mempools (in terms of # of transactions). Which makes sense when you think about it, as the > > slope of the supply/demand curve is fairly flat right now. > > See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated from diverging mempool min fees from the ground iirc. https://github.com/bitcoin/bitcoin/issues/28371#issuecomment-1939604817 is the only actual data I could find in that link. I'm very curious as to what those nodes are actually doing. Possibly some pre-made node distribution is in fact setting non-standard mempool size limits. Or these are fake spy nodes with unusual behavior. > > From the point of view of a single node, an attacker can not reuse a UTXO in a replacement cycling attack. The BIP125 rules, in particular rule #4, ensure that each > > replacement consumes liquidity because each replacement requires a higher fee, at least high enough to "pay for" the bandwidth of the replacement. An attacker trying to > use the same UTXO's to cycle out multiple victim transactions has to pay a higher fee for each victim cycled out. This is because at each step of the cycle, the attacker had > to broadcast a transaction with a higher fee than some other transaction. > > This does not stay true with nVersion=3, where a package parent can be signed with a feerate > under min relay tx fee. See the second test attached in the initial full report email on replacement > cycling attacks, one can replace the child of the package and the parent is automatically evicted, > without the "pay for" bandwidth of the replacement fully covered. > > This is correct there is a minimal fee basis for each additional victim cycled out, while one can get > a very advantageous scaling effect by RC'ing the child txn. If V3 transactions is such that a child tx can be replaced at a cost that doesn't "pay for" the bandwidth of the parent that is evicted, that is a straight-forward design flaw/bug in V3 transactions. Fixing that should be pretty straight forward, at which point the attacker is again paying "fairly" with fees on each cycle. -- https://petertodd.org 'peter'[:-1]@petertodd.org -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zfmpi/9y4vFMAUtu%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* [bitcoindev] Re: OP_Expire mempool behavior 2024-03-19 15:04 ` Peter Todd @ 2024-06-20 23:09 ` Antoine Riard 0 siblings, 0 replies; 4+ messages in thread From: Antoine Riard @ 2024-06-20 23:09 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 10621 bytes --] (pursuing the conversation as the problem of transaction with perishable finality in the mempool ain't solved) > That's not really a comparable situation. If the HTLC-timeout transaction > replaces a HTLC-preimage transaction in a mempool, it will do so under ordinary > BIP125 rules, and is thus "paying for" the bandwidth with a higher fee. > Equally, in a replace-by-fee-rate scenario, it would be "paying for" its > bandwidth with a higher fee-rate. Either way, something will confirm. > In the OP_Expire case, we're talking about a transaction that becomes entirely > invalid after a point in time. If the transaction isn't mined with reasonably > high probability (eg >10%, preferably higher) an attacker may be able to > consume bandwidth indefinitely at little to no cost. In my view, there is a generic concept of "perishable transactions", i.e transactions of which the broadcast might be wasted by either a candidate replacement or expiring due to future semantics like op_expire. This is correct that the latter is a bit different as there is no guarantee that an on-chain fee is paid (be it replace-by-fee or replace-by-fee-rate). However, from the viewpoint of the transaction-relay node there is still a probability that when the HTLC-preimage broadcast time is near `cltv_expiry`, the broadcast is "wasted" as it might be replaced immediately by the HTLC-timeout, even before it's fully propagated on the whole transaction-relay topology. I think you can reduce the observation in some LN configuration for an attacker to waste transaction-relay bandwidth, though there is a notable minimum bar, the attacker might have to bear channel on-chain funding cost. > Similar to what I wrote above, in altruistic re-broadcasting, the attacker > doing the replacement cycling attack has already paid for the bandwidth > consumed in broadcasting the replaced transaction because they paid fees for > the cycling attack. Nothing more needs to be done beyond existing RBF/RBFR > rules to avoid DoS attacks. And while I share the opinon that for a classic altruistic re-broadcasting, an attacker doing the replacement is paying for the bandwidth, this might be restrained by the caveat laid out above, namely exploiting the settlement timing of a payment channel network to drift the altruistic re-broadcasting behavior to a maximum of concurrent propagation situation where the bandwidth is wasted. > I mean, that's still BIP157 working. It's just not supported by every node. > It's easy to learn about lots of addrs from the addr distribution mechanisms, > so I don't think that's a serious issue. Yes, you can say it's still working though note how a limited number of BIP157 peers can open the doors to other risks, e.g privacy issues. > I'm very curious as to what those nodes are actually doing. Possibly some > pre-made node distribution is in fact setting non-standard mempool size limits. > Or these are fake spy nodes with unusual behavior. I must say I have not investigated further myself in deep why some nodes sounds to run with lower mempool size, a likely explanation like you're pointing to is pre-made node running on raspi devices (with already other pre-configured services running), where mempool transaction buffering can be an issue. > If V3 transactions is such that a child tx can be replaced at a cost that > doesn't "pay for" the bandwidth of the parent that is evicted, that is a > straight-forward design flaw/bug in V3 transactions. Fixing that should be > pretty straight forward, at which point the attacker is again paying "fairly" > with fees on each cycle. This is correct that V3 transactions might still have open design issues, w.r.t parent package under mempool min transaction relay fees. Best, Antoine Le mercredi 20 mars 2024 à 20:52:58 UTC, Peter Todd a écrit : > (replying manually with a cut-n-paste due to a mailing list delivery issue) > > > > > > nodes should require higher minimum relay fees for transactions > close to > > > > their expiration height to ensure we don’t waste bandwidth on > transactions > > > > that have no potential to be mined > > > > I think this concern can be raised on _today_ LN second-stage > transactions (HTLC-preimage / HTLC-timeout), > > when a HTLC-preimage is broadcast near "cltv_expiry". LN routing nodes > will automatically go to broadcast an > > on-chain HTLC-timeout transaction. Probabilistically, we're wasting > bandwidth on transactions that _might_ have > > lower odds to be mined. > > That's not really a comparable situation. If the HTLC-timeout transaction > replaces a HTLC-preimage transaction in a mempool, it will do so under > ordinary > BIP125 rules, and is thus "paying for" the bandwidth with a higher fee. > Equally, in a replace-by-fee-rate scenario, it would be "paying for" its > bandwidth with a higher fee-rate. Either way, something will confirm. > > In the OP_Expire case, we're talking about a transaction that becomes > entirely > invalid after a point in time. If the transaction isn't mined with > reasonably > high probability (eg >10%, preferably higher) an attacker may be able to > consume bandwidth indefinitely at little to no cost. > > > > If you already have a need to make such transactions, you can argue > that the > > > marginal cost to also use up that bandwidth is low. But that's already > the case > > > with RBF: we allow any transaction to be replaced with RBF for a (by > default) > > > 1sat/vB additional cost to "pay for" the bandwidth of that replacement. > > > OP_EXPIRE does not change this situation: you're still paying for an > additional > > > 1sat/vB cost over the replaced transaction, as eventually one of your > > > replacements will get mined. > > > > I think yes this is indeed more a replacement issue, nothing new > introduced by OP_EXPIRE finality time-bounding semantics. > > However, I think it's more an issue if we introduce things like > altruistic re-broadcasting. > > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022188.html > > > > Certainly, the re-broadcast could favor transactions with higher odds of > being mined, which naively should match RBF rules. > > Similar to what I wrote above, in altruistic re-broadcasting, the attacker > doing the replacement cycling attack has already paid for the bandwidth > consumed in broadcasting the replaced transaction because they paid fees > for > the cycling attack. Nothing more needs to be done beyond existing RBF/RBFR > rules to avoid DoS attacks. > > > And by the same way taking time to answer the open questions on this > thread from the old mailing list: > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022224.html > > > > > Are you claiming that BIP157 doesn't work well? In my experience it > does. > > > > I've not checked recently, though from research memory a while back the > numbers of BIP157 services offering peers > > was in the range of ~10 / 100. > > > > One can check by collecting nVersions messages from peers with > `NODE_COMPACT_FILTERS`. > > I mean, that's still BIP157 working. It's just not supported by every node. > It's easy to learn about lots of addrs from the addr distribution > mechanisms, > so I don't think that's a serious issue. > > > > Huh? Bitcoin nodes almost always use the same mempool limit, 300MB, so > mempool min fees are very consistent across nodes. I just checked four > different long running > nodes I have access to, running a variety of > Bitcoin Core versions on different platforms and very different places in > the world, and their minfees all agree to well within 1% > In fact, they > agree on min fee much *more* closely than the size of their mempools (in > terms of # of transactions). Which makes sense when you think about it, as > the > > > slope of the supply/demand curve is fairly flat right now. > > > > See https://github.com/bitcoin/bitcoin/pull/28488 which is motivated > from diverging mempool min fees from the ground iirc. > > https://github.com/bitcoin/bitcoin/issues/28371#issuecomment-1939604817 > is the > only actual data I could find in that link. > > I'm very curious as to what those nodes are actually doing. Possibly some > pre-made node distribution is in fact setting non-standard mempool size > limits. > Or these are fake spy nodes with unusual behavior. > > > > From the point of view of a single node, an attacker can not reuse a > UTXO in a replacement cycling attack. The BIP125 rules, in particular rule > #4, ensure that each > > > replacement consumes liquidity because each replacement requires a > higher fee, at least high enough to "pay for" the bandwidth of the > replacement. An attacker trying to > use the same UTXO's to cycle out > multiple victim transactions has to pay a higher fee for each victim cycled > out. This is because at each step of the cycle, the attacker had > to > broadcast a transaction with a higher fee than some other transaction. > > > > This does not stay true with nVersion=3, where a package parent can be > signed with a feerate > > under min relay tx fee. See the second test attached in the initial full > report email on replacement > > cycling attacks, one can replace the child of the package and the parent > is automatically evicted, > > without the "pay for" bandwidth of the replacement fully covered. > > > > This is correct there is a minimal fee basis for each additional victim > cycled out, while one can get > > a very advantageous scaling effect by RC'ing the child txn. > > If V3 transactions is such that a child tx can be replaced at a cost that > doesn't "pay for" the bandwidth of the parent that is evicted, that is a > straight-forward design flaw/bug in V3 transactions. Fixing that should be > pretty straight forward, at which point the attacker is again paying > "fairly" > with fees on each cycle. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/d9f8f4dc-e772-4383-8024-1e67695f5685n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 13526 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-06-20 23:58 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-03-13 3:32 [bitcoindev] OP_Expire mempool behavior Peter Todd 2024-03-16 18:21 ` [bitcoindev] " Antoine Riard 2024-03-19 15:04 ` Peter Todd 2024-06-20 23:09 ` Antoine Riard
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox