path: root/de/a21329830da64618c98707c7039a12929d548e

Return-Path: <email@yancy.lol>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1BEC1C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 19:25:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id E47E240143
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 19:25:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E47E240143
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 smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JvV07ech3NyQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 19:25:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DDE4D40101
Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240])
 by smtp2.osuosl.org (Postfix) with ESMTPS id DDE4D40101
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 19:25:43 +0000 (UTC)
Received: from relay4-d.mail.gandi.net (unknown [217.70.183.196])
 by mslow1.mail.gandi.net (Postfix) with ESMTP id D7D4CCC742
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 19:22:04 +0000 (UTC)
Received: (Authenticated sender: email@yancy.lol)
 by mail.gandi.net (Postfix) with ESMTPA id 4CD5CE0005;
 Thu, 20 Oct 2022 19:21:58 +0000 (UTC)
MIME-Version: 1.0
Date: Thu, 20 Oct 2022 21:21:58 +0200
From: email@yancy.lol
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAD5xwhgGuqC-4kV7+MFiiV4JVf_mjQzuVkpQ=qp_yCVZTiRGvw@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>
Message-ID: <723c5f33823db10def2a07316ea88456@yancy.lol>
X-Sender: email@yancy.lol
Content-Type: multipart/alternative;
 boundary="=_84b35ee22e0c99a8c832ee6d5b691e39"
X-Mailman-Approved-At: Thu, 20 Oct 2022 22:03:49 +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: Thu, 20 Oct 2022 19:25:46 -0000

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


I had one other idea on the topic.  Namely, in the last section 
"calculation", Satoshi talks more about what he/she/they consider to be 
bad actors.  The idea that someone is not doing "tip mining" does not 
mean they are dishonest.

> We consider the scenario of an attacker trying to generate an alternate 
> chain faster than the honest
> chain. Even if this is accomplished, it does not throw the system open 
> to arbitrary changes, such
> as creating value out of thin air or taking money that never belonged 
> to the attacker. Nodes are
> not going to accept an invalid transaction as payment, and honest nodes 
> will never accept a block
> containing them. An attacker can only try to change one of his own 
> transactions to take back
> money he recently spent.

It seems to me that there's a distinction in the game theoretics between 
"not tip mining" and actively being a bad actor (changing a past 
transaction signed by yourself).

I rewrote the "AttackerSuccessProbability" C function in Rust for fun:
https://github.com/yancyribbens/attacker-success-probability-rust

Cheers,
-Yancy

On 2022-10-18 18:27, Jeremy Rubin via bitcoin-dev 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.)

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
--=_84b35ee22e0c99a8c832ee6d5b691e39
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'>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
I had one other idea on the topic. &nbsp;Namely, in the last section "calcu=
lation", Satoshi talks more about what he/she/they consider to be bad actor=
s. &nbsp;The idea that someone is not doing "tip mining" does not mean they=
 are dishonest.</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<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">=
<span style=3D"left: 288.267px; top: 1058.82px; font-size: 10pt; font-famil=
y: serif; transform: scaleX(0.770205);">We consider the scenario of an atta=
cker trying to generate an alternate chain faster than the honest</span><br=
 role=3D"presentation" /><span style=3D"left: 288.267px; top: 1089.75px; fo=
nt-size: 10pt; font-family: serif; transform: scaleX(0.797234);">chain. Eve=
n if this is accomplished, it does not throw the system open to arbitrary c=
hanges, such</span><br role=3D"presentation" /><span style=3D"font-size: 10=
pt;"><span style=3D"left: 288.267px; top: 1120.95px; font-family: serif; tr=
ansform: scaleX(0.798385);">as creating value out of thin air or taking mon=
ey that never belonged to the attacker.</span><span style=3D"left: 1216.39p=
x; top: 1120.95px; font-family: serif;"> </span><span style=3D"left: 1233.3=
8px; top: 1120.95px; font-family: serif; transform: scaleX(0.785145);">Node=
s are</span></span><br role=3D"presentation" /><span style=3D"left: 288.267=
px; top: 1151.88px; font-size: 10pt; font-family: serif; transform: scaleX(=
0.786178);">not going to accept an invalid transaction as payment, and hone=
st nodes will never accept a block</span><br role=3D"presentation" /><span =
style=3D"font-size: 10pt;"><span style=3D"left: 288.267px; top: 1183.08px; =
font-family: serif; transform: scaleX(0.795086);">containing them.</span><s=
pan style=3D"left: 472.329px; top: 1183.08px; font-family: serif;"> </span>=
<span style=3D"left: 490.644px; top: 1183.08px; font-family: serif; transfo=
rm: scaleX(0.824627);">An attacker can only try to change one of his own tr=
ansactions to take back</span></span><br role=3D"presentation" /><span styl=
e=3D"left: 288.267px; top: 1214.02px; font-size: 10pt; font-family: serif; =
transform: scaleX(0.781482);">money he recently spent.</span></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">=
It seems to me that there's a distinction in the game theoretics between "n=
ot tip mining" and actively being a bad actor (changing a past transaction =
signed by yourself).</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">=
I rewrote the "AttackerSuccessProbability" C function in Rust for fun:</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
https://github.com/yancyribbens/attacker-success-probability-rust</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">=
Cheers,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
-Yancy</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 18:27, Jeremy Rubin via bitcoin-dev wrote:
<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. rule<br />following) majority is to just be accepted as an axiom a=
nd if it is<br />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 is<br />only considered an assumption because even if following the =
rules<br />were clearly the 100% dominant strategy, this doesn't prove that=
 the<br />majority is honest, since mathematics cannot say what is happenin=
g<br />in the real world at any given time. &nbsp;Still, we must have a rea=
son<br />to think that the majority would be honest, and that reasoning<br =
/>should come from an argument that the rule set is incentive<br />compatib=
le.</blockquote>
<br />epistemically is that even within the game that you prove the dominan=
t<br />strategy, you can't be certain that you've captured (except maybe<br=
 />through clever use of exogenous parameters, which reduces to the same<br=
 />thing as % honest) the actual incentives of all players. For example,<br=
 />you would need to capture the existence of large hegemonic governments<b=
r />defending their legacy currencies by attacking bitcoin.<br /><br />I th=
ink we may be talking past each other if it is a concern /<br />valuable ex=
ercise to decrease the assumptions that Bitcoin rests on to<br />make it mo=
re secure than it is as defined in the whitepaper. That's an<br />exercise =
of tremendous value. I think my point is that those things<br />are aspirat=
ional (aspirations that perhaps we should absolutely<br />achieve?) but to =
the extent that we need to fix things like the fee<br />market, selfish min=
ing, mind the gap, etc, those are modifying Bitcoin<br />to be secure (or m=
ore fair is perhaps another way to look at it) in<br />the presence of devi=
ations from a hypothesized "incentive compatible<br />Bitcoin", which is a =
different thing that "whitepaper bitcoin". I<br />think that I largely fall=
 in the camp -- as evidenced by some past<br />conversations I won't rehash=
 -- that all of Bitcoin should be<br />incentive compatible and we should f=
ix it if not. But from those<br />conversations I also learned that there a=
re large swaths of the<br />community who don't share that value, or only s=
hare it up to a point,<br />and do feel comfortable resting on honest major=
ity assumptions at one<br />layer of the stack or another. And I think that=
 prior / axiom is a<br />pretty central one to debug or comprehend when dea=
ling with, as is<br />happening now, a fight over something that seems obvi=
ously not<br />incentive compatible.<br /><br />--<br />@JeremyRubin [<a hr=
ef=3D"https://twitter.com/JeremyRubin" target=3D"_blank" rel=3D"noopener no=
referrer">1</a>]<br /><br />On Tue, Oct 18, 2022 at 10:30 AM Russell O'Conn=
or<br />&lt;<a href=3D"mailto:roconnor@blockstream.com">roconnor@blockstrea=
m.com</a>&gt; wrote:<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitco=
in-dev<br />&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-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">However, what *is* important about what Satoshi wrote =
is that it<br />is sort of the "social contract" of what Bitcoin is that we=
 can<br />all sort of minimally agree to. This makes it clear, when we try<=
br />to describe Bitcoin with differing assumptions than in the<br />whitep=
aper, what the changes are and why we think the system might<br />support t=
hose claims. But if we can't prove the new description<br />sound, such as =
showing tip mining to be rational in a fully<br />adversarial model, it doe=
sn't mean Bitcoin doesn't work as<br />promised, since all that was promise=
d originally is functioning<br />under an honest majority. Caveat Emptor!</=
blockquote>
<br />I still think it is misguided to think that the "honest" (i.e. rule<b=
r />following) majority is to just be accepted as an axiom and if it is<br =
/>violated, well, then sorry. &nbsp;The rules need to be incentive<br />com=
patible for the system to be functional. &nbsp;The honest majority is<br />=
only considered an assumption because even if following the rules<br />were=
 clearly the 100% dominant strategy, this doesn't prove that the<br />major=
ity is honest, since mathematics cannot say what is happening<br />in the r=
eal world at any given time. &nbsp;Still, we must have a reason<br />to thi=
nk that the majority would be honest, and that reasoning<br />should come f=
rom an argument 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 actually a huge concern, especially in a future low<br />subsidy =
environment. &nbsp;There is actually much fretting about this<br />issue, a=
nd rightly so. &nbsp;We don't actually know that Bitcoin can<br />function =
in a low subsidy environment because we have never tested<br />it. &nbsp;Bi=
tcoin could still end up a failure if that doesn't work out.<br />My curren=
t understanding/guess is that with a "thick mempool" (that<br />is lots of =
transactions without large gaps in fee rates between<br />them) and/or mine=
rs 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 bl=
ock 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 mempool" 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 be the prefered strategy.<br />But even if that happens on occ=
asion, it's not like the protocol<br />immediately collapses, because minin=
g 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 mor=
e of a question 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 minin=
g policy<br />to leave some transactions out based on current (and anticipa=
ted)<br />mempool conditions, or (for a sufficiently capitalized miner) lea=
ve<br />an explicit, ANYONECANSPEND transaction output as a tip for the nex=
t<br />miner to build upon mined blocks.)</blockquote>
&nbsp;<br /><br />Links:<br />------<br />[1] <a href=3D"https://twitter.co=
m/JeremyRubin" target=3D"_blank" rel=3D"noopener noreferrer">https://twitte=
r.com/JeremyRubin</a><br />_______________________________________________<=
br />bitcoin-dev mailing list<br /><a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.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.org/mailma=
n/listinfo/bitcoin-dev</a></blockquote>
</div>
</body></html>

--=_84b35ee22e0c99a8c832ee6d5b691e39--