path: root/fb/b19e8eb97b94e361f52d5ba204042d65254da5

Return-Path: <d@esotericnonsense.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 20FEEC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 15:30:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id CC7174020C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 15:30:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CC7174020C
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key, unprotected) header.d=esotericnonsense.com
 header.i=@esotericnonsense.com header.a=rsa-sha256 header.s=fm1
 header.b=5jfZMXod; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm2 header.b=Ke0bra4D
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.803
X-Spam-Level: 
X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fRtePa2L-sFw
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 15:30:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org F13FC401F4
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com
 [64.147.123.25])
 by smtp4.osuosl.org (Postfix) with ESMTPS id F13FC401F4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 15:30:39 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id EE36D32005CA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 10:30:35 -0500 (EST)
Received: from imap45 ([10.202.2.95])
 by compute2.internal (MEProxy); Sun, 11 Dec 2022 10:30:36 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 esotericnonsense.com; h=cc:content-transfer-encoding
 :content-type:date:date:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:sender:subject
 :subject:to:to; s=fm1; t=1670772635; x=1670859035; bh=S6pqfPMD0p
 YpnHLHZv8h3SfV8kFHBKwjJUvWaSuCqAQ=; b=5jfZMXodR2wGky9tcXmhwXbllE
 v6DonLNRTr/QwjZJwtAkYg1XBsXntrhF4P14YMaWhJETC0PNACzIG+D2Wy0OYmc5
 /3cFGGry2THqtFWCyCrC4kB5btL0XQym8H+6mvT3OsBJnAGXdWjx+KHJAsBrvfcD
 5EKxJUAa99jBipBN+cNUES1nY/c2Dsz+k86QZdT+QeR5D7PlwlNatUormOpAzA7X
 WSzYfU9q69qW8MWbXEjeyTWInso2wNUosNfkDDrYhNL9a5BEAa7T+lrmqmYSIZLS
 veo0AlFwf8V9cVeasgHU9OrweligIYBuU5bcXT9xUYxRNd86nx2W8eJxE73g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:date:feedback-id:feedback-id:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:sender
 :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender
 :x-me-sender:x-sasl-enc; s=fm2; t=1670772635; x=1670859035; bh=S
 6pqfPMD0pYpnHLHZv8h3SfV8kFHBKwjJUvWaSuCqAQ=; b=Ke0bra4DDT6ET7bVt
 KEjQDndeLK6C0I4LeLOxtCCT1LCr4Y3nhe6nJgyE//md1CjTgwKizPCKyRFMRr4N
 +J2N0ron7YZmfx71ONwV3lFk5e3c1N3ZZ2xrPowvyUM5OKQYr1yPLOBBXnmk2zFN
 XRMmYKZFx0yMyjWMtgePV0XkVZT4pceth0UQWUCY8Kd//zu2BBuXTSntTs3NRX+Q
 eO49083iUxABCsAl+mG3FiPzWOI6JEpcPFMXDYUClO44PHe9vBD5+ExoekduScrI
 qcRXdycvRDac8hGL6LeWKkHw1TTuoK3exJbsjfvuq2rY+3U/Np2YPWXgMgfdqCOG
 CCGrQ==
X-ME-Sender: <xms:m_eVY1-aTHIAKlgr_a4-Ls0Pw6XKRr0k4I3XffknMT_LeRxjNdUlfw>
 <xme:m_eVY5sw2XZagUUcavZdfeN9Xr_zSU-sX8SFCgYQ4odbgNAgOGItJmT9lGfdN0CNA
 cnNbnPr3riMyriL4Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeigdejjecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdffrghn
 ihgvlhcugfgughgvtghumhgsvgdfuceougesvghsohhtvghrihgtnhhonhhsvghnshgvrd
 gtohhmqeenucggtffrrghtthgvrhhnpedtgeeugfekfeekhfeifffhuddtffejfeejjeek
 keehteevudeiuefgieejffduffenucffohhmrghinhepvghsohhtvghrihgtnhhonhhsvg
 hnshgvrdgtohhmpdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgnecuvehluhhsthgv
 rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepugesvghsohhtvghrihgtnh
 honhhsvghnshgvrdgtohhm
X-ME-Proxy: <xmx:m_eVYzBMaezXIJc4Xw6VWKQ-QDVfluSSw3cLf7EKvtqqKxgviQdZyA>
 <xmx:m_eVY5f8a2RgY6jeYN7jYd-Ub7Bks6NNQT27tS-B29HMvYjQBs2WKA>
 <xmx:m_eVY6P6YdD0Zjj-WY2anzt--2lxNgeux_1DYcu0SqNpTOhyVrXr6g>
 <xmx:m_eVYwZSzCy-Lu5Bxxf6JNhV7Y1GDZrO0vL8Qj3Z5wVQMbH3a1ZbyQ>
Feedback-ID: ib8694789:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501)
 id 4D6DE272007A; Sun, 11 Dec 2022 10:30:35 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
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
X-Mailman-Approved-At: Sun, 11 Dec 2022 15:38:53 +0000
Subject: Re: [bitcoin-dev]
 =?utf-8?q?Rethinking_=E2=80=9CIncentive_Compatibili?=
 =?utf-8?q?ty=E2=80=9D_Within_the_Bitcoin_Protocol?=
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Dec 2022 15:30:42 -0000

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