path: root/7d/57b0fbb77cbef66e02d98e95646c9f2e6974b0

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C614EC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 16:27:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 97C1661087
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 16:27:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 97C1661087
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=evB6B8fA
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 FN6kf_h5TeMY
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 16:27:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 36E5B606CB
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com
 [IPv6:2607:f8b0:4864:20::b33])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 36E5B606CB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 16:27:40 +0000 (UTC)
Received: by mail-yb1-xb33.google.com with SMTP id t186so17587683yba.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 09:27:40 -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=fVRLM8m9WrP2Ojv9bc7I/+ryV0RDi0N9jkSFQ6mAZ+Y=;
 b=evB6B8fA5ixf7vZYr8+7Y9hy4Tz4psLQ4biIoobEYTKC06yyruawNy/Bgpujeeu0Of
 +s0M6L6UgOwokJ7QShOd7TBuBUCiZCebMxgcNdd2Ue694rpi+F/A/mYxjmrRMDEbGmLt
 /4lXAzVw2uRIJezp5bXz+j7owbL4B8ojw7oDDPm9Vp1YcZ9DKU4mU6A6DPcnrfwAAH6i
 wtMGg8sxw+iOwvvqh5Ke4Qx1vjxNpBD6+v7hh2VHiwl3P0zwlJQwyV8XwGQcqJWd+Qtx
 4fz8T5+oXL5qD0PJ+50ieBqETzkdJaVnVuk7igk4XngQE9ghCVaUZURUsq60snKiIb9Q
 Ka+w==
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=fVRLM8m9WrP2Ojv9bc7I/+ryV0RDi0N9jkSFQ6mAZ+Y=;
 b=jIvjLRRhaCxFruiA5a62WezCJrpIA7tR30MMV1rLXpUw5V+IHyHNKL+4VSbWmQT6HW
 StU26IdcbUI7arh1nQhJEtcV5YGzs11j5PjJ0wnkoZS+0YMJH+VzysGEjzrQPn97JBRF
 FqPSS6jOyK/+hB3Z9k4QXEtnk093Kcs9ZOvoAtnH05LM3tlLLwQKMAeRy8uyM/SutZYp
 mMvsuNlar7TO7Axsh1l7FhJgPHTnFrckjg+ablhtwwAPLVdf/1k2PqBzBabZKNWs/2LF
 zf0Kkj8Ii2Bo1bUiKc0u/LaZ8GePiCkwvfLatJqq/UQP/voEm5vl/K3UWLmtSMAF1dnE
 MBZw==
X-Gm-Message-State: ACrzQf2dw5OTIQLwv3Lb0d6vj2tBEoy6smo01ex57RyV3ga50L9mj8HD
 ygf7KbiHrt5pAu5pva3ayQEOuuQvD2ofT7bu8bo=
X-Google-Smtp-Source: AMsMyM6SN2Ws3C+WW8u1BfS6kFRvu0PMmPxRm3P2m26cEpyhhibbKl9XERbpxCBhbasH200OJrvkK5eXqsup0LO6QoU=
X-Received: by 2002:a25:2509:0:b0:6c1:86e1:b8a1 with SMTP id
 l9-20020a252509000000b006c186e1b8a1mr3392362ybl.350.1666110458888; Tue, 18
 Oct 2022 09:27:38 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
 <903a46d95473714a7e11e33310fe9f56@yancy.lol>
 <CAD5xwhgKw+jWkadAvUU3KOqT19LmGX6vhUQFpZfJ_Zk0AjTcNA@mail.gmail.com>
 <2f4344b4c7952c3799f8766ae6b590bf@yancy.lol>
 <CAD5xwhjFeUPGFfpNTt=4iuZMYAzBOc5vMuai0vxJCN9NO9e0dw@mail.gmail.com>
 <CAMZUoKkbDjeMKX3zsBpOKOS2cXQNbC+RDA=Zkxxy4r4xP2m2Yw@mail.gmail.com>
In-Reply-To: <CAMZUoKkbDjeMKX3zsBpOKOS2cXQNbC+RDA=Zkxxy4r4xP2m2Yw@mail.gmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Tue, 18 Oct 2022 12:27:26 -0400
Message-ID: <CAD5xwhgGuqC-4kV7+MFiiV4JVf_mjQzuVkpQ=qp_yCVZTiRGvw@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>
Content-Type: multipart/alternative; boundary="0000000000000f070405eb5192dd"
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: Tue, 18 Oct 2022 16:27:41 -0000

--0000000000000f070405eb5192dd
Content-Type: text/plain; charset="UTF-8"

I think the issue with

I still think it is misguided to think that the "honest" (i.e. rule
> following) majority is to just be accepted as an axiom and if it is
> violated, well, then sorry.  The rules need to be incentive compatible for
> the system to be functional.  The honest majority is only considered an
> assumption because even if following the rules were clearly the 100%
> dominant strategy, this doesn't prove that the majority is honest, since
> mathematics cannot say what is happening in the real world at any given
> time.  Still, we must have a reason to think that the majority would be
> honest, and that reasoning should come from an argument that the rule set
> is incentive compatible.


epistemically is that even within the game that you prove the dominant
strategy, you can't be certain that you've captured (except maybe through
clever use of exogenous parameters, which reduces to the same thing as %
honest) the actual incentives of all players. For example, you would need
to capture the existence of large hegemonic governments defending their
legacy currencies by attacking bitcoin.


I think we may be talking past each other if it is a concern / valuable
exercise to decrease the assumptions that Bitcoin rests on to make it more
secure than it is as defined in the whitepaper. That's an exercise of
tremendous value. I think my point is that those things are aspirational
(aspirations that perhaps we should absolutely achieve?) but to the extent
that we need to fix things like the fee market, selfish mining, mind the
gap, etc, those are modifying Bitcoin to be secure (or more fair is perhaps
another way to look at it) in the presence of deviations from a
hypothesized "incentive compatible Bitcoin", which is a different thing
that "whitepaper bitcoin". I think that I largely fall in the camp -- as
evidenced by some past conversations I won't rehash -- that all of Bitcoin
should be incentive compatible and we should fix it if not. But from those
conversations I also learned that there are large swaths of the community
who don't share that value, or only share it up to a point, and do feel
comfortable resting on honest majority assumptions at one layer of the
stack or another. And I think that prior / axiom is a pretty central one to
debug or comprehend when dealing with, as is happening now, a fight over
something that seems obviously not incentive compatible.

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


On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor <roconnor@blockstream.com>
wrote:

> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> However, what *is* important about what Satoshi wrote is that it is sort
>> of the "social contract" of what Bitcoin is that we can all sort of
>> minimally agree to. This makes it clear, when we try to describe Bitcoin
>> with differing assumptions than in the whitepaper, what the changes are and
>> why we think the system might support those claims. But if we can't prove
>> the new description sound, such as showing tip mining to be rational in a
>> fully adversarial model, it doesn't mean Bitcoin doesn't work as promised,
>> since all that was promised originally is functioning under an honest
>> majority. Caveat Emptor!
>>
>
> I still think it is misguided to think that the "honest" (i.e. rule
> following) majority is to just be accepted as an axiom and if it is
> violated, well, then sorry.  The rules need to be incentive compatible for
> the system to be functional.  The honest majority is only considered an
> assumption because even if following the rules were clearly the 100%
> dominant strategy, this doesn't prove that the majority is honest, since
> mathematics cannot say what is happening in the real world at any given
> time.  Still, we must have a reason to think that the majority would be
> honest, and that reasoning should come from an argument that the rule set
> is incentive compatible.
>
> The stability of mining, i.e. the incentives to mine on the most work
> chain, is actually a huge concern, especially in a future low subsidy
> environment.  There is actually much fretting about this issue, and rightly
> so.  We don't actually know that Bitcoin can function in a low subsidy
> environment because we have never tested it.  Bitcoin could still end up a
> failure if that doesn't work out.  My current understanding/guess is that
> with a "thick mempool" (that is lots of transactions without large gaps in
> fee rates between them) and/or miners rationally leaving behind
> transactions to encourage mining on their block (after all it is in a
> miner's own interest not to have their block orphaned), that mining will be
> stable.  But I don't know this for sure, and we cannot know with certainty
> that we are going to have a "thick mempool" when it is needed.
>
> It is most certainly the case that one can construct situations where not
> mining on the tip is going to be the prefered strategy.  But even if that
> happens on occasion, it's not like the protocol immediately collapses,
> because mining off the tip is indistinguishable from being a high latency
> miner who simply didn't receive the most work block in time.  So it is more
> of a question of how rare does it need to be, and what can we do to reduce
> the chances of such situations arising (e.g. updating our mining policy to
> leave some transactions out based on current (and anticipated) mempool
> conditions, or (for a sufficiently capitalized miner) leave an explicit,
> ANYONECANSPEND transaction output as a tip for the next miner to build upon
> mined blocks.)
>

--0000000000000f070405eb5192dd
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">I think the issue with=C2=
=A0</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_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,=
204,204);padding-left:1ex">I still think it is misguided to think that the =
&quot;honest&quot; (i.e. rule following) majority is to just be accepted as=
 an axiom and if it is violated, well, then sorry.=C2=A0 The rules need to =
be incentive compatible for the system to be functional.=C2=A0 The honest m=
ajority is only considered an assumption because even if following the rule=
s were clearly the 100% dominant strategy, this doesn&#39;t prove that the =
majority is honest, since mathematics cannot say what is happening in the r=
eal world at any given time.=C2=A0 Still, we must have a reason to think th=
at the majority would be honest, and that reasoning should come from an arg=
ument that the rule set is incentive compatible.</blockquote><div><br></div=
><div>epistemically is that even within the game that you prove the dominan=
t strategy, you can&#39;t be certain that you&#39;ve captured (except maybe=
 through clever use of exogenous parameters, which reduces to the same thin=
g as % honest) the actual incentives of all players. For example, you would=
 need to capture the existence of large hegemonic governments defending the=
ir legacy currencies by attacking bitcoin.</div><div><br></div><div><br></d=
iv><div>I think we may be talking past each other if it is a concern / valu=
able exercise to decrease the assumptions that Bitcoin rests on to make it =
more secure than it is as defined in the whitepaper. That&#39;s an exercise=
 of tremendous value. I think my point is that those things are aspirationa=
l (aspirations that perhaps we should absolutely achieve?) but to the exten=
t that we need to fix things like the fee market, selfish mining, mind the =
gap, etc, those are modifying Bitcoin to be secure (or more fair is perhaps=
 another way to look at it) in the presence of deviations from a hypothesiz=
ed &quot;incentive compatible Bitcoin&quot;, which is a different thing tha=
t &quot;whitepaper bitcoin&quot;. I think that I largely fall in the camp -=
- as evidenced by some past conversations I won&#39;t rehash -- that all of=
 Bitcoin should be incentive compatible and we should fix it if not. But fr=
om those conversations I also learned that there are large swaths of the co=
mmunity who don&#39;t share that value, or only share it up to a point, and=
 do feel comfortable resting on honest majority assumptions at one layer of=
 the stack or another. And I think that prior / axiom is a pretty central o=
ne to debug or comprehend when dealing with, as is happening now, a fight o=
ver something that seems obviously not incentive compatible.</div><br class=
=3D"gmail-Apple-interchange-newline"></div><div><div dir=3D"ltr" class=3D"g=
mail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><=
a href=3D"https://twitter.com/JeremyRubin" 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 Tue, Oct 18, 2022 at 10:30 AM Russell O&#3=
9;Connor &lt;<a href=3D"mailto:roconnor@blockstream.com">roconnor@blockstre=
am.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde=
r-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 18, 2022=
 at 9:07 AM Jeremy Rubin via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=
=3D"ltr"><div><div style=3D"margin:0px;padding:0px"><br><div style=3D"margi=
n:0px;padding:0px"><div title=3D"Page 4" style=3D"color:rgb(0,0,0)"><div><d=
iv><div>However, what *is* important about what Satoshi wrote is that it is=
 sort of the &quot;social contract&quot; of what Bitcoin is that we can all=
 sort of minimally agree to. This makes it clear, when we try to describe B=
itcoin with differing=C2=A0assumptions than in the whitepaper, what the cha=
nges are and why we think the system might support those claims. But if we =
can&#39;t prove the new description sound, such as showing tip mining to be=
 rational in a fully adversarial model, it doesn&#39;t mean Bitcoin doesn&#=
39;t work as promised, since all that was promised originally is functionin=
g under an honest majority. Caveat Emptor!</div></div></div></div></div></d=
iv></div></div></div></blockquote><div><br></div><div>I still think it is m=
isguided to think that the &quot;honest&quot; (i.e. rule following) majorit=
y is to just be accepted as an axiom and if it is violated, well, then sorr=
y.=C2=A0 The rules need to be incentive compatible for the system to be fun=
ctional.=C2=A0 The honest majority is only considered an assumption because=
 even if following the rules were clearly the 100% dominant strategy, this =
doesn&#39;t prove that the majority is honest, since mathematics cannot say=
 what is happening in the real world at any given time.=C2=A0 Still, we mus=
t have a reason to think that the majority would be honest, and that reason=
ing should come from an argument that the rule set is incentive compatible.=
</div><div><br></div><div>The stability of mining, i.e. the incentives to m=
ine on the most work chain, is actually a huge concern, especially in a fut=
ure low subsidy environment.=C2=A0 There is actually much fretting about th=
is issue, and rightly so.=C2=A0 We don&#39;t actually know that Bitcoin can=
 function in a low subsidy environment because we have never tested it.=C2=
=A0 Bitcoin could still end up a failure if that doesn&#39;t work out.=C2=
=A0 My current understanding/guess is that with a &quot;thick mempool&quot;=
 (that is lots of transactions without large gaps in fee rates between them=
) and/or miners rationally leaving behind transactions to encourage mining =
on their block (after all it is in a miner&#39;s own interest not to have t=
heir block orphaned), that mining will be stable.=C2=A0 But I don&#39;t kno=
w this for sure, and we cannot know with certainty that we are going to hav=
e a &quot;thick mempool&quot; when it is needed.<br></div><div><br></div><d=
iv>It is most certainly the case that one can construct situations where no=
t mining on the tip is going to be the prefered strategy.=C2=A0 But even if=
 that happens on occasion, it&#39;s not like the protocol immediately colla=
pses, because mining off the tip is indistinguishable from being a high lat=
ency miner who simply didn&#39;t receive the most work block in time.=C2=A0=
 So it is more of a question of how rare does it need to be, and what can w=
e do to reduce the chances of such situations arising (e.g. updating our mi=
ning policy to leave some transactions out based on current (and anticipate=
d) mempool conditions, or (for a sufficiently capitalized miner) leave an e=
xplicit, ANYONECANSPEND transaction output as a tip for the next miner to b=
uild upon mined blocks.)<br></div></div></div>
</blockquote></div>

--0000000000000f070405eb5192dd--