path: root/f7/d05cc7f6c1f898573a5bbe5ca1283e6f8ef97d

Return-Path: <john@synonym.to>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 778BAC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Dec 2022 12:10:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 457A360A84
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Dec 2022 12:10:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 457A360A84
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com
 header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=CH/7ZUsh
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id O7Qp6ok7-Wd4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Dec 2022 12:10:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E9E79607F1
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com
 [IPv6:2607:f8b0:4864:20::12c])
 by smtp3.osuosl.org (Postfix) with ESMTPS id E9E79607F1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Dec 2022 12:10:36 +0000 (UTC)
Received: by mail-il1-x12c.google.com with SMTP id i25so1222152ila.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 10 Dec 2022 04:10:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=synonym-to.20210112.gappssmtp.com; s=20210112;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=31aoD+Byybq3UhOXJwJTppMusIOeVlnQHeyqN3pyA4A=;
 b=CH/7ZUshyE5A0h59Px38FYQjR2Fx68OjsIndaLibm4VXl/HgIiBV6lHy2kyTPOgEqr
 Tjm3XuHZP8vqD+kLbcZtq0AGv8MM4KlTAn+wDm0ZNuTQI/JsHHbJKuraqTuUckQtUAHO
 NIRP+h8bnomBAzPW9S23LJgsg5zKxqGQCNVAEMJzCCo/hHMuGZA8fK8vcKQzSyfrrJJR
 3H+mzf1+u+a7+3PDrkq9RyH9YMVuWO5IeiekDecz+r0xd0myo5WzfuLaYqwo0ftDphAb
 u4qq8GvXXdgjm33AVon154m9+G3dktbpn5mvoxQXlG3jTGaSVRml8WFOjY7mT/5b5+rv
 mg0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=31aoD+Byybq3UhOXJwJTppMusIOeVlnQHeyqN3pyA4A=;
 b=iZN0jVzfwkpxIDcBDyb8Optf02o94qvacvhP5zoDlX66q+BGBC0zvpSWCSDem+posn
 0yQO/AH++YIRlxevV7TVzaFsrvdvIVSwPw+OkbOK9/eagL48IijvCZ/UlA9/CnkusHdC
 iKFrWtmmAeqaQJ3/xCt57Jq6vK43lqMo0/8o9rgJOL1A3MjCUJNzKL1JIUgSduyaM6aw
 4oBmWOYwJ3G8SZowvG3YlBX6f41pHm5viRRknMJPdmQFh0tAcQG1qrFiPoNzsSv4du2B
 0O+tv1ALRtX6/Kl8qV33qnZLY6xthGPSp3kyFzIJgM6JBnDyBbSGeXTU/xrg7i2lvahF
 tygQ==
X-Gm-Message-State: ANoB5pnTRt9XF9+Rt9ZV0RD+qHoJTcV+yJ69KhjGQU8hmVMKsaVqRwW3
 WTu27fzlYUoiKQ2JonbdDiYXGc7nxqOcSsUuxq1ihHrZj8ExA112
X-Google-Smtp-Source: AA0mqf5rMzPPxMxduLXChXf3irtB9fWUg1F3pi/SHLAQXhd0DIBQvA/likuLxGa20Fe0e0h77FlQ548FoJQaxy/2zcQ=
X-Received: by 2002:a05:6e02:194b:b0:303:387f:2ac0 with SMTP id
 x11-20020a056e02194b00b00303387f2ac0mr14732433ilu.122.1670674235413; Sat, 10
 Dec 2022 04:10:35 -0800 (PST)
MIME-Version: 1.0
From: John Carvalho <john@synonym.to>
Date: Sat, 10 Dec 2022 12:10:24 +0000
Message-ID: <CAHTn92zBcMp7Fn27aCV75V7GEzUcP2-cDcGN+CKe5+SRgyt2ow@mail.gmail.com>
To: Bitcoin <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005673cc05ef78288d"
X-Mailman-Approved-At: Sat, 10 Dec 2022 16:50:11 +0000
Subject: [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: Sat, 10 Dec 2022 12:10:38 -0000

--0000000000005673cc05ef78288d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=99t help but think about how I see people using t=
he term
=E2=80=9Cincentive-compatible=E2=80=9D and how it seems to be awfully presu=
mptive.

The idea that a single Bitcoin transaction can be =E2=80=9Cincentive-compat=
ible=E2=80=9D 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
=E2=80=9Cincentive-compatibility=E2=80=9D to be about miners in this contex=
t, 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=E2=80=99t making sense yet, let me summarize by how such a prob=
lem
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 =E2=80=94 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=E2=80=99t nee=
d 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 =E2=80=9Cmarket compatible=E2=80=9D and enab=
les 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=E2=80=99t be sure what the market wants, but we can be sure th=
at 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?

=E2=80=94

John Carvalho
CEO, Synonym.to

--0000000000005673cc05ef78288d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As we debate mempoolfullrbf, and I familiarize myself with=
 related PRs from engineers trying to reign in all of the possible behavior=
s that make it inconsistent, I can=E2=80=99t help but think about how I see=
 people using the term =E2=80=9Cincentive-compatible=E2=80=9D and how it se=
ems to be awfully presumptive.<br><br>The idea that a single Bitcoin transa=
ction can be =E2=80=9Cincentive-compatible=E2=80=9D by simply restricting i=
t 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 c=
oncept, as I understand =E2=80=9Cincentive-compatibility=E2=80=9D to be abo=
ut miners in this context, makes RBF to be anti-incentives; miners are fee =
maximizers.<br><br>Miners want the most fees per block, and per lifetime, d=
o they not? If miners, and the mempool, are prioritizing for the smallest t=
xns with the highest fees, over the longest acceptable amount of time, this=
 may conflict with extra-mempool behaviors that result in more txns per blo=
ck / per lifetime.<br><br>If this isn=E2=80=99t making sense yet, let me su=
mmarize by how such a problem would express: a per-transaction fee-minimize=
d, fully replaceable mempool as policy, that appears to always require the =
highest fee per txn, but ultimately includes less txns per block and less f=
ees per lifetime. Basically, less use cases, less users, less txns=E2=80=8A=
=E2=80=94=E2=80=8Aall to enforce a misunderstood theory and predictive spec=
ulation of what people want out of the system and what miners will do about=
 it.<br><br>Simply, we probably want designs that fill blocks, and we don=
=E2=80=99t need to do anything at all to facilitate bidding on a use case l=
ike replacement.<br><br>Bidding does not require protocol enforcement, it i=
s 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 c=
ode? If bidding is already accepted as incentive-compatible, and Bitcoin al=
ready allows setting a fee, then replacement requires no special code at al=
l.<br><br>I would think a holistic definition of what is incentive-compatib=
le would be something more like what is =E2=80=9Cmarket compatible=E2=80=9D=
 and enables the complementary goals &amp; incentives of every user in the =
system to make it thrive.<br><br>It has been shown that users control Bitco=
in (UASF) and thus ultimately miners would be incentivized to do what users=
 want, up to the point of inability or loss. Correct?<br><br>So, in contras=
t, 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.<br=
><br>Since we can=E2=80=99t be sure what the market wants, but we can be su=
re that the more users we have, making the most possible txns, at the highe=
st 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.<br><br>The most basic design would be to simp=
ly 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 hac=
ks of their Bitcoin Core software.<br><br>I know this is a bit of a high-le=
vel abstract perspective, but I think it is important to respect such dynam=
ics when making smaller decisions. It certainly is not our charge to priori=
tize what miners want any more than any other user type, nor is it within o=
ur ability to predict the future or fully model incentives of all players a=
cross all use cases.<br><br>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 i=
n active management, speculation, and misapplied game theory that may perme=
ate many Bitcoin Core decisions and designs, even beyond the mempoolrbf / z=
ero-conf debate.<br><br>So, what to do?<br><br>=E2=80=94<br><br>John Carval=
ho<br>CEO, Synonym.to</div>

--0000000000005673cc05ef78288d--