Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1BEC1C002D for ; 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 ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion In-Reply-To: References: <903a46d95473714a7e11e33310fe9f56@yancy.lol> <2f4344b4c7952c3799f8766ae6b590bf@yancy.lol> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > wrote: > > On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev > 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
= I had one other idea on the topic.  Namely, in the last section "calcu= lation", Satoshi talks more about what he/she/they consider to be bad actor= s.  The idea that someone is not doing "tip mining" does not mean they= are dishonest.
=  
= We consider the scenario of an atta= cker trying to generate an alternate chain faster than the honestchain. Eve= n if this is accomplished, it does not throw the system open to arbitrary c= hanges, such
as creating value out of thin air or taking mon= ey that never belonged to the attacker. Node= s are
not going to accept an invalid transaction as payment, and hone= st nodes will never accept a block
containing them. = An attacker can only try to change one of his own tr= ansactions to take back
money he recently spent.
=  
= 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).
=  
= 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 "hones= t" (i.e. rule
following) majority is to just be accepted as an axiom a= nd if it is
violated, well, then sorry.  The rules need to be inc= entive
compatible for the system to be functional.  The honest ma= jority 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 happenin= g
in the real world at any given time.  Still, we must have a rea= son
to think that the majority would be honest, and that reasoning
should come from an argument that the rule set is incentive
compatib= le.

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

I th= ink we may be talking past each other if it is a concern /
valuable ex= ercise to decrease the assumptions that Bitcoin rests on to
make it mo= re 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 aspirat= ional (aspirations that perhaps we should absolutely
achieve?) but to = the extent that we need to fix things like the fee
market, selfish min= ing, mind the gap, etc, those are modifying Bitcoin
to be secure (or m= ore fair is perhaps another way to look at it) in
the presence of devi= ations 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 f= ix it if not. But from those
conversations I also learned that there a= re large swaths of the
community who don't share that value, or only s= hare it up to a point,
and do feel comfortable resting on honest major= ity 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 dea= ling with, as is
happening now, a fight over something that seems obvi= ously not
incentive compatible.

--
@JeremyRubin [1]

On Tue, Oct 18, 2022 at 10:30 AM Russell O'Conn= or
<roconnor@blockstrea= m.com> wrote:

On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitco= in-dev
<bi= tcoin-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<= br />to describe Bitcoin with differing assumptions than in the
whitep= aper, what the changes are and why we think the system might
support t= hose 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 doe= sn't mean Bitcoin doesn't work as
promised, since all that was promise= d originally is functioning
under an honest majority. Caveat Emptor!
I still think it is misguided to think that the "honest" (i.e. rulefollowing) majority is to just be accepted as an axiom and if it is
violated, well, then sorry.  The rules need to be incentive
com= patible 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
major= ity is honest, since mathematics cannot say what is happening
in the r= eal world at any given time.  Still, we must have a reason
to thi= nk that the majority would be honest, and that reasoning
should come f= rom 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, a= nd rightly so.  We don't actually know that Bitcoin can
function = in a low subsidy environment because we have never tested
it.  Bi= tcoin could still end up a failure if that doesn't work out.
My curren= t understanding/guess is that with a "thick mempool" (that
is lots of = transactions without large gaps in fee rates between
them) and/or mine= rs rationally leaving behind transactions to
encourage mining on their= block (after all it is in a miner's own
interest not to have their bl= ock 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 occ= asion, it's not like the protocol
immediately collapses, because minin= g 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 mor= e 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 minin= g policy
to leave some transactions out based on current (and anticipa= ted)
mempool conditions, or (for a sufficiently capitalized miner) lea= ve
an explicit, ANYONECANSPEND transaction output as a tip for the nex= t
miner to build upon mined blocks.)
 

Links:
------
[1] https://twitte= r.com/JeremyRubin
_______________________________________________<= br />bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailma= n/listinfo/bitcoin-dev
--=_84b35ee22e0c99a8c832ee6d5b691e39--