* [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) @ 2022-10-16 17:35 Jeremy Rubin 2022-10-16 19:03 ` email ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Jeremy Rubin @ 2022-10-16 17:35 UTC (permalink / raw) To: Bitcoin development mailing list [-- Attachment #1: Type: text/plain, Size: 4154 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 5241 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-16 17:35 [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) Jeremy Rubin @ 2022-10-16 19:03 ` email 2022-10-17 19:10 ` Jeremy Rubin 2022-10-17 15:51 ` Russell O'Connor 2022-10-20 22:28 ` Peter Todd 2 siblings, 1 reply; 18+ messages in thread From: email @ 2022-10-16 19:03 UTC (permalink / raw) To: Jeremy Rubin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8036 bytes --] > 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 [-- Attachment #2: Type: text/html, Size: 11740 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-16 19:03 ` email @ 2022-10-17 19:10 ` Jeremy Rubin 2022-10-17 22:31 ` email 0 siblings, 1 reply; 18+ messages in thread From: Jeremy Rubin @ 2022-10-17 19:10 UTC (permalink / raw) To: email; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 9402 bytes --] 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 <https://twitter.com/JeremyRubin> 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 > > [-- Attachment #2: Type: text/html, Size: 15545 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-17 19:10 ` Jeremy Rubin @ 2022-10-17 22:31 ` email 2022-10-18 3:34 ` Jeremy Rubin 0 siblings, 1 reply; 18+ messages in thread From: email @ 2022-10-17 22:31 UTC (permalink / raw) To: Jeremy Rubin; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 11731 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 16661 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-17 22:31 ` email @ 2022-10-18 3:34 ` Jeremy Rubin 2022-10-18 14:30 ` Russell O'Connor 0 siblings, 1 reply; 18+ messages in thread From: Jeremy Rubin @ 2022-10-18 3:34 UTC (permalink / raw) To: email; +Cc: Bitcoin Protocol Discussion [-- Attachment #1.1: Type: text/plain, Size: 16978 bytes --] I think a diagram might help a little... [image: image.png] (diagram contains below text, which should be sufficient to reimagine it for the unsighted) Given you observe events in the following order: 1. Tx A 2. Tx B 3. Red Block 4. Tx C 5. Tx D 6. Tx E 7. Tx F Which block would you most want to attempt to mine at times 1..=7? Block W Subsidy: 1 Fee: 10 Txs: A, B Height N Prev V Block X Subsidy: 1 Fee: 2 Txs: C, D Height N+1 Prev W Block Y Subsidy: 1 Fee: 12 Txs: A, B, C, D Height N Prev V Subsidy: 1 Fee: 1 Txs: E, F Height N+1 Prev Y Block Z Subsidy: 1 Fee: 6 Txs: A, D Height N Prev V Subsidy: 1 Fee: 6 Txs: B, C Height N+1 Prev Z I'd argue that Y, Z, W (re-mining it with different coinbase) all beat X. And that most likely, something like Z is most incentive compatible for miners, but supremely bad UX for users "pay more to wait more?? What kind of society is this". Anti-fee sniping exists to decrease likelihood of this circumstance, but is not sufficient in general to solve it. > 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. quote the whitepaper: > The steps to run the network are as follows: > 1) New transactions are broadcast to all nodes. > 2) Each node collects new transactions into a block. > 3) Each node works on finding a difficult proof-of-work for its block. > 4) When a node finds a proof-of-work, it broadcasts the block to all > nodes. > 5) Nodes accept the block only if all transactions in it are valid and > not already spent. > 6) Nodes express their acceptance of the block by working on creating the > next block in the > chain, using the hash of the accepted block as the previous hash. > Nodes always consider the longest chain to be the correct one and will > keep working on extending it. If two nodes broadcast different versions of > the next block simultaneously, some nodes may receive one or the other > first. In that case, they work on the first one they received, but save the > other branch in case it becomes longer. The tie will be broken when the > next proof- of-work is found and one branch becomes longer; the nodes that > were working on the other branch will then switch to the longer one. The idea that bitcoin should work in an adversarial, stepwise selfishly interested model is nice. But I think that it is critical to keep in mind that is an *aspiration*, and very likely not the reality of the network today, which depends on people caring about other things exogenous to simplified game descriptions (like price increasing or rather not decreasing, long term hardware investments, etc). If you note the later whitepaper language: By convention, the first transaction in a block is a special transaction > that starts a new coin owned by the creator of the block. This adds an > incentive for nodes to support the network, and provides a way to initially > distribute coins into circulation, since there is no central authority to > issue them. The steady addition of a constant of amount of new coins is > analogous to gold miners expending resources to add gold to circulation. In > our case, it is CPU time and electricity that is expended. > The incentive may help encourage nodes to stay honest. If a greedy > attacker is able to assemble more CPU power than all the honest nodes, he > would have to choose between using it to defraud people by stealing back > his payments, or using it to generate new coins. He ought to find it more > profitable to play by the rules, such rules that favour him with more new > coins than everyone else combined, than to undermine the system and the > validity of his own wealth. It is clear that the incentive is there to help encourage honest miners to join at all, and to encourage nodes of hidden phenotype "Greedy" to prefer honest behavior, improving network convergence, but not to make the network functional if all players are phenotype Greedy. Satoshi still expected, in his analysis, an honest majority. Side Bar: What Satoshi said doesn't really matter in one sense. The protocol is what it is, not what somebody described it as more than a decade ago. 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! -- @JeremyRubin <https://twitter.com/JeremyRubin> On Mon, Oct 17, 2022 at 6:31 PM <email@yancy.lol> wrote: > 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 <https://twitter.com/JeremyRubin>] > > 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 > > [-- Attachment #1.2: Type: text/html, Size: 38911 bytes --] [-- Attachment #2: image.png --] [-- Type: image/png, Size: 653415 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-18 3:34 ` Jeremy Rubin @ 2022-10-18 14:30 ` Russell O'Connor 2022-10-18 16:27 ` Jeremy Rubin 2022-10-20 22:19 ` Peter Todd 0 siblings, 2 replies; 18+ messages in thread From: Russell O'Connor @ 2022-10-18 14:30 UTC (permalink / raw) To: Jeremy Rubin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3024 bytes --] On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev < bitcoin-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 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.) [-- Attachment #2: Type: text/html, Size: 3691 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-18 14:30 ` Russell O'Connor @ 2022-10-18 16:27 ` Jeremy Rubin 2022-10-18 17:33 ` Erik Aronesty 2022-10-20 19:21 ` email 2022-10-20 22:19 ` Peter Todd 1 sibling, 2 replies; 18+ messages in thread From: Jeremy Rubin @ 2022-10-18 16:27 UTC (permalink / raw) To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 5663 bytes --] 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 <https://twitter.com/JeremyRubin> On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor <roconnor@blockstream.com> wrote: > On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev < > bitcoin-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 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.) > [-- Attachment #2: Type: text/html, Size: 7431 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-18 16:27 ` Jeremy Rubin @ 2022-10-18 17:33 ` Erik Aronesty 2022-10-18 18:57 ` email 2022-10-20 19:21 ` email 1 sibling, 1 reply; 18+ messages in thread From: Erik Aronesty @ 2022-10-18 17:33 UTC (permalink / raw) To: Jeremy Rubin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7111 bytes --] not sure if this is helpful, but when i'm code reviewing a change to an existing, functioning and very complex system, i rarely go back to "first principles" to analyze that change independently, and instead try to decide if it's better or worse than what we have now you can introduce a new feature, for example, that has a bunch of noncritical bugs, especially in ux, and then you can weigh in on whether its better to get it out now for the people that need it, or bikeshed ux for another 2 releases i'm often a fan of the former if someone proposes a change to bitcoin, we should probably review it as "better or worse than what we have", rather than "has perfectly aligned incentives promoting honest behavior even among selfish actors" we know bitcoin functions now with a complex series of incentives, especially regarding node operators in other words, does the change "improve what we have" is a better bar than "stands on its own" in that way the system can slowly improve over time, rather than be stuck On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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 <https://twitter.com/JeremyRubin> > > > On Tue, Oct 18, 2022 at 10:30 AM Russell O'Connor < > roconnor@blockstream.com> wrote: > >> On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev < >> bitcoin-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 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.) >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 9274 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-18 17:33 ` Erik Aronesty @ 2022-10-18 18:57 ` email 0 siblings, 0 replies; 18+ messages in thread From: email @ 2022-10-18 18:57 UTC (permalink / raw) To: Erik Aronesty, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8296 bytes --] > not sure if this is helpful, but when i'm code reviewing a change to > an existing, functioning and very complex system, i rarely go back to > "first principles" to analyze that change independently, and instead > try to decide if it's better or worse than what we have now I agree that it's important to not be too dogmatic, which includes Satoshi and the white paper. It's fun to look back and read to try to find inspiration, although, it seems to me, a lot has been learned since then. And a lot will be learned in the future. I was thinking to myself, what if in the distant future, quantum entanglement could be used to update all nodes simultaneously across any distance in space? How cool would that be? How might that change from the original vision? Well, if we ever get that far, I'm sure Satoshi could not have planned for that, or maybe they could have.. :) On 2022-10-18 19:33, Erik Aronesty via bitcoin-dev wrote: > not sure if this is helpful, but when i'm code reviewing a change to > an existing, functioning and very complex system, i rarely go back to > "first principles" to analyze that change independently, and instead > try to decide if it's better or worse than what we have now > > you can introduce a new feature, for example, that has a bunch of > noncritical bugs, especially in ux, and then you can weigh in on > whether its better to get it out now for the people that need it, or > bikeshed ux for another 2 releases > > i'm often a fan of the former > > if someone proposes a change to bitcoin, we should probably review it > as "better or worse than what we have", rather than "has perfectly > aligned incentives promoting honest behavior even among selfish > actors" > > we know bitcoin functions now with a complex series of incentives, > especially regarding node operators > > in other words, does the change "improve what we have" is a better bar > than "stands on its own" > > in that way the system can slowly improve over time, rather than be > stuck > > On Tue, Oct 18, 2022 at 12:28 PM Jeremy Rubin via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> 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 > <roconnor@blockstream.com> wrote: > > On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev > <bitcoin-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 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.) _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 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 [-- Attachment #2: Type: text/html, Size: 10500 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-18 16:27 ` Jeremy Rubin 2022-10-18 17:33 ` Erik Aronesty @ 2022-10-20 19:21 ` email 1 sibling, 0 replies; 18+ messages in thread From: email @ 2022-10-20 19:21 UTC (permalink / raw) To: Jeremy Rubin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7151 bytes --] 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 > <roconnor@blockstream.com> wrote: > > On Tue, Oct 18, 2022 at 9:07 AM Jeremy Rubin via bitcoin-dev > <bitcoin-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 > 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 [-- Attachment #2: Type: text/html, Size: 10929 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-18 14:30 ` Russell O'Connor 2022-10-18 16:27 ` Jeremy Rubin @ 2022-10-20 22:19 ` Peter Todd 1 sibling, 0 replies; 18+ messages in thread From: Peter Todd @ 2022-10-20 22:19 UTC (permalink / raw) To: Russell O'Connor, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1487 bytes --] On Tue, Oct 18, 2022 at 10:30:26AM -0400, Russell O'Connor via bitcoin-dev wrote: > 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 I don't believe that's a good argument. A sufficiently large high latency miner who doesn't receive the most work block in time would cause huge disruptions to the network, potentially causing other miners to be unprofitable. I even gave a talk on this a few years back, on how if Bitcoin mining in space becomes profitable, it'll cause enormous problems due to the slow speed of light. > 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.) ...at which point the large miners are likely to be significantly more profitable than small miners, because they can collect more fees. That's a disaster. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-16 17:35 [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) Jeremy Rubin 2022-10-16 19:03 ` email @ 2022-10-17 15:51 ` Russell O'Connor 2022-10-17 19:02 ` Jeremy Rubin 2022-10-20 22:28 ` Peter Todd 2 siblings, 1 reply; 18+ messages in thread From: Russell O'Connor @ 2022-10-17 15:51 UTC (permalink / raw) To: Jeremy Rubin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6968 bytes --] From my limited academic interactions, people generally take the "honest" to mean following the rules (regardless of how bad it is for you to follow those rules). This has in turn led to some blockchain designs based on their own absurd set of rules, and simply waiving away their issues by stipulating their own honest majority or supermajority requirement. For example, a proof of stake blockchain might require as a rule that users securely delete their signing keys after a period of time, and prove their blockchain secure under these rules. They then argue that so long as the "honest" majority follows this rule, then there is no risk of reorganization. If enough users don't delete their signing keys, well their honest majority assumption is violated, so anything goes. The thing is that it is most certainly in each user's interest to *not* delete their signing keys. Each user has strictly more power and options available by keeping their keys and not deleting them. This rule violation is undetectable, at least until it is too late and a coalition decides to try to collaborate for a reorg to their advantage. It is not reasonable to build a distributed pseudonymous system built on arbitrary rules and then simply define your system to be secure by fiat. Users need an incentive to follow the rules of the system or it just won't work. In particular, the rules ought to form a Nash Equilibrium, and this is violated by, for example, a requirement that users delete their signing keys. If Bitcoin relied on users acting against their own interest to function, I doubt Bitcoin would be in operation today. Certainly I would have no interest in it. While it doesn't really matter, I do believe Satoshi was also aware that the rules cannot just be arbitrary, with no incentive to follow them. After all, he did note that it was designed to be in the miner's self interest to build upon the longest (most work) chain, even if that point ended up being rather involved. That is to say, I don't think that an "honest" (i.e rule following) majority is meant to be taken as an assumption, rather it is something that ought to be a consequence of the design. Anyhow, the above is simply a comment on "honest majority", and I'm not trying to make a specific claim about RBF here, though I do have my opinions and I do see how it is related. On Sun, Oct 16, 2022 at 1:36 PM Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> 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 > [-- Attachment #2: Type: text/html, Size: 8585 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-17 15:51 ` Russell O'Connor @ 2022-10-17 19:02 ` Jeremy Rubin 0 siblings, 0 replies; 18+ messages in thread From: Jeremy Rubin @ 2022-10-17 19:02 UTC (permalink / raw) To: Russell O'Connor; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 10456 bytes --] Good points, Russell. I think maybe for that particular property, one can partition the types of rules one can put into the "honest rules" without compromising the system. For example, your "keys deleted" property is one that is surely bad, but it can be broken down into a many different buckets, such as: 1) Many Keys deleted one time at the start, all parties seem to have an exogenous interest in not having the keys, as well as an endogenous one (e.g., trusted setup ceremonies for ZCash, all parties seem to love privacy, but also if anyone thinks you have your key maybe they rubber hose you) 2) Keys should be deleted, but only "in play" for some amount of time (Bitcoin NG maybe, statechains after the coin does a withdrawal, PoS with checkpoints) 3) "Keys" should be deleted, but can only cause mild or local harms / resolvable (Lightning, both eltoo and traditional, old transactions are "Keys") 4) Keys must be deleted for all time (proof of work if done as leader election In particular, I think the honest behavior assumptions are OK as long as they are reasonably time bounded and observable. For example, in transaction selection, assuming "honest behavior" may be acceptable because if the property is not true, it doesn't fundamentally brick the system or cause mass outage, but it does cause an annoyance and is observable. Further, agents may have a rationalization for following the honest policy even above their pointwise interest in profit maximizing, if they think it makes their overall participation more valuable. This is because it is an infinite game and not finite, the most effective strategies aren't always doing to be next-step profit maximizing (for those new to these concepts, http://www.econ.uiuc.edu/~hrtdmrt2/Teaching/GT_2015_19/L12.pdf is a decent primer). The example of deleting keys is interesting, because you don't need to make your defection observable. But for transaction selection, it absolutely is. Ultimately, I think the reason why (some) systems do the cop-out of "honest majority rules" --> "secure outcome" is because of a belief that there is an "existential unknown proof" that there is an infinite game that can be described where this should be the dominant strategy for all players, whether defined or not. However, one must be incredibly careful with such assumptions of an unknown existential game to which that is the dominant strategy to not abuse them to ex-falso-quod-libet themselves into a corner (Bertrand Russel is the Pope) if such a game does not actually exist. It's obviously much better to actually prove the incentive compatibility against an explicit game with explicitly stated assumptions for this reason (can include exogenous details like "wanting number-go-up", "have a 5 year hardware investment", or "belief that 0conf working required for adoption"). I (somewhat) suspect that things like the 0Conf safety assumptions are in this category where one must be careful, because I think there might not be a game where they are secure, so it leads to being able to prove false. But I also understand why others might think such a game would exist, so therein the debate. Best, Jeremy -- @JeremyRubin <https://twitter.com/JeremyRubin> On Mon, Oct 17, 2022 at 11:51 AM Russell O'Connor <roconnor@blockstream.com> wrote: > From my limited academic interactions, people generally take the "honest" > to mean following the rules (regardless of how bad it is for you to follow > those rules). This has in turn led to some blockchain designs based on > their own absurd set of rules, and simply waiving away their issues by > stipulating their own honest majority or supermajority requirement. For > example, a proof of stake blockchain might require as a rule that users > securely delete their signing keys after a period of time, and prove their > blockchain secure under these rules. They then argue that so long as the > "honest" majority follows this rule, then there is no risk of > reorganization. If enough users don't delete their signing keys, well > their honest majority assumption is violated, so anything goes. > > The thing is that it is most certainly in each user's interest to *not* > delete their signing keys. Each user has strictly more power and options > available by keeping their keys and not deleting them. This rule violation > is undetectable, at least until it is too late and a coalition decides to > try to collaborate for a reorg to their advantage. > > It is not reasonable to build a distributed pseudonymous system built on > arbitrary rules and then simply define your system to be secure by fiat. > Users need an incentive to follow the rules of the system or it just won't > work. In particular, the rules ought to form a Nash Equilibrium, and this > is violated by, for example, a requirement that users delete their signing > keys. If Bitcoin relied on users acting against their own interest to > function, I doubt Bitcoin would be in operation today. Certainly I would > have no interest in it. > > While it doesn't really matter, I do believe Satoshi was also aware that > the rules cannot just be arbitrary, with no incentive to follow them. > After all, he did note that it was designed to be in the miner's self > interest to build upon the longest (most work) chain, even if that point > ended up being rather involved. That is to say, I don't think that an > "honest" (i.e rule following) majority is meant to be taken as an > assumption, rather it is something that ought to be a consequence of the > design. > > Anyhow, the above is simply a comment on "honest majority", and I'm not > trying to make a specific claim about RBF here, though I do have my > opinions and I do see how it is related. > > On Sun, Oct 16, 2022 at 1:36 PM Jeremy Rubin via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> 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 >> > [-- Attachment #2: Type: text/html, Size: 14997 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-16 17:35 [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) Jeremy Rubin 2022-10-16 19:03 ` email 2022-10-17 15:51 ` Russell O'Connor @ 2022-10-20 22:28 ` Peter Todd 2022-10-20 23:54 ` Jeremy Rubin 2 siblings, 1 reply; 18+ messages in thread From: Peter Todd @ 2022-10-20 22:28 UTC (permalink / raw) To: Jeremy Rubin, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2245 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-20 22:28 ` Peter Todd @ 2022-10-20 23:54 ` Jeremy Rubin 2022-10-21 0:26 ` Peter Todd 0 siblings, 1 reply; 18+ messages in thread From: Jeremy Rubin @ 2022-10-20 23:54 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6247 bytes --] 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 <https://twitter.com/JeremyRubin> 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 > 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 > [-- Attachment #2: Type: text/html, Size: 10064 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-20 23:54 ` Jeremy Rubin @ 2022-10-21 0:26 ` Peter Todd 2022-10-21 8:47 ` email 0 siblings, 1 reply; 18+ messages in thread From: Peter Todd @ 2022-10-21 0:26 UTC (permalink / raw) To: Jeremy Rubin; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2578 bytes --] 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! -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-21 0:26 ` Peter Todd @ 2022-10-21 8:47 ` email 2022-10-21 13:17 ` S kang 0 siblings, 1 reply; 18+ messages in thread From: email @ 2022-10-21 8:47 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3630 bytes --] > ...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 [-- Attachment #2: Type: text/html, Size: 5977 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) 2022-10-21 8:47 ` email @ 2022-10-21 13:17 ` S kang 0 siblings, 0 replies; 18+ messages in thread From: S kang @ 2022-10-21 13:17 UTC (permalink / raw) To: email, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6256 bytes --] Hello respected parties of the bitcoin network, The point, as put forward by Jeremy is, economic rationality sometimes leads to breaking the ’social contract’ set earlier in history. Beyond its implications to RBF discussion, following economic rationality, rather than trying to uphold the social contract(honesty), may lead to hijacking of the network. Few examples: Development/Mining might follow the economic rational path of supporting whatever the blockchains winning in the market are doing (supporting smart contracts, or becoming a privacy chain, etc.) even at the price of giving up peer to peer payment system (the meme infinity/21m maybe the opposite of issuing multiple coins). A centralized third party may acquire the market sentiment to motivate this direction or influence miners/bitcoin dev to follow their roadmap, which seems beneficial to individuals until the extreme case where the core use-case is needed to secure themselves. The main issue it seems is consensus(pow-based-vote or market sentiment driven improvements) cannot be vetoed by an individual(minority is not quite the right term, since it is opposite of majority, vs consensus). They can only exit at that point(, as the 'ship sails'). My point is ‘purity’ about Satoshi's vision(a cringe term at this point, but it means nothing more than the original ’social contract’ here) should be aspired to (while not considering Satoshi's word as given truth, as pointed out by the bugs) & all ‘improvements’ must NOT be entertained. On the other hand, as pointed out by Peter & Yancy, it may be practically impossible to do anything better than economic rationality. (A corollary, is that attacks described might have already happened and thus current audience might be ‘unable to grok’ as explained by Jeremy.) Thanks for your time, mindshare & bearing my lack of academic quality. - S Kang > On Oct 21, 2022, at 1:47 AM, yancy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > >> ...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 <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 <mailto:bitcoin-dev@lists.linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>_______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> [-- Attachment #2: Type: text/html, Size: 16601 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-10-21 13:17 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-16 17:35 [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf) Jeremy Rubin 2022-10-16 19:03 ` email 2022-10-17 19:10 ` Jeremy Rubin 2022-10-17 22:31 ` email 2022-10-18 3:34 ` Jeremy Rubin 2022-10-18 14:30 ` Russell O'Connor 2022-10-18 16:27 ` Jeremy Rubin 2022-10-18 17:33 ` Erik Aronesty 2022-10-18 18:57 ` email 2022-10-20 19:21 ` email 2022-10-20 22:19 ` Peter Todd 2022-10-17 15:51 ` Russell O'Connor 2022-10-17 19:02 ` Jeremy Rubin 2022-10-20 22:28 ` Peter Todd 2022-10-20 23:54 ` Jeremy Rubin 2022-10-21 0:26 ` Peter Todd 2022-10-21 8:47 ` email 2022-10-21 13:17 ` S kang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox