John Carvalho [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-05 📝 Original message:> > The perception seems ...
📅 Original date posted:2022-12-05
📝 Original message:>
> 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.
If this "perception" were not true, RBF & full-RBF would not be necessary
at all. Think about it.
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.
The risk exposure to merchants providing zero-conf acceptance as a service
is finite, capped by their risk-tolerance, and capped by the current block
exposure. Merchants cap their exposure to be an amount worth less than the
value of this service.
It is highly inefficient and difficult for a miner to pull off an
industry-wide attack across diverse merchants to capture the current
maximum exposure in any given block, not to mention the enormous surface
area of legal risk across jurisdictions...
I don't think zero-conf opponents properly grasp that the risk exposure is
exact and perfectly, trustlessly manageable. I would like the opportunity
to spec the methods Bitrefill, Synonym, and most such merchants, use to
make it standard practice, as it is cheaper for merchants and more
convenient to Bitcoin consumers when merchants behave this way.
As has been pointed out by may others before, full RBF is aligned with
> miner (and user) economic incentives
This is a theory, not a fact. I can refute this theory by pointing out
several aspects:
1. RBF is actually a fee-minimization feature that allows users to game
the system to spend the *least* amount in fees that correlates to their
time-preference. Miners earn less when fees can be minimized (obviously).
This feature also comes at an expense (albeit small) to nodes providing
replacement service and propagation.
2. Miners care about max fees per block, not slightly increased fees on a
minority % of incidentally replaced txns when they happen to need it. They
want the most txns for the highest price per *block*. In order to qualify
for zero-conf acceptance, merchants require that the fee rate match or
exceed an amount that makes the txn likely to be included in the very next
block. This creates a priority competition from users with high
time-preference. This creates not only more fees for miners, but more txns
from more people using the chain for commerce. This is evidenced by stats
provided recently to this mailing list, but here are more numbers from
Bitrefill:
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282
3. Miners ultimately want what users want, as more users = more txns = more
fees = higher BTC price. For all of Bitcoin's history, more users have
wanted zero-conf than replacements. This is evidenced by first-seen policy
thriving for years without disruption (until engineers actively disrupted
it, using fallible theories as justification). This is also evidenced by
the UASF battle where miners capitulated to providing the type of blocks
that users demanded, to avoid uncertainty.
4. A replaceable mempool is inherently less valuable than a first-seen
policy mempool in that Bitcoin is ultimately a ledger for a *payments*
system where people are trying to pay and be paid with certainty. A
full-RBF system would result in more real-world doublespends to existing
merchants and p2p commerce, as it is impossible to fully teach all aspects
of Bitcoin dynamics to users, particularly when they have enjoyed many
years of first-seen behavior as status quo.
Zero-conf and first-seen policies are clearly more
incentive-compatible than RBF outright for these reasons.
The long-term 'what to do about it' is to use Lightning if you want fast
> payments with risk-free instant settlement
Many zero-conf proponents work on the bleeding edge of supporting
Lightning, including myself. Lightning is not risk-free and the base layer
should not be assuming it as a primary dependency for commercial payments.
The UX and complexity of supporting Lightning is still considerable,
adoption is still very low, and there are many unsolved attack vectors and
risks that remain untested due to Lightning's low prevalence.
Further, zero-conf is also useful as a tool in improving Lightning
onboarding, rebalancing, splicing, and UX overall. Bitcoin second-layers
are only as good as the base layer, everything else is a tradeoff.
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.
This is pure speculation. If Bitcoin Core publishes an update without the
mistakenly-rushed feature, the mempoolfullrbf movement is likely to die on
the vine as users opt into the latest versions more and more, as evidenced
by all older versions decreasing in usage over time. The incentive to run
old versions, just to be able to force non-RBF txns to be treated as RBF,
is lower than the incentive and likelihood of updating. Frankly, such an
incentive is mostly obscure, vindictive, and perverse, IMO.
We should remove the mempoolfullrbf feature immediately from Bitcoin Core
distributions, as requested here:
https://github.com/bitcoin/bitcoin/pull/26525
This mistake demands correction, and no one has provided a
rational beneficial argument so far for breaking the user space and
disrupting mempool harmony.
If you would like further arguments and refutations of full-RBF, please
read all of the posts in my PR thread:
https://github.com/bitcoin/bitcoin/pull/26525
Thank you,
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>;
Date: Mon, 05 Dec 2022 12:21:44 +0000
> From: angus <angus at toaster.cc>
> To: Daniel Lipshitz <daniel at gap600.com>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
> danger
> Message-ID:
>
> <-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_CstCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=@toaster.cc>
>
> Content-Type: text/plain; charset="utf-8"
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/f3d67ada/attachment-0001.html>;
📝 Original message:>
> 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.
If this "perception" were not true, RBF & full-RBF would not be necessary
at all. Think about it.
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.
The risk exposure to merchants providing zero-conf acceptance as a service
is finite, capped by their risk-tolerance, and capped by the current block
exposure. Merchants cap their exposure to be an amount worth less than the
value of this service.
It is highly inefficient and difficult for a miner to pull off an
industry-wide attack across diverse merchants to capture the current
maximum exposure in any given block, not to mention the enormous surface
area of legal risk across jurisdictions...
I don't think zero-conf opponents properly grasp that the risk exposure is
exact and perfectly, trustlessly manageable. I would like the opportunity
to spec the methods Bitrefill, Synonym, and most such merchants, use to
make it standard practice, as it is cheaper for merchants and more
convenient to Bitcoin consumers when merchants behave this way.
As has been pointed out by may others before, full RBF is aligned with
> miner (and user) economic incentives
This is a theory, not a fact. I can refute this theory by pointing out
several aspects:
1. RBF is actually a fee-minimization feature that allows users to game
the system to spend the *least* amount in fees that correlates to their
time-preference. Miners earn less when fees can be minimized (obviously).
This feature also comes at an expense (albeit small) to nodes providing
replacement service and propagation.
2. Miners care about max fees per block, not slightly increased fees on a
minority % of incidentally replaced txns when they happen to need it. They
want the most txns for the highest price per *block*. In order to qualify
for zero-conf acceptance, merchants require that the fee rate match or
exceed an amount that makes the txn likely to be included in the very next
block. This creates a priority competition from users with high
time-preference. This creates not only more fees for miners, but more txns
from more people using the chain for commerce. This is evidenced by stats
provided recently to this mailing list, but here are more numbers from
Bitrefill:
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282
3. Miners ultimately want what users want, as more users = more txns = more
fees = higher BTC price. For all of Bitcoin's history, more users have
wanted zero-conf than replacements. This is evidenced by first-seen policy
thriving for years without disruption (until engineers actively disrupted
it, using fallible theories as justification). This is also evidenced by
the UASF battle where miners capitulated to providing the type of blocks
that users demanded, to avoid uncertainty.
4. A replaceable mempool is inherently less valuable than a first-seen
policy mempool in that Bitcoin is ultimately a ledger for a *payments*
system where people are trying to pay and be paid with certainty. A
full-RBF system would result in more real-world doublespends to existing
merchants and p2p commerce, as it is impossible to fully teach all aspects
of Bitcoin dynamics to users, particularly when they have enjoyed many
years of first-seen behavior as status quo.
Zero-conf and first-seen policies are clearly more
incentive-compatible than RBF outright for these reasons.
The long-term 'what to do about it' is to use Lightning if you want fast
> payments with risk-free instant settlement
Many zero-conf proponents work on the bleeding edge of supporting
Lightning, including myself. Lightning is not risk-free and the base layer
should not be assuming it as a primary dependency for commercial payments.
The UX and complexity of supporting Lightning is still considerable,
adoption is still very low, and there are many unsolved attack vectors and
risks that remain untested due to Lightning's low prevalence.
Further, zero-conf is also useful as a tool in improving Lightning
onboarding, rebalancing, splicing, and UX overall. Bitcoin second-layers
are only as good as the base layer, everything else is a tradeoff.
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.
This is pure speculation. If Bitcoin Core publishes an update without the
mistakenly-rushed feature, the mempoolfullrbf movement is likely to die on
the vine as users opt into the latest versions more and more, as evidenced
by all older versions decreasing in usage over time. The incentive to run
old versions, just to be able to force non-RBF txns to be treated as RBF,
is lower than the incentive and likelihood of updating. Frankly, such an
incentive is mostly obscure, vindictive, and perverse, IMO.
We should remove the mempoolfullrbf feature immediately from Bitcoin Core
distributions, as requested here:
https://github.com/bitcoin/bitcoin/pull/26525
This mistake demands correction, and no one has provided a
rational beneficial argument so far for breaking the user space and
disrupting mempool harmony.
If you would like further arguments and refutations of full-RBF, please
read all of the posts in my PR thread:
https://github.com/bitcoin/bitcoin/pull/26525
Thank you,
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>;
Date: Mon, 05 Dec 2022 12:21:44 +0000
> From: angus <angus at toaster.cc>
> To: Daniel Lipshitz <daniel at gap600.com>, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
> danger
> Message-ID:
>
> <-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_CstCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=@toaster.cc>
>
> Content-Type: text/plain; charset="utf-8"
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/f3d67ada/attachment-0001.html>;