From: Daniel Lipshitz <daniel@gap600•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Pull-req to enable Full-RBF by default
Date: Mon, 31 Jul 2023 13:26:11 +0300 [thread overview]
Message-ID: <CACkWPs9JRYNd5bNGCZzihhywY1GDaXfSh858GhL7TrU=uzUB0A@mail.gmail.com> (raw)
In-Reply-To: <mailman.126799.1690753843.956.bitcoin-dev@lists.linuxfoundation.org>
[-- 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 --]
next prev parent reply other threads:[~2023-07-31 10:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.126799.1690753843.956.bitcoin-dev@lists.linuxfoundation.org>
2023-07-31 4:12 ` [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn) Hugo L
2023-08-02 5:58 ` Keagan McClelland
2023-07-31 10:26 ` Daniel Lipshitz [this message]
2023-08-01 15:04 ` [bitcoin-dev] Pull-req to enable Full-RBF by default Peter Todd
2023-08-01 22:27 ` Daniel Lipshitz
2023-08-02 1:28 ` Peter Todd
2023-08-02 10:38 ` Daniel Lipshitz
2023-08-02 15:29 ` Daniel Lipshitz
2023-08-03 12:46 ` Peter Todd
2023-08-16 10:25 ` [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now Peter Todd
2023-08-16 14:02 ` Peter Todd
2023-07-30 15:44 [bitcoin-dev] Pull-req to enable Full-RBF by default Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACkWPs9JRYNd5bNGCZzihhywY1GDaXfSh858GhL7TrU=uzUB0A@mail.gmail.com' \
--to=daniel@gap600$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox