Feedback-ID: ib8694789:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-Id: <bc30bad3-1b93-4972-9893-80f3d51675eb@app.fastmail.com>
In-Reply-To: <CAHTn92zBcMp7Fn27aCV75V7GEzUcP2-cDcGN+CKe5+SRgyt2ow@mail.gmail.com>
References: <CAHTn92zBcMp7Fn27aCV75V7GEzUcP2-cDcGN+CKe5+SRgyt2ow@mail.gmail.com>
Date: Sun, 11 Dec 2022 15:30:14 +0000
From: "Daniel Edgecumbe" <d@esotericnonsense.com>
To: "M.K. Safi via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev]
 =?utf-8?q?Rethinking_=E2=80=9CIncentive_Compatibili?=
 =?utf-8?q?ty=E2=80=9D_Within_the_Bitcoin_Protocol?=
Precedence: list

I've been on the sidelines for a while reading these e-mails but it's be=
come 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 spend=
s is provided in Bitcoin.

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

RBF doesn't actually materially affect that at all. Regardless of what h=
appens 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 s=
ome sort of short term 51% attack behaviour, you're SOL.

Zeroconf goes even beyond that - if you rely on a transaction in the mem=
pool, a miner can choose to mine a conflicting one regardless of what th=
e relay policy in Core is. The only cost to them is the fee difference b=
etween 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 mine=
rs 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 does=
n't matter what colour we paint the zeroconf shed, it doesn't have a roo=
f 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=20
> from engineers trying to reign in all of the possible behaviors that=20
> make it inconsistent, I can=E2=80=99t help but think about how I see p=
eople=20
> using the term =E2=80=9Cincentive-compatible=E2=80=9D and how it seems=
 to be awfully=20
> presumptive.
>
> The idea that a single Bitcoin transaction can be=20
> =E2=80=9Cincentive-compatible=E2=80=9D by simply restricting it to hav=
ing a higher fee=20
> or fee rate is theoretical, likely narrow, and not totally objective.=20
> RBF is inherently a fee-minimization tool, which as a concept, as I=20
> understand =E2=80=9Cincentive-compatibility=E2=80=9D to be about miner=
s in this=20
> 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=20
> miners, and the mempool, are prioritizing for the smallest txns with=20
> the highest fees, over the longest acceptable amount of time, this may=20
> conflict with extra-mempool behaviors that result in more txns per=20
> block / per lifetime.
>
> If this isn=E2=80=99t making sense yet, let me summarize by how such a=
 problem=20
> would express: a per-transaction fee-minimized, fully replaceable=20
> mempool as policy, that appears to always require the highest fee per=20
> txn, but ultimately includes less txns per block and less fees per=20
> lifetime. Basically, less use cases, less users, less txns=E2=80=8A=E2=
=80=94=E2=80=8Aall to=20
> enforce a misunderstood theory and predictive speculation of what=20
> people want out of the system and what miners will do about it.
>
> Simply, we probably want designs that fill blocks, and we don=E2=80=99=
t need to=20
> do anything at all to facilitate bidding on a use case like replacemen=
t.
>
> Bidding does not require protocol enforcement, it is miner-subjective.=20
> So why are we pursuing it? Why do we even have RBF? Why are we trying=20
> to clean up all of the mess RBF creates with more and more code? If=20
> bidding is already accepted as incentive-compatible, and Bitcoin=20
> already allows setting a fee, then replacement requires no special cod=
e=20
> at all.
>
> I would think a holistic definition of what is incentive-compatible=20
> would be something more like what is =E2=80=9Cmarket compatible=E2=80=9D=
 and enables=20
> the complementary goals & incentives of every user in the system to=20
> make it thrive.
>
> It has been shown that users control Bitcoin (UASF) and thus ultimatel=
y=20
> miners would be incentivized to do what users want, up to the point of=20
> inability or loss. Correct?
>
> So, in contrast, how would the opposite, a user-compatible design,=20
> express? Well, I think the idea of txns being able to signal intent an=
d=20
> desired behavior is more interesting (more useful) than a mempool that=20
> overrides all intent with RBF, and possibly more incentive-compatible=20
> than mempoolfullrbf as concept.
>
> Since we can=E2=80=99t be sure what the market wants, but we can be su=
re that=20
> the more users we have, making the most possible txns, at the highest=20
> possible prices, will yield the most valuable Bitcoin, and thus the=20
> most hashpower, we could entertain giving users the most ways to=20
> express their intent, the most flexibility.
>
> The most basic design would be to simply have no mempool policy at all=
,=20
> and let market incentives emerge on their own, but we have a status qu=
o=20
> to consider, and most users do not have the technical expertise to=20
> express their own policies with misc patches and hacks of their Bitcoi=
n=20
> Core software.
>
> I know this is a bit of a high-level abstract perspective, but I think=20
> it is important to respect such dynamics when making smaller decisions=
.=20
> It certainly is not our charge to prioritize what miners want any more=20
> than any other user type, nor is it within our ability to predict the=20
> 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,=20
> but what I am trying to convey is a possible folly in active=20
> management, speculation, and misapplied game theory that may permeate=20
> many Bitcoin Core decisions and designs, even beyond the mempoolrbf /=20
> zero-conf debate.
>
> So, what to do?
>
> =E2=80=94
>
> John Carvalho
> CEO, Synonym.to
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev