Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3A0BCC002D for ; Fri, 21 Oct 2022 08:47:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 1BAA14115D for ; Fri, 21 Oct 2022 08:47:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1BAA14115D X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 YrqLe8Q7kfgW for ; Fri, 21 Oct 2022 08:47:22 +0000 (UTC) X-Greylist: delayed 13:25:20 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6260B40123 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by smtp2.osuosl.org (Postfix) with ESMTPS id 6260B40123 for ; Fri, 21 Oct 2022 08:47:22 +0000 (UTC) Received: (Authenticated sender: email@yancy.lol) by mail.gandi.net (Postfix) with ESMTPA id 7BDB21BF210; Fri, 21 Oct 2022 08:47:19 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 21 Oct 2022 10:47:19 +0200 From: email@yancy.lol To: Peter Todd , Bitcoin Protocol Discussion In-Reply-To: References: Message-ID: <1f575fa24af142126507eebdf0e6b2e8@yancy.lol> X-Sender: email@yancy.lol Content-Type: multipart/alternative; boundary="=_37a2996167c1835d3a565f1477d4dd82" X-Mailman-Approved-At: Fri, 21 Oct 2022 12:11:23 +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: Fri, 21 Oct 2022 08:47:24 -0000 --=_37a2996167c1835d3a565f1477d4dd82 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > ...and the easiest way to avoid Bitcoin being a system that doesn't > arbitrarily > change rules, is to rely on economically rational rules that aren't > likely to > change! Yes, I think many people on this thread have been making the same point. This is the basis of the Nash Equilibrium, from what I remember. > This, Satoshi (who doesn't really matter anyways I guess?) It doesn't seem to me Satoshi was classically trained in CS else maybe he/she/they might have referenced the Nash Equilibrium. Looking at some of the other references, including a statistics book titled "An Introduction to Probability Theory and its Applications" from 1957 makes me think this Satoshi person was closer in training and practice to a mathematician. Cheers, -Yancy On 2022-10-21 02:26, Peter Todd via bitcoin-dev wrote: > On Thu, Oct 20, 2022 at 04:54:00PM -0700, Jeremy Rubin wrote: > >> The difference between honest majority and longest chain is that the >> longest chain bug was something acknowledged by Satoshi & patched >> https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420 >> . >> >> OTOH, we have more explicit references that the honest majority really >> should be thought of as good guys vs bad guys... e.g. > > The point is Satoshi got a lot of very fundamental stuff wrong. > Bringing up > what Satoshi wrote now, almost 14 years later, misleads less-technical > readers > into thinking our understanding of Bitcoin is still based on that > early, > incorrect, understanding. > > Incidentally, you realize that it was _Satoshi_ who added RBF to > Bitcoin with > nSequence replacements. My contribution was to fix that obviously > broken design > with fee-based RBF (with nSequence a transaction could be replaced up > to 4 > billion times, using essentially unlimited P2P bandwidth; it was a > terrible > idea). > >> I do think the case can be fairly made for full RBF, but if you don't >> grok >> the above maybe you won't have as much empathy for people who built a >> business around particular aspects of the Bitcoin network that they >> feel >> are now being changed. They have every right to be mad about that and >> make >> disagreements known and argue for why we should preserve these >> properties. > > Those people run mild sybil attacks on the network in their efforts to > "mitigate risk" by monitoring propagation; fundamentally doing so is > centralizing and unfair, as only a small number of companies can do > that > without DoS attacking the P2P network. It's pretty obvious that > reliance to > zeroconf is harmful to Bitcoin, and people trying to do that have > repeatedly > taken big losses when their risk mitigations turned out to not work. > Their only > right to be mad comes from the 1st Ammendment. > >> As someone who wants for Bitcoin to be a system which doesn't >> arbitrarily >> change rules based on the whims of others, I think it important that >> we can >> steelman and provide strong cases for why our actions might be in the >> wrong, so that we make sure our justifications are not only >> well-justified, >> but that we can communicate them clearly to all participants in a >> global >> value network. > > ...and the easiest way to avoid Bitcoin being a system that doesn't > arbitrarily > change rules, is to rely on economically rational rules that aren't > likely to > change! > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --=_37a2996167c1835d3a565f1477d4dd82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
= =2E..and the easiest way to avoid Bitcoin being a system that doesn't arbit= rarily
change rules, is to rely on economically rational rules that ar= en't likely to
change!
=  
= Yes, I think many people on this thread have been making the same point.&nb= sp; This is the basis of the Nash Equilibrium, from what I remember.
=  
This, Satoshi (who doesn't really matter anyways I guess?= )
=  
= It doesn't seem to me Satoshi was classically trained in CS else maybe he/s= he/they might have referenced the Nash Equilibrium.  Looking at some o= f the other references, including a statistics book titled "An Introduction to Probability Theor= y and its Applications" from 1957 makes me think this Satoshi person= was closer in training and practice to a mathematician.
=  
= Cheers,
= -Yancy
=  
= On 2022-10-21 02:26, Peter Todd via bitcoin-dev wrote:
On Thu, Oct 20, 2022 at 04:54:00PM -0700, Jeremy Rubin= wrote:
The difference between honest majority and longest cha= in is that the
longest chain bug was something acknowledged by Satoshi= & patched
https://github.com/bit= coin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6d= a1a45222eeec71496747b31R420
.


OTOH, we have more = explicit references that the honest majority really
should be thought = of as good guys vs bad guys... e.g.

The point is Satoshi got a lot of very fundamental stuff wrong. Bring= ing up
what Satoshi wrote now, almost 14 years later, misleads less-te= chnical readers
into thinking our understanding of Bitcoin is still ba= sed on that early,
incorrect, understanding.

Incidentally, = you realize that it was _Satoshi_ who added RBF to Bitcoin with
nSeque= nce replacements. My contribution was to fix that obviously broken designwith fee-based RBF (with nSequence a transaction could be replaced up t= o 4
billion times, using essentially unlimited P2P bandwidth; it was a= terrible
idea).

I do think the case can be fairly made for full RBF, b= ut if you don't grok
the above maybe you won't have as much empathy fo= r people who built a
business around particular aspects of the Bitcoin= network that they feel
are now being changed. They have every right t= o be mad about that and make
disagreements known and argue for why we = should preserve these properties.

Those people run mild sybil attacks on the network in their efforts t= o
"mitigate risk" by monitoring propagation; fundamentally doing so is=
centralizing and unfair, as only a small number of companies can do t= hat
without DoS attacking the P2P network. It's pretty obvious that re= liance to
zeroconf is harmful to Bitcoin, and people trying to do that= have repeatedly
taken big losses when their risk mitigations turned o= ut to not work. Their only
right to be mad comes from the 1st Ammendme= nt.

As someone who wants for Bitcoin to be a system which = doesn't arbitrarily
change rules based on the whims of others, I think= it important that we can
steelman and provide strong cases for why ou= r actions might be in the
wrong, so that we make sure our justificatio= ns are not only well-justified,
but that we can communicate them clear= ly to all participants in a global
value network.

...and the easiest way to avoid Bitcoin being a system that doesn't a= rbitrarily
change rules, is to rely on economically rational rules tha= t aren't likely to
change!

________________________________= _______________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<= br />https://lists.linuxfound= ation.org/mailman/listinfo/bitcoin-dev
--=_37a2996167c1835d3a565f1477d4dd82--