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">= </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">= </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">= </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 < 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. 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">= </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? Wouldn't that leave 8+c?</div> <div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">= </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. 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">= </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">= </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. 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. 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">= </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">= </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 < 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 <<a href=3D"ma= ilto:email@yancy.lol">email@yancy.lol</a>> 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. 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 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? 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. 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. 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. 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> <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--