Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol

From: "Daniel Edgecumbe" <d@esotericnonsense•com>
To: "M.K. Safi via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol
Date: Sun, 11 Dec 2022 15:30:14 +0000	[thread overview]
Message-ID: <bc30bad3-1b93-4972-9893-80f3d51675eb@app.fastmail.com> (raw)
In-Reply-To: <CAHTn92zBcMp7Fn27aCV75V7GEzUcP2-cDcGN+CKe5+SRgyt2ow@mail.gmail.com>

I've been on the sidelines for a while reading these e-mails but it's become rather frustrating to read as of late.

As far as I see it the fundamental principle is that the blockchain, via subsequent confirmations, is the way that security against double spends is provided in Bitcoin.

The application of proof of work to achieve that is the primary innovation of the system that seperates it from simply using digital signatures.

RBF doesn't actually materially affect that at all. Regardless of what happens in the mempool, if you rely on an N-conf transaction being final, and N blocks get reversed, either by an inadvertant chain split or by some sort of short term 51% attack behaviour, you're SOL.

Zeroconf goes even beyond that - if you rely on a transaction in the mempool, a miner can choose to mine a conflicting one regardless of what the relay policy in Core is. The only cost to them is the fee difference between the two transactions, which in the vast majority of cases will be zero or in the favour of the miner.

If we're going to talk about incentive compatibility - in this case the incentive compatible thing, perhaps even a design decision, is that miners just create a backchannel that ignores your censoring of transactions in the mempool.

The debate itself feels like bikeshedding to me for that reason. It doesn't matter what colour we paint the zeroconf shed, it doesn't have a roof and it's made of cardboard.

Daniel Edgecumbe | esotericnonsense
d@esotericnonsense•com | https://esotericnonsense.com

On Sat, Dec 10, 2022, at 12:10, John Carvalho via bitcoin-dev wrote:
> As we debate mempoolfullrbf, and I familiarize myself with related PRs 
> from engineers trying to reign in all of the possible behaviors that 
> make it inconsistent, I can’t help but think about how I see people 
> using the term “incentive-compatible” and how it seems to be awfully 
> presumptive.
>
> The idea that a single Bitcoin transaction can be 
> “incentive-compatible” by simply restricting it to having a higher fee 
> or fee rate is theoretical, likely narrow, and not totally objective. 
> RBF is inherently a fee-minimization tool, which as a concept, as I 
> understand “incentive-compatibility” to be about miners in this 
> context, makes RBF to be anti-incentives; miners are fee maximizers.
>
> Miners want the most fees per block, and per lifetime, do they not? If 
> miners, and the mempool, are prioritizing for the smallest txns with 
> the highest fees, over the longest acceptable amount of time, this may 
> conflict with extra-mempool behaviors that result in more txns per 
> block / per lifetime.
>
> If this isn’t making sense yet, let me summarize by how such a problem 
> would express: a per-transaction fee-minimized, fully replaceable 
> mempool as policy, that appears to always require the highest fee per 
> txn, but ultimately includes less txns per block and less fees per 
> lifetime. Basically, less use cases, less users, less txns — all to 
> enforce a misunderstood theory and predictive speculation of what 
> people want out of the system and what miners will do about it.
>
> Simply, we probably want designs that fill blocks, and we don’t need to 
> do anything at all to facilitate bidding on a use case like replacement.
>
> Bidding does not require protocol enforcement, it is miner-subjective. 
> So why are we pursuing it? Why do we even have RBF? Why are we trying 
> to clean up all of the mess RBF creates with more and more code? If 
> bidding is already accepted as incentive-compatible, and Bitcoin 
> already allows setting a fee, then replacement requires no special code 
> at all.
>
> I would think a holistic definition of what is incentive-compatible 
> would be something more like what is “market compatible” and enables 
> the complementary goals & incentives of every user in the system to 
> make it thrive.
>
> It has been shown that users control Bitcoin (UASF) and thus ultimately 
> miners would be incentivized to do what users want, up to the point of 
> inability or loss. Correct?
>
> So, in contrast, how would the opposite, a user-compatible design, 
> express? Well, I think the idea of txns being able to signal intent and 
> desired behavior is more interesting (more useful) than a mempool that 
> overrides all intent with RBF, and possibly more incentive-compatible 
> than mempoolfullrbf as concept.
>
> Since we can’t be sure what the market wants, but we can be sure that 
> the more users we have, making the most possible txns, at the highest 
> possible prices, will yield the most valuable Bitcoin, and thus the 
> most hashpower, we could entertain giving users the most ways to 
> express their intent, the most flexibility.
>
> The most basic design would be to simply have no mempool policy at all, 
> and let market incentives emerge on their own, but we have a status quo 
> to consider, and most users do not have the technical expertise to 
> express their own policies with misc patches and hacks of their Bitcoin 
> Core software.
>
> I know this is a bit of a high-level abstract perspective, but I think 
> it is important to respect such dynamics when making smaller decisions. 
> It certainly is not our charge to prioritize what miners want any more 
> than any other user type, nor is it within our ability to predict the 
> future or fully model incentives of all players across all use cases.
>
> I know some of you may scoff at my bias for use cases like zero-conf, 
> but what I am trying to convey is a possible folly in active 
> management, speculation, and misapplied game theory that may permeate 
> many Bitcoin Core decisions and designs, even beyond the mempoolrbf / 
> zero-conf debate.
>
> So, what to do?
>
> —
>
> John Carvalho
> CEO, Synonym.to
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev