[bitcoin-dev] Pull-req to enable Full-RBF by default

[bitcoin-dev] Pull-req to enable Full-RBF by default

[Peter Todd]

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

FYI I have submitted a pull-req to Bitcoin Core to enable full-rbf by default:

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

At the moment approximately 40% of the total Bitcoin hash power is mining
full-rbf replacements, spread over 8 different pools. Multiple block explorers,
including blockstream.info(1) and mempool.space(2), have enabled full-rbf on
all their nodes. Nodes installed via BTCPay Server(3) and MyNode(4), among
others, enable full-rbf by default. Measurements also indicate that a
significant percentage of nodes have manually enabled full-rbf(5), and there
exists a well-connected set of nodes running my full-rbf peering patch(6).

As https://mempool.space/rbf#fullrbf shows, successful full-rbf replacements
are fairly common. Though the fact that only a minority of nodes relay full-rbf
replacements is still a nuisance barrier to taking advantage of them, eg in
multi-party transactions(7). A typical non-listening node with only 8 outgoing
connections is certainly *not* guaranteed to have full-rbf peers. Thus, my
pull-req to enable full-rbf by default.

Meanwhile, the last time full-rbf was discussed on this mailing list the only
opposition to full-rbf from actual entities with an actual claimed use(8) of
unconfirmed transactions was Bitrefill. I've checked multiple times, most
recently today, and I can find no evidence that Bitrefill actually accepts
unconfirmed transactions as payment any more even though their payment page
claims otherwise. Every test transactions I've done - from a variety of emails
and accounts not linked to myself - has required a confirmation.

Finally, on-chain wallets have been moving towards removing the ability to set
non-BIP125-rbf transactions entirely. For example, Electrum removed the ability
to turn off BIP125 last year(9), and Phoenix, Green, Nunchuck, and Zeus, -
among others - also provide no way to turn BIP125 off. For these wallets, the
existence of "non-replaceable" transactions is merely a support headache(10).

The fact is the dream of "on-chain coffee payments" is well and truly dead.
There is clearly no value in having the BIP125 distinction when ~40% of hashing
power ignores it. There is also clear value in *not* having that distinction:
https://petertodd.org/2023/why-you-should-run-mempoolfullrbf


We should enable full-rbf by default in Bitcoin Core github master, to be
released in the upcoming v26.0. Following that, we can depreciate and
eventually remove all BIP125 code and associated complexity in future releases
after that.


# References

1) https://github.com/Blockstream/esplora/commit/289cc6539497c3f42ab5c591c2369b75d90046e6
2) https://github.com/mempool/mempool/pull/3867
3) https://docs.btcpayserver.org/FAQ/Wallet/#does-btcpay-server-use-mempoolfullrbf-1-
4) https://github.com/mynodebtc/mynode/commit/a6cd63583cab8c62510925492bb2cfda9d2add09
5) https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
6) https://github.com/petertodd/bitcoin/tree/full-rbf-v25.0
7) https://petertodd.org/2023/fullrbf-multiparty-protocols
8) While GAP600 claimed to act as a payment processor for unconfirmed
   transactions, they refused to actually provide examples of real services
   making use of them. Given their ties to BSV, I'm inclined to believe that
   they are lying.
9) https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388
10) https://github.com/spesmilo/electrum/issues/8490

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

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

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Peter Todd]

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

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/

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

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

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Daniel Lipshitz]

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

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

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

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Daniel Lipshitz]

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

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
>

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

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Peter Todd]

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

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

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

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Daniel Lipshitz]

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

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
>

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

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Peter Todd]

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

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

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

[bitcoin-dev] Pull-req to enable Full-RBF by default

[Daniel Lipshitz]

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

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

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