path: root/73/147ce0d0ae00af7d7c60dd36312c0388ece025

Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 93E25C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 14:30:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 6CE86418D2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 14:30:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6CE86418D2
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com
 header.i=@blockstream-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=76joS51p
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 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_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 U5mUoF98mdJ3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 14:30:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EC6B341755
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com
 [IPv6:2607:f8b0:4864:20::534])
 by smtp4.osuosl.org (Postfix) with ESMTPS id EC6B341755
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 14:30:38 +0000 (UTC)
Received: by mail-pg1-x534.google.com with SMTP id 129so13460238pgc.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 07:30:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20210112.gappssmtp.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=YoBR2gKcosBEBZSzXqKpZz6OK7N93avQPPcQWHFAGGA=;
 b=76joS51p6zpVH3aYbIz+BZl6TL7Q8KpbdD2+WmEkZfOwbXV5pGSM+WvyjUFJ479JxW
 DP5vf9443qPKu76Udfa4ZTMIaifag6f781RUC52huBiuzMn4AkUA7DgGFkuUxf7GPlSP
 9RnK8fL+JRkRHWrco2wlZqQz0DNNWsNtucP0kfbNthVztQ50cxJs4Palp/D8S+m2HDXp
 Zr2zrWtaiFNJe1/RGe1On+RgK52OGa6eV4sa2t0HPbj/apExCEvZ4ayYGcKsVAjOwq14
 m/1piNm2I2703xKr8s7T6MUPNe8WRsZEwbjC5vT119NCgF2Of7TErxOM7qNxoOHwBKoy
 yUYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=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=YoBR2gKcosBEBZSzXqKpZz6OK7N93avQPPcQWHFAGGA=;
 b=M3j00+CPstEFbTRRLG2sRikOXAUTBlHh2Squ0gmHOfIjy52aggCEq5jYpEhreh2xVn
 j/+8t1KiKQOuYS729tWfOLqaSOYotU7eJ5mI03Wi7millwzOUlibdASkTq2gznwIDvcv
 v1WjransMKtvGFJhFycMHbmEGhAQ3mWilYkNpERanMfp9P3mg1zM5D4VZu+SDhdX70on
 jF/Oo+vC/5TRSqLkO91pysQUWQWFYJEQL2NOm8HAQhgDkwHeDXIeXzIhy4oFLpdfLJcI
 z3WCyxh0b77+/SfnPwoy0YDMtR9OJMANXsvZ4/G5uXjTRShO3bq+Xh9MgEvZrlLxxE0k
 1GPA==
X-Gm-Message-State: ACrzQf34V4HjiWwe8aU/mOT9qHQ6SrtTd52+P0f0zd6iDOHfyAD78BJi
 Xk3SYYcCPzYTeQQGIdXny7rlEIVmUHj4GEqREnHd+Q==
X-Google-Smtp-Source: AMsMyM4IpFrdUPqWwz6A198aKkbw+xukazrwzwGh+LYw0XQV1ElDp3qxHdMUyO1C1sNzzprgWk4LBm6xkmca96PDsa8=
X-Received: by 2002:a63:1e56:0:b0:462:970:e0de with SMTP id
 p22-20020a631e56000000b004620970e0demr2978143pgm.90.1666103438291; Tue, 18
 Oct 2022 07:30: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>
In-Reply-To: <CAD5xwhjFeUPGFfpNTt=4iuZMYAzBOc5vMuai0vxJCN9NO9e0dw@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 18 Oct 2022 10:30:26 -0400
Message-ID: <CAMZUoKkbDjeMKX3zsBpOKOS2cXQNbC+RDA=Zkxxy4r4xP2m2Yw@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009954bc05eb4fef7b"
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 14:30:40 -0000

--0000000000009954bc05eb4fef7b
Content-Type: text/plain; charset="UTF-8"

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.)

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

<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">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div><div style=3D"margin=
:0px;padding:0px"><br><div style=3D"margin:0px;padding:0px"><div title=3D"P=
age 4" style=3D"color:rgb(0,0,0)"><div><div><div>However, what *is* importa=
nt 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 Bitcoin with differing=C2=A0assumpt=
ions than in the whitepaper, what the changes are and why we think the syst=
em might support those claims. But if we can&#39;t prove the new descriptio=
n sound, such as showing tip mining to be rational in a fully adversarial m=
odel, it doesn&#39;t mean Bitcoin doesn&#39;t work as promised, since all t=
hat was promised originally is functioning under an honest majority. Caveat=
 Emptor!</div></div></div></div></div></div></div></div></div></blockquote>=
<div><br></div><div>I still think it is misguided to think that the &quot;h=
onest&quot; (i.e. rule following) majority is to just be accepted as an axi=
om and if it is violated, well, then sorry.=C2=A0 The rules need to be ince=
ntive compatible for the system to be functional.=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 majorit=
y is honest, since mathematics cannot say what is happening in the real wor=
ld at any given time.=C2=A0 Still, we must have a reason to think that the =
majority would be honest, and that reasoning should come from an argument t=
hat the rule set is incentive compatible.</div><div><br></div><div>The stab=
ility of mining, i.e. the incentives to mine on the most work chain, is act=
ually a huge concern, especially in a future low subsidy environment.=C2=A0=
 There is actually much fretting about this issue, and rightly so.=C2=A0 We=
 don&#39;t actually know that Bitcoin can function in a low subsidy environ=
ment because we have never tested it.=C2=A0 Bitcoin could still end up a fa=
ilure 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 withou=
t large gaps in fee rates between them) and/or miners rationally leaving be=
hind transactions to encourage mining on their block (after all it is in a =
miner&#39;s own interest not to have their block orphaned), that mining wil=
l be stable.=C2=A0 But I don&#39;t know this for sure, and we cannot know w=
ith certainty that we are going to have a &quot;thick mempool&quot; when it=
 is needed.<br></div><div><br></div><div>It is most certainly the case that=
 one can construct situations where not mining on the tip is going to be th=
e prefered strategy.=C2=A0 But even if that happens on occasion, it&#39;s n=
ot like the protocol immediately collapses, because mining off the tip is i=
ndistinguishable from being a high latency miner who simply didn&#39;t rece=
ive the most work block in time.=C2=A0 So it is more of a question of how r=
are does it need to be, and what can we do to reduce the chances of such si=
tuations arising (e.g. updating our mining policy to leave some transaction=
s out based on current (and anticipated) mempool conditions, or (for a suff=
iciently capitalized miner) leave an explicit, ANYONECANSPEND transaction o=
utput as a tip for the next miner to build upon mined blocks.)<br></div></d=
iv></div>

--0000000000009954bc05eb4fef7b--