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 >