Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Peter Todd via bitcoin-dev]

On Tue, Dec 06, 2022 at 12:39:40AM -0500, Peter Todd via bitcoin-dev wrote:
> 10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by
> default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes 
> on
> the network. When a node learns of a new block, it tells all it's peers that
> the new block exists.
> 
> For your censorship to work, there has to be a substantial propability that a
> miner *only* runs a single node (they don't), that has no incoming peers, and
> all 8 peers of that node happen to be one of your 20 censoring nodes.
> Obviously, since the probability of a given peer being a censoring node is
> 20/5000, all 8 being censored is extraordinarily unlikely.
> 
> Even if you ran so many nodes that 20% of the entire network was censoring, 
> the
> probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256%
> 
> 
> This is an example of information being hard to censor and easy to spread. In
> fact, for full-rbf this same math works in our favor: for a node to have a 50%
> chance of connecting to at least one full-rbf peer, just 8.3% of the network
> needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes.
> 
> The percolation threshold doesn't need to be met for this to be succesful,
> because someone to just run a full-rbf node that connects to every single
> listening node simultaneously.

FYI here's a percolation simulator for full-rbf:

https://github.com/mzumsande/fullrbf_simulation

It finds similar results to my math above.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Peter Todd via bitcoin-dev]

On Mon, Dec 05, 2022 at 09:20:58AM -0300, El_Hoy wrote:
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
> 
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).

For the record, I do not and have never had commit access to anything under
https://github.com/bitcoin

The last time I contributed to Bitcoin Core was in Mar 1st 2017, and that was
to add an explanatory comment. Pretty much the only reason why you know my name
is I'm very good at argument and critique, I come up with some good ideas, and
conference organizers love to put me on stage.

> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.

You do not understand the percolation model.

10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by
default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes on
the network. When a node learns of a new block, it tells all it's peers that
the new block exists.

For your censorship to work, there has to be a substantial propability that a
miner *only* runs a single node (they don't), that has no incoming peers, and
all 8 peers of that node happen to be one of your 20 censoring nodes.
Obviously, since the probability of a given peer being a censoring node is
20/5000, all 8 being censored is extraordinarily unlikely.

Even if you ran so many nodes that 20% of the entire network was censoring, the
probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256%


This is an example of information being hard to censor and easy to spread. In
fact, for full-rbf this same math works in our favor: for a node to have a 50%
chance of connecting to at least one full-rbf peer, just 8.3% of the network
needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes.

The percolation threshold doesn't need to be met for this to be succesful,
because someone to just run a full-rbf node that connects to every single
listening node simultaneously.


Anyway, as others' have pointed out, you're idea is also broken in other ways.
But I thought it'd be worth pointing out how futile it is to even try.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in immediate danger

[Peter Todd via bitcoin-dev]

On Fri, Dec 02, 2022 at 05:35:39PM -0500, Antoine Riard via bitcoin-dev wrote:
> To recall, the original technical motivation of this option, and the wider
> smoother deployment was to address a DoS vector affecting another class of
> use-case: multi-party transactions like coinjoin and contracting protocols
> like Lightning [2] [3]. All of them expect to generate economic flows and
> corresponding mining income. Since then, alternative paths to solve this
> DoS vector have been devised, all with their own trade-offs and conceptual
> issues [4] [5].



> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html

To be clear, these alternative paths all negatively impact privacy as they're
creating yet more ways for bad actors such as Chainalysis to deanonymize
transactions. We have a fundamental political tradeoff between the few
centralized services trying to accept unconfirmed txs, and the huge number of
users - everyone else - who desires privacy.

A big part of the promise of taproot was that we'd be able to eventually
greatly improve the anonymity set of all transactions by making multi-party
transactions indistinguishable from any other transaction. That's a huge part
of why the community fought for taproot adoption.

Your proposal [5] that multi-party protocols use a different nVersion to signal
full-rbf in their txouts negates that anonymity set for the obvious reason that
single-party wallets are discouraged from using it by the fact that a few
services like Bitrefill complain about RBF transactions. Indeed, since
nVersion=3 transactions are non-standard, we additionally have the problem that
many more wallets won't even see such payments until a confirmation, or in some
cases due to bugs, never.


Worse, this trade-offs is fundamental: it is impossible to design such a
protocol without harming privacy. Why? Let's assume such a protocol was
possible. To be compatible with how unconfirmed txs are accepted today the
protocol would have to have the following two simultaneous properties:

1) Zeroconf services would need to be able to inspect the tx data and determine
   whether or not the txout had opted into full-rbf.
2) Chainalysis services would need to be unable to inspect the tx data and
   determine whether or not the txout had opted into full-rbf.

This is an obvious contradiction, and the only alternative of commit-reveal
schemes is ridiculous and would *itself* create yet another privacy impact. We
do not need any further technical debate on this issue: this is a political
tradeoff between a few centralized services and all other users that needs to
be decied by the community. No different than the blocksize wars.


The v3 proposal Suhas mentions in [4] has similar privacy issues: again we're
forcing a class of multiparty protocols to create transactions that are clearly
identified as being multiparty. In this case the privacy impact isn't as stark,
because the common case of cooperative actions in Lightning can use v2
transactions. But this is still a privacy impact that could be avoided by
better mempool design. Eg as I showed in:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021175.html

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 91, Issue 5

[John Carvalho via bitcoin-dev]

Antoine,


> In the direction of removing the current option from Bitcoin Core, I think
> the prerequisite to address are the qualification of enough economic flows
> at risk and the presence of a sizable loss in miners income.


Are such prerequisites for feature removal published somewhere? I don't see
any reason why removing a controversial change should be harder than adding
one. Generally, it is impossible to definitively attribute any change in
network condition to one thing in such a complex system, and also difficult
to know how much time is required to express negative effects. The whole
argument here is to prevent disruption of the status quo that has lasted
the whole history of Bitcoin, to avoid taking a speculative risk that
full-RBF, at the expense of zero-conf, is maybe better for miners... or
something.

Further, I feel the mempoolfullrbf feature was rushed through while this
controversy was growing, specifically to attempt to achieve this imaginary
protection of "sorry, that ship has sailed" which indicates an agenda that
is counter to greater social consensus and status quo. We should not
incentivize such behavior further by allowing this sort of feature
sainthood.

Beyond that, I think there is still the open question if we (we, as the
> Bitcoin protocol development community, with all its stakeholders) should
> restrain user choice in policy settings in the name of preserving mining
> income and established use-case stability.


Removing the mempoolfullrbf feature is the opposite of restraining user
choice.

First, any incentivized user can still create and distribute patches for
any given mempool policy, regardless of whether we remove the feature from
Core, but it is important to note that extremely few have felt the need to
do so in the past.

Second, the very debate here is about how it is mempoolfullrbf that removes
the user choice of zero-conf services. With a first-seen policy in place,
users have *more* options, and Bitcoin is thus more useful, and thus more
valuable to everyone. This is evident in that the feature of full-rbf is
that it overrides any ability for users to signal intent of how they wish
their transaction to be handled by nodes and miners. This is useful info to
miners, as they make more money by facilitating use cases than by
fee-minimizers painting everything as RBF. User-signaling is a useful
feature for the mempool, full-RBF removes that feature.

Third, when Bitcoin Core adds special support for specific policies, it
positions itself as a political authority and influencer. It is not Core's
place to support one subjective policy more than another, particularly when
it conflicts with years of status quo and breaks the current user space,
and likely resulting in more doublespent user experiences.

To recall, the original technical motivation of this option, and the wider
> smoother deployment was to address a DoS vector affecting another class of
> use-case: multi-party transactions like coinjoin and contracting protocols
> like Lightning [2] [3]. All of them expect to generate economic flows and
> corresponding mining income. Since then, alternative paths to solve this
> DoS vector have been devised, all with their own trade-offs and conceptual
> issues [4] [5].


I am particularly skeptical that users sending Bitcoin to themselves
(coinjoin) could ever be more incentive-compatible than fast-paced commerce
& priority competition. I am also skeptical that mempoolfullrbf actually
solves LN risks any better than opt-in RBF by default by LN implementations
and wallets.

Further, zero-conf support reduces friction for LN adoption by allowing us
to make instant, seamless UX within wallets when onboarding, rebalancing,
and splicing.

--
John Carvalho
CEO, Synonym.to 



>
> Date: Fri, 2 Dec 2022 17:35:39 -0500
> From: Antoine Riard 
> To: Bitcoin Protocol Discussion
> 
> Subject: [bitcoin-dev] Fwd: [Opt-in full-RBF] Zero-conf apps in
> immediate   danger
> Message-ID:
> <
> calzpt+hffwy4xecnzj3xlqnaumpedjrwvncsra3vsgqfuxn...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Daniel,
>
> >From my understanding of GAP600, you're operating a zero-conf risk
> analysis
> business, which is integrated and leveraged by payment processors/liquidity
> providers and merchants. A deployment of fullrbf by enough full-node
> operators and a subset of the mining hashrate would lower the cost of
> double-spend attack by lamda users, therefore increasing the risk exposure
> of your users. This increased risk exposure could lead you to alter the
> acceptance of incoming zero-conf transactions, AFAICT in a similar
> reasoning as exposed by Bitrefill earlier this year [0].
>
> About the statistics you're asking for considerations, few further
> questions, on those 1.5M transactions per month, a) how many are
> Bitcoin-only (as I understand to be multi-cryptocurrencies), b) how many
> are excluded from zeroconf due to 

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Erik Aronesty via bitcoin-dev]

note: if it was possible to enforce this, we wouldn't need proof of work at
all.   since it isn't possible, proof of work is strictly necessary.


On Mon, Dec 5, 2022 at 9:53 AM Rijndael via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning,
>
> That sounds like a very dangerous mode of operation. You can already hand
> a transaction to a miner privately. I hand a transaction to a miner with
> some reasonable fee, and then I go and broadcast a different transaction
> with a minimal fee that spends the same inputs. The whole network
> (including the miner I handed the tx to) could all be running with a strict
> first-seen mempool policy, but we can still have a situation where the
> miner creates a block with a different transaction from what you see in
> your mempool. If anytime this happens, the nodes running your proposed rule
> drop the block, then anyone can fork those nodes off the network whenever
> they want.
>
> Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt
> to) promise consistency across mempools. Making a consensus rule that
> enforces mempool consistency is a recipe for (unintended?) chainsplits.
>
> - rijndael
>
>
> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:
>
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
>
> Regards.
>
> ---  Eloy
>
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
>> wrote:
>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
>> wrote:
>> > > FYI I've gotten a few hundred dollars worth of donations to this
>> effort, and
>> > > have raised the reward to about 0.02 BTC, or $400 USD at current
>> prices.
>> >
>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more
>> than
>> enough donations to give another run at it (the majority was donated
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>> >
>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>> >
>> > The block it was claimed in seems to have been about an hour after the
>> > default mempool filled up:
>> >
>> > https://twitter.com/murchandamus/status/1592274621977477120
>> >
>> > That block actually seems to have included two
>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>> > (309sat/vb):
>> >
>> >
>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar,
>> along
>> the same lines:
>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>
>> I double-spent the txin of the high fee tx that got mined. But I
>> mistakenly had
>> RBF enabled in that double-spend, so while it propagated initially, I
>> believe
>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb
>> tx.
>>
>> > Timeline (utc) to me looks like:
>> >
>> >  - 13:12 - block 763148 is mined: last one that had a min fee <
>> 1.5sat/vb
>> >  - 13:33 -
>> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>> >is announced and propogates widely (1.2sat/vb)
>> >  - 18:42 -
>> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>> >is announced and propogates widely (1.2sat/vb)
>> >  - 21:52 - ba967010 tx is announced and propogates widely, since
>> >conflicting tx 746daab9 has been removed from default
>> >  mempools
>> >  - 21:53 - murch tweets about default mempool filling up
>> >  - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>> >conflicting tx f503868 has already been removed from default
>> >  mempools
>>
>> Is that 22:03 time for 397 from your node's 

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[El_Hoy via bitcoin-dev]

You are doing quite big claims without explaining those, let me add a few
questions inline:

On Mon, Dec 5, 2022 at 10:39 AM Greg Sanders  wrote:

This will greatly centralize the network as well as not actually achieve
> the intended goal which is literally impossible.
>

Why would this centralize the network? Adding more nodes that propagate
valid blocks on the network should be good. Also, I cannot see why you say
it is "literally impossible", could you give any explanation for your words?

On Mon, Dec 5, 2022 at 11:53 AM Rijndael via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning,
>
> That sounds like a very dangerous mode of operation. You can already hand
> a transaction to a miner privately. I hand a transaction to a miner with
> some reasonable fee, and then I go and broadcast a different transaction
> with a minimal fee that spends the same inputs. The whole network
> (including the miner I handed the tx to) could all be running with a strict
> first-seen mempool policy, but we can still have a situation where the
> miner creates a block with a different transaction from what you see in
> your mempool. If anytime this happens, the nodes running your proposed rule
> drop the block, then anyone can fork those nodes off the network whenever
> they want.
>
I cannot see the danger you are talking about, sending a transaction
directly to a miner does not sound like anyone can do (except a miner) and
is not the main workflow, usually transactions propagate on the network and
it is quite difficult to have different miners with different opt-out-rbb
transactions that spends the same input. In that strange scenario that you
mention, the miner generated block might be lost if another miner creates
an alternative block.

> Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt
> to) promise consistency across mempools. Making a consensus rule that
> enforces mempool consistency is a recipe for (unintended?) chainsplits.
>
That is not entirely true for opt-out rbf transactions, as most 0conf
setups are based on such consistency. And breaking a consensus rule always
leads to a chainsplit. For example when a miner creates a block that
double-spends an input, the normal bitcoin flow is a chain-split. That is
not an unintended chainsplit, is a consensus rule enforcement.

> - rijndael
>
>
> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:
>
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
>
> Regards.
>
> ---  Eloy
>
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
>> wrote:
>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
>> wrote:
>> > > FYI I've gotten a few hundred dollars worth of donations to this
>> effort, and
>> > > have raised the reward to about 0.02 BTC, or $400 USD at current
>> prices.
>> >
>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more
>> than
>> enough donations to give another run at it (the majority was donated
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>> >
>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>> >
>> > The block it was claimed in seems to have been about an hour after the
>> > default mempool filled up:
>> >
>> > https://twitter.com/murchandamus/status/1592274621977477120
>> >
>> > That block actually seems to have included two
>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>> > (309sat/vb):
>> >
>> >
>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar,
>> along
>> the same lines:
>> 

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Michael Folkson via bitcoin-dev]

> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun 
> wallet developers) could work on a fork and run several nodes with such 
> functionality.

Daniel Lipshitz has been working on BSV apparently [0] so I guess anything is 
possible with him. But as others have said turning a mempool policy issue 
(users have always been free to choose whatever policy they like with zero 
chain split risk) into a consensus issue and a contentious soft fork issue at 
that would not be advised. I highly doubt any of the long term Muun 
contributors would want to support a contentious soft fork and fight a 
consensus rule war on this.

[0]: 
https://coingeek.com/gap600-ceo-daniel-lipshitz-talks-bsv-powered-stablecoins-on-coingeek-backstage-video/
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

--- Original Message ---
On Monday, December 5th, 2022 at 16:12, Rijndael via bitcoin-dev 
 wrote:

> Good morning,
>
> That sounds like a very dangerous mode of operation. You can already hand a 
> transaction to a miner privately. I hand a transaction to a miner with some 
> reasonable fee, and then I go and broadcast a different transaction with a 
> minimal fee that spends the same inputs. The whole network (including the 
> miner I handed the tx to) could all be running with a strict first-seen 
> mempool policy, but we can still have a situation where the miner creates a 
> block with a different transaction from what you see in your mempool. If 
> anytime this happens, the nodes running your proposed rule drop the block, 
> then anyone can fork those nodes off the network whenever they want.
>
> Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt 
> to) promise consistency across mempools. Making a consensus rule that 
> enforces mempool consistency is a recipe for (unintended?) chainsplits.
>
> - rijndael
>
> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:
>
>> The only option I see against the attack Peter Todd is doing to opt-in RBF 
>> and 0Conf bitcoin usage is working on a bitcoin core implementation that 
>> stops propagation of full-rbf replaced blocks. Running multiple of such 
>> nodes on the network will add a risk to miners that enable full-rbf that 
>> would work as an incentive against that.
>>
>> Obviously that would require adding an option on bitcoin core (that is not 
>> technically but politically difficult to implement as Petter Todd already 
>> have commit access to the main repository).
>>
>> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun 
>> wallet developers) could work on a fork and run several nodes with such 
>> functionality. As far as I understand the percolation model, with 10 to 20 
>> nodes running such a rule would create a significant risk for full-rbf 
>> miners.
>>
>> Regards.
>>
>> --- Eloy
>>
>> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev 
>>  wrote:
>>
>>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev 
>>> wrote:
 On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote:
 > FYI I've gotten a few hundred dollars worth of donations to this effort, 
 > and
 > have raised the reward to about 0.02 BTC, or $400 USD at current prices.

 Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>>
>>> I'm turning it back on when (if) the mempool settles down. I've got more 
>>> than
>>> enough donations to give another run at it (the majority was donated 
>>> privately
>>> FWIW). There's a risk of the mempool filling up again of course; hard to 
>>> avoid
>>> that.
>>>
>>> Right now of course it's really easy to double spend with the obvious
>>> low-fee/high-fee method as the min relay fee keeps shifting.
>>>
 https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c

 The block it was claimed in seems to have been about an hour after the
 default mempool filled up:

 https://twitter.com/murchandamus/status/1592274621977477120

 That block actually seems to have included two
 alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
 (309sat/vb):

 https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>>
>>> The second is because I turned down the full-rbf reward to more normal fee
>>> levels. There's also another full-rbf double-spend from the Bob calendar, 
>>> along
>>> the same lines: 
>>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>>
>>> I double-spent the txin of the high fee tx that got mined. But I mistakenly 
>>> had
>>> RBF enabled in that double-spend, so while it propagated initially, I 
>>> believe
>>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb 
>>> tx.
>>>
 Timeline (utc) to me looks like:

 - 13:12 - 

Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)

[John Carvalho via bitcoin-dev]

>
> The perception seems to be that Core adding the full RBF option is
> increasing the risk to zero-conf users, but I'm not convinced that that is
> the case.


If this "perception" were not true, RBF & full-RBF would not be necessary
at all. Think about it.

It's always been the risk of getting double-spent out of hundreds or
> thousands of bitcoins that's worth seriously worrying about, which is much
> more the kind of attack a determined attacker is able to carry out.


The risk exposure to merchants providing zero-conf acceptance as a service
is finite, capped by their risk-tolerance, and capped by the current block
exposure. Merchants cap their exposure to be an amount worth less than the
value of this service.

It is highly inefficient and difficult for a miner to pull off an
industry-wide attack across diverse merchants to capture the current
maximum exposure in any given block, not to mention the enormous surface
area of legal risk across jurisdictions...

I don't think zero-conf opponents properly grasp that the risk exposure is
exact and perfectly, trustlessly manageable. I would like the opportunity
to spec the methods Bitrefill, Synonym, and most such merchants, use to
make it standard practice, as it is cheaper for merchants and more
convenient to Bitcoin consumers when merchants behave this way.

As has been pointed out by may others before, full RBF is aligned with
> miner (and user) economic incentives


This is a theory, not a fact. I can refute this theory by pointing out
several aspects:

1.  RBF is actually a fee-minimization feature that allows users to game
the system to spend the *least* amount in fees that correlates to their
time-preference. Miners earn less when fees can be minimized (obviously).
This feature also comes at an expense (albeit small) to nodes providing
replacement service and propagation.

2. Miners care about max fees per block, not slightly increased fees on a
minority % of incidentally replaced txns when they happen to need it. They
want the most txns for the highest price per *block*. In order to qualify
for zero-conf acceptance, merchants require that the fee rate match or
exceed an amount that makes the txn likely to be included in the very next
block. This creates a priority competition from users with high
time-preference. This creates not only more fees for miners, but more txns
from more people using the chain for commerce. This is evidenced by stats
provided recently to this mailing list, but here are more numbers from
Bitrefill:
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282

3. Miners ultimately want what users want, as more users = more txns = more
fees = higher BTC price. For all of Bitcoin's history, more users have
wanted zero-conf than replacements. This is evidenced by first-seen policy
thriving for years without disruption (until engineers actively disrupted
it, using fallible theories as justification). This is also evidenced by
the UASF battle where miners capitulated to providing the type of blocks
that users demanded, to avoid uncertainty.

4. A replaceable mempool is inherently less valuable than a first-seen
policy mempool in that Bitcoin is ultimately a ledger for a *payments*
system where people are trying to pay and be paid with certainty. A
full-RBF system would result in more real-world doublespends to existing
merchants and p2p commerce, as it is impossible to fully teach all aspects
of Bitcoin dynamics to users, particularly when they have enjoyed many
years of first-seen behavior as status quo.

Zero-conf and first-seen policies are clearly more
incentive-compatible than RBF outright for these reasons.

The long-term 'what to do about it' is to use Lightning if you want fast
> payments with risk-free instant settlement


Many zero-conf proponents work on the bleeding edge of supporting
Lightning, including myself. Lightning is not risk-free and the base layer
should not be assuming it as a primary dependency for commercial payments.
The UX and complexity of supporting Lightning is still considerable,
adoption is still very low, and there are many unsolved attack vectors and
risks that remain untested due to Lightning's low prevalence.

Further, zero-conf is also useful as a tool in improving Lightning
onboarding, rebalancing, splicing, and UX overall. Bitcoin second-layers
are only as good as the base layer, everything else is a tradeoff.

Bitcoin core 24 with the full RBF option is already out in the wild at
> around 5%+ of running nodes and growing, so it's too late to kill it.


This is pure speculation. If Bitcoin Core publishes an update without the
mistakenly-rushed feature, the mempoolfullrbf movement is likely to die on
the vine as users opt into the latest versions more and more, as evidenced
by all older versions decreasing in usage over time. The incentive to run
old versions, just to be able to force non-RBF txns to be treated as RBF,
is lower than the incentive and likelihood of updating. 

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Rijndael via bitcoin-dev]

Good morning,

That sounds like a very dangerous mode of operation. You can already hand a 
transaction to a miner privately. I hand a transaction to a miner with some 
reasonable fee, and then I go and broadcast a different transaction with a 
minimal fee that spends the same inputs. The whole network (including the miner 
I handed the tx to) could all be running with a strict first-seen mempool 
policy, but we can still have a situation where the miner creates a block with 
a different transaction from what you see in your mempool. If anytime this 
happens, the nodes running your proposed rule drop the block, then anyone can 
fork those nodes off the network whenever they want.

Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt to) 
promise consistency across mempools. Making a consensus rule that enforces 
mempool consistency is a recipe for (unintended?) chainsplits.

- rijndael

On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:

> The only option I see against the attack Peter Todd is doing to opt-in RBF 
> and 0Conf bitcoin usage is working on a bitcoin core implementation that 
> stops propagation of full-rbf replaced blocks. Running multiple of such nodes 
> on the network will add a risk to miners that enable full-rbf that would work 
> as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not 
> technically but politically difficult to implement as Petter Todd already 
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun 
> wallet developers) could work on a fork and run several nodes with such 
> functionality. As far as I understand the percolation model, with 10 to 20 
> nodes running such a rule would create a significant risk for full-rbf miners.
>
> Regards.
>
> --- Eloy
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev 
>  wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev 
>> wrote:
>>> On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev wrote:
>>> > FYI I've gotten a few hundred dollars worth of donations to this effort, 
>>> > and
>>> > have raised the reward to about 0.02 BTC, or $400 USD at current prices.
>>>
>>> Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more than
>> enough donations to give another run at it (the majority was donated 
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to 
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>>>
>>> The block it was claimed in seems to have been about an hour after the
>>> default mempool filled up:
>>>
>>> https://twitter.com/murchandamus/status/1592274621977477120
>>>
>>> That block actually seems to have included two
>>> alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>>> (309sat/vb):
>>>
>>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar, 
>> along
>> the same lines: 
>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>
>> I double-spent the txin of the high fee tx that got mined. But I mistakenly 
>> had
>> RBF enabled in that double-spend, so while it propagated initially, I believe
>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb tx.
>>
>>> Timeline (utc) to me looks like:
>>>
>>> - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb
>>> - 13:33 - f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>>> is announced and propogates widely (1.2sat/vb)
>>> - 18:42 - 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>>> is announced and propogates widely (1.2sat/vb)
>>> - 21:52 - ba967010 tx is announced and propogates widely, since
>>> conflicting tx 746daab9 has been removed from default
>>> mempools
>>> - 21:53 - murch tweets about default mempool filling up
>>> - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>>> conflicting tx f503868 has already been removed from default
>>> mempools
>>
>> Is that 22:03 time for 397 from your node's logs? It was originally announced
>> hours earlier. From one of my full-rbf nodes:
>>
>> 2022-11-14T14:08:37Z [mempool] replacing tx 
>> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with 
>> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for 0.00468 
>> additional fees, -1 delta bytes
>>
>>> - 22:35 - block 763189 is mined
>>> - 22:39 - block 763190 is mined
>>> - 23:11 - block 763191 is mined
>>> 

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[Greg Sanders via bitcoin-dev]

This will greatly centralize the network as well as not actually achieve
the intended goal which is literally impossible.

On Mon, Dec 5, 2022, 8:27 AM El_Hoy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
>
> Regards.
>
> ---  Eloy
>
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
>> wrote:
>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
>> wrote:
>> > > FYI I've gotten a few hundred dollars worth of donations to this
>> effort, and
>> > > have raised the reward to about 0.02 BTC, or $400 USD at current
>> prices.
>> >
>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more
>> than
>> enough donations to give another run at it (the majority was donated
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>> >
>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>> >
>> > The block it was claimed in seems to have been about an hour after the
>> > default mempool filled up:
>> >
>> > https://twitter.com/murchandamus/status/1592274621977477120
>> >
>> > That block actually seems to have included two
>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>> > (309sat/vb):
>> >
>> >
>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar,
>> along
>> the same lines:
>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>
>> I double-spent the txin of the high fee tx that got mined. But I
>> mistakenly had
>> RBF enabled in that double-spend, so while it propagated initially, I
>> believe
>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb
>> tx.
>>
>> > Timeline (utc) to me looks like:
>> >
>> >  - 13:12 - block 763148 is mined: last one that had a min fee <
>> 1.5sat/vb
>> >  - 13:33 -
>> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>> >is announced and propogates widely (1.2sat/vb)
>> >  - 18:42 -
>> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>> >is announced and propogates widely (1.2sat/vb)
>> >  - 21:52 - ba967010 tx is announced and propogates widely, since
>> >conflicting tx 746daab9 has been removed from default
>> >  mempools
>> >  - 21:53 - murch tweets about default mempool filling up
>> >  - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>> >conflicting tx f503868 has already been removed from default
>> >  mempools
>>
>> Is that 22:03 time for 397 from your node's logs? It was originally
>> announced
>> hours earlier. From one of my full-rbf nodes:
>>
>> 2022-11-14T14:08:37Z [mempool] replacing tx
>> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with
>> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for
>> 0.00468 additional fees, -1 delta bytes
>>
>> >  - 22:35 - block 763189 is mined
>> >  - 22:39 - block 763190 is mined
>> >  - 23:11 - block 763191 is mined
>> >  - 23:17 - block 763192 is mined including 397dcbe4
>> >
>> > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
>> > first three blocks, and gives similar mempool ages for those txs to what
>> > my logs report:
>> >
>> >
>> https://miningpool.observer/template-and-block/000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/0005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> 

[bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger

[angus via bitcoin-dev]

Core adding full RBF is a change of node policy that may be highly inconvenient 
for zero-conf users, but there has always been and will always be a risk of a 
double-spend for anyone that treats zero-confirmation transactions as settled. 
It's literally in the name - this transaction has zero confirmations and no 
guarantee it'll make it into a block, and so has not yet settled.


The perception seems to be that Core adding the full RBF option is increasing 
the risk to zero-conf users, but I'm not convinced that that is the case - 
someone wanting to double-spend attack you isn't going to be bothered to do so 
over a few thousand sats (unless they can do it thousands of times), and losing 
a few thousand sats to a double-spend isn't the biggest deal.


It's always been the risk of getting double-spent out of hundreds or thousands 
of bitcoins that's worth seriously worrying about, which is much more the kind 
of attack a determined attacker is able to carry out. Such a determined 
attacker is much more likely to attempt and succeed at a sybil attack, or 
directly colluding with a miner. So your zero-conf risk increases non-linearly 
as the amount of bitcoin being transacted grows. (caveat: this paragraph is 
opinion).


There does, however, seem to be a legitimate business for providing 
insurance/risk management for people that are willing to accept the zero-conf 
risk - it is pretty similar to accepting credit cards with a chargeback risk or 
any payment card with a capture risk, though there's no-one to mediate a 
dispute. On-chain is final.

But what doesn't make any sense is trying to avoid Bitcoin Core and nodes from 
adopting a full RBF policy to try to protect this use case. As has been pointed 
out by may others before, full RBF is aligned with miner (and user) economic 
incentives and is a node policy, not consensus, so you can't even tell which 
nodes are doing it nor can you prevent them from doing so. Second, Bitcoin core 
24 with the full RBF option is already out in the wild at around 5%+ of running 
nodes and growing, so it's too late to kill it.


So my point is that relying on node policy as part of your protection for 
zero-conf transaction acceptance is fragile, and should not be relied upon. The 
protocol rules have always tacitly allowed double-spending before a 
confirmation, and it has always been clear that there's no consensus on which 
transactions have occurred until they have in a block and have at-least one 
confirmation.

The long-term 'what to do about it' is to use Lightning if you want fast 
payments with risk-free instant settlement, or as above, accept the zero-conf 
risk and cover yourself with an insurance premium (e.g. a margin on 
transactions that goes into an insurance fund, and limiting max transaction 
amount so you're not exposed to uncoverable losses if you do get double-spend 
attacked)




Angus

signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty

[El_Hoy via bitcoin-dev]

The only option I see against the attack Peter Todd is doing to opt-in RBF
and 0Conf bitcoin usage is working on a bitcoin core implementation that
stops propagation of full-rbf replaced blocks. Running multiple of such
nodes on the network will add a risk to miners that enable full-rbf that
would work as an incentive against that.

Obviously that would require adding an option on bitcoin core (that is not
technically but politically difficult to implement as Petter Todd already
have commit access to the main repository).

That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
wallet developers) could work on a fork and run several nodes with such
functionality. As far as I understand the percolation model, with 10 to 20
nodes running such a rule would create a significant risk for full-rbf
miners.

Regards.

---  Eloy


On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
> wrote:
> > > FYI I've gotten a few hundred dollars worth of donations to this
> effort, and
> > > have raised the reward to about 0.02 BTC, or $400 USD at current
> prices.
> >
> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>
> I'm turning it back on when (if) the mempool settles down. I've got more
> than
> enough donations to give another run at it (the majority was donated
> privately
> FWIW). There's a risk of the mempool filling up again of course; hard to
> avoid
> that.
>
> Right now of course it's really easy to double spend with the obvious
> low-fee/high-fee method as the min relay fee keeps shifting.
>
> >
> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
> >
> > The block it was claimed in seems to have been about an hour after the
> > default mempool filled up:
> >
> > https://twitter.com/murchandamus/status/1592274621977477120
> >
> > That block actually seems to have included two
> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
> > (309sat/vb):
> >
> >
> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>
> The second is because I turned down the full-rbf reward to more normal fee
> levels. There's also another full-rbf double-spend from the Bob calendar,
> along
> the same lines:
> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>
> I double-spent the txin of the high fee tx that got mined. But I
> mistakenly had
> RBF enabled in that double-spend, so while it propagated initially, I
> believe
> it was replaced when something (someone?) rebroadcast the high-fee 397dcb
> tx.
>
> > Timeline (utc) to me looks like:
> >
> >  - 13:12 - block 763148 is mined: last one that had a min fee < 1.5sat/vb
> >  - 13:33 -
> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
> >is announced and propogates widely (1.2sat/vb)
> >  - 18:42 -
> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
> >is announced and propogates widely (1.2sat/vb)
> >  - 21:52 - ba967010 tx is announced and propogates widely, since
> >conflicting tx 746daab9 has been removed from default
> >  mempools
> >  - 21:53 - murch tweets about default mempool filling up
> >  - 22:03 - 397dcbe4 tx is announced and propogates widely, since
> >conflicting tx f503868 has already been removed from default
> >  mempools
>
> Is that 22:03 time for 397 from your node's logs? It was originally
> announced
> hours earlier. From one of my full-rbf nodes:
>
> 2022-11-14T14:08:37Z [mempool] replacing tx
> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with
> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for
> 0.00468 additional fees, -1 delta bytes
>
> >  - 22:35 - block 763189 is mined
> >  - 22:39 - block 763190 is mined
> >  - 23:11 - block 763191 is mined
> >  - 23:17 - block 763192 is mined including 397dcbe4
> >
> > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
> > first three blocks, and gives similar mempool ages for those txs to what
> > my logs report:
> >
> >
> https://miningpool.observer/template-and-block/000436aba59d8430061e0e50592215f7f263bfb1073ccac7
> >
> https://miningpool.observer/template-and-block/0005600404792bacfd8a164d2fe9843766afb2bfbd937309
> >
> https://miningpool.observer/template-and-block/0004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
> >
> > That presumably means those pools (AntPool twice and "unknown") are
> > running with large mempools that didn't kept the earlier 1.2sat/vb txs.
>
> To be clear, you think that AntPool and that other exchange is running
> with a
> larger than normal max mempool size limit? You mean those miners *did*
> keep the
> earlier 1.2sat/vb tx?