Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-17 📝 Original message:>From my limited academic ...
📅 Original date posted:2022-10-17
📝 Original message:>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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/cf650127/attachment-0001.html>;
📝 Original message:>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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221017/cf650127/attachment-0001.html>;