summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Edgecumbe <d@esotericnonsense.com>2022-12-11 15:30:14 +0000
committerbitcoindev <bitcoindev@gnusha.org>2022-12-11 15:30:42 +0000
commit0f6837f4989c793b0013a78cc38e571a247eeb3e (patch)
tree2ef9df175195011a705cb081a411e58e48210dac
parent15fac97816327f20319ee64c1bec5f4b4e403bf3 (diff)
downloadpi-bitcoindev-0f6837f4989c793b0013a78cc38e571a247eeb3e.tar.gz
pi-bitcoindev-0f6837f4989c793b0013a78cc38e571a247eeb3e.zip
Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol
-rw-r--r--fb/b19e8eb97b94e361f52d5ba204042d65254da5253
1 files changed, 253 insertions, 0 deletions
diff --git a/fb/b19e8eb97b94e361f52d5ba204042d65254da5 b/fb/b19e8eb97b94e361f52d5ba204042d65254da5
new file mode 100644
index 000000000..b3803a702
--- /dev/null
+++ b/fb/b19e8eb97b94e361f52d5ba204042d65254da5
@@ -0,0 +1,253 @@
+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
+