* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
[not found] <mailman.48662.1670246787.956.bitcoin-dev@lists.linuxfoundation.org>
@ 2022-12-05 15:19 ` John Carvalho
2022-12-05 21:14 ` Erik Aronesty
2022-12-12 2:27 ` ZmnSCPxj
0 siblings, 2 replies; 6+ messages in thread
From: John Carvalho @ 2022-12-05 15:19 UTC (permalink / raw)
To: Bitcoin-Dev, angus
[-- Attachment #1: Type: text/plain, Size: 9029 bytes --]
>
> 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@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
> 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
>
[-- Attachment #2: Type: text/html, Size: 11258 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
2022-12-05 15:19 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) John Carvalho
@ 2022-12-05 21:14 ` Erik Aronesty
2022-12-09 15:58 ` angus
2022-12-12 2:27 ` ZmnSCPxj
1 sibling, 1 reply; 6+ messages in thread
From: Erik Aronesty @ 2022-12-05 21:14 UTC (permalink / raw)
To: John Carvalho, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
>
>
>
> 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.
>
for low-value payments, lightning is the only workable version because the
current low-fee environment is not scalable and never will be
for high valued payments, zero conf was never valuable or useful and never
can be - it was always the beneficence of users you are relying on low
fee/high fee double spends of a zero conf with no rbf flag has
been demonstrated, repeatedly ad nauseum.
... so there is no long term scenario where zero conf is valuable.
right *now* with low fees it might "seem nice", but really it just
incentivises network-wide surveillance, increased peer burden on nodes, and
unsustainable practices that are akin to a "mev" bounty hanging over
merchant's heads.
also, i've been using bitcoin for years without zero conf. selling and
buying online. operating merchants with millions in transactions. the
20 minute wait before i ship is meaningless, and the only risk i take on is
that a user replaces a transaction with a different destination. which
i've never observed. even with the flag on (which i dont care about, and
never have).
and if i do observe it ... i just won't ship. it was easy to code up.
the user will have to initiate a new tx. i have no objection to a user
being able to cancel their order. why would i?
>
[-- Attachment #2: Type: text/html, Size: 1998 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
2022-12-05 21:14 ` Erik Aronesty
@ 2022-12-09 15:58 ` angus
2022-12-13 12:55 ` Anthony Towns
0 siblings, 1 reply; 6+ messages in thread
From: angus @ 2022-12-09 15:58 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion, John Carvalho
[-- Attachment #1.1.1: Type: text/plain, Size: 3449 bytes --]
I think the fundamental disagreement here that's causing the controversy and impasse is this:
Those in favour of Full RBF see trusting and relying on predictable mempool policy as a fundamentally flawed bad idea. Node policy is not a consensus rule - a miner has always been allowed to produce a block in the way a Full RBF node now would. An otherwise valid block that contains a tx that your not-full-RBF node ignored because it double-spent an earlier lower fee tx that didn't opt in to RBF is still a valid block. Knowing this, we conclude that it doesn't matter how useful or widely used Zero Conf is, it is fundamentally unsafe and should be actively discouraged, and changing mempool policy is a way to do this. The existence of Lightning as an alternative for immediate settlement makes this case stronger.
(As I see it) those that oppose Full RBF and want Zero Conf use to continue argue that node mempool policy can and has been relied upon for a long time already, and argue (rightly) that Zero Conf acceptance is already widely used and useful for both customers and merchants. Further arguing that Full RBF can be sucessfully unshipped, which requires that majority of node operators don't particularly care about it. Lastly, that neither miners nor users have an economic incentive to switch to Full RBF from the current core First-Seen policy. (Am I missing something else?)
---
I have sympathy for the utility argument, but to me it's completely overpowered by the "node policy is not consensus and not trustworthy" argument. Zero Conf acceptance rests on trusting that nodes are running with a first-seen policy. Just because this has worked out OK so far, doesn't mean that you won't get got bigtime in the future. You can accept this risk if you want to, but it shouldn't be a soft-rule that everyone else running a node should please help reduce that risk for you.
Sure, if I'm selling something on eBay or whatever for 100k sats and someone wants to pay in BTC in person, I'll accept with zero confirmations because there's a degree of trust and the risk isn't unbearable. If I'm accepting BTC as a company though, no, I'm not considering zero-confirmation transactions as settled.
I don't think the economic incentive argument currently matters all that much - miners want to maximise fees, users want to minimise, it's hard to tell which policy would have the higher overall fees for miners, and who wins miners-vs-users. This would also seem to depend on how wallets do or don't make use of the new RBF option (particularly hard for multisig). There is still an obvious incentive for someone to double-spend attack a Zero-Conf merchant, though.
I could be convinced to reverse my stance and oppose Full RBF if there was a strong economic argument that miners (better still, miners and users) should oppose it, because that would imply first-seen is incentive aligned. Aligning policy with incentives feels like the correct principle.
But for now, I want to run a Full RBF node because I see it as ultimately making Bitcoin stronger. It eliminates a use-case that takes risk. Accepting Zero Conf changes from "hrm, you shouldn't really do that but it works most of the time" to "no, really don't do that, you will probably lose money". Perhaps this is actually somewhat "vindictive, and perverse" as John said, but Bitcoin is money for enemies.
Thanks,
Angus
[-- Attachment #1.1.2.1: Type: text/html, Size: 6893 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
2022-12-05 15:19 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) John Carvalho
2022-12-05 21:14 ` Erik Aronesty
@ 2022-12-12 2:27 ` ZmnSCPxj
2022-12-12 9:57 ` John Carvalho
1 sibling, 1 reply; 6+ messages in thread
From: ZmnSCPxj @ 2022-12-12 2:27 UTC (permalink / raw)
To: John Carvalho, Bitcoin Protocol Discussion
Good morning John, et al,
> > 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.
It is helpful to remember that the fees are a price on confirmation.
And in economics, there is a "price theory":
* As price goes down, demand goes up.
* As price goes up, net-earning-per-unit goes up.
The combination of both forces causes a curve where *total* earnings vs price has a peak somewhere, an "optimum price", and that peak is *unlikely* to be at the maximum possible price you might deem reasonable.
And this optimum price may very well be *lower* than the prevailing market price of a good.
Thus, saying "RBF is actually a fee-minimization feature" neglects the economics of the situation.
If more people could use RBF onchain, more people would use Bitcoin and increase the value to miners.
Rather than a fee-minimization feature, RBF is really an optimization to *speed up* the discovery of the optimum price, and is thus desirable.
Unfortunately many 0-conf acceptors outright reject opt-in-RBF, despite the improved discovery of the optimum price, and thus there is a need for full-RBF to improve price discovery of blockspace when such acceptors are too prevalent.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
2022-12-12 2:27 ` ZmnSCPxj
@ 2022-12-12 9:57 ` John Carvalho
0 siblings, 0 replies; 6+ messages in thread
From: John Carvalho @ 2022-12-12 9:57 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]
Zman,
Price Theory simply explains the relationship between supply & demand. Your
post makes some logical leaps in that you are implying that demand follows
supply, which of course is not true, nor is that a claim of Price Theory.
If Bitcoin has less utility, it will have less demand, regardless of
whether it is well-optimized to allow for capacity saturation.
I do agree that there is an optimal state, and that such state is not
likely to be at the maximum price, because price maximization is exclusive.
(Whether I deem any of this as "reasonable," as you say, is irrelevant
other than whether I personally, subjectively choose to participate.)
The optimal state (most fees earned), would surely be a result of the most
value provided (per blockspace, per time period). While we must do our best
to make sure txns have the smallest footprint, and that people have ways to
pay a fee proportional to their time preference, there is always a maximum
quantity of demand willing to pay any given fee. My arguments express how
zero-conf currently creates added demand for blockspace, by
merchants/consumers, and additionally, demand for *next-block* inclusion
(maximum time preference) due to merchants qualifying fee rates to be
eligible for zero-conf acceptance.
So, me saying that RBF is fee-minimization, which you have conceded, is
apt, in that we should probably not trade off something like zero-conf
utility (demand) for something like mempoolfullrbf (blanket replaceability
that overrides status quo use cases).
Your statement of "If more people could use RBF onchain, more people would
use Bitcoin and increase the value to miners." is not economically rational
unless you truly can prove that supply creates demand. This is observably
false, as blocks are not full.
Also, you stated "Unfortunately many 0-conf acceptors outright reject
opt-in-RBF, despite the improved discovery of the optimum price, and thus
there is a need for full-RBF to improve price discovery of blockspace when
such acceptors are too prevalent." This is also irrational and incorrect.
First, merchants do not "outright reject" opt-in RBF, they simply make the
customer wait 1 conf. Second, full-rbf has no positive effect on price
discovery for blockspace if it results in less people using Bitcoin for
actual trade.
~John
It is helpful to remember that the fees are a price on confirmation.
> And in economics, there is a "price theory":
>
> * As price goes down, demand goes up.
> * As price goes up, net-earning-per-unit goes up.
>
> The combination of both forces causes a curve where *total* earnings vs
> price has a peak somewhere, an "optimum price", and that peak is *unlikely*
> to be at the maximum possible price you might deem reasonable.
> And this optimum price may very well be *lower* than the prevailing market
> price of a good.
>
> Thus, saying "RBF is actually a fee-minimization feature" neglects the
> economics of the situation.
> If more people could use RBF onchain, more people would use Bitcoin and
> increase the value to miners.
>
> Rather than a fee-minimization feature, RBF is really an optimization to
> *speed up* the discovery of the optimum price, and is thus desirable.
>
> Unfortunately many 0-conf acceptors outright reject opt-in-RBF, despite
> the improved discovery of the optimum price, and thus there is a need for
> full-RBF to improve price discovery of blockspace when such acceptors are
> too prevalent.
>
> Regards,
> ZmnSCPxj
>
[-- Attachment #2: Type: text/html, Size: 4005 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
2022-12-09 15:58 ` angus
@ 2022-12-13 12:55 ` Anthony Towns
0 siblings, 0 replies; 6+ messages in thread
From: Anthony Towns @ 2022-12-13 12:55 UTC (permalink / raw)
To: angus, Bitcoin Protocol Discussion; +Cc: John Carvalho
On Fri, Dec 09, 2022 at 03:58:37PM +0000, angus via bitcoin-dev wrote:
> Those in favour of Full RBF see trusting and relying on predictable
> mempool policy as a fundamentally flawed bad idea.
I don't believe that claim is true, at least in general: the motivation
for the -mempoolfullrbf PR was to make mempool policy behave in a way
that was (believed to be) more reliable and predictable than the current
behaviour.
In particular, if you can't rely on predictable relay/mempool policy,
you can't build "fraud proof" protocols on top of the blockchain: whether
that be like lightning today, which relies on people being able to get a
penalty transaction mined in a reasonable amount of time, or lightning in
the future which in an eltoo world relies on getting an update transaction
mined in a similar amount of time, or optimistic rollups that offer the
ability for people to challenge with a fraud proof.
I think the basis for the fullrbf vision is more that fullrbf advocates
think miners will always want to optimise fees in the short term: that is,
given two conflicting transactions H and L, if including H in the block
gives a higher total reward for that block than including L, they will
always want to include H. Presuming that is a common attitude amongst
miners, fullrbf is a natural outcome: those miners will advertise how
to connect to their nodes, and anyone who prefers H over L will send H
to them directly, and H will be mined and L will not be.
I think it's fair to say that's what people mean when they talk about
"incentive compatible" -- miners want to see the highest fee alternative
of a transaction, and are "incentivised" by fees to do so, so relaying
that transaction is "incentive compatible" while relaying lower fee
alternatives is "incentive incompatible".
That can be a stable outcome too: if it's common to have multiple
transactions like that, then the pools that take the higher fee
transactions will give higher payouts per hashrate, and owners of mining
hardware will switch to those pools, so that the amount of hashrate
accepting replacements will tend towards 100%. That scenario is already
the case for opt-in RBF.
However, expecting pools/miners to optimise fees in the short term is an
assumption, not the economic fact of life that some seem to assume it is.
It's also possible that owners of ASICs or pool operators will decide that
they're in this for the long term, and therefore that it's smarter to look
at fee income over multiple blocks, rather than taking each block as its
own entity. Similar to treating the prisoner's dilemma as a one-off game
(where the dominant strategy is to always defect) versus an iterated game
(where cooperation or tit-for-tat may be better strategies).
In particular, the outcome of fullrbf might not simply be the rosy
scenario:
+ there are just as many txs paying similar fees as there now,
except that
+ it's easy for people to cancel mistakes, and
+ people stop complaining to wallet authors when their opt-in
rbf tx takes longer to confirm than they expected
but might instead be either:
+ everyone using BTC for payments switches to lightning, causing
- on-chain traffic to drop and fee income to drop with it
or
- everyone paying for goods/services online with cryptocurrency
switches to stablecoins or ETH or Liquid or RSK,
- bitcoin traffic and tx fees drop substantially as a result,
- and bitcoin price drops too as people switch to hodling their
hot wallet balances in stablecoins and ETH
which pool operators or hashrate owners might consider to not be in
their best interests.
Sergej's numbers at
https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282
suggest bitefill's zeroconf txs alone account for something like 0.5%
of on-chain txs. I'm not really sure how to interpret the numbers Daniel
Lipshitz/Max Krupyshev reported; "700+ inputs a month" doesn't sound like
very many, but "300k incoming transactions" would be 35 years worth of
700 inputs per month, so something doesn't add up... The gap600 webpage
from 2018 cites 3 million Bitcoin txs over about 13 months, which would
be about 230k/month, which would be roughly 3% of on-chain txs at the
moment.
It's not clear to me what that adds up to; is reducing tx volume
by perhaps 5% or 10% a big deal? Given fee income is maybe 2% of the
block reward at the best of times, reducing it by 5% (to 1.9%) probably
doesn't matter directly, but then, nor would increasing it by 5%. So
if there's a negative effect on demand for bitcoin because it becomes
slower and less widely accepted, driving its price down, though, that
probably dominates. Is that likely to be signficant? No idea. Is there
some counterveiling effect where mempoolfullrbf would make bitcoin more
desirable, increasing demand and hence increasing its price? I can't
see one.
(The original reasoning for the mempoolfullrbf option was that it
would allow new use cases, namely collaborative funding of coinjoins or
lightning channels with less risk of getting your utxo stuck without
being able to blame whoever was causing it to get stuck, which would
have added a potential for both more fees from additional txs, and more
demand due to those use cases. Without that actually working as hoped,
we just have fewer on chain txs and worse demand in every scenario,
as far as I can see)
This isn't necessarily an incredibly stable equilibrium: once somewhere
around 10%-30% of hashrate is mining with fullrbf, presumably that
would make it too easy to cheat anyone willing to accept txs signalling
first-seen-final with 0 confirmations and they'll stop doing that, and if
the consequences are that everyone switches to lightning or stablecoins
and ETH, then that's all there is to it; it doesn't really matter what
the remaining 70%-90% of hashrate does, so at that point they might as
well do fullrbf as well, even if it only gets them a few pennies more.
But it's certainly possible for 95%+ of hashrate to decide that continuing
to ignore high fee replacements is in their best interests over the
long term -- that's how things are working currently, and how they've
worked for some years now. It's also how we'll want things to work if
we want anti-pinning schemes like those proposed for version-3 relay to
be effective.
One reason we might hope that miners will take a long-term view and
(presuming the long-term view is actually in favour of zeroconf) decide to
keep supporting zeroconf, even if we don't care about zeroconf ourselves,
is that miners prioritising long term income is arguably one of plausible
ways we can prevent 51% attacks from being a dominant strategy. If miners
are only focussing on immediate revenue, then case #4 in section 3.1 of
[0] applies, so 51% attacks are likely to be possible and profitable,
whereas if miners are focussing on bitcoin's long term value proposition,
then reorgs due to successful 51% attacks can be expected to trigger a
decline in the value of their investment in mining equipment, causing
case #4 not to apply. This is a similar argument to that presented in
section 2.3 of [1].
[0] https://www.nber.org/papers/w24717
[1] https://uncommoncore.co/wp-content/uploads/2019/10/A-model-for-Bitcoins-security-and-the-declining-block-subsidy-v1.02.pdf
Of course, that only needs perhaps 30%-50% of hashpower to be thinking
long term, rather than 70%-90%, and a lack of regular reorgs is probably
a clearer benefit than zeroconf transactions. Which is a bit of a win-win:
success at keeping zeroconf going should give confidence that miners will
help prevent 51% attacks; but failure at keeping zeroconf going doesn't
mean they won't be of help. And, of course it assumes that there is a
negative impact on either BTC price or block reward from killing off
zeroconf, which might not be true.
> I have sympathy for the utility argument, but to me it's completely
> overpowered by the "node policy is not consensus and not trustworthy"
> argument.
Anyway, in summary: consistent and predictable relay policy across nodes
remains important and possible whether or not that's a relay policy of
first seen is final, or highest fee rate wins, or something else.
> But for now, I want to run a Full RBF node because I see it as ultimately making Bitcoin stronger. It eliminates a use-case that takes risk.
It seems strange to advocate for preventing other people from voluntarily
taking on a small risk, that's demonstrably quite easily managed, and
also already quite easily avoided.
> Bitcoin is money for enemies.
I mean, if you want to live in a world where everyone's trying to help
someone else steal your money from you, it seems like the existing
banking system already had you covered?
If everyone's actually your enemy, your payments are going to get 51%
attacked, nodes are going to blacklist your utxos, miners are going
to ignore your penalty transactions so you'll lose all your L2 funds,
on-ramps and off-ramps will run KYC and put a hold on all your withdrawals
and confiscate your deposits, and in general Bitcoin isn't going to work
for you.
The point of "money for enemies" isn't that we need to treat other
Bitcoiners as enemies and stop them from doing things we dislike; it's
that to be a Bitcoiner you only need to agree on a few things, almost
none of which are the things that usually cause people to become enemies.
An alternative aphorism might be: Bitcoin is the money of the honest
majority.
That is, it puts the power in the hands of everyone running a node,
operating a miner, or holding their own private keys, rather than in a
few regulators or people with printing presses -- trusting an eclectic
majority rather than an elite minority, perhaps on the basis that you're
more likely to have a few dishonest people getting power out of a mass
of upstanding ordinary folks, rather than the reverse.
YMMV, of course, but I know how I'd prefer to view fellow Bitcoiners,
even the ones that disagree with me. (OTOH, if you claim we're enemies,
and I claim you're honest, where's that end up?)
Cheers,
aj
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-12-13 12:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.48662.1670246787.956.bitcoin-dev@lists.linuxfoundation.org>
2022-12-05 15:19 ` [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) John Carvalho
2022-12-05 21:14 ` Erik Aronesty
2022-12-09 15:58 ` angus
2022-12-13 12:55 ` Anthony Towns
2022-12-12 2:27 ` ZmnSCPxj
2022-12-12 9:57 ` John Carvalho
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox