path: root/e1/ca27cd206d47f1e2d304a983cc19997c3b037b

Return-Path: <email@yancy.lol>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 392D6C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 22:32:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id EDDD541857
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 22:32:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EDDD541857
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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id KpV2LpdeuZWx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 22:32:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1240841851
Received: from mslow1.mail.gandi.net (mslow1.mail.gandi.net [217.70.178.240])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 1240841851
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 22:32:20 +0000 (UTC)
Received: from relay6-d.mail.gandi.net (unknown [217.70.183.198])
 by mslow1.mail.gandi.net (Postfix) with ESMTP id CF77DC1A82
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Oct 2022 22:31:44 +0000 (UTC)
Received: (Authenticated sender: email@yancy.lol)
 by mail.gandi.net (Postfix) with ESMTPA id 851EFC0002;
 Mon, 17 Oct 2022 22:31:39 +0000 (UTC)
MIME-Version: 1.0
Date: Tue, 18 Oct 2022 00:31:39 +0200
From: email@yancy.lol
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>
In-Reply-To: <CAD5xwhgKw+jWkadAvUU3KOqT19LmGX6vhUQFpZfJ_Zk0AjTcNA@mail.gmail.com>
References: <CAD5xwhjXh33AdK96eToHtDP3t_Zx5JbxCqJFbAQRRRKy6rFC2Q@mail.gmail.com>
 <903a46d95473714a7e11e33310fe9f56@yancy.lol>
 <CAD5xwhgKw+jWkadAvUU3KOqT19LmGX6vhUQFpZfJ_Zk0AjTcNA@mail.gmail.com>
Message-ID: <2f4344b4c7952c3799f8766ae6b590bf@yancy.lol>
X-Sender: email@yancy.lol
Content-Type: multipart/alternative;
 boundary="=_fc86712a6f922e1f2eebe0423bbcc2dd"
X-Mailman-Approved-At: Mon, 17 Oct 2022 22:32:52 +0000
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 22:32:24 -0000

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


Hi Jeremy,

Thanks for the reply. I do find the semantics of mempool and block org 
interesting (although there's a lot on the topic I don't know).

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

If I'm reading this correctly, Block N was already mined, but the miner 
who mined block N+1 repacks the transactions from block N because they 
have more to gain.  Wouldn't such a situation be resolved in the same 
way as two miners who find a block at a similar time? E.g the network 
will choose depending on when block N+2 is created.

> Assume instead your reward is 8, leaving 3+c on the table.

Mining block N+1 with the mempool leads to reward 2+8 = 10, reorging 
leads to 10 + 8 + c?  Wouldn't that leave 8+c?

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

I'm curious how the "fee sharing" would be organized.  To see if I 
understand, You're asking what would happen if one of the two miners 
incentives (bribes in this case) the next miner (block N+1) to choose 
one of the competing tip miners?

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

Agree.

> 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?

The idea that people won't do something because it's "bad for Bitcoin" 
doesn't fit an adversarial model.  Even in the above examples (which I 
think wouldn't expect to happen often), I would argue the network still 
conforms to a Nash Equilibrium without requiring trust.  Although It's 
mostly speculation without some empirical data.

Cheers,
-Yancy

On 2022-10-17 21:10, Jeremy Rubin wrote:

> 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 [1 [1]]
> 
> 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

Links:
------
[1] https://twitter.com/JeremyRubin

Links:
------
[1] https://twitter.com/JeremyRubin
--=_fc86712a6f922e1f2eebe0423bbcc2dd
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">=
Hi Jeremy,</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">=
Thanks for the reply. I do find the semantics of mempool and block org inte=
resting (although there's a lot on the topic I don't know).</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">=
E.g., suppose:<br /><br />Block N: Fees =3D 10, reward =3D 1<br /><br />Mem=
pool: Fees =3D 2</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">=
Mining block N+1 with the mempool leads to reward 2+1 =3D 3, reorging<br />=
leads to reward of up to 10 + 1 + c, (c &lt; 2, where c is the extra<br />t=
ransactions that fit).</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
If I'm reading this correctly, Block N was already mined, but the miner who=
 mined block N+1 repacks the transactions from block N because they have mo=
re to gain.&nbsp; Wouldn't such a situation be resolved in the same way as =
two miners who find a block at a similar time? E.g the network will choose =
depending on when block N+2 is created.</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">=
Assume instead your reward is 8, leaving 3+c on the table.</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Mining block N+1 with the mempool leads to reward 2+8 =3D 10, reorging lead=
s to 10 + 8 + c?&nbsp; Wouldn't that leave 8+c?</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">=
If you assume all other miners are tip miners, and there are two<br />confl=
icting tips, they should pick the one with the more profit for<br />them, w=
hich is the new one you made as a non-tip miner since you<br />"shared" som=
e fee.</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
I'm curious how the "fee sharing" would be organized.&nbsp; To see if I und=
erstand, You're asking what would happen if one of the two miners incentive=
s (bribes in this case) the next miner (block N+1) to choose one of the com=
peting tip miners?</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">=
You aren't particularly more likely to remine block N or N+1, before<br />s=
omeone builds on it, as opposed to deeper reorgs (which require<br />larger=
 incentive).</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Agree.</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">=
However, as many have pointed out, perhaps not following the simple<br />"h=
onest tip mining" strategy is bad for bitcoin, so maybe we should<br />expe=
ct it not to happen often?</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
The idea that people won't do something because it's "bad for Bitcoin" does=
n't fit an adversarial model.&nbsp; Even in the above examples (which I thi=
nk wouldn't expect to happen often), I would argue the network still confor=
ms to a Nash Equilibrium without requiring trust.&nbsp; Although It's mostl=
y speculation without some empirical data.</div>
</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-17 21:10, Jeremy Rubin wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Building on the most work chain is perhaps not rationa=
l in many normal<br />circumstances that can come up today under the stated=
 reference<br />strategy:<br /><br />1) Take highest paying transactions th=
at fit<br />2) Mine on tips<br /><br />E.g., suppose:<br /><br />Block N: F=
ees =3D 10, reward =3D 1<br /><br />Mempool: Fees =3D 2<br /><br />Mining b=
lock N+1 with the mempool leads to reward 2+1 =3D 3, reorging<br />leads to=
 reward of up to 10 + 1 + c, (c &lt; 2, where c is the extra<br />transacti=
ons that fit). Assume instead your reward is 8, leaving 3+c<br />on the tab=
le.<br /><br />If you assume all other miners are tip miners, and there are=
 two<br />conflicting tips, they should pick the one with the more profit f=
or<br />them, which is the new one you made as a non-tip miner since you<br=
 />"shared" some fee.<br /><br />You aren't particularly more likely to rem=
ine block N or N+1, before<br />someone builds on it, as opposed to deeper =
reorgs (which require<br />larger incentive).<br /><br />However, as many h=
ave pointed out, perhaps not following the simple<br />"honest tip mining" =
strategy is bad for bitcoin, so maybe we should<br />expect it not to happe=
n often? Or other strategies to emerge around<br />selecting transactions s=
o that the next M blocks have a similar fee<br />profile, as opposed to pic=
king greedily for the next block.<br /><br />--<br />@JeremyRubin [<a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank" rel=3D"noopener nore=
ferrer">1</a>]<br /><br />On Sun, Oct 16, 2022 at 3:03 PM &lt;<a href=3D"ma=
ilto:email@yancy.lol">email@yancy.lol</a>&gt; wrote:<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">The proof-of-work also solves the problem of determini=
ng<br />representation in majority decision<br />making. If the majority we=
re based on one-IP-address-one-vote, it<br />could be subverted by anyone<b=
r />able to allocate many IPs. Proof-of-work is essentially<br />one-CPU-on=
e-vote. The majority<br />decision is represented by the longest chain, whi=
ch has the<br />greatest<br />proof-of-work effort invested<br />in it. If =
a majority of CPU power is controlled by honest nodes,<br />the<br />honest=
 chain will grow the<br />fastest and outpace any competing chains. To modi=
fy a past block,<br />an<br />attacker would have to<br />redo the proof-of=
-work of the block and all blocks after it and<br />then<br />catch up with=
 and surpass the<br />work of the honest nodes. We will show later that the=
 probability<br />of a<br />slower attacker catching up<br />diminishes exp=
onentially as subsequent blocks are added.</blockquote>
<br />It's interesting that Nash Equilibrium isn't mentioned here. &nbsp;Si=
nce<br />each miner has the option to either contribute to the longest chai=
n<br />or not, even if the miners know what strategy the other miners will<=
br />use, they still wouldn't change their decision to contribute to the<br=
 />majority.<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">For example, if I run a shop that takes rain checks, b=
ut I sell an<br />item to a higher bidder who didn't have a hold on the ite=
m, that<br />is<br />not honest, but it may be selfish profit maximizing.</=
blockquote>
<br />It would be honest if the store policy said ahead of time they are<br=
 />allowed to sell rain checks for more in such an occurrence.<br />Althoug=
h this is a good example of the difference between honest and<br />rational=
=2E &nbsp;I think this means it's not a Nash Equilibrium if we<br />needed =
to rely on the store owner to be honest.<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Satoshi said an honest majority is required for the ch=
ain to be<br />extended. Honest is not really defined though. Honesty, in m=
y<br />definition, is that you follow a pre specified rule, rational or<br =
/>not.</blockquote>
<br />My take is that "rational" is probably a better word than honest.<br =
/>In terms of a Nash Equilibrium, each participant is simply trying to<br /=
>maximize their outcome and honesty doesn't matter (only that<br />particip=
ants are rational).<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">It seems a lot of the RBF controversy is that Protocol=
 developers<br />have<br />aspired to make the honest behavior also be the =
rational behavior.<br />This is maybe a good idea because, in theory, if th=
e honest<br />behavior<br />is rational then we can make a weaker assumptio=
n of selfishness<br />maximizing a parameter.</blockquote>
<br />I'm curious, can RBF can be described by a Nash Equilibrium? &nbsp;If=
<br />yes, then it also shouldn't matter if participants are honest?<br /><=
br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Overall, it might be nice to more tightly document wha=
t bitcoins<br />assumptions are in practice and what those assumptions do i=
n terms<br />of<br />properties of Bitcoin, as well as pathways to weakenin=
g the<br />assumptions without compromising the behaviors users expect the<=
br />network to have. &nbsp;An "extended white paper" if you will.</blockqu=
ote>
<br />White paper 1.1 :D<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">A last reflection is that Bitcoin is specified with an=
 honest<br />majority<br />assumption, but also has a rational dishonest mi=
nority assumption<br />over<br />both endogenous (rewards) and exogenous (e=
lectricity) costs.<br />Satoshi<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 co=
unterexamples)</blockquote>
<br />My take is the opposite unless I'm missing something. &nbsp;Participa=
nts<br />are always incentivized to choose the rational solution (Not to<br=
 />waste electricity on a minority chain).<br /><br />Cheers,<br />-Yancy<b=
r /><br />On 2022-10-16 19:35, Jeremy Rubin via bitcoin-dev wrote:<br /><br=
 />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">The Bitcoin white paper says:<br /><br />The proof-of-=
work also solves the problem of determining<br />representation in majority=
 decision<br />making. If the majority were based on one-IP-address-one-vot=
e, it<br />could be subverted by anyone<br />able to allocate many IPs. Pro=
of-of-work is essentially<br />one-CPU-one-vote. The majority<br />decision=
 is represented by the longest chain, which has the<br />greatest<br />proo=
f-of-work effort invested<br />in it. If a majority of CPU power is control=
led by honest nodes,<br />the<br />honest chain will grow the<br />fastest =
and outpace any competing chains. To modify a past block,<br />an<br />atta=
cker would have to<br />redo the proof-of-work of the block and all blocks =
after it and<br />then<br />catch up with and surpass the<br />work of the =
honest nodes. We will show later that the probability<br />of a<br />slower=
 attacker catching up<br />diminishes exponentially as subsequent blocks ar=
e added.<br /><br />This, Satoshi (who doesn't really matter anyways I gues=
s?) 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't have a hold on the it=
em, that<br />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 />def=
inition, is that you follow a pre specified rule, rational or<br />not.<br =
/><br />It seems a lot of the RBF controversy is that Protocol developers<b=
r />have<br />aspired to make the honest behavior also be the rational beha=
vior.<br />This is maybe a good idea because, in theory, if the honest<br /=
>behavior<br />is rational then we can make a weaker assumption of selfishn=
ess<br />maximizing a parameter.<br /><br />However, Satoshi did not partic=
ularly bound what aspects of<br />honesty<br />are important for the networ=
k, because there isn't a spec defining<br />exactly what is honest or not. =
And also as soon as people are<br />honest,<br />you can rely on that assum=
ption for good effect.<br /><br />And sometimes, defining an honest behavio=
r can be creating a<br />higher<br />utility system because most people are=
 "law abiding citizens" who<br />might not be short term rational. For exam=
ple, one might expect<br />that<br />miners would be interested in making s=
ure lightning closes are<br />"accurate" 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 />assumpt=
ion where the honest behavior is not doing replacement if<br />not<br />req=
uested. This is really not much different than trying to close<br />lightni=
ng channels "the right way".<br /><br />However, where it may be different,=
 is that even in the presence<br />of<br />honest majority, the safety of 0=
conf isn't assured given the<br />potential<br />of race conditions in the =
mempool. Therefore it's not clear to me<br />that<br />0conf working well i=
s something you can drive from the Honest<br />Majority<br />Assumption (wh=
ere honest includes first seen).<br /><br />Overall, it might be nice to mo=
re tightly document what bitcoins<br />assumptions are in practice and what=
 those assumptions do in terms<br />of<br />properties of Bitcoin, as well =
as pathways to weakening the<br />assumptions without compromising the beha=
viors users expect the<br />network to have. &nbsp;An "extended white paper=
" if you will.<br /><br />It's somewhat clear to me that we shouldn't weake=
n assumptions<br />that<br />only seem local to one subsystem of Bitcoin if=
 they end up<br />destabilizing another system. In particular, things that =
decrease<br />"transaction utility" for end users decrease the demand for<b=
r />transactions which hurts the fee market's longer term viability,<br />e=
ven<br />if we feel good about making an honest policy assumption into a<br=
 />self<br />interested policy assumption.<br /><br />A last reflection is =
that Bitcoin is specified with an honest<br />majority<br />assumption, but=
 also has a rational dishonest minority assumption<br />over<br />both endo=
genous (rewards) and exogenous (electricity) costs.<br />Satoshi<br />did n=
ot suggest, at least as I read it, that Bitcoin works with an<br />rational=
 majority assumption. (If anyone thinks these three are<br />similar proper=
ties you can make some trivial counterexamples)<br /><br />Cheers,<br /><br=
 />Jeremy<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://list=
s.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=
=3D"noopener noreferrer">https://lists.linuxfoundation.org/mailman/listinfo=
/bitcoin-dev</a></blockquote>
</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></blockquote>
</div>
</body></html>

--=_fc86712a6f922e1f2eebe0423bbcc2dd--