path: root/06/2ac181dc02146b2533adf6add8d4a48bb4f4d2

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 969E4C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 19:10:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 494EE60A6C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 19:10:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 494EE60A6C
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=Xeh8Yy0a
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, 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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id LczCxMC9ZyjU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 19:10:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7E1F66063B
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
 [IPv6:2607:f8b0:4864:20::b2c])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 7E1F66063B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 19:10:31 +0000 (UTC)
Received: by mail-yb1-xb2c.google.com with SMTP id e62so14407230yba.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 12:10:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=TDEKJyPRFQDIujt/ozBSSvZBFtBgrKKSzbJ/Pe1pDmU=;
 b=Xeh8Yy0aCMJBCa+oAO2z+x4wQRAXk7kspaej4X1Y7ETV0WdIRo/HpddCMRZ3xIH6BX
 B7NiPo0//ce/ZXY7a8DLDXgt0bI98VGuwquGqV2vaPbe1WSYm5C+Xg5n4rdz5DRgpFJV
 eBUYzf35tu46gnIXCUATRtJCXnS4jan5qONA5u4vWjGS2rYzd47VqbYNsPD4d2ytu33q
 UJkCt3oiqhyGG0I3+GWdtqrxqN7QHQtyC5NV20qwCYgiZoGaDCTEg1k0GjxLYi1jQ9QE
 S/4BpsC33m+5EaeQLsdlMg07B/+UN+QgkGg1sMLK9huMkdUwUqtCHngNdacyrQ7TGZ6k
 xdwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=TDEKJyPRFQDIujt/ozBSSvZBFtBgrKKSzbJ/Pe1pDmU=;
 b=KSZzcm8syM01JfQF5GB9/LtTqziSE7GZxqgSVr8nIArKhg+VvN2YRjcvHovGIO+Tmt
 1DSV8wxfa1n8d0S1/92MyvSVPhdlmN0PqvJd9ZuVlh+oJFIzE1cQu+gnT30t598BwVqE
 9wP8OhQA6ESpxJT4PD0p8B/5+DXBfkqx9LouY07c9A/WuuvGLzO07E4HtUCJqcymjvjT
 tAiye4cNCwlewDq+i31OcXEtcMT8ZDb6uJfCa4hTUWtcB9Owx5HIpPfU156XG3b52p//
 i7WOo62B0gotPB6IZYJ5Ojp4hVNdlnw976gKwpN33lpOA98iyXsAgG2q8QILAkR2IqxZ
 jsCw==
X-Gm-Message-State: ACrzQf3DF4Y1dyVYqC+tyzegsBEhzs7raNBeRCVN+cwSvamdTEK/iKjQ
 B4R8H1WsQPxQs3ZTMgsfRerzebeVkO9ADLl40+atTT28
X-Google-Smtp-Source: AMsMyM4GG8T3L50hgXpKEnAMT3xUEDiw3go8WlL9yAm6dfeR7u3N6p/k5cdRP4YYwbanHmI5rs+N5AavPufvQNIgPD4=
X-Received: by 2002:a25:b11:0:b0:6bc:ea1a:6fe2 with SMTP id
 17-20020a250b11000000b006bcea1a6fe2mr11029865ybl.255.1666033830132; Mon, 17
 Oct 2022 12:10:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
 <903a46d95473714a7e11e33310fe9f56@yancy.lol>
In-Reply-To: <903a46d95473714a7e11e33310fe9f56@yancy.lol>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Mon, 17 Oct 2022 15:10:18 -0400
Message-ID: <CAD5xwhgKw+jWkadAvUU3KOqT19LmGX6vhUQFpZfJ_Zk0AjTcNA@mail.gmail.com>
To: email@yancy.lol
Content-Type: multipart/alternative; boundary="000000000000a103fc05eb3fba46"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Mon, 17 Oct 2022 19:10:33 -0000

--000000000000a103fc05eb3fba46
Content-Type: text/plain; charset="UTF-8"

Building on the most work chain is perhaps not rational in many normal
circumstances that can come up today under the stated reference strategy:

1) Take highest paying transactions that fit
2) Mine on tips

E.g., suppose:

Block N: Fees = 10, reward = 1

Mempool: Fees = 2

Mining block N+1 with the mempool leads to reward 2+1 = 3, reorging leads
to reward of up to 10 + 1 + c, (c < 2, where c is the extra transactions
that fit). Assume instead your reward is 8, leaving 3+c on the table.

If you assume all other miners are tip miners, and there are two
conflicting tips, they should pick the one with the more profit for them,
which is the new one you made as a non-tip miner since you "shared" some
fee.

You aren't particularly more likely to remine block N or N+1, before
someone builds on it, as opposed to deeper reorgs (which require larger
incentive).


However, as many have pointed out, perhaps not following the simple "honest
tip mining" strategy is bad for bitcoin, so maybe we should expect it not
to happen often? Or other strategies to emerge around selecting
transactions so that the next M blocks have a similar fee profile, as
opposed to picking greedily for the next block.


--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Sun, Oct 16, 2022 at 3:03 PM <email@yancy.lol> wrote:

> 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.
>
>
> It's interesting that Nash Equilibrium isn't mentioned here.  Since each
> miner has the option to either contribute to the longest chain or not, even
> if the miners know what strategy the other miners will use, they still
> wouldn't change their decision to contribute to the majority.
>
>
> 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.
>
>
> It would be honest if the store policy said ahead of time they are allowed
> to sell rain checks for more in such an occurrence.  Although this is a
> good example of the difference between honest and rational.  I think this
> means it's not a Nash Equilibrium if we needed to rely on the store owner
> to be honest.
>
>
> 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.
>
>
> My take is that "rational" is probably a better word than honest.  In
> terms of a Nash Equilibrium, each participant is simply trying to maximize
> their outcome and honesty doesn't matter (only that participants are
> rational).
>
>
> 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.
>
>
> I'm curious, can RBF can be described by a Nash Equilibrium?  If yes, then
> it also shouldn't matter if participants are honest?
>
>
> 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.
>
>
> White paper 1.1 :D
>
>
> 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)
>
>
> My take is the opposite unless I'm missing something.  Participants are
> always incentivized to choose the rational solution (Not to waste
> electricity on a minority chain).
>
> Cheers,
> -Yancy
>
> On 2022-10-16 19:35, Jeremy Rubin via bitcoin-dev wrote:
>
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Building on the most work=
 chain is perhaps not rational in many normal circumstances that can come u=
p today under the stated reference strategy:</div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:#000000">1) Take highest paying t=
ransactions that fit</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:#000000">2) Mine on tips<=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000">E.g., suppose:</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000">Block N: Fees =3D 10, reward =3D 1</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Mempool=
: Fees =3D 2</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:#000000">Mining block N+1 with the mempool leads to reward 2+1 =
=3D 3, reorging leads to reward of up to 10=C2=A0+ 1=C2=A0+ c, (c &lt; 2, w=
here c is the extra transactions that fit). Assume instead your reward is 8=
, leaving 3+c on the table.</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000">If you assume all other miners are tip mi=
ners, and there are two conflicting tips, they should pick the one with the=
 more profit for them, which is the new one you made as a non-tip miner sin=
ce you &quot;shared&quot; some fee.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">You aren&#39;t particularly more =
likely to remine block N or N+1, before someone builds on it, as opposed to=
 deeper reorgs (which require larger incentive).</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">However, as many have pointed out, perhaps not follo=
wing the simple &quot;honest tip mining&quot; strategy is bad for bitcoin, =
so maybe we should expect it not to happen often? Or other strategies to em=
erge around selecting transactions so that the next M blocks have a similar=
 fee profile, as opposed to picking greedily for the next block.</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gma=
il_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyR=
ubin" target=3D"_blank">@JeremyRubin</a><br></div></div></div><br></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, O=
ct 16, 2022 at 3:03 PM &lt;email@yancy.lol&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:=
1ex"><div style=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif">
<blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left-width:2px;=
border-left-style:solid;border-left-color:rgb(16,16,255);margin:0px">
<div style=3D"margin:0px;padding:0px;font-family:monospace">The proof-of-wo=
rk also solves the problem of determining<br>representation in majority dec=
ision <br>making. If the majority were based on one-IP-address-one-vote, it=
<br>could be subverted by anyone <br>able to allocate many IPs. Proof-of-wo=
rk is essentially<br>one-CPU-one-vote. The majority <br>decision is represe=
nted by the longest chain, which has the greatest<br>proof-of-work effort i=
nvested <br>in it. If a majority of CPU power is controlled by honest nodes=
, the<br>honest chain will grow the <br>fastest and outpace any competing c=
hains. To modify a past block, an<br>attacker would have to <br>redo the pr=
oof-of-work of the block and all blocks after it and then<br>catch up with =
and surpass the <br>work of the honest nodes. We will show later that the p=
robability of a<br>slower attacker catching up <br>diminishes exponentially=
 as subsequent blocks are added.</div>
</blockquote>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">It&#39;s intere=
sting that Nash Equilibrium isn&#39;t mentioned here.=C2=A0 Since each mine=
r has the option to either contribute to the longest chain or not, even if =
the miners know what strategy the other miners will use, they still wouldn&=
#39;t change their decision to contribute to the majority.</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left-width:2px;=
border-left-style:solid;border-left-color:rgb(16,16,255);margin:0px">
<div style=3D"margin:0px;padding:0px;font-family:monospace">For example, if=
 I run a shop that takes rain checks, but I sell an<br>item to a higher bid=
der who didn&#39;t have a hold on the item, that is<br>not honest, but it m=
ay be selfish profit maximizing.</div>
</blockquote>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">It would be hon=
est if the store policy said ahead of time they are allowed to sell rain ch=
ecks for more in such an occurrence.=C2=A0 Although this is a good example =
of the difference between honest and rational.=C2=A0 I think this means it&=
#39;s not a Nash Equilibrium if we needed to rely on the store owner to be =
honest.</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left-width:2px;=
border-left-style:solid;border-left-color:rgb(16,16,255);margin:0px">
<div style=3D"margin:0px;padding:0px;font-family:monospace">Satoshi said an=
 honest majority is required for the chain to be<br>extended. Honest is not=
 really defined though. Honesty, in my<br>definition, is that you follow a =
pre specified rule, rational or not.</div>
</blockquote>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">My take is that=
 &quot;rational&quot; is probably a better word than honest.=C2=A0 In terms=
 of a Nash Equilibrium, each participant is simply trying to maximize their=
 outcome and honesty doesn&#39;t matter (only that participants are rationa=
l).</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left-width:2px;=
border-left-style:solid;border-left-color:rgb(16,16,255);margin:0px">
<div style=3D"margin:0px;padding:0px;font-family:monospace">It seems a lot =
of the RBF controversy is that Protocol developers have<br>aspired to make =
the honest behavior also be the rational behavior.<br>This is maybe a good =
idea because, in theory, if the honest behavior<br>is rational then we can =
make a weaker assumption of selfishness<br>maximizing a parameter.</div>
</blockquote>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">I&#39;m curious=
, can RBF can be described by a Nash Equilibrium?=C2=A0 If yes, then it als=
o shouldn&#39;t matter if participants are honest?</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left-width:2px;=
border-left-style:solid;border-left-color:rgb(16,16,255);margin:0px">
<div style=3D"margin:0px;padding:0px;font-family:monospace">Overall, it mig=
ht be nice to more tightly document what bitcoins<br>assumptions are in pra=
ctice and what those assumptions do in terms of<br>properties of Bitcoin, a=
s well as pathways to weakening the<br>assumptions without compromising the=
 behaviors users expect the<br>network to have.=C2=A0 An &quot;extended whi=
te paper&quot; if you will.</div>
</blockquote>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">White paper 1.1=
 :D</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left-width:2px;=
border-left-style:solid;border-left-color:rgb(16,16,255);margin:0px">
<div style=3D"margin:0px;padding:0px;font-family:monospace">A last reflecti=
on is that Bitcoin is specified with an honest majority<br>assumption, but =
also has a rational dishonest minority assumption over<br>both endogenous (=
rewards) and exogenous (electricity) costs. Satoshi<br>did not suggest, at =
least as I read it, that Bitcoin works with an<br>rational majority assumpt=
ion. (If anyone thinks these three are<br>similar properties you can make s=
ome trivial counterexamples)</div>
</blockquote>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">My take is the =
opposite unless I&#39;m missing something.=C2=A0 Participants are always in=
centivized to choose the rational solution (Not to waste electricity on a m=
inority chain).</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">=C2=A0</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">Cheers,</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace">-Yancy</div>
<div style=3D"margin:0px;padding:0px;font-family:monospace"><br>On 2022-10-=
16 19:35, Jeremy Rubin via bitcoin-dev wrote:</div>
<blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left-width:2px;=
border-left-style:solid;border-left-color:rgb(16,16,255);margin:0px">The Bi=
tcoin white paper says: <br><br>The proof-of-work also solves the problem o=
f determining<br>representation in majority decision <br>making. If the maj=
ority were based on one-IP-address-one-vote, it<br>could be subverted by an=
yone <br>able to allocate many IPs. Proof-of-work is essentially<br>one-CPU=
-one-vote. The majority <br>decision is represented by the longest chain, w=
hich has the greatest<br>proof-of-work effort invested <br>in it. If a majo=
rity of CPU power is controlled by honest nodes, the<br>honest chain will g=
row the <br>fastest and outpace any competing chains. To modify a past bloc=
k, an<br>attacker would have to <br>redo the proof-of-work of the block and=
 all blocks after it and then<br>catch up with and surpass the <br>work of =
the honest nodes. We will show later that the probability of a<br>slower at=
tacker catching up <br>diminishes exponentially as subsequent blocks are ad=
ded.<br><br>This, Satoshi (who doesn&#39;t really matter anyways I guess?) =
claimed<br>that for Bitcoin to function properly you need a majority honest=
<br>nodes. <br><br>There are multiple behaviors one can describe as honest,=
 and<br>economically rational or optimizing is not necessarily rational.<br=
><br>For example, if I run a shop that takes rain checks, but I sell an<br>=
item to a higher bidder who didn&#39;t have a hold on the item, that is<br>=
not honest, but it may be selfish profit maximizing.<br><br>Satoshi said an=
 honest majority is required for the chain to be<br>extended. Honest is not=
 really defined though. Honesty, in my<br>definition, is that you follow a =
pre specified rule, rational or not.<br><br>It seems a lot of the RBF contr=
oversy is that Protocol developers have<br>aspired to make the honest behav=
ior also be the rational behavior.<br>This is maybe a good idea because, in=
 theory, if the honest behavior<br>is rational then we can make a weaker as=
sumption of selfishness<br>maximizing a parameter.<br><br>However, Satoshi =
did not particularly bound what aspects of honesty<br>are important for the=
 network, because there isn&#39;t a spec defining<br>exactly what is honest=
 or not. And also as soon as people are honest,<br>you can rely on that ass=
umption for good effect.<br><br>And sometimes, defining an honest behavior =
can be creating a higher<br>utility system because most people are &quot;la=
w abiding citizens&quot; who<br>might not be short term rational. For examp=
le, one might expect that<br>miners would be interested in making sure ligh=
tning closes are<br>&quot;accurate&quot; because increasing the utility of =
lightning is good for<br>Bitcoin, even if it is irrational.<br><br>It seems=
 that the NoRBF crowd want to rely on an honest majority<br>assumption wher=
e the honest behavior is not doing replacement if not<br>requested. This is=
 really not much different than trying to close<br>lightning channels &quot=
;the right way&quot;.<br><br>However, where it may be different, is that ev=
en in the presence of<br>honest majority, the safety of 0conf isn&#39;t ass=
ured given the potential<br>of race conditions in the mempool. Therefore it=
&#39;s not clear to me that<br>0conf working well is something you can driv=
e from the Honest Majority<br>Assumption (where honest includes first seen)=
.<br><br>Overall, it might be nice to more tightly document what bitcoins<b=
r>assumptions are in practice and what those assumptions do in terms of<br>=
properties of Bitcoin, as well as pathways to weakening the<br>assumptions =
without compromising the behaviors users expect the<br>network to have.=C2=
=A0 An &quot;extended white paper&quot; if you will.<br><br>=C2=A0It&#39;s =
somewhat clear to me that we shouldn&#39;t weaken assumptions that<br>only =
seem local to one subsystem of Bitcoin if they end up<br>destabilizing anot=
her system. In particular, things that decrease<br>&quot;transaction utilit=
y&quot; for end users decrease the demand for<br>transactions which hurts t=
he fee market&#39;s longer term viability, even<br>if we feel good about ma=
king an honest policy assumption into a self<br>interested policy assumptio=
n.<br><br>A last reflection is that Bitcoin is specified with an honest maj=
ority<br>assumption, but also has a rational dishonest minority assumption =
over<br>both endogenous (rewards) and exogenous (electricity) costs. Satosh=
i<br>did not suggest, at least as I read it, that Bitcoin works with an<br>=
rational majority assumption. (If anyone thinks these three are<br>similar =
properties you can make some trivial counterexamples)<br><br>Cheers,<br><br=
>Jeremy<br>_______________________________________________<br>bitcoin-dev m=
ailing list<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"http=
s://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=3D"noopener=
 noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailman/li=
stinfo/bitcoin-dev</a></blockquote>
</div>
</blockquote></div>

--000000000000a103fc05eb3fba46--