diff options
author | Daniel Edgecumbe <d@esotericnonsense.com> | 2022-12-11 15:30:14 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-12-11 15:30:42 +0000 |
commit | 0f6837f4989c793b0013a78cc38e571a247eeb3e (patch) | |
tree | 2ef9df175195011a705cb081a411e58e48210dac | |
parent | 15fac97816327f20319ee64c1bec5f4b4e403bf3 (diff) | |
download | pi-bitcoindev-0f6837f4989c793b0013a78cc38e571a247eeb3e.tar.gz pi-bitcoindev-0f6837f4989c793b0013a78cc38e571a247eeb3e.zip |
Re: [bitcoin-dev] Rethinking “Incentive Compatibility” Within the Bitcoin Protocol
-rw-r--r-- | fb/b19e8eb97b94e361f52d5ba204042d65254da5 | 253 |
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 + |