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