Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4FC66C002D for ; Thu, 20 Oct 2022 23:54:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 0A97884002 for ; Thu, 20 Oct 2022 23:54:15 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0A97884002 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=oA+roffC X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROWRXG1bGVgQ for ; Thu, 20 Oct 2022 23:54:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 74C1983FAD Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) by smtp1.osuosl.org (Postfix) with ESMTPS id 74C1983FAD for ; Thu, 20 Oct 2022 23:54:13 +0000 (UTC) Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-3690482f5dfso8509347b3.6 for ; Thu, 20 Oct 2022 16:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OgOdlzDUrnFSYaozP168PV6zpEIYRrrIzGusWSmC7Xo=; b=oA+roffCy3D/PqihACwjHsEaXt8QaXznswDgH/ZEAZGcnQGb2bbP4vi7r1+s3O6175 MUNb6uor8kFqwyuktZXuR4iC8gpiou6R1akv9nlWIanITU3jP6SgNVRoe+nbr+SkLahU B2W7ReFu5Fh9WzZA6OsfRopN7u6r2Upx1JlAqQK+nzGYNXhrWSEgcSa49JLariiC73Cr 1VmQzm7BURj1jz8gkw41+zA4yV0MpZQgoxq/gHvMZBe2sR6yzf2ZCZbHMgt8fVWivAo1 UyBvAFPuICS1pjx6YFNGyrR73Ol/T8CDl9tX37k5wHYFfxQ8oUfQYnVMHhTPLmM0BuwX jsjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OgOdlzDUrnFSYaozP168PV6zpEIYRrrIzGusWSmC7Xo=; b=8N0//43x94Wcf88OjjLm9yZ35cKfM7f/T5qcrbQ1ROUnLfjYnTKr4aa/Vs1F81SMjG wuT9txIOrBbOuMrU7tjpaPGHJLRZpr6h3/oZyouJSVh32cFQQrultYyTLst/0adRm63Q oIUZuzCi7KgCi200o66T27BR2sj/wmOCcqT/qfFi2rSPxnpSVV6b5r5OFtLifNiPgsYL ojZ+jb0tehSOcdk1jtsL8tJ2tjun5FXIJScQ2s8mCF0xn+cwfYZIbcRejVXWY0l98wfi 9xKMJGIkDObPnQ5gjCsd7DxFXsMJeyfyWJ0AJ6CxM02jPlvqZwGHB2KLJ5i3fkv5Vtq3 eREA== X-Gm-Message-State: ACrzQf18fEkHzD7hndGMdfpzbmKOKaryT+bbtl+vs2JIHAGOnv73bJ55 xUd9Khh0wGufQu3g0nq4RIE9mJr8K3IWBSWj0f31yGOYSOc= X-Google-Smtp-Source: AMsMyM6E2aJsBRp+t2ELBW4whc/2I42XTg5ccnTT7irFTOqvq+3VDgcAIZPKxKFIYrp5KIVNbKheR8NrsX6Ed7+rCos= X-Received: by 2002:a0d:d911:0:b0:369:375c:6657 with SMTP id b17-20020a0dd911000000b00369375c6657mr2495127ywe.355.1666310052162; Thu, 20 Oct 2022 16:54:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Rubin Date: Thu, 20 Oct 2022 16:54:00 -0700 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="000000000000beb27c05eb800a8a" Cc: Bitcoin Protocol Discussion 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 23:54:15 -0000 --000000000000beb27c05eb800a8a Content-Type: text/plain; charset="UTF-8" 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. > > Thanks for bringing up that point. > I didn't really make that statement as strong as I could have. The > requirement is that the good guys collectively have more CPU power than any > single attacker. > There would be many smaller zombie farms that are not big enough to > overpower the network, and they could still make money by generating > bitcoins. The smaller farms are then the "honest nodes". (I need a better > term than "honest") The more smaller farms resort to generating bitcoins, > the higher the bar gets to overpower the network, making larger farms also > too small to overpower it so that they may as well generate bitcoins too. > According to the "long tail" theory, the small, medium and merely large > farms put together should add up to a lot more than the biggest zombie farm. > Even if a bad guy does overpower the network, it's not like he's instantly > rich. All he can accomplish is to take back money he himself spent, like > bouncing a check. To exploit it, he would have to buy something from a > merchant, wait till it ships, then overpower the network and try to take > his money back. I don't think he could make as much money trying to pull a > carding scheme like that as he could by generating bitcoins. With a zombie > farm that big, he could generate more bitcoins than everyone else combined. > The Bitcoin network might actually reduce spam by diverting zombie farms > to generating bitcoins instead. > Satoshi Nakamoto There is clearly a notion that Satoshi categorizes good guys / bad guys as people interested in double spending and people who aren't. Sure, Satoshi's writings don't *really* matter in the context of what Bitcoin is / can be, and I've acknowledged that repeatedly. For you to call it misleading is more misleading than for me to quote from it! There's a reason I'm citing it. To not read the original source material that pulled the community together is to make one ignorant around why there is resistance to something like RBF. This is because there are still elements of the community who expect the rules that good-phenotype node operators run to be the ones maximally friendly to resolving transactions on the first seen basis, so that there aren't double spends. This is a view which you can directly derive from these early writings around what one should expect of node operators. The burden rests on the community, who has undertaken a project to adopt a different security model from the original "social contract" generated by the early writings of Satoshi, to demonstrate why damaging one group's reliance interest on a property derived from the honest majority assumption is justified. 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. 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. -- @JeremyRubin On Thu, Oct 20, 2022 at 3:28 PM Peter Todd wrote: > On Sun, Oct 16, 2022 at 01:35:54PM -0400, 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. > > Satoshi also made a very fundamental mistake: the whitepaper and initial > Bitcoin release chooses the *longest* chain, rather than the most work > chain. > Longest chain is totally broken. > > What Satoshi said in the whitepaper is completely irrelevant and quoting > it in > circumstances like this is IMO misleading. > > > Anyway, obviously we should always try to make systems that work properly > with > an economically rational majority, rather than the much more risky honest > majority. Economically rational is a better security guarantee. And > whenever > possible we should go even further, using the standard computationally > infeasible guarantees (as seen in our EC signature schems), or even, > mathematically impossible (1+1=2). > > It's notable how in ethereum land, their smart contract schemes have lead > to > significant effort in economically rational MEV optimization, at a > significant > cost to decentralization (eg majority of blocks are now OFAC compliant). > There's no reason why Bitcoin should be fundamentally any different in the > long > run. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > --000000000000beb27c05eb800a8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The difference betwee= n honest majority and longest chain is that the longest chain=C2=A0bug was something acknowledged = by Satoshi & patched https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385= 950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420.

<= br>OTOH, we have more explicit references that the honest majority really s= hould be thought of as good guys vs bad guys... e.g.
Thanks for bringing up that point.
I didn't really make that statement as strong as = I could have. The requirement is that the good guys collectively have more = CPU power than any single attacker.=C2=A0
The= re would be many smaller zombie farms that are not big enough to overpower = the network, and they could still make money by generating bitcoins. The sm= aller farms are then the "honest nodes". (I need a better term th= an "honest") The more smaller farms resort to generating bitcoins= , the higher the bar gets to overpower the network, making larger farms als= o too small to overpower it so that they may as well generate bitcoins too.= According to the "long tail" theory, the small, medium and merel= y large farms put together should add up to a lot more than the biggest zom= bie farm.
Even if a b= ad guy does overpower the network, it's not like he's instantly ric= h. All he can accomplish is to take back money he himself spent, like bounc= ing a check. To exploit it, he would have to buy something from a merchant,= wait till it ships, then overpower the network and try to take his money b= ack. I don't think he could make as much money trying to pull a carding= scheme like that as he could by generating bitcoins. With a zombie farm th= at big, he could generate more bitcoins than everyone else combined.=
The Bitcoin network might a= ctually reduce spam by diverting zombie farms to generating bitcoins instea= d.
Satoshi Nakamoto


Ther= e is clearly a notion that Satoshi categorizes good guys / bad guys as peop= le interested in double spending and people who aren't.

<= div>
Sure, Satoshi's writings don= 9;t really=C2=A0matter in the context of what Bitcoin is / can be, a= nd I've acknowledged that repeatedly. For you to call it misleading is = more misleading than for me to quote from it!

There's a rea= son I'm citing it. To not read the original source material that pulled= the community together is to make one ignorant around why there is resista= nce to something like RBF. This is because there are still elements of the = community who expect the rules that good-phenotype node operators run to be= the ones maximally friendly to resolving transactions on the first seen ba= sis, so that there aren't double spends. This is a view which you can d= irectly derive from these early writings around what one should expect of n= ode operators.

The burden rests on the community, who has under= taken a project to adopt a different security model from the original "= ;social contract" generated by the early writings of Satoshi, to demon= strate why damaging one group's reliance interest on a property derived= from the honest majority assumption is justified.

I do think t= he case can be fairly made for full RBF, but if you don't grok the abov= e 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 bei= ng changed. They have every right to be mad about that and make disagreemen= ts known and argue for why we should preserve these properties. As someone = who wants for Bitcoin to be a system which doesn't arbitrarily change r= ules based on the whims of others, I think it important that we can steelma= n and provide strong cases for why our actions might be in the wrong, so th= at 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= .



On Thu, Oct 20, 2022 at 3:28 PM Peter Todd <pete@petertodd.org> wrote:
= On Sun, Oct 16, 2022 at 01:35:54PM -0400, Jeremy Rubin via bitcoin-dev wrot= e:
> The Bitcoin white paper says:
>
> The proof-of-work also solves the problem of determining representatio= n in
> majority decision
> making. If the majority were based on one-IP-address-one-vote, it coul= d be
> subverted by anyone
> able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vo= te.
> 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 h= onest
> 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 c= atch
> 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.

Satoshi also made a very fundamental mistake: the whitepaper and initial Bitcoin release chooses the *longest* chain, rather than the most work chai= n.
Longest chain is totally broken.

What Satoshi said in the whitepaper is completely irrelevant and quoting it= in
circumstances like this is IMO misleading.


Anyway, obviously we should always try to make systems that work properly w= ith
an economically rational majority, rather than the much more risky honest majority. Economically rational is a better security guarantee. And wheneve= r
possible we should go even further, using the standard computationally
infeasible guarantees (as seen in our EC signature schems), or even,
mathematically impossible (1+1=3D2).

It's notable how in ethereum land, their smart contract schemes have le= ad to
significant effort in economically rational MEV optimization, at a signific= ant
cost to decentralization (eg majority of blocks are now OFAC compliant). There's no reason why Bitcoin should be fundamentally any different in = the long
run.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--000000000000beb27c05eb800a8a--