public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Announcement: Full-RBF Miner Bounty
@ 2022-11-02  9:26 Peter Todd
  2022-11-02 19:02 ` alicexbt
  2022-11-08 18:16 ` Peter Todd
  0 siblings, 2 replies; 21+ messages in thread
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	[flat|nested] 21+ messages in thread

• * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
    2022-11-02  9:26 [bitcoin-dev] Announcement: Full-RBF Miner Bounty Peter Todd
  @ 2022-11-02 19:02 ` alicexbt
    2022-11-03 13:32   ` Erik Aronesty
    2022-11-08 18:16 ` Peter Todd
    1 sibling, 1 reply; 21+ messages in thread
  From: alicexbt @ 2022-11-02 19:02 UTC (permalink / raw)
    To: Peter Todd; +Cc: 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	[flat|nested] 21+ messages in thread

• • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
      2022-11-02 19:02 ` alicexbt
    @ 2022-11-03 13:32   ` Erik Aronesty
      2022-11-09 12:14     ` email
      0 siblings, 1 reply; 21+ messages in thread
    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	[flat|nested] 21+ messages in thread

  • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
        2022-11-03 13:32   ` Erik Aronesty
      @ 2022-11-09 12:14     ` email
        0 siblings, 0 replies; 21+ messages in thread
      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	[flat|nested] 21+ messages in thread

• * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
    2022-11-02  9:26 [bitcoin-dev] Announcement: Full-RBF Miner Bounty Peter Todd
    2022-11-02 19:02 ` alicexbt
  @ 2022-11-08 18:16 ` Peter Todd
    2022-11-15  5:36   ` Anthony Towns
    1 sibling, 1 reply; 21+ messages in thread
  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	[flat|nested] 21+ messages in thread

• • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
      2022-11-08 18:16 ` Peter Todd
    @ 2022-11-15  5:36   ` Anthony Towns
      2022-11-15 14:43     ` Peter Todd
      2022-12-09 16:04     ` 0xB10C
      0 siblings, 2 replies; 21+ messages in thread
    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	[flat|nested] 21+ messages in thread

  • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
        2022-11-15  5:36   ` Anthony Towns
      @ 2022-11-15 14:43     ` Peter Todd
        2022-12-05 12:20       ` El_Hoy
        2022-12-09 16:04     ` 0xB10C
        1 sibling, 1 reply; 21+ messages in thread
      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	[flat|nested] 21+ messages in thread

    • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
          2022-11-15 14:43     ` Peter Todd
        @ 2022-12-05 12:20       ` El_Hoy
          2022-12-05 13:38         ` Greg Sanders
                                   ` (2 more replies)
          0 siblings, 3 replies; 21+ messages in thread
        From: El_Hoy @ 2022-12-05 12:20 UTC (permalink / raw)
          To: Bitcoin Protocol Discussion; +Cc: 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	[flat|nested] 21+ messages in thread

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

        • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
            2022-12-05 12:20       ` El_Hoy
            2022-12-05 13:38         ` Greg Sanders
          @ 2022-12-05 14:12         ` Rijndael
            2022-12-05 15:33           ` Michael Folkson
                                       ` (2 more replies)
            2022-12-06  5:39         ` Peter Todd
            2 siblings, 3 replies; 21+ messages in thread
          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	[flat|nested] 21+ messages in thread

        • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
              2022-12-05 14:12         ` Rijndael
            @ 2022-12-05 15:33           ` Michael Folkson
              2022-12-05 17:00           ` Erik Aronesty
              2022-12-05 17:25           ` El_Hoy
              2 siblings, 0 replies; 21+ messages in thread
            From: Michael Folkson @ 2022-12-05 15:33 UTC (permalink / raw)
              To: Rijndael, Bitcoin Protocol Discussion
            
            [-- Attachment #1: Type: text/plain, Size: 8136 bytes --]
            
            > That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun wallet developers) could work on a fork and run several nodes with such functionality.
            
            Daniel Lipshitz has been working on BSV apparently [0] so I guess anything is possible with him. But as others have said turning a mempool policy issue (users have always been free to choose whatever policy they like with zero chain split risk) into a consensus issue and a contentious soft fork issue at that would not be advised. I highly doubt any of the long term Muun contributors would want to support a contentious soft fork and fight a consensus rule war on this.
            
            [0]: https://coingeek.com/gap600-ceo-daniel-lipshitz-talks-bsv-powered-stablecoins-on-coingeek-backstage-video/
            --
            Michael Folkson
            Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
            Keybase: michaelfolkson
            PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
            
            ------- Original Message -------
            On Monday, December 5th, 2022 at 16:12, Rijndael via bitcoin-dev <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
            
            [-- Attachment #2: Type: text/html, Size: 16338 bytes --]
            
            ^ permalink raw reply	[flat|nested] 21+ messages in thread

          • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
              2022-12-05 14:12         ` Rijndael
              2022-12-05 15:33           ` Michael Folkson
            @ 2022-12-05 17:00           ` Erik Aronesty
              2022-12-06  4:48             ` El_Hoy
              2022-12-05 17:25           ` El_Hoy
              2 siblings, 1 reply; 21+ messages in thread
            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	[flat|nested] 21+ messages in thread

          • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
                2022-12-05 17:00           ` Erik Aronesty
              @ 2022-12-06  4:48             ` El_Hoy
                0 siblings, 0 replies; 21+ messages in thread
              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	[flat|nested] 21+ messages in thread

          • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
              2022-12-05 14:12         ` Rijndael
              2022-12-05 15:33           ` Michael Folkson
              2022-12-05 17:00           ` Erik Aronesty
            @ 2022-12-05 17:25           ` El_Hoy
              2 siblings, 0 replies; 21+ messages in thread
            From: El_Hoy @ 2022-12-05 17:25 UTC (permalink / raw)
              To: Bitcoin Protocol Discussion; +Cc: 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	[flat|nested] 21+ messages in thread

        • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
            2022-12-05 12:20       ` El_Hoy
            2022-12-05 13:38         ` Greg Sanders
            2022-12-05 14:12         ` Rijndael
          @ 2022-12-06  5:39         ` Peter Todd
            2022-12-06  7:37           ` Peter Todd
            2 siblings, 1 reply; 21+ messages in thread
          From: Peter Todd @ 2022-12-06  5:39 UTC (permalink / raw)
            To: El_Hoy; +Cc: 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	[flat|nested] 21+ messages in thread

        • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
              2022-12-06  5:39         ` Peter Todd
            @ 2022-12-06  7:37           ` Peter Todd
              0 siblings, 0 replies; 21+ messages in thread
            From: Peter Todd @ 2022-12-06  7:37 UTC (permalink / raw)
              To: Bitcoin Protocol Discussion; +Cc: 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	[flat|nested] 21+ messages in thread

    • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
        2022-11-15  5:36   ` Anthony Towns
        2022-11-15 14:43     ` Peter Todd
      @ 2022-12-09 16:04     ` 0xB10C
        2022-12-09 21:16       ` Peter Todd
        2022-12-13  4:01       ` Anthony Towns
        1 sibling, 2 replies; 21+ messages in thread
      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	[flat|nested] 21+ messages in thread

    • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
          2022-12-09 16:04     ` 0xB10C
        @ 2022-12-09 21:16       ` Peter Todd
          2022-12-10 11:59         ` 0xB10C
          2022-12-13  4:01       ` Anthony Towns
          1 sibling, 1 reply; 21+ messages in thread
        From: Peter Todd @ 2022-12-09 21:16 UTC (permalink / raw)
          To: 0xB10C, Bitcoin Protocol Discussion; +Cc: 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	[flat|nested] 21+ messages in thread

      • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
            2022-12-09 21:16       ` Peter Todd
          @ 2022-12-10 11:59         ` 0xB10C
            2022-12-10 18:07           ` Peter Todd
            0 siblings, 1 reply; 21+ messages in thread
          From: 0xB10C @ 2022-12-10 11:59 UTC (permalink / raw)
            To: Peter Todd, Bitcoin Protocol Discussion; +Cc: 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	[flat|nested] 21+ messages in thread

        • • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
              2022-12-10 11:59         ` 0xB10C
            @ 2022-12-10 18:07           ` Peter Todd
              0 siblings, 0 replies; 21+ messages in thread
            From: Peter Todd @ 2022-12-10 18:07 UTC (permalink / raw)
              To: 0xB10C; +Cc: 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	[flat|nested] 21+ messages in thread

      • * Re: [bitcoin-dev] Announcement: Full-RBF Miner Bounty
          2022-12-09 16:04     ` 0xB10C
          2022-12-09 21:16       ` Peter Todd
        @ 2022-12-13  4:01       ` Anthony Towns
          1 sibling, 0 replies; 21+ messages in thread
        From: Anthony Towns @ 2022-12-13  4:01 UTC (permalink / raw)
          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
        
        
        ^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2022-12-13  4:01 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-02  9:26 [bitcoin-dev] Announcement: Full-RBF Miner Bounty Peter Todd
2022-11-02 19:02 ` alicexbt
2022-11-03 13:32   ` Erik Aronesty
2022-11-09 12:14     ` email
2022-11-08 18:16 ` Peter Todd
2022-11-15  5:36   ` Anthony Towns
2022-11-15 14:43     ` Peter Todd
2022-12-05 12:20       ` El_Hoy
2022-12-05 13:38         ` Greg Sanders
2022-12-05 14:12         ` Rijndael
2022-12-05 15:33           ` Michael Folkson
2022-12-05 17:00           ` Erik Aronesty
2022-12-06  4:48             ` El_Hoy
2022-12-05 17:25           ` El_Hoy
2022-12-06  5:39         ` Peter Todd
2022-12-06  7:37           ` Peter Todd
2022-12-09 16:04     ` 0xB10C
2022-12-09 21:16       ` Peter Todd
2022-12-10 11:59         ` 0xB10C
2022-12-10 18:07           ` Peter Todd
2022-12-13  4:01       ` Anthony Towns

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox