path: root/34/e8c52e357bb1ad1027aa99212f941f8ddad896

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id BCD46C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Oct 2022 17:36:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 909AB40104
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Oct 2022 17:36:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 909AB40104
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=a6V9fUMm
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 3koZQvCnM5pI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Oct 2022 17:36:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5826640223
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com
 [IPv6:2607:f8b0:4864:20::b35])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 5826640223
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Oct 2022 17:36:08 +0000 (UTC)
Received: by mail-yb1-xb35.google.com with SMTP id 81so10979490ybf.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Oct 2022 10:36:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=M1ifEUQGcir7A3eE5u5x6hhXlM7fZF4RcA4qPYy5NLI=;
 b=a6V9fUMmJA+HX7Ltq8bAkW1e+N8YzL4VcyLnTB32BkaaWCkPhIfxEtaGFSRtRkQYBq
 mpCb9859YLDdoI6X47ADVr+ZyhFq9rp1NQOUOmlFcOVmPK12d2XfOAvwuoK62Q+Cbd0I
 Tlp90qWzYuAjKvdhF/HvM/FnuZpcJkhm7KsooH2XbIjCNbe6OHpUKBiFRtw53ruG0MRn
 QBGRXjhtcoQdS2p4+7A6ff7NdSw7V0fgPi5By4rhJuqXcLkP8NKw+rnCTArKwtzsnLI9
 SoN9oNsjUkaJaqwAWbQhrEXdj/+t8W+1F6V9iXfTXwZZkm6tfn7RwQs7o38GpLea2L8n
 DU/A==
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=M1ifEUQGcir7A3eE5u5x6hhXlM7fZF4RcA4qPYy5NLI=;
 b=lWSI6bxt7UTAa9bT9sbujbnf+NxWyqMsrn4Ns4hK9fmRzEGglAMvft68+ZJI5EVYCs
 oFTqiAgszuYfhMf6qJIpA7XoSEkltFtI2sPYqE2AXlDQfa9jZWhP+XitU099L2sXPkUe
 wLq+H2BrqGwPiQaQ61XiLWSySY+17JjkEbMB/511kwDSJLICS4I+/y+6k3Kt48vtCNtI
 Rinody2rOHkPuzFyJ7eaTb1HPbK7MktonEMEOpBeKgFa66QHPe9CyIfm2Pt6pWxgZ+IE
 0gJ5lQzEvMK1cvNFKscr4BHzIFEr8UvAqSmThYhk0Cf5DZFcVw5k4MaTbI9DjTDoZ85B
 H0Lg==
X-Gm-Message-State: ACrzQf1Da8TJic3ugkGveEp5oQc0/ixkcQiPu8TbCP2dxdfHsmnDyMdZ
 GefTzl+KA29XjWWspHXzuYclZSnsqHD1V6xIIiwxujAH
X-Google-Smtp-Source: AMsMyM6sqfiP4KOGtT/nXxa/XuFSUKLgneVEv4gssxfz1fysHr/nbkFuK1EgaY5ee0s8vYn1KI7f9XFfMcRI230nT7s=
X-Received: by 2002:a25:2509:0:b0:6c1:86e1:b8a1 with SMTP id
 l9-20020a252509000000b006c186e1b8a1mr6664377ybl.350.1665941766553; Sun, 16
 Oct 2022 10:36:06 -0700 (PDT)
MIME-Version: 1.0
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Sun, 16 Oct 2022 13:35:54 -0400
Message-ID: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000036438305eb2a4b47"
Subject: [bitcoin-dev] Does Bitcoin require or have an honest majority or a
 rational one? (re rbf)
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, 16 Oct 2022 17:36:10 -0000

--00000000000036438305eb2a4b47
Content-Type: text/plain; charset="UTF-8"

The Bitcoin white paper says:

The proof-of-work also solves the problem of determining representation in
majority decision
making. If the majority were based on one-IP-address-one-vote, it could be
subverted by anyone
able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.
The majority
decision is represented by the longest chain, which has the greatest
proof-of-work effort invested
in it. If a majority of CPU power is controlled by honest nodes, the honest
chain will grow the
fastest and outpace any competing chains. To modify a past block, an
attacker would have to
redo the proof-of-work of the block and all blocks after it and then catch
up with and surpass the
work of the honest nodes. We will show later that the probability of a
slower attacker catching up
diminishes exponentially as subsequent blocks are added.


This, Satoshi (who doesn't really matter anyways I guess?) claimed that for
Bitcoin to function properly you need a majority honest nodes.

There are multiple behaviors one can describe as honest, and economically
rational or optimizing is not necessarily rational.

For example, if I run a shop that takes rain checks, but I sell an item to
a higher bidder who didn't have a hold on the item, that is not honest, but
it may be selfish profit maximizing.

Satoshi said an honest majority is required for the chain to be extended.
Honest is not really defined though. Honesty, in my definition, is that you
follow a pre specified rule, rational or not.

It seems a lot of the RBF controversy is that Protocol developers have
aspired to make the honest behavior also be the rational behavior. This is
maybe a good idea because, in theory, if the honest behavior is rational
then we can make a weaker assumption of selfishness maximizing a parameter.

However, Satoshi did not particularly bound what aspects of honesty are
important for the network, because there isn't a spec defining exactly what
is honest or not. And also as soon as people are honest, you can rely on
that assumption for good effect.

And sometimes, defining an honest behavior can be creating a higher utility
system because most people are "law abiding citizens" who might not be
short term rational. For example, one might expect that miners would be
interested in making sure lightning closes are "accurate" because
increasing the utility of lightning is good for Bitcoin, even if it is
irrational.

It seems that the NoRBF crowd want to rely on an honest majority assumption
where the honest behavior is not doing replacement if not requested. This
is really not much different than trying to close lightning channels "the
right way".

However, where it may be different, is that even in the presence of honest
majority, the safety of 0conf isn't assured given the potential of race
conditions in the mempool. Therefore it's not clear to me that 0conf
working well is something you can drive from the Honest Majority Assumption
(where honest includes first seen).


Overall, it might be nice to more tightly document what bitcoins
assumptions are in practice and what those assumptions do in terms of
properties of Bitcoin, as well as pathways to weakening the assumptions
without compromising the behaviors users expect the network to have.  An
"extended white paper" if you will.


 It's somewhat clear to me that we shouldn't weaken assumptions that only
seem local to one subsystem of Bitcoin if they end up destabilizing another
system. In particular, things that decrease "transaction utility" for end
users decrease the demand for transactions which hurts the fee market's
longer term viability, even if we feel good about making an honest policy
assumption into a self interested policy assumption.

A last reflection is that Bitcoin is specified with an honest majority
assumption, but also has a rational dishonest minority assumption over both
endogenous (rewards) and exogenous (electricity) costs. Satoshi did not
suggest, at least as I read it, that Bitcoin works with an rational
majority assumption. (If anyone thinks these three are similar properties
you can make some trivial counterexamples)


Cheers,

Jeremy

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

<div dir=3D"auto"><div dir=3D"auto">The Bitcoin white paper says:=C2=A0</di=
v><div dir=3D"auto"><br></div>The proof-of-work also solves the problem of =
determining representation in majority decision
<div dir=3D"auto">making. If the majority were based on one-IP-address-one-=
vote, it could be subverted by anyone
</div><div dir=3D"auto">able to allocate many IPs. Proof-of-work is essenti=
ally one-CPU-one-vote. The majority
</div><div dir=3D"auto">decision is represented by the longest chain, which=
 has the greatest proof-of-work effort invested
</div><div dir=3D"auto">in it. If a majority of CPU power is controlled by =
honest nodes, the honest chain will grow the
</div><div dir=3D"auto">fastest and outpace any competing chains. To modify=
 a past block, an attacker would have to
</div><div dir=3D"auto">redo the proof-of-work of the block and all blocks =
after it and then catch up with and surpass the
</div><div dir=3D"auto">work of the honest nodes. We will show later that t=
he probability of a slower attacker catching up
</div><div dir=3D"auto">diminishes exponentially as subsequent blocks are a=
dded.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">This, Satoshi (who doesn&#39;t really matter anyways I guess?) cl=
aimed that for Bitcoin to function properly you need a majority honest node=
s.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">There are multi=
ple behaviors one can describe as honest, and economically rational or opti=
mizing is not necessarily rational.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">For example, if I run a shop that takes rain checks, but I sell=
 an item to a higher bidder who didn&#39;t have a hold on the item, that is=
 not honest, but it may be selfish profit maximizing.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Satoshi said an honest majority is required f=
or the chain to be extended. Honest is not really defined though. Honesty, =
in my definition, is that you follow a pre specified rule, rational or not.=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">It seems a lot of the R=
BF controversy is that Protocol developers have aspired to make the honest =
behavior also be the rational behavior. This is maybe a good idea because, =
in theory, if the honest behavior is rational then we can make a weaker ass=
umption of selfishness maximizing a parameter.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">However, Satoshi did not particularly bound what asp=
ects of honesty are important for the network, because there isn&#39;t a sp=
ec defining exactly what is honest or not. And also as soon as people are h=
onest, you can rely on that assumption for good effect.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">And sometimes, defining an honest behavior =
can be creating a higher utility system because most people are &quot;law a=
biding citizens&quot; who might not be short term rational. For example, on=
e might expect that miners would be interested in making sure lightning clo=
ses are &quot;accurate&quot; because increasing the utility of lightning is=
 good for Bitcoin, even if it is irrational.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">It seems that the NoRBF crowd want to rely on an hones=
t majority assumption where the honest behavior is not doing replacement if=
 not requested. This is really not much different than trying to close ligh=
tning channels &quot;the right way&quot;.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">However, where it may be different, is that even in the p=
resence of honest majority, the safety of 0conf isn&#39;t assured given the=
 potential of race conditions in the mempool. Therefore it&#39;s not clear =
to me that 0conf working well is something you can drive from the Honest Ma=
jority Assumption (where honest includes first seen).</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Overall, it might=
 be nice to more tightly document what bitcoins assumptions are in practice=
 and what those assumptions do in terms of properties of Bitcoin, as well a=
s pathways to weakening the assumptions without compromising the behaviors =
users expect the network to have.=C2=A0 An &quot;extended white paper&quot;=
 if you will.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">=C2=A0It&#39;s somewhat clear to me that we shouldn&#39;t=
 weaken assumptions that only seem local to one subsystem of Bitcoin if the=
y end up destabilizing another system. In particular, things that decrease =
&quot;transaction utility&quot; for end users decrease the demand for trans=
actions which hurts the fee market&#39;s longer term viability, even if we =
feel good about making an honest policy assumption into a self interested p=
olicy assumption.</div><div dir=3D"auto"><br></div><div dir=3D"auto">A last=
 reflection is that Bitcoin is specified with an honest majority assumption=
, but also has a rational dishonest minority assumption over both endogenou=
s (rewards) and exogenous (electricity) costs. Satoshi did not suggest, at =
least as I read it, that Bitcoin works with an rational majority assumption=
. (If anyone thinks these three are similar properties you can make some tr=
ivial counterexamples)</div><div dir=3D"auto"><br></div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Cheers,</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Jeremy=C2=A0</div></div>

--00000000000036438305eb2a4b47--