From: angus <angus@toaster•cc>
To: Daniel Lipshitz <daniel@gap600•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
Date: Mon, 05 Dec 2022 12:21:44 +0000 [thread overview]
Message-ID: <-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_CstCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=@toaster.cc> (raw)
In-Reply-To: <CACkWPs-2e8QVTwnBcos7WA0c2+iLcY2XGCZzY0xt9L_voyx9UA@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 2883 bytes --]
Core adding full RBF is a change of node policy that may be highly inconvenient for zero-conf users, but there has always been and will always be a risk of a double-spend for anyone that treats zero-confirmation transactions as settled. It's literally in the name - this transaction has zero confirmations and no guarantee it'll make it into a block, and so has not yet settled.
The perception seems to be that Core adding the full RBF option is increasing the risk to zero-conf users, but I'm not convinced that that is the case - someone wanting to double-spend attack you isn't going to be bothered to do so over a few thousand sats (unless they can do it thousands of times), and losing a few thousand sats to a double-spend isn't the biggest deal.
It's always been the risk of getting double-spent out of hundreds or thousands of bitcoins that's worth seriously worrying about, which is much more the kind of attack a determined attacker is able to carry out. Such a determined attacker is much more likely to attempt and succeed at a sybil attack, or directly colluding with a miner. So your zero-conf risk increases non-linearly as the amount of bitcoin being transacted grows. (caveat: this paragraph is opinion).
There does, however, seem to be a legitimate business for providing insurance/risk management for people that are willing to accept the zero-conf risk - it is pretty similar to accepting credit cards with a chargeback risk or any payment card with a capture risk, though there's no-one to mediate a dispute. On-chain is final.
But what doesn't make any sense is trying to avoid Bitcoin Core and nodes from adopting a full RBF policy to try to protect this use case. As has been pointed out by may others before, full RBF is aligned with miner (and user) economic incentives and is a node policy, not consensus, so you can't even tell which nodes are doing it nor can you prevent them from doing so. Second, Bitcoin core 24 with the full RBF option is already out in the wild at around 5%+ of running nodes and growing, so it's too late to kill it.
So my point is that relying on node policy as part of your protection for zero-conf transaction acceptance is fragile, and should not be relied upon. The protocol rules have always tacitly allowed double-spending before a confirmation, and it has always been clear that there's no consensus on which transactions have occurred until they have in a block and have at-least one confirmation.
The long-term 'what to do about it' is to use Lightning if you want fast payments with risk-free instant settlement, or as above, accept the zero-conf risk and cover yourself with an insurance premium (e.g. a margin on transactions that goes into an insurance fund, and limiting max transaction amount so you're not exposed to uncoverable losses if you do get double-spend attacked)
Angus
[-- Attachment #1.1.2.1: Type: text/html, Size: 5800 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
next prev parent reply other threads:[~2022-12-05 12:27 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 12:27 Daniel Lipshitz
2022-12-01 22:03 ` Erik Aronesty
2022-12-02 6:34 ` Daniel Lipshitz
2022-12-02 1:52 ` Antoine Riard
2022-12-02 6:59 ` Daniel Lipshitz
2022-12-02 22:35 ` [bitcoin-dev] Fwd: " Antoine Riard
2022-12-06 5:03 ` Peter Todd
2022-12-02 4:30 ` [bitcoin-dev] " Peter Todd
2022-12-02 7:06 ` Daniel Lipshitz
2022-12-03 8:50 ` Peter Todd
2022-12-03 11:01 ` Daniel Lipshitz
2022-12-03 11:51 ` Daniel Lipshitz
2022-12-03 12:12 ` Peter Todd
2022-12-03 13:17 ` Daniel Lipshitz
2022-12-03 14:03 ` Daniel Lipshitz
2022-12-05 12:21 ` angus [this message]
[not found] <6342098B-A548-43C9-8F92-AAD9D0BB66AB@coinspaid.com>
2022-12-03 14:06 ` Daniel Lipshitz
[not found] <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
2022-10-19 14:29 ` Sergej Kotliar
2022-10-19 14:45 ` Erik Aronesty
2022-10-19 15:43 ` Jeremy Rubin
2022-10-19 15:51 ` Greg Sanders
2022-10-19 16:04 ` Sergej Kotliar
2022-10-19 16:08 ` Greg Sanders
2022-10-20 1:37 ` Antoine Riard
2022-10-20 14:11 ` Sergej Kotliar
2022-10-21 1:04 ` Antoine Riard
2022-10-20 4:05 ` Peter Todd
2022-10-21 19:35 ` Peter Todd
2022-10-20 7:22 ` Anthony Towns
2022-10-20 12:37 ` Sergej Kotliar
2022-10-20 14:14 ` Ruben Somsen
2022-10-20 14:17 ` Sergej Kotliar
2022-10-20 19:58 ` Anthony Towns
2022-10-20 21:05 ` David A. Harding
2022-10-20 21:07 ` Greg Sanders
2022-10-20 22:02 ` Eloy
2022-10-21 12:02 ` Sergej Kotliar
2022-10-21 14:01 ` Greg Sanders
2022-10-21 14:19 ` Sergej Kotliar
2022-10-21 14:47 ` Greg Sanders
2022-10-21 19:43 ` Peter Todd
2022-10-24 7:55 ` Sergej Kotliar
2022-10-20 22:13 ` Peter Todd
2022-10-21 9:34 ` Sergej Kotliar
2022-10-21 19:33 ` Peter Todd
2022-10-24 7:45 ` Sergej Kotliar
2022-10-21 11:56 ` Sergej Kotliar
2022-10-23 19:20 ` David A. Harding
2022-10-23 20:51 ` alicexbt
[not found] <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
2022-10-14 10:03 ` John Carvalho
2022-10-14 15:04 ` Peter Todd
2022-10-14 16:28 ` Erik Aronesty
2022-10-15 4:08 ` John Carvalho
2022-10-15 4:20 ` John Carvalho
-- strict thread matches above, loose matches on Subject: below --
2022-10-07 16:20 Dario Sneidermanis
2022-10-07 17:21 ` David A. Harding
2022-10-07 17:28 ` Greg Sanders
2022-10-07 21:37 ` Dario Sneidermanis
2022-10-11 16:18 ` Pieter Wuille
2022-10-12 5:42 ` Anthony Towns
2022-10-12 16:11 ` Pieter Wuille
2022-10-12 21:44 ` Dario Sneidermanis
2022-10-13 4:35 ` Anthony Towns
2022-10-16 8:08 ` Anthony Towns
2022-10-17 14:25 ` Greg Sanders
2022-10-17 21:41 ` Antoine Riard
2022-10-18 7:00 ` Anthony Towns
2022-10-19 3:01 ` Antoine Riard
2022-10-19 3:17 ` alicexbt
2022-10-20 22:08 ` Peter Todd
2022-11-02 15:04 ` AdamISZ
2022-10-20 23:18 ` Peter Todd
2022-11-09 13:19 ` ArmchairCryptologist
2022-11-10 9:35 ` ZmnSCPxj
2022-10-07 20:56 ` Luke Dashjr
2022-10-08 20:47 ` alicexbt
2022-10-13 16:07 ` linuxfoundation.cndm1
2022-10-14 2:44 ` alicexbt
2022-10-14 15:02 ` Peter Todd
2022-10-17 20:31 ` Antoine Riard
2022-10-17 22:14 ` Antoine Riard
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='-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_CstCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=@toaster.cc' \
--to=angus@toaster$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=daniel@gap600$(echo .)com \
/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