path: root/d1/84fd2106aa7a003b692dbe941914812a75b2e2

Return-Path: <email@yancy.lol>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 35BF8C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 19:01:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E70F261001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 19:01:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E70F261001
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001,
 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 SIjfp_uPvk3y
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 19:01:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E014F60B55
Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240])
 by smtp3.osuosl.org (Postfix) with ESMTPS id E014F60B55
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 19:01:30 +0000 (UTC)
Received: from relay3-d.mail.gandi.net (unknown [217.70.183.195])
 by mslow1.mail.gandi.net (Postfix) with ESMTP id E3E2CCC0BC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 18 Oct 2022 18:57:23 +0000 (UTC)
Received: (Authenticated sender: email@yancy.lol)
 by mail.gandi.net (Postfix) with ESMTPA id BA66760006;
 Tue, 18 Oct 2022 18:57:17 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 18 Oct 2022 20:57:17 +0200
From: email@yancy.lol
To: Erik Aronesty <erik@q32.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAJowKg+5-U9sFXt0=1O-Ux-WSm8gOodPAg1neNyP+CcjZNx6PQ@mail.gmail.com>
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>
 <CAD5xwhgGuqC-4kV7+MFiiV4JVf_mjQzuVkpQ=qp_yCVZTiRGvw@mail.gmail.com>
 <CAJowKg+5-U9sFXt0=1O-Ux-WSm8gOodPAg1neNyP+CcjZNx6PQ@mail.gmail.com>
Message-ID: <331b2badd29349f8268498e12e492cad@yancy.lol>
X-Sender: email@yancy.lol
Content-Type: multipart/alternative;
 boundary="=_30f082f5038d51b2dbfa318be188649c"
X-Mailman-Approved-At: Tue, 18 Oct 2022 20:01:09 +0000
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 19:01:33 -0000

--=_30f082f5038d51b2dbfa318be188649c
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



> not sure if this is helpful, but when i'm code reviewing a change to
> an existing, functioning and very complex system, i rarely go back to
> "first principles" to analyze that change independently, and instead
> try to decide if it's better or worse than what we have now

I agree that it's important to not be too dogmatic, which includes 
Satoshi and the white paper. It's fun to look back and read to try to 
find inspiration, although, it seems to me, a lot has been learned since 
then.  And a lot will be learned in the future.  I was thinking to 
myself, what if in the distant future, quantum entanglement could be 
used to update all nodes simultaneously across any distance in space? 
How cool would that be?  How might that change from the original vision? 
  Well, if we ever get that far, I'm sure Satoshi could not have planned 
for that, or maybe they could have.. :)

On 2022-10-18 19:33, Erik Aronesty via bitcoin-dev wrote:

> not sure if this is helpful, but when i'm code reviewing a change to
> an existing, functioning and very complex system, i rarely go back to
> "first principles" to analyze that change independently, and instead
> try to decide if it's better or worse than what we have now
> 
> you can introduce a new feature, for example, that has a bunch of
> noncritical bugs, especially in ux, and then you can weigh in on
> whether its better to get it out now for the people that need it, or
> bikeshed ux for another 2 releases
> 
> i'm often a fan of the former
> 
> if someone proposes a change to bitcoin, we should probably review it
> as "better or worse than what we have", rather than "has perfectly
> aligned incentives promoting honest behavior even among selfish
> actors"
> 
> we know bitcoin functions now with a complex series of incentives,
> especially regarding node operators
> 
> in other words, does the change "improve what we have" is a better bar
> than "stands on its own"
> 
> in that way the system can slowly improve over time, rather than be
> stuck
> 
> On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 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 [1 [1]]
> 
> 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.)
   _______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Links:
------
[1] https://twitter.com/JeremyRubin
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Links:
------
[1] https://twitter.com/JeremyRubin
--=_30f082f5038d51b2dbfa318be188649c
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
not sure if this is helpful, but when i'm code reviewing a change to<br />a=
n existing, functioning and very complex system, i rarely go back to<br />"=
first principles" to analyze that change independently, and instead<br />tr=
y to decide if it's better or worse than what we have now</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
I agree that it's important to not be too dogmatic, which includes Satoshi =
and the white paper. It's fun to look back and read to try to find inspirat=
ion, although, it seems to me, a lot has been learned since then. &nbsp;And=
 a lot will be learned in the future. &nbsp;I was thinking to myself, what =
if in the distant future, quantum entanglement could be used to update all =
nodes simultaneously across any distance in space? How cool would that be? =
&nbsp;How might that change from the original vision? &nbsp;Well, if we eve=
r get that far, I'm sure Satoshi could not have planned for that, or maybe =
they could have.. :)</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On 2022-10-18 19:33, Erik Aronesty via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">not sure if this is helpful, but when i'm code reviewi=
ng a change to<br />an existing, functioning and very complex system, i rar=
ely go back to<br />"first principles" to analyze that change independently=
, and instead<br />try to decide if it's better or worse than what we have =
now<br /><br />you can introduce a new feature, for example, that has a bun=
ch of<br />noncritical bugs, especially in ux, and then you can weigh in on=
<br />whether its better to get it out now for the people that need it, or<=
br />bikeshed ux for another 2 releases &nbsp;<br /><br />i'm often a fan o=
f the former<br /><br />if someone proposes a change to bitcoin, we should =
probably review it<br />as "better or worse than what we have", rather than=
 "has perfectly<br />aligned incentives promoting honest behavior even amon=
g selfish<br />actors"<br /><br />we know bitcoin functions now with a comp=
lex series of incentives,<br />especially regarding node operators<br /><br=
 />in other words, does the change "improve what we have" is a better bar<b=
r />than "stands on its own"<br /><br />in that way the system can slowly i=
mprove over time, rather than be<br />stuck<br /><br />On Tue, Oct 18, 2022=
 at 12:28 PM Jeremy Rubin via bitcoin-dev<br />&lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">I think the issue with<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">I still think it is misguided to think that the "hones=
t" (i.e.<br />rule following) majority is to just be accepted as an axiom a=
nd if<br />it is violated, well, then sorry. &nbsp;The rules need to be inc=
entive<br />compatible for the system to be functional. &nbsp;The honest ma=
jority<br />is only considered an assumption because even if following the<=
br />rules were clearly the 100% dominant strategy, this doesn't prove<br /=
>that the majority is honest, since mathematics cannot say what is<br />hap=
pening in the real world at any given time. &nbsp;Still, we must<br />have =
a reason to think that the majority would be honest, and that<br />reasonin=
g should come from an argument that the rule set is<br />incentive compatib=
le.</blockquote>
<br />epistemically is that even within the game that you prove the<br />do=
minant strategy, you can't be certain that you've captured (except<br />may=
be through clever use of exogenous parameters, which reduces to<br />the sa=
me thing as % honest) the actual incentives of all players.<br />For exampl=
e, you would need to capture the existence of large<br />hegemonic governme=
nts defending their legacy currencies by attacking<br />bitcoin.<br /><br /=
>I think we may be talking past each other if it is a concern /<br />valuab=
le exercise to decrease the assumptions that Bitcoin rests on<br />to make =
it more secure than it is as defined in the whitepaper.<br />That's an exer=
cise of tremendous value. I think my point is that<br />those things are as=
pirational (aspirations that perhaps we should<br />absolutely achieve?) bu=
t to the extent that we need to fix things<br />like the fee market, selfis=
h mining, mind the gap, etc, those are<br />modifying Bitcoin to be secure =
(or more fair is perhaps another way<br />to look at it) in the presence of=
 deviations from a hypothesized<br />"incentive compatible Bitcoin", which =
is a different thing that<br />"whitepaper bitcoin". I think that I largely=
 fall in the camp -- as<br />evidenced by some past conversations I won't r=
ehash -- that all of<br />Bitcoin should be incentive compatible and we sho=
uld fix it if not.<br />But from those conversations I also learned that th=
ere are large<br />swaths of the community who don't share that value, or o=
nly share it<br />up to a point, and do feel comfortable resting on honest =
majority<br />assumptions at one layer of the stack or another. And I think=
 that<br />prior / axiom is a pretty central one to debug or comprehend whe=
n<br />dealing with, as is happening now, a fight over something that seems=
<br />obviously not incentive compatible.<br /><br />--<br />@JeremyRubin [=
<a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank" rel=3D"noopen=
er noreferrer">1</a>]<br /><br />On Tue, Oct 18, 2022 at 10:30 AM Russell O=
'Connor<br />&lt;<a href=3D"mailto:roconnor@blockstream.com">roconnor@block=
stream.com</a>&gt; wrote:<br /><br />On Tue, Oct 18, 2022 at 9:07 AM Jeremy=
 Rubin via bitcoin-dev<br />&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br /><br=
 />However, what *is* important about what Satoshi wrote is that it is<br /=
>sort of the "social contract" of what Bitcoin is that we can all<br />sort=
 of minimally agree to. This makes it clear, when we try to<br />describe B=
itcoin with differing assumptions than in the whitepaper,<br />what the cha=
nges are and why we think the system might support those<br />claims. But i=
f we can't prove the new description sound, such as<br />showing tip mining=
 to be rational in a fully adversarial model, it<br />doesn't mean Bitcoin =
doesn't work as promised, since all that was<br />promised originally is fu=
nctioning under an honest majority. Caveat<br />Emptor!<br /><br />I still =
think it is misguided to think that the "honest" (i.e. rule<br />following)=
 majority is to just be accepted as an axiom and if it is<br />violated, we=
ll, then sorry. &nbsp;The rules need to be incentive<br />compatible for th=
e system to be functional. &nbsp;The honest majority is<br />only considere=
d an assumption because even if following the rules<br />were clearly the 1=
00% dominant strategy, this doesn't prove that the<br />majority is honest,=
 since mathematics cannot say what is happening<br />in the real world at a=
ny given time. &nbsp;Still, we must have a reason<br />to think that the ma=
jority would be honest, and that reasoning<br />should come from an argumen=
t that the rule set is incentive<br />compatible.<br /><br />The stability =
of mining, i.e. the incentives to mine on the most<br />work chain, is actu=
ally a huge concern, especially in a future low<br />subsidy environment. &=
nbsp;There is actually much fretting about this<br />issue, and rightly so.=
 &nbsp;We don't actually know that Bitcoin can<br />function in a low subsi=
dy environment because we have never tested<br />it. &nbsp;Bitcoin could st=
ill end up a failure if that doesn't work out.<br />My current understandin=
g/guess is that with a "thick mempool" (that<br />is lots of transactions w=
ithout large gaps in fee rates between<br />them) and/or miners rationally =
leaving behind transactions to<br />encourage mining on their block (after =
all it is in a miner's own<br />interest not to have their block orphaned),=
 that mining will be<br />stable. &nbsp;But I don't know this for sure, and=
 we cannot know with<br />certainty that we are going to have a "thick memp=
ool" when it is<br />needed.<br /><br />It is most certainly the case that =
one can construct situations<br />where not mining on the tip is going to b=
e the prefered strategy.<br />But even if that happens on occasion, it's no=
t like the protocol<br />immediately collapses, because mining off the tip =
is<br />indistinguishable from being a high latency miner who simply didn't=
<br />receive the most work block in time. &nbsp;So it is more of a questio=
n of<br />how rare does it need to be, and what can we do to reduce the<br =
/>chances of such situations arising (e.g. updating our mining policy<br />=
to leave some transactions out based on current (and anticipated)<br />memp=
ool conditions, or (for a sufficiently capitalized miner) leave<br />an exp=
licit, ANYONECANSPEND transaction output as a tip for the next<br />miner t=
o build upon mined blocks.)</blockquote>
&nbsp;_______________________________________________<br />bitcoin-dev mail=
ing list<br /><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a><br /><a href=3D"https://lists.linuxfo=
undation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noopene=
r noreferrer">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de=
v</a><br />&nbsp;<br /><br />Links:<br />------<br />[1] <a href=3D"https:/=
/twitter.com/JeremyRubin" target=3D"_blank" rel=3D"noopener noreferrer">htt=
ps://twitter.com/JeremyRubin</a><br />_____________________________________=
__________<br />bitcoin-dev mailing list<br /><a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />=
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
target=3D"_blank" rel=3D"noopener noreferrer">https://lists.linuxfoundation=
=2Eorg/mailman/listinfo/bitcoin-dev</a></blockquote>
</div>
</body></html>

--=_30f082f5038d51b2dbfa318be188649c--