Pull-req to enable Full-RBF by default

This would unnecessarily and extremely negatively impact merchants and users who choose to accept 0-conf while using mitigation tools like GAP600. This negative impact could be avoided by simply adding first seen safe rule - ie a trx can be replaced but needs to include the original outputs.

At GAP600 we continue to see strong use of our service for BTC we have seen circa 350k unique trx hash per month (over the last 3 months) requested to our platform. Our clients include - Coinpayments, Coinspaid and Changelly. Given the period of Mempool being full we have seen an increase in the fee required in order to be approved by our platform for trx. This is not an insignificant use case and one which can be easily maintained as is.

We have provided further statistics in the past and direct feedback from Coinspaid CEO with in the mailing list see here - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html

We have not seen any impact of full RBF on double spend rates for our trxs which seems to put in large question the stated figure of 40% adoption by miners at such a rate of adoption we would expect to see a large increase in double spends. We expect once this setting becomes default this will greatly change the adoption of this service. GAP600 model targets not to get it wrong and as such we are very sensitive to any double spend which we get wrong in predicting as we reimburse our clients. GAP600 is not a payment processor; rather services payment processors, merchants and non custodial liquidity providers which service non-custodial wallets.

________________________________

Daniel Lipshitz GAP600| www.gap600.com

On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel Lipshitz via bitcoin-dev wrote:

> This would unnecessarily and extremely negatively impact merchants and
> users who choose to accept 0-conf while using mitigation tools like GAP600.
> This negative impact could be avoided by simply adding first seen safe rule
> - ie a trx can be replaced but needs to include the original outputs.
>
> At GAP600 we continue to see strong use of our service for BTC we have seen
> circa 350k unique trx hash per month (over the last 3 months) requested to
> our platform. Our clients include - Coinpayments, Coinspaid and Changelly.

I checked, and Coinpayments and Coinspaid are both merchant processors. I could not find any example of actual merchants using their platform accepting unconfirmed payments. I also could not find any documentation on their websites indicating unconfirmed transaction acceptance.

As for Changelly, their website says right on the front that "With an average transaction speed of 5–40 minutes, we ensure you can swiftly take advantage of market opportunities." Obivously, 5 minutes is not an unconfirmed payment.

Additionally, I verified myself by doing test transactions with BIP125 disabled and an adequate fee: unconfirmed payments are not accepted by Changelly. As their exchange flow clearly says "Once BTC is confirmed in the blockchain, we’ll start exchanging it to <coin>."

You need to provide an genuine example of an actual merchant who accepts unconfirmed transactions as payment, and actually relies on first-seen behavior.

> We have not seen any impact of full RBF on double spend rates for our trxs

Based on the above findings, this appears to be because you don't actually have any clients who rely on unconfirmed payments.

Your research is not thorough and reaches an incorrect conclusion.

As stated many times - we service payment processors and some merchants directly - Coinspaid services multiple merchants and process a significant amount of BTC they are a well known and active in the space - as I provided back in December 2022 a email from Max the CEO of Coinspaid confirming their use of 0-conf as well as providing there cluster addresses to validate there deposit flows see here again - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html - if this is not sufficient then please email support@coinspaid•com and ask to be connected to Max or someone from the team who can confirm Conspaid is clients of GAP600. Max also at the time was open to do a call, I can check again now and see if this is still the case and connect you.

That on its own is enough of a sample to validate our statistics.

I have also spoken to Changelly earlier today and they offered to email pro @ changelly.com and they will be able to confirm GAP600 as a service provider. Also please send me the 1 trx hash you tested and I can see if it was queried to our system and if so offer some info as to why it wasnt approved. Also if you can elaborate how you integrated with Changelly - I can check with them if that area is not integrated with GAP600.

As the architect of such a major change to the status of 0-conf transactions I would think you would welcome the opportunity to speak to business and users who actual activities will be impacted by full RBF becoming dominant.

Are you able to provide the same i.e emails and contacts of people at the mining pools who can confirm they have adopted FULL RBF ?

________________________________

Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz

On Tue, Aug 1, 2023 at 6:04 PM Peter Todd <pete@petertodd•org> wrote:

> On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel Lipshitz via bitcoin-dev
> wrote:
> > This would unnecessarily and extremely negatively impact merchants and
> > users who choose to accept 0-conf while using mitigation tools like
> GAP600.
> > This negative impact could be avoided by simply adding first seen safe
> rule
> > - ie a trx can be replaced but needs to include the original outputs.
> >
> > At GAP600 we continue to see strong use of our service for BTC we have
> seen
> > circa 350k unique trx hash per month (over the last 3 months) requested
> to
> > our platform. Our clients include - Coinpayments, Coinspaid and
> Changelly.
>
> I checked, and Coinpayments and Coinspaid are both merchant processors. I
> could
> not find any example of actual merchants using their platform accepting
> unconfirmed payments. I also could not find any documentation on their
> websites
> indicating unconfirmed transaction acceptance.
>
> As for Changelly, their website says right on the front that "With an
> average
> transaction speed of 5–40 minutes, we ensure you can swiftly take
> advantage of
> market opportunities." Obivously, 5 minutes is not an unconfirmed payment.
>
> Additionally, I verified myself by doing test transactions with BIP125
> disabled
> and an adequate fee: unconfirmed payments are not accepted by Changelly. As
> their exchange flow clearly says "Once BTC is confirmed in the blockchain,
> we’ll start exchanging it to <coin>."
>
> You need to provide an genuine example of an actual merchant who accepts
> unconfirmed transactions as payment, and actually relies on first-seen
> behavior.
>
> > We have not seen any impact of full RBF on double spend rates for our
> trxs
>
> Based on the above findings, this appears to be because you don't actually
> have
> any clients who rely on unconfirmed payments.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:

> Your research is not thorough and reaches an incorrect conclusion.
>
> As stated many times - we service payment processors and some merchants
> directly  - Coinspaid services multiple merchants and process a
> significant amount of BTC they are a well known and active in the space -
> as I provided back in December 2022 a email from Max the CEO of Coinspaid
> confirming their use of 0-conf as well as providing there cluster addresses
> to validate there deposit flows see here again -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> - if this is not sufficient then please email support@coinspaid•com and ask
> to be connected to Max or someone from the team who can confirm Conspaid is
> clients of GAP600. Max also at the time was open to do a call, I can check
> again now and see if this is still the case and connect you.
>
> That on its own is enough of a sample to validate our statistics.

Why don't you just give me an example of some merchants using Coinspaid, and another example using Coinpayments, who rely on unconfirmed transactions? If those merchants actually exist it should be very easy to give me some names of them.

Without actual concrete examples for everyone to see for themselves, why should we believe you?

> I have also spoken to Changelly earlier today and they offered to email pro
> @ changelly.com and they will be able to confirm GAP600 as a service

Emailed; waiting on a reply.

> provider. Also please send me the 1 trx hash you tested and I can see if it
> was queried to our system and if so offer some info as to why it wasnt
> approved. Also if you can elaborate how you integrated with Changelly - I
> can check with them if that area is not integrated with GAP600.

Why don't you just tell me exactly what service Changelly offers that relies on unconfirmed transactions, and what characteristics would meet GAP600's risk criteria? I and others on this mailing list could easily do test transactions if you told us what we can actually test. If your service actually works, then you can safely provide that information.

I'm not going to give you any exact tx hashes of transactions I've already done, as I don't want to cause any problems for the owners of the accounts I borrowed for testing. Given your lack of honesty so far I have every reason to believe they might be retalliated against in some way.

> As the architect of such a major change to the status of 0-conf
> transactions I would think you would welcome the opportunity to speak to
> business and users who actual activities will be impacted by full RBF
> becoming dominant.

Funny how you say this, without actually giving any concrete examples of businesses that will be affected. Who exactly are these businesses? Payment processors obviously don't count.

> Are you able to provide the same i.e emails and contacts of people at
> the mining pools who can confirm they have adopted FULL RBF ?

I've already had multiple mining pools complain to me that they and their employees have been harassed over full-rbf, so obviously I'm not going to provide you with any private contact information I have. There's no need to expose them to further harassment.

If you actually offered an unconfirmed transaction guarantee service, with real customers getting an actual benefit, you'd be doing test transactions frequently and would already have a very good idea of what pools do full-rbf. Why don't you already have this data?

Your assessment of my dishonesty is based on your assumption of how I should be running GAP600, your assumptions are baseless and lack commercial experience and likewise your conclusions are false.

I have provided already back in December clear access to clarify opposite our clients corroborated with easily verifiable trxs activity of a major client of ours. This is more than enough to corroborate our statistics.

As far as validating real RBF adoption I have offered a clear option here https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440 something like this or similar would offer a clear assessment of adoption. Since you are not able to provide documents or public emails of hashing pools confirming there adoption of Full RBF. ________________________________

Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz

On Wed, Aug 2, 2023 at 4:28 AM Peter Todd <pete@petertodd•org> wrote:

> On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
> > Your research is not thorough and reaches an incorrect conclusion.
> >
> > As stated many times - we service payment processors and some merchants
> > directly  - Coinspaid services multiple merchants and process a
> > significant amount of BTC they are a well known and active in the space -
> > as I provided back in December 2022 a email from Max the CEO of Coinspaid
> > confirming their use of 0-conf as well as providing there cluster
> addresses
> > to validate there deposit flows see here again -
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> > - if this is not sufficient then please email support@coinspaid•com and
> ask
> > to be connected to Max or someone from the team who can confirm Conspaid
> is
> > clients of GAP600. Max also at the time was open to do a call, I can
> check
> > again now and see if this is still the case and connect you.
> >
> > That on its own is enough of a sample to validate our statistics.
>
> Why don't you just give me an example of some merchants using Coinspaid,
> and
> another example using Coinpayments, who rely on unconfirmed transactions?
> If
> those merchants actually exist it should be very easy to give me some
> names of
> them.
>
> Without actual concrete examples for everyone to see for themselves, why
> should
> we believe you?
>
> > I have also spoken to Changelly earlier today and they offered to email
> pro
> > @ changelly.com and they will be able to confirm GAP600 as a service
>
> Emailed; waiting on a reply.
>
> > provider. Also please send me the 1 trx hash you tested and I can see if
> it
> > was queried to our system and if so offer some info as to why it wasnt
> > approved. Also if you can elaborate how you integrated with Changelly - I
> > can check with them if that area is not integrated with GAP600.
>
> Why don't you just tell me exactly what service Changelly offers that
> relies on
> unconfirmed transactions, and what characteristics would meet GAP600's risk
> criteria? I and others on this mailing list could easily do test
> transactions
> if you told us what we can actually test. If your service actually works,
> then
> you can safely provide that information.
>
> I'm not going to give you any exact tx hashes of transactions I've already
> done, as I don't want to cause any problems for the owners of the accounts
> I
> borrowed for testing. Given your lack of honesty so far I have every
> reason to
> believe they might be retalliated against in some way.
>
> > As the architect of such a major change to the status of 0-conf
> > transactions I would think you would welcome the opportunity to speak to
> > business and users who actual activities will be impacted by full RBF
> > becoming dominant.
>
> Funny how you say this, without actually giving any concrete examples of
> businesses that will be affected. Who exactly are these businesses? Payment
> processors obviously don't count.
>
> > Are you able to provide the same i.e emails and contacts of people at
> > the mining pools who can confirm they have adopted FULL RBF ?
>
> I've already had multiple mining pools complain to me that they and their
> employees have been harassed over full-rbf, so obviously I'm not going to
> provide you with any private contact information I have. There's no need to
> expose them to further harassment.
>
> If you actually offered an unconfirmed transaction guarantee service, with
> real
> customers getting an actual benefit, you'd be doing test transactions
> frequently and would already have a very good idea of what pools do
> full-rbf.
> Why don't you already have this data?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

For clarity purposes.

   1. Our research is based on monitoring main net transactions and network
   activity - as too is our risk engine. We do not engage in specific hashing
   pool assessments or research.
   2. It is not easily possible or comfortable to engage with our clients
   to offer up their client names and applications - the competition is fierce
   and like other industries it is not an acceptable approach to ask.
   3. The information offered by Coinpaid and posted on this list, provides
   root addresses which using tools like Chainanlysis, or
   similar service providers can confirm these addresses are associated with
   Coinspaid. This can validate a significant amount of our traffic.
   4. Based on the information provided it will be very possible to reach
   out to Max at Coinpaid - and will be able to confirm GAP600 use with
   Coinspaid. This is in addition to me posting an email from Max back in Dec
   2022 to this list confirming all of this information.
   5.  It is more than likely that Changelly has not implemented our
   service across all irts offerings, a large section of their business is
   servicing partners.

________________________________

Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz

On Wed, Aug 2, 2023 at 1:38 PM Daniel Lipshitz <daniel@gap600•com> wrote:

> Your assessment of my dishonesty is based on your assumption of how I
> should be running GAP600, your assumptions are baseless and lack commercial
> experience and likewise your conclusions are false.
>
> I have provided already back in December clear access to clarify opposite
> our clients corroborated with easily verifiable trxs activity of a major
> client of ours. This is more than enough to corroborate our statistics.
>
> As far as validating real RBF adoption I have offered a clear option here
> https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440
> something like this or similar would offer a clear assessment of adoption.
> Since you are not able to provide documents or public emails of hashing
> pools confirming there adoption of Full RBF.
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
> Phone: +44 113 4900 117
> Skype: daniellipshitz123
> Twitter: @daniellipshitz
>
>
> On Wed, Aug 2, 2023 at 4:28 AM Peter Todd <pete@petertodd•org> wrote:
>
>> On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
>> > Your research is not thorough and reaches an incorrect conclusion.
>> >
>> > As stated many times - we service payment processors and some merchants
>> > directly  - Coinspaid services multiple merchants and process a
>> > significant amount of BTC they are a well known and active in the space
>> -
>> > as I provided back in December 2022 a email from Max the CEO of
>> Coinspaid
>> > confirming their use of 0-conf as well as providing there cluster
>> addresses
>> > to validate there deposit flows see here again -
>> >
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
>> > - if this is not sufficient then please email support@coinspaid•com
>> and ask
>> > to be connected to Max or someone from the team who can confirm
>> Conspaid is
>> > clients of GAP600. Max also at the time was open to do a call, I can
>> check
>> > again now and see if this is still the case and connect you.
>> >
>> > That on its own is enough of a sample to validate our statistics.
>>
>> Why don't you just give me an example of some merchants using Coinspaid,
>> and
>> another example using Coinpayments, who rely on unconfirmed transactions?
>> If
>> those merchants actually exist it should be very easy to give me some
>> names of
>> them.
>>
>> Without actual concrete examples for everyone to see for themselves, why
>> should
>> we believe you?
>>
>> > I have also spoken to Changelly earlier today and they offered to email
>> pro
>> > @ changelly.com and they will be able to confirm GAP600 as a service
>>
>> Emailed; waiting on a reply.
>>
>> > provider. Also please send me the 1 trx hash you tested and I can see
>> if it
>> > was queried to our system and if so offer some info as to why it wasnt
>> > approved. Also if you can elaborate how you integrated with Changelly -
>> I
>> > can check with them if that area is not integrated with GAP600.
>>
>> Why don't you just tell me exactly what service Changelly offers that
>> relies on
>> unconfirmed transactions, and what characteristics would meet GAP600's
>> risk
>> criteria? I and others on this mailing list could easily do test
>> transactions
>> if you told us what we can actually test. If your service actually works,
>> then
>> you can safely provide that information.
>>
>> I'm not going to give you any exact tx hashes of transactions I've already
>> done, as I don't want to cause any problems for the owners of the
>> accounts I
>> borrowed for testing. Given your lack of honesty so far I have every
>> reason to
>> believe they might be retalliated against in some way.
>>
>> > As the architect of such a major change to the status of 0-conf
>> > transactions I would think you would welcome the opportunity to speak to
>> > business and users who actual activities will be impacted by full RBF
>> > becoming dominant.
>>
>> Funny how you say this, without actually giving any concrete examples of
>> businesses that will be affected. Who exactly are these businesses?
>> Payment
>> processors obviously don't count.
>>
>> > Are you able to provide the same i.e emails and contacts of people at
>> > the mining pools who can confirm they have adopted FULL RBF ?
>>
>> I've already had multiple mining pools complain to me that they and their
>> employees have been harassed over full-rbf, so obviously I'm not going to
>> provide you with any private contact information I have. There's no need
>> to
>> expose them to further harassment.
>>
>> If you actually offered an unconfirmed transaction guarantee service,
>> with real
>> customers getting an actual benefit, you'd be doing test transactions
>> frequently and would already have a very good idea of what pools do
>> full-rbf.
>> Why don't you already have this data?
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>

On Wed, Aug 02, 2023 at 01:38:21PM +0300, Daniel Lipshitz wrote:

> Your assessment of my dishonesty is based on your assumption of how I
> should be running GAP600, your assumptions are baseless and lack commercial
> experience and likewise your conclusions are false.
>
> I have provided already back in December clear access to clarify opposite
> our clients corroborated with easily verifiable trxs activity of a major
> client of ours. This is more than enough to corroborate our statistics.

Claims of "trxs activity" are completely meaningless when you can't demonstrate that a single client of yours actually relies on unconfirmed transaction acceptance.

> As far as validating real RBF adoption I have offered a clear option here
> https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440
> something like this or similar would offer a clear assessment of adoption.
> Since you are not able to provide documents or public emails of hashing
> pools confirming there adoption of Full RBF.

Repeating your github comment here for purposes of reply:

> A clear and open method to research the adoption of full RBF would look something like this and could easily be done -
>
> Create 20 trxs (larger numbers better) in between every block and after 30 seconds try replace them.
> Run this test for at least a few hours preferably more than 24 hours or even a few days.
> See results of how many were replaced.
> Ignore trx results if trx are included in blocks before replace trxs are published.
> Have other Bitcoin Core developers independently implement and review the test results

I am baffled at the fact that you claim GAP600 offers a "real-time risk engine"(1) guaranteeing "instant deposits & payments"(1), yet you are not already testing full-rbf adoption yourself in this manner. If your business was in fact real, it'd be essential to keep track of double spend success rates.

> Based on a test like this or something similar it would be reliable to get to an assessment of the adoption of full RBF.

As you should know, my OpenTimestamps calendars, https://alice.btc.calendar.opentimestamps.org/ and https://bob.btc.calendar.opentimestamps.org/, have been creating full-rbf double spends multiple times a day since last year. Those calendars have created literally thousands of full-rbf replacements, providing ample test data.

If your business was real - if you actually have a "real time risk engine" that monitors mempools - you'd already know this. You'd also know about the successful full-rbf replacements that Alice got mined today:

291e1abf146209839f8910cf9ede6979bb12e6efa6d73f52ca7ae0476eafa6a5 - AntPool e7ea70c2e366ef035ed0428c704c55e5331211200c6e0298eb85a574812aa010 - Binance Pool aa9e034283cc50a3cb042284833607bc49dea275854004a3757acf776e679a6b - Poolin ae74600b66ccf9d8ee8d62e5881581b5baff11117e47ea51c3e4d1fee1612504 - AntPool

Those four transactions are each part of a chain of replacements, and every chain started with a transaction paying well above the minimum relay fee in present mempool conditions. Tell me, how do you think those full-rbf replacements get mined?

On Wed, Aug 02, 2023 at 06:29:54PM +0300, Daniel Lipshitz wrote:

> For clarity purposes.
>
>    1. Our research is based on monitoring main net transactions and network
>    activity - as too is our risk engine. We do not engage in specific hashing
>    pool assessments or research.

So if you are "monitoring main net transactions and network activity", why are you not already aware of the many full-rbf replacements getting mined every day?

>    2. It is not easily possible or comfortable to engage with our clients
>    to offer up their client names and applications - the competition is fierce
>    and like other industries it is not an acceptable approach to ask.
>    3. The information offered by Coinpaid and posted on this list, provides
>    root addresses which using tools like Chainanlysis, or
>    similar service providers can confirm these addresses are associated with
>    Coinspaid. This can validate a significant amount of our traffic.

This reminds me of how Craig Wright appears to have picked a bunch of bitcoin addresses off of a "rich list" and fraudulently claimed those addresses to be his.

Anyone can create a list of addresses from blockchain data. That is not proof that any actual merchant relies on unconfirmed transactions. To prove that you need to provide the names of those merchant(s), so others can actually verify that they provides things of value in exchange for an unconfirmed transaction.

>    4. Based on the information provided it will be very possible to reach
>    out to Max at Coinpaid - and will be able to confirm GAP600 use with
>    Coinspaid. This is in addition to me posting an email from Max back in Dec
>    2022 to this list confirming all of this information.

Again, Coinspaid is a merchant processor. Unless you or they actually provide details on real merchants making use of your claimed service, you have not proven anything of value.

>    5.  It is more than likely that Changelly has not implemented our
>    service across all irts offerings, a large section of their business is
>    servicing partners.

FYI I emailed pro@changelly•com two days ago, asking for confirmation that they use GAP600, and information on how exactly they rely on unconfirmed transactions. So far I have not gotten a reply.

# References

1) https://www.gap600.com/

Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption, I've been doing high-fee full-RBF testing to re-confirm my findings. Specifically, that means sending a high fee tx1 with a fee more than sufficient to get mined in the next block. Then 30 seconds later, I send tx2, a double spend with an even higher fee, removing one of tx1's outputs. Propagation was verified for each full-RBF double-spend by checking debug.log on another very well-connected node.

Results: >31% of hash power, over at least 4 different pools, is mining full-RBF at the moment, assuming Binance Pool is mining full-RBF with half their hashing power (see below for details). This finding confirms my OTS calendar research, which found similar results.

Specifically, in my testing yesterday I successfully did the following full-RBF double-spends:

Antpool: 2ebe68edca320dabdd8b39ebae5f18efaac829055058a2c0f4bc2b37c69cd88c
         dac9895795efa3956cc775b4f48a5d2b01fa0ea0d7a915fa350baa4779d2e0e9
         b7d43485bf8f0f9792ba6889ab2f53fb462aa4997f3995d9d027375993fa7907
         e2cd91093399dcad5ad3fd73627e497c5e808434ecc7aaec13d9d488973f099c
         5bb7e7d6c34dfd2ae65466a2968a0e500ef25d9b70f7f2b299203dffc1a1b10d
         ad7d2f74eab240726604dfd66231f52ac7778567028cf818387dc9395474f63b
         1ddb11bad477e8b5bcdb36dbaa26065ae8e3c37b39b37a2b34780b98274bd076
         f16bb35670b66ab3c8ccbbaf5f06da5f311e9b05a02b23a77a6fec5e8e5951a4
         b6123a7c126b7937a23bf93cce09358bc2c1047a3bd20fad47bf187e453aadc5
         66f3da902d43ab0a2561d0477c7050d057bb0f69ade79015494363ad08ed172d
         17a6995a757e027b2a51b9cc58635b29553ccc6c164555c0ed922074a23bcbfe
Poolin: 68ca9ee95748dc98ba24018ea64c18de31fca552e4753ef012acd0b615cd7384
        477089a1e997a0115b3d4cd1d4ce21eb9dc83c45c14a7f7441e4fc74c3649ba2
EMCDPool: dde0975ad42fd9e03677f64b6c4f7efbe2ec0b6f905206d47893a77ac6336fca
          a0131d4f8cc13d70443cd87f2ee7543e1142640666a88f80d1e0c885c7eb2c12
Binance Pool: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669cdb5
              637c58f3c0447ee99808b37e4f9559096c00ceb0d21130a9254558c4d2d7ae63

Anyone running a full-RBF node with debug=mempool can easily verify all these double-spends by examining their debug.log files.

With Antpool, Poolin, and EMCDPool, it is most likely that they're mining full-RBF with ~100% of their hash power. These pools mined every double-spend available to them, with the exception of some Antpool blocks found very close to when the double-spend was broadcast. Binance Pool did *not* mine a full-RBF replacement on two occasions, which makes me suspect they're mining full-RBF with less than 100% of their hash power. During this testing, Binance Pool, AntPool, Poolin, and EMCDPool, also all mined multiple double-spends from my OTS calendars, further confirming my findings.

My OTS research also found examples of KuCoinPool and ULTIMUSPOOL mining full-RBF double spends. They didn't find any blocks during this testing, so I have no data on them with this testing. Luxor _did_ mine some blocks without mining the double-spends, so at the moment it's reasonable to assume they have full-RBF fully or partially disabled, or have some kind of full-RBF propagation issue. They have confirmed similar issues to me in the past (eg employees unintentionally disabling it on some nodes during an upgrade), so it's likely that has happened again. MARA Pool also mined some blocks without mining double-spends, so they too may have full-RBF fully or partially disabled, as I mentioned in my OTS research.(1)

The tool I used is the following:

    https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py

Note that this script was written years ago, pre-segwit, and I hastily updated it for recent Bitcoin Core/python-bitcoinlib versions. I haven't checked if all the options like OP_Return outputs and multisig still work, and it doesn't even take segwit into account when calculating fees. Don't use it on a wallet with funds you can't afford to lose; it definitely has bugs in it.

For reference, here is the logs from a successful double-spend attempt:

	$ sleep 15 ; ./doublespend.py --fee1 0.00018 --fee2 0.000224 `/home/user/bitcoin/src/bitcoin-cli getnewaddress` 0.00001
	DEBUG:root:Delta fee: 0.00002296
	DEBUG:root:Adding new input caec040f4435e98de9ae44a385e301312c5a3cddfb33f1bd08e1cf63307f87ce:0 with value 0.00072549 BTC
	DEBUG:root:Delta fee: 0.00003035
	DEBUG:root:Payment tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e385a344aee98de935440f04ecca0000000000ffffffff028a0f0100000000001600149e12f3ef33ba4ccde4b85978e675c9fe59bb24a2e8030000000000001600149049e0f57ec5899c1eed2c5e9aab1c34ff5cec1f02473044022063834a187727c1eceb9b3e6ae9ccd0d369b51af3493fafba1d61ed3b273d48f7022049fbe71ecd600c7345fb6002e04275eb8445031df746eceaa6e6f5f413f67497012102c56d86e3031851822485d1a2f9f0e402f14b96b64e711d5a2567412d1ea49a8b00000000
	INFO:root:Payment tx size: 0.222 KB, fees: 0.00002035, 0.00009166 BTC/KB
	INFO:root:Sent payment tx: 1c28870a78efd1c4616726ea0ca3f9d67f5591aab415222e2c9ec6184fc0b4f2
	INFO:root:Sleeping for 30 seconds
	DEBUG:root:Delta fee: 0.00004279
	DEBUG:root:Double-spend tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e385a344aee98de935440f04ecca0000000000ffffffff01ae0a0100000000001600149e12f3ef33ba4ccde4b85978e675c9fe59bb24a20247304402201289c26da70e9ec4424fc2ff7194b57384c78c9c986c2efe6771ac6f5fda199702200cefa72560f21cd9abe846078ce13197029562102f7a44b8ec50772a851c1799012102c56d86e3031851822485d1a2f9f0e402f14b96b64e711d5a2567412d1ea49a8b00000000
	INFO:root:Double-spend tx size: 0.191 KB, fees: 0.00004279, 0.00022403 BTC/KB
	INFO:root:Sent double-spend tx: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669cdb5

Remember that if you want to replicate this, don't be surprised if it takes quite a few attempts if you're sending tx1 with next-block fees. A minority of hash power is mining full-RBF. There's also a chance that in the ~30s or whatever you wait between tx1 and tx2, a block is found and tx1 gets mined. This chance is actually even higher than the ~5% you'd expect, because miners don't instantly update their block templates.

So if ~30% of hash power is actively mining full-RBF, you might actually have a ~20% chance per attempt at succeeding at a naive high-fee/higher-fee double-spend. Thus there's a (1-20%)^10 = 11% chance that 10 attempts in a row fail. Being that unlucky happens all the time; the Gods of Probability, probably hate you. :)

Finally, research like this is expensive in terms of my time and transaction fees; research via the OTS calendar approach is essentially free. Donations are appreciated as no-one is paying me to do full-RBF work or covering these expenses.

Cheapest/easiest way is via Lightning: https://stacker.news/petertodd

Or on-chain: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv

# References

1) https://github.com/bitcoin/bitcoin/pull/28132

On August 16, 2023 12:25:58 PM GMT+02:00, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

>Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption,

Correction: Anthony Towns

I am truly terrible with names...