Announcement: Full-RBF Miner Bounty

Announcement: Full-RBF Miner Bounty
2022-11-02 19:02 ` alicexbt
  2022-11-08 18:16 ` Peter Todd
  
From: Peter Todd @ 2022-11-02  9:26 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]

I'm now running a full-RBf bounty program for miners.

tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
times of congestion. Miner and pool profit margins are pretty small, on the
order of $1k/block in many cases, so I know it doesn't take that much more
money to make a difference.

Why should you do this? Full-RBF/zeroconf has been discussed to death. But
tl;dr: You'll earn more money, and help transition Bitcoin to a more secure
mempool policy based on economic incentives rather than trust.


If you're a miner and want to participate, the easiest way to so is to use the
mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.

You can also just modify the code yourself by removing the opt-in RBF check.
For example against the v23.0 tag:

    $ git diff
    diff --git a/src/validation.cpp b/src/validation.cpp
    index 214112e2b..44c364623 100644
    --- a/src/validation.cpp
    +++ b/src/validation.cpp
    @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& ws)
                     // check all unconfirmed ancestors; otherwise an opt-in ancestor
                     // might be replaced, causing removal of this descendant.
                     if (!SignalsOptInRBF(*ptxConflicting)) {
    -                    return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "txn-mempool-conflict");
    +                    // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "txn-mempool-conflict");
                     }
     
                     ws.m_conflicts.insert(ptxConflicting->GetHash());

Once you've enabled full-RBF, you need a full-RBF peer. I'm running a few of
them:

    cup.nop.lol
    mug.nop.lol
    jar.nop.lol
    jug.nop.lol

These nodes run a preferential peering patch (https://github.com/bitcoin/bitcoin/pull/25600)
to ensure that full-RBF nodes are interconnected to each other and replacements
can easily propagate. Also feel free to contact me if you'd like to peer with a
private node.


If you'd like to donate to this effort, send BTC to
bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m


...and yes, I'm well aware that miners could collect this bounty in other ways,
eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not too
concerned.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-11-02  9:26 [bitcoin-dev] Announcement: Full-RBF Miner Bounty Peter Todd

  2022-11-03 13:32   ` Erik Aronesty
  2022-11-08 18:16 ` Peter Todd
  
From: alicexbt @ 2022-11-02 19:02 UTC (permalink / raw)
  To: Peter Todd;  bitcoin-dev

Hi Peter,

> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion. Miner and pool profit margins are pretty small, on the
> order of $1k/block in many cases, so I know it doesn't take that much more
> money to make a difference.

I appreciate this effort and perhaps this was all that was needed in addition to Bitcoin Core's inclusion of full rbf support. Making it default right away or enabling preferential peering with service flag in a bitcoin core release was unnecessary.

> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m

Sorry, I don't trust you based on some of the things you support on Twitter. Hopefully, others will donate and help this bounty.

/dev/fd0

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:


> I'm now running a full-RBf bounty program for miners.
> 
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion. Miner and pool profit margins are pretty small, on the
> order of $1k/block in many cases, so I know it doesn't take that much more
> money to make a difference.
> 
> Why should you do this? Full-RBF/zeroconf has been discussed to death. But
> tl;dr: You'll earn more money, and help transition Bitcoin to a more secure
> mempool policy based on economic incentives rather than trust.
> 
> 
> If you're a miner and want to participate, the easiest way to so is to use the
> mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
> 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.
> 
> You can also just modify the code yourself by removing the opt-in RBF check.
> For example against the v23.0 tag:
> 
> $ git diff
> diff --git a/src/validation.cpp b/src/validation.cpp
> index 214112e2b..44c364623 100644
> --- a/src/validation.cpp
> +++ b/src/validation.cpp
> @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& ws)
> // check all unconfirmed ancestors; otherwise an opt-in ancestor
> // might be replaced, causing removal of this descendant.
> if (!SignalsOptInRBF(*ptxConflicting)) {
> - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "txn-mempool-conflict");
> + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "txn-mempool-conflict");
> }
> 
> ws.m_conflicts.insert(ptxConflicting->GetHash());
> 
> 
> Once you've enabled full-RBF, you need a full-RBF peer. I'm running a few of
> them:
> 
> cup.nop.lol
> mug.nop.lol
> jar.nop.lol
> jug.nop.lol
> 
> These nodes run a preferential peering patch (https://github.com/bitcoin/bitcoin/pull/25600)
> to ensure that full-RBF nodes are interconnected to each other and replacements
> can easily propagate. Also feel free to contact me if you'd like to peer with a
> private node.
> 
> 
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> 
> 
> ...and yes, I'm well aware that miners could collect this bounty in other ways,
> eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not too
> concerned.
> 
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


 permalink raw reply	[|nested]
2022-11-02 19:02 ` alicexbt

  2022-11-09 12:14     ` email
  
From: Erik Aronesty @ 2022-11-03 13:32 UTC (permalink / raw)
  To: alicexbt, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4452 bytes --]

actually, peter makes an important point here

technically, all we need is for *miners* to consistently mine "full rbf"

as long as they do, businesses that accept 0conf will have to adjust their
risk accordingly, and the problem of misaligned incentives is resolved

i don't think it matters what non-mining users do nearly as much


On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Hi Peter,
>
> > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees
> to
> > reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in
> > times of congestion. Miner and pool profit margins are pretty small, on
> the
> > order of $1k/block in many cases, so I know it doesn't take that much
> more
> > money to make a difference.
>
> I appreciate this effort and perhaps this was all that was needed in
> addition to Bitcoin Core's inclusion of full rbf support. Making it default
> right away or enabling preferential peering with service flag in a bitcoin
> core release was unnecessary.
>
> > If you'd like to donate to this effort, send BTC to
> > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
>
> Sorry, I don't trust you based on some of the things you support on
> Twitter. Hopefully, others will donate and help this bounty.
>
> /dev/fd0
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
> > I'm now running a full-RBf bounty program for miners.
> >
> > tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees
> to
> > reward miners that turn on full-RBF. I'm starting small, just
> ~$100/block in
> > times of congestion. Miner and pool profit margins are pretty small, on
> the
> > order of $1k/block in many cases, so I know it doesn't take that much
> more
> > money to make a difference.
> >
> > Why should you do this? Full-RBF/zeroconf has been discussed to death.
> But
> > tl;dr: You'll earn more money, and help transition Bitcoin to a more
> secure
> > mempool policy based on economic incentives rather than trust.
> >
> >
> > If you're a miner and want to participate, the easiest way to so is to
> use the
> > mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 release (eg the
> > 24.0rc3 tag), or use the mempoolreplacement=fee option in Bitcoin Knots.
> >
> > You can also just modify the code yourself by removing the opt-in RBF
> check.
> > For example against the v23.0 tag:
> >
> > $ git diff
> > diff --git a/src/validation.cpp b/src/validation.cpp
> > index 214112e2b..44c364623 100644
> > --- a/src/validation.cpp
> > +++ b/src/validation.cpp
> > @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args,
> Workspace& ws)
> > // check all unconfirmed ancestors; otherwise an opt-in ancestor
> > // might be replaced, causing removal of this descendant.
> > if (!SignalsOptInRBF(*ptxConflicting)) {
> > - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> > + // return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY,
> "txn-mempool-conflict");
> > }
> >
> > ws.m_conflicts.insert(ptxConflicting->GetHash());
> >
> >
> > Once you've enabled full-RBF, you need a full-RBF peer. I'm running a
> few of
> > them:
> >
> > cup.nop.lol
> > mug.nop.lol
> > jar.nop.lol
> > jug.nop.lol
> >
> > These nodes run a preferential peering patch (
> https://github.com/bitcoin/bitcoin/pull/25600)
> > to ensure that full-RBF nodes are interconnected to each other and
> replacements
> > can easily propagate. Also feel free to contact me if you'd like to peer
> with a
> > private node.
> >
> >
> > If you'd like to donate to this effort, send BTC to
> > bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> >
> >
> > ...and yes, I'm well aware that miners could collect this bounty in
> other ways,
> > eg by raising minimum fees. Doing that also breaks zeroconf, so I'm not
> too
> > concerned.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6096 bytes --]

 permalink raw reply	[|nested]
2022-11-02  9:26 [bitcoin-dev] Announcement: Full-RBF Miner Bounty Peter Todd
  2022-11-02 19:02 ` alicexbt

  2022-11-15  5:36   ` Anthony Towns
  
From: Peter Todd @ 2022-11-08 18:16 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Wed, Nov 02, 2022 at 05:26:27AM -0400, Peter Todd via bitcoin-dev wrote:
> I'm now running a full-RBf bounty program for miners.
> 
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion.

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.

To be clear, this doesn't mean there will always be a $400 fee tx in the
full-rbf mempool. I have to take a number of precautions to avoid the
double-spend tx being mined by accident, such as only spending txouts with >2
confirmations, and waiting significant amounts of time before the 1st
transaction is sent to allow for maximal propagation.

> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-11-03 13:32   ` Erik Aronesty

  
From: email @ 2022-11-09 12:14 UTC (permalink / raw)
  To: Erik Aronesty, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 5046 bytes --]



> technically, all we need is for *miners* to consistently mine "full
> rbf"

There's another important point I think:

technically, all we need is for *miners* to consistently mine the 
highest fee-rate transaction (or the one with the most incentive).

Miners could probably be incentivized to mine transactions that double 
spend a previous transaction that isn't rbf, also.

Cheers,
-Yancy

On 2022-11-03 14:32, Erik Aronesty via bitcoin-dev wrote:

> actually, peter makes an important point here
> 
> technically, all we need is for *miners* to consistently mine "full
> rbf"
> 
> as long as they do, businesses that accept 0conf will have to adjust
> their risk accordingly, and the problem of misaligned incentives is
> resolved
> 
> i don't think it matters what non-mining users do nearly as much
> 
> On Wed, Nov 2, 2022 at 3:05 PM alicexbt via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> Hi Peter,
> 
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high 
> fees to reward miners that turn on full-RBF. I'm starting small, just 
> ~$100/block in times of congestion. Miner and pool profit margins are 
> pretty small, on the order of $1k/block in many cases, so I know it 
> doesn't take that much more money to make a difference.
> I appreciate this effort and perhaps this was all that was needed in
> addition to Bitcoin Core's inclusion of full rbf support. Making it
> default right away or enabling preferential peering with service
> flag in a bitcoin core release was unnecessary.
> 
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> Sorry, I don't trust you based on some of the things you support on
> Twitter. Hopefully, others will donate and help this bounty.
> 
> /dev/fd0
> 
> Sent with Proton Mail secure email.
> 
> ------- Original Message -------
> On Wednesday, November 2nd, 2022 at 2:56 PM, Peter Todd via
> bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> I'm now running a full-RBf bounty program for miners.
> 
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high 
> fees to reward miners that turn on full-RBF. I'm starting small, just 
> ~$100/block in times of congestion. Miner and pool profit margins are 
> pretty small, on the order of $1k/block in many cases, so I know it 
> doesn't take that much more money to make a difference.
> 
> Why should you do this? Full-RBF/zeroconf has been discussed to death. 
> But tl;dr: You'll earn more money, and help transition Bitcoin to a 
> more secure mempool policy based on economic incentives rather than 
> trust.
> 
> If you're a miner and want to participate, the easiest way to so is to 
> use the mempoolfullrbf=1 option in the upcoming Bitcoin Core v24 
> release (eg the 24.0rc3 tag), or use the mempoolreplacement=fee option 
> in Bitcoin Knots.
> You can also just modify the code yourself by removing the opt-in RBF 
> check. For example against the v23.0 tag:
> 
> $ git diff
> diff --git a/src/validation.cpp b/src/validation.cpp
> index 214112e2b..44c364623 100644
> --- a/src/validation.cpp
> +++ b/src/validation.cpp
> @@ -736,7 +736,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, 
> Workspace& ws) // check all unconfirmed ancestors; otherwise an opt-in 
> ancestor
> // might be replaced, causing removal of this descendant.
> if (!SignalsOptInRBF(*ptxConflicting)) {
> - return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, 
> "txn-mempool-conflict"); + // return 
> state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, 
> "txn-mempool-conflict"); }
> 
> ws.m_conflicts.insert(ptxConflicting->GetHash());
> 
> Once you've enabled full-RBF, you need a full-RBF peer. I'm running a 
> few of them:
> 
> cup.nop.lol
> mug.nop.lol
> jar.nop.lol
> jug.nop.lol
> 
> These nodes run a preferential peering patch 
> (https://github.com/bitcoin/bitcoin/pull/25600) to ensure that full-RBF 
> nodes are interconnected to each other and replacements can easily 
> propagate. Also feel free to contact me if you'd like to peer with a 
> private node.
> 
> If you'd like to donate to this effort, send BTC to
> bc1qagmufdn6rf80kj3faw4d0pnhxyr47sevp3nj9m
> 
> ...and yes, I'm well aware that miners could collect this bounty in 
> other ways, eg by raising minimum fees. Doing that also breaks 
> zeroconf, so I'm not too concerned.
> 
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org [1 [1]]
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Links:
------
[1] http://petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Links:
------
[1] http://petertodd.org

[-- Attachment #2: Type: text/html, Size: 10482 bytes --]

 permalink raw reply	[|nested]
2022-11-08 18:16 ` Peter Todd

  2022-11-15 14:43     ` Peter Todd
  2022-12-09 16:04     ` 0xB10C
  
From: Anthony Towns @ 2022-11-15  5:36 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

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):

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

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
 - 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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
  https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
  https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1

That presumably means those pools (AntPool twice and "unknown") are
running with large mempools that didn't kept the earlier 1.2sat/vb txs.

The txs were mined by Foundry:

  https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5

This seems to be pretty good evidence that we currently don't have any
significant hashrate mining with fullrbf policies (<0.5% if there was a
high fee replacement available prior to every block having been mined),
despite the bounty having been collected.

Cheers,
aj


 permalink raw reply	[|nested]
2022-11-15  5:36   ` Anthony Towns

  2022-12-05 12:20       ` El_Hoy
  2022-12-09 16:04     ` 0xB10C
  
From: Peter Todd @ 2022-11-15 14:43 UTC (permalink / raw)
  To: Anthony Towns, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4794 bytes --]

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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>   https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>   https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
> 
> 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?

> The txs were mined by Foundry:
> 
>   https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
> 
> This seems to be pretty good evidence that we currently don't have any
> significant hashrate mining with fullrbf policies (<0.5% if there was a
> high fee replacement available prior to every block having been mined),
> despite the bounty having been collected.

Oh, we can put much lower bounds on that. I've been running OTS calendars with
full-rbf replacements for a few months without clear evidence of a full-rbf
replacement.  While there was good reason to think some miners were mining
full-rbf before a few years back, they probably didn't bother to reapply their
patches each upgrade. `mempoolfullrbf=1` is much simpler to use.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-11-15 14:43     ` Peter Todd

  2022-12-05 13:38         ` Greg Sanders
                           ` (2 more replies)
  
From: El_Hoy @ 2022-12-05 12:20 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion;  Daniel Lipshitz

[-- Attachment #1: Type: text/plain, Size: 6066 bytes --]

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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
> >
> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
> >
> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
> >
> > 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?
>
> > The txs were mined by Foundry:
> >
> >
> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
> >
> > This seems to be pretty good evidence that we currently don't have any
> > significant hashrate mining with fullrbf policies (<0.5% if there was a
> > high fee replacement available prior to every block having been mined),
> > despite the bounty having been collected.
>
> Oh, we can put much lower bounds on that. I've been running OTS calendars
> with
> full-rbf replacements for a few months without clear evidence of a full-rbf
> replacement.  While there was good reason to think some miners were mining
> full-rbf before a few years back, they probably didn't bother to reapply
> their
> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 8670 bytes --]

 permalink raw reply	[|nested]
2022-11-15 14:43     ` Peter Todd

  2022-12-05 13:38         ` 
                           ` 
  
From: El_Hoy @ 2022-12-05 12:20 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion;  Daniel Lipshitz

[-- Attachment #1: Type: text/plain, Size: 6066 bytes --]

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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
> >
> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
> >
> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
> >
> > 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?
>
> > The txs were mined by Foundry:
> >
> >
> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
> >
> > This seems to be pretty good evidence that we currently don't have any
> > significant hashrate mining with fullrbf policies (<0.5% if there was a
> > high fee replacement available prior to every block having been mined),
> > despite the bounty having been collected.
>
> Oh, we can put much lower bounds on that. I've been running OTS calendars
> with
> full-rbf replacements for a few months without clear evidence of a full-rbf
> replacement.  While there was good reason to think some miners were mining
> full-rbf before a few years back, they probably didn't bother to reapply
> their
> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 8670 bytes --]

 permalink raw reply	[|nested]
2022-12-05 12:20       ` El_Hoy
  2022-12-05 13:38         ` Greg Sanders

  2022-12-05 15:33           ` Michael Folkson
                             ` (2 more replies)
  2022-12-06  5:39         ` Peter Todd
  
From: Rijndael @ 2022-12-05 14:12 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 6951 bytes --]

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 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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>>>
>>> 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?
>>
>>> The txs were mined by Foundry:
>>>
>>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>>>
>>> This seems to be pretty good evidence that we currently don't have any
>>> significant hashrate mining with fullrbf policies (<0.5% if there was a
>>> high fee replacement available prior to every block having been mined),
>>> despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars with
>> full-rbf replacements for a few months without clear evidence of a full-rbf
>> replacement. While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 12904 bytes --]

 permalink raw reply	[|nested]
2022-12-05 12:20       ` El_Hoy
  2022-12-05 13:38         ` Greg Sanders

  2022-12-05 15:33           ` 
                             ` 
  2022-12-06  5:39         ` Peter Todd
  
From: Rijndael @ 2022-12-05 14:12 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 6951 bytes --]

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 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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>>>
>>> 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?
>>
>>> The txs were mined by Foundry:
>>>
>>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>>>
>>> This seems to be pretty good evidence that we currently don't have any
>>> significant hashrate mining with fullrbf policies (<0.5% if there was a
>>> high fee replacement available prior to every block having been mined),
>>> despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars with
>> full-rbf replacements for a few months without clear evidence of a full-rbf
>> replacement. While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 12904 bytes --]

 permalink raw reply	[|nested]
2022-12-05 14:12         ` Rijndael
  2022-12-05 15:33           ` Michael Folkson

  2022-12-06  4:48             ` El_Hoy
  2022-12-05 17:25           ` El_Hoy
  
From: Erik Aronesty @ 2022-12-05 17:00 UTC (permalink / raw)
  To: Rijndael, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 7677 bytes --]

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 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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>> >
>> > 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?
>>
>> > The txs were mined by Foundry:
>> >
>> >
>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>> >
>> > This seems to be pretty good evidence that we currently don't have any
>> > significant hashrate mining with fullrbf policies (<0.5% if there was a
>> > high fee replacement available prior to every block having been mined),
>> > despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars
>> with
>> full-rbf replacements for a few months without clear evidence of a
>> full-rbf
>> replacement.  While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply
>> their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 12799 bytes --]

 permalink raw reply	[|nested]
2022-12-05 14:12         ` Rijndael
  2022-12-05 15:33           ` Michael Folkson
  2022-12-05 17:00           ` Erik Aronesty

  
From: El_Hoy @ 2022-12-05 17:25 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion;  Greg Sanders

[-- Attachment #1: Type: text/plain, Size: 8870 bytes --]

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 <gsanders87@gmail•com> 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:
>> 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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>> >
>> > 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?
>>
>> > The txs were mined by Foundry:
>> >
>> >
>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>> >
>> > This seems to be pretty good evidence that we currently don't have any
>> > significant hashrate mining with fullrbf policies (<0.5% if there was a
>> > high fee replacement available prior to every block having been mined),
>> > despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars
>> with
>> full-rbf replacements for a few months without clear evidence of a
>> full-rbf
>> replacement.  While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply
>> their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 14658 bytes --]

 permalink raw reply	[|nested]
2022-12-05 17:00           ` Erik Aronesty

  
From: El_Hoy @ 2022-12-06  4:48 UTC (permalink / raw)
  To: Erik Aronesty, Michael Folkson, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 9172 bytes --]

On Mon, Dec 5, 2022 at 3:58 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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.
>

If making empty statements were enough to convince people, we would not
need to give good arguments to back our claims. Proof of work is "strictly
necessary" to build blocks that are accepted by the consensus rules, that
are enforced by the validation nodes that propagate those blocks. If there
are multiple valid blocks that are generated close enough and some of them
propagate faster than the others, then validation nodes add some economic
incentive against certain practices. Miners will obviously choose what
validation nodes enforce or they will lose money.

On Mon, Dec 5, 2022 at 3:58 PM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

>
> Daniel Lipshitz has been working on BSV apparently [0] so I guess anything
> is possible with him.(...)
>
--
> Michael Folkson


You are apparently making an Ad Hominem attack [1] so I guess your comment
is not serious. Thanks for the context anyway.

[1]: https://en.wikipedia.org/wiki/Ad_hominem

--- Eloy


> 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 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/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>>> >
>>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>>> >
>>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>>> >
>>> > 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?
>>>
>>> > The txs were mined by Foundry:
>>> >
>>> >
>>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>>> >
>>> > This seems to be pretty good evidence that we currently don't have any
>>> > significant hashrate mining with fullrbf policies (<0.5% if there was a
>>> > high fee replacement available prior to every block having been mined),
>>> > despite the bounty having been collected.
>>>
>>> Oh, we can put much lower bounds on that. I've been running OTS
>>> calendars with
>>> full-rbf replacements for a few months without clear evidence of a
>>> full-rbf
>>> replacement.  While there was good reason to think some miners were
>>> mining
>>> full-rbf before a few years back, they probably didn't bother to reapply
>>> their
>>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 16450 bytes --]

 permalink raw reply	[|nested]
2022-12-05 12:20       ` El_Hoy
  2022-12-05 13:38         ` Greg Sanders
  2022-12-05 14:12         ` Rijndael

  2022-12-06  7:37           ` Peter Todd
  
From: Peter Todd @ 2022-12-06  5:39 UTC (permalink / raw)
  To: El_Hoy;  Bitcoin Protocol Discussion, Daniel Lipshitz

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-12-06  5:39         ` Peter Todd

  
From: Peter Todd @ 2022-12-06  7:37 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion;  Daniel Lipshitz

[-- Attachment #1: Type: text/plain, Size: 1602 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-11-15  5:36   ` Anthony Towns
  2022-11-15 14:43     ` Peter Todd

  2022-12-09 21:16       ` Peter Todd
  2022-12-13  4:01       ` Anthony Towns
  
From: 0xB10C @ 2022-12-09 16:04 UTC (permalink / raw)
  To: Anthony Towns, Bitcoin Protocol Discussion


[-- Attachment #1.1.1: Type: text/plain, Size: 1316 bytes --]

Hi AJ and list,

> This seems to be pretty good evidence that we currently don't have any
> significant hashrate mining with fullrbf policies (<0.5% if there was a
> high fee replacement available prior to every block having been mined),
> despite the bounty having been collected.

For further monitoring, I've set-up a mempoolfullrbf=1 node and are
logging replacement events with [0]. I filter the full-RBF replacements
and list the replaced and replacement transactions here:

https://fullrbf.mempool.observer/

This also tries to find out if either the replaced or replacement
transaction has been included in a block upon loading the site. The
yellow mined-in-badges link to the block on miningpool.observer to a)
show the mining pool (if known) and b) see if the (mempoolfullrbf=0)
miningpool-observer node thinks this transaction is extra / conflicts
with the mined transaction. This should be the case if a full-RBF
replacement transaction is mined.

Over the last few days, I has mostly seen OP_RETURN transactions
(presumably mostly by OpenTimestamps; but I haven't checked closely) and
a few other non-OP_RETURN transactions. None of the replacement
transactions have been mined yet.

[0]: https://github.com/bitcoin/bitcoin/pull/26531#issuecomment-1333832906

Best,
0xB10C

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6989 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-12-09 16:04     ` 0xB10C

  2022-12-10 11:59         ` 0xB10C
  2022-12-13  4:01       ` Anthony Towns
  
From: Peter Todd @ 2022-12-09 21:16 UTC (permalink / raw)
  To: 0xB10C, Bitcoin Protocol Discussion;  Anthony Towns

[-- Attachment #1: Type: text/plain, Size: 1835 bytes --]

On Fri, Dec 09, 2022 at 05:04:05PM +0100, 0xB10C via bitcoin-dev wrote:
> Hi AJ and list,
> 
> > This seems to be pretty good evidence that we currently don't have any
> > significant hashrate mining with fullrbf policies (<0.5% if there was a
> > high fee replacement available prior to every block having been mined),
> > despite the bounty having been collected.
> 
> For further monitoring, I've set-up a mempoolfullrbf=1 node and are
> logging replacement events with [0]. I filter the full-RBF replacements
> and list the replaced and replacement transactions here:

Question: are you taking any special steps to peer that node with other
full-rbf nodes? I see you are in fact getting all the replacements I'd expect
you to get, so you must have good peering. I'm curious what it took (if
anything) to achieve that. Also, is that node accepting incoming connections?

> Over the last few days, I has mostly seen OP_RETURN transactions
> (presumably mostly by OpenTimestamps; but I haven't checked closely) and
> a few other non-OP_RETURN transactions. None of the replacement
> transactions have been mined yet.

They are mostly OpenTimestamps transactions; I checked against the records from
my calendars and didn't find any OP_Return tx that wasn't one of mine.

The two calendars making full-rbf replacements are:

https://alice.btc.calendar.opentimestamps.org/
https://bob.btc.calendar.opentimestamps.org/

The status pages currently link to https://mempool.nixbitcoin.org, which is
also running mempoolfullrbf=1 As you can see, I've started the full-rbf bounty
again on Alice.

https://blockstream.info also enabled full-rbf a few days ago. But currently
propagation to their nodes is spotty, so replacements don't always show up.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-12-09 21:16       ` Peter Todd

  2022-12-10 18:07           ` Peter Todd
  
From: 0xB10C @ 2022-12-10 11:59 UTC (permalink / raw)
  To: Peter Todd, Bitcoin Protocol Discussion;  Anthony Towns


[-- Attachment #1.1.1: Type: text/plain, Size: 3562 bytes --]

On 12/9/22 22:16, Peter Todd wrote:
>> For further monitoring, I've set-up a mempoolfullrbf=1 node and are
>> logging replacement events with [0]. I filter the full-RBF replacements
>> and list the replaced and replacement transactions here:
> Question: are you taking any special steps to peer that node with other
> full-rbf nodes? I see you are in fact getting all the replacements I'd expect
> you to get, so you must have good peering. I'm curious what it took (if
> anything) to achieve that. Also, is that node accepting incoming connections?
No special steps like #25600 preferential peering or similar. I suspect
I was lucky to have a full-RBF peer (or more than one) from the start or
there are more mempoolfullrbf=1 nodes than I'd think on the network. The
node accepts incoming connections on a non-default port and currently
has 45 inbound slots filled up. Mostly buy v23.0 and v24.0 nodes though,
as older Bitcoin Core version usually don't connect to non-default port
peers.
>> Over the last few days, I has mostly seen OP_RETURN transactions
>> (presumably mostly by OpenTimestamps; but I haven't checked closely) and
>> a few other non-OP_RETURN transactions. None of the replacement
>> transactions have been mined yet.
> They are mostly OpenTimestamps transactions; I checked against the records from
> my calendars and didn't find any OP_Return tx that wasn't one of mine.
>
> The two calendars making full-rbf replacements are:
>
> https://alice.btc.calendar.opentimestamps.org/
> https://bob.btc.calendar.opentimestamps.org/
>
> The status pages currently link to https://mempool.nixbitcoin.org, which is
> also running mempoolfullrbf=1 As you can see, I've started the full-rbf bounty
> again on Alice.
>
> https://blockstream.info also enabled full-rbf a few days ago. But currently
> propagation to their nodes is spotty, so replacements don't always show up.

Since my last post, five full-RBF replacements have been mined in two
blocks:

766733 by Luxor:

    41d497d64bfa71390408ddb65c478a5400c721c71336fa51509929f19a5c8aa5 1x
P2WPKH in -> 1x P2WPKH out (12.50 sat/vByte)
    3061eec0b57346c01419db091ce3af16094e796db91f4f3eb9b7ad42ce8f6e25
OpenTimestamps Alice ~170 USD bounty (6424.72 sat/vByte)
    9000f73e818af9019d26b2edde6e8e11f67d6d6f35916dabd808bbdd314ce807 1x
P2WPKH in -> 1x P2WPKH out  (22.73 sat/vByte)
    3843e93a0ec5cf09d757fd497fdda8f15f5094c64b149624c5d343b24e675093
OpenTimestamps Bob (108.25 sat/vByte)

It seems like Luxor (5.5 EH/s or 2.11% network hashrate in the last 7
days)[0] might have mempoolfullrbf=1 enabled.

766736 by AntPool:

   3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1
OpenTimestamps Bob (4.25 sat/vByte)

I'm not too sure if AntPool has full RBF enabled based on this one
transaction. 3c96fe.. is the first replacement of
903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (1.19
sat/vByte) which they might not have seen (?). They have nearly 20% of
the network hashrate [0], so if the have mempoolfullrbf=1 set, we should
see them include more full-RBF replacements soonish. There was also
1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f which
bumped 3c96fe.. by 1.53 sat/vByte, but was only broadcast shortly before
AntPool found the block. The might not have seen it yet.

I've also updated the site to allow only showing the replacements that
were mined.

[0]: https://btc.com/stats/pool?pool_mode=week
for future reference: https://archive.ph/TARhP


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6989 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-12-10 11:59         ` 0xB10C

  
From: Peter Todd @ 2022-12-10 18:07 UTC (permalink / raw)
  To: 0xB10C;  Bitcoin Protocol Discussion, Anthony Towns

[-- Attachment #1: Type: text/plain, Size: 5736 bytes --]

On Sat, Dec 10, 2022 at 12:59:05PM +0100, 0xB10C wrote:
> On 12/9/22 22:16, Peter Todd wrote:
> >> For further monitoring, I've set-up a mempoolfullrbf=1 node and are
> >> logging replacement events with [0]. I filter the full-RBF replacements
> >> and list the replaced and replacement transactions here:
> > Question: are you taking any special steps to peer that node with other
> > full-rbf nodes? I see you are in fact getting all the replacements I'd expect
> > you to get, so you must have good peering. I'm curious what it took (if
> > anything) to achieve that. Also, is that node accepting incoming connections?
> No special steps like #25600 preferential peering or similar. I suspect
> I was lucky to have a full-RBF peer (or more than one) from the start or
> there are more mempoolfullrbf=1 nodes than I'd think on the network. The
> node accepts incoming connections on a non-default port and currently
> has 45 inbound slots filled up. Mostly buy v23.0 and v24.0 nodes though,
> as older Bitcoin Core version usually don't connect to non-default port
> peers.

Interesting! I'm running a full-rbf node that is (manually) connected to a few
hundred v24.0 nodes to ensure good propagation. But I'm only connected to
standard ports (I'm reusing the DNS seed list). So you must have a full-rbf
peer purely by luck.

Could you please grep your logs for which peer(s) are sending you replacements?
I don't want to know the IP addresses. I'm just curious if you have exactly one
full-rbf peer or more.

BTW I have Antoine's preferential peering patch ported to v24.0, along with a
few other minor fixes:

https://github.com/petertodd/bitcoin/tree/full-rbf-v24.0

I think it'd be reasonable for you to run that, as what's more interesting is
the replacements, not whether or not propagation happens to work out of the
box.

> > https://blockstream.info also enabled full-rbf a few days ago. But currently
> > propagation to their nodes is spotty, so replacements don't always show up.
> 
> Since my last post, five full-RBF replacements have been mined in two
> blocks:
> 
> 766733 by Luxor:
> 
>     41d497d64bfa71390408ddb65c478a5400c721c71336fa51509929f19a5c8aa5 1x
> P2WPKH in -> 1x P2WPKH out (12.50 sat/vByte)
>     3061eec0b57346c01419db091ce3af16094e796db91f4f3eb9b7ad42ce8f6e25
> OpenTimestamps Alice ~170 USD bounty (6424.72 sat/vByte)
>     9000f73e818af9019d26b2edde6e8e11f67d6d6f35916dabd808bbdd314ce807 1x
> P2WPKH in -> 1x P2WPKH out  (22.73 sat/vByte)
>     3843e93a0ec5cf09d757fd497fdda8f15f5094c64b149624c5d343b24e675093
> OpenTimestamps Bob (108.25 sat/vByte)
> 
> It seems like Luxor (5.5 EH/s or 2.11% network hashrate in the last 7
> days)[0] might have mempoolfullrbf=1 enabled.
> 
> 766736 by AntPool:
> 
>    3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1
> OpenTimestamps Bob (4.25 sat/vByte)
> 
> I'm not too sure if AntPool has full RBF enabled based on this one
> transaction. 3c96fe.. is the first replacement of
> 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (1.19
> sat/vByte) which they might not have seen (?). They have nearly 20% of
> the network hashrate [0], so if the have mempoolfullrbf=1 set, we should
> see them include more full-RBF replacements soonish. There was also
> 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f which
> bumped 3c96fe.. by 1.53 sat/vByte, but was only broadcast shortly before
> AntPool found the block. The might not have seen it yet.

So according to my logs the replacement that AntPool mined, 3c96fe813, was the
third replacement in a row of four replacements:

2022-12-10T07:46:09Z [mempool] AcceptToMemoryPool: peer=<snip>: accepted 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (poolsz 6320 txn, 90818 kB)
2022-12-10T07:47:14Z [mempool] replacing tx 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 with f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:01:09Z [mempool] replacing tx f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 with 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:06:06Z [mempool] replacing tx 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 with 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f for 0.00000234 additional fees, 0 delta bytes

There's significant time between tx #2 and tx #3, and the block was found soon
after #4 reached my node, so it's quite possible that AntPool was in fact
running full-rbf and they simply didn't see #4 in time.

Big pools tend to run many different nodes at once, splitting up hash rate
between them, so they could be simply running full-rbf on a subset of their
hashing power to test it out. I noticed F2Pool mined a few full-rbf
replacements a few weeks ago too (they also mined a replacement that appeared
to be due to them starting a new node, with an empty mempool).

Similarly, note how Luxor has mined a few blocks since #766733, without mining
full-rbf replacements.


I'll also note that Foundry USA mined a doublespend,
fab4df6b9b51dcfe94b366f17bccca50430f4ceb274a87f948a5493cd31a8551, which your
site shows. In that case according to my logs the two transactions were sent
essentially simultaneously, so likely just an accident of propagation. But it's
good to remind people that such double-spends are easy. :)

> I've also updated the site to allow only showing the replacements that
> were mined.

Thanks! That's very useful.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-12-09 16:04     ` 0xB10C
  2022-12-09 21:16       ` Peter Todd

  
From: Anthony Towns @ 2022-12-13  4:01 UTC ( / )
  To: 0xB10C, Bitcoin Protocol Discussion

On Fri, Dec 09, 2022 at 05:04:05PM +0100, 0xB10C via bitcoin-dev wrote:
> For further monitoring, I've set-up a mempoolfullrbf=1 node and are
> logging replacement events with [0]. I filter the full-RBF replacements
> and list the replaced and replacement transactions here:
> https://fullrbf.mempool.observer/

I think it would be helpful to list (a) how long ago the replaced
transaction was seen compared to the [full RBF event] timestamp, and (b)
particularly for cases where the replaced tx was the one that was mined,
how long after the [full RBF event] the block was received.

Might be more hassle than it's worth, but you might consider grouping
all related replacements together, so that you can see:

2b771b7949e62434bf3002ad0d38f383a29b362cf2dc31627a35a883d0de36c3
  [2601.19 sat/vb]
9ce405ab14e8d68c7a43d190414e39564d90bbee21f23020f2ce45136927ce9b
  [2448.25 sat/vb]
1a5f239e7fc008f337605e0b405579234d0fecebaf6be966000dcfaf0bcb7beb
  [2295.31 sat/vb]
0500a3ca5e4998fb273be9b51a4c3a75780acf28b23409a54f4260e069441e32
  [2142.37 sat/vb]
955623c789eb0a7ca0848ce964325d6b2c7d1731a686d573018f6348de6c00a1
  [1989.42 sat/vb]
7838bc60405f9b38a79c94f4f045b8debaf41c0a5acfdeebc6a3904188b2bbc9
  [1836.48 sat/vb]
2d5e6b84602d45c5c834e0cad4db4dd8a9142ba7eff6bacdb34a97e5cfacb418
  [1683.54 sat/vb]
130851951a1d9270776852491bda3e17bb08b9309e5b76b206633f88a9341604
  [1530.60 sat/vb]
3c9b2530c02a22c966fa9ef60ec0acf17bd23a8b0b4c5202589c190ee770c880
  [1377,66 sat/vb]
49889043ec7dae7a4f1573c5feaca6a549d88e4fb306cf3b410155ba919da83d
  [1224.72 sat/vb]
861156e18ae0399cd458c6f7f7faed1a94142db45f1d879b9ae78cb11cd7e96c
  [1071.78 sat/vb]
961bf21f1fc35edacd4929e8db67b27a52c69a593d32aab5a024757503c0490b
  [ 918.84 sat/vb]
5cdb24e2ed30dfc55b23820676a9d47d158fec982e77dddadc648280f0b2c914
  [ 765.90 sat/vb]
159494115af33b414df77d3965de5eb191b4a3af1c1219509f3175abc5dcd132
  [ 612.95 sat/vb]
dcf4c0e688ee76188e9ef829d03cc66ee7da404717b9d56d74bcd75708612271
  [ 460.01 sat/vb]
1971d9122551a898bcbc5183d4ea79e273dea89aa4075d4e014f8f7dd4eb8321
  [ 307.07 sat/vb]
c43316d2e4bb12fbb408de01d64c4b480fd7d6875db4ebbf006fdc7579546d13
  [ 154.13 sat/vb]
8bbf6a0f3dd8358c6d8a81f0811216d7980288b14daeac82ff2f672ea8e4851d
  [   1.19 sat/vb]
  [mined in 767044]

at a glance as a single block (ideally with timestamps).

Arguably, that might be interesting to see in general (ie for bip-125
opt-in rbf txs as well), to see how common the "offer a low fee, and
raise it over time" approach is in practice.

Cheers,
aj