[bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Jeremy Rubin]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[email]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Russell O'Connor]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Jeremy Rubin]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Jeremy Rubin]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[email]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Jeremy Rubin]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Russell O'Connor]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Jeremy Rubin]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Erik Aronesty]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[email]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[email]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Jeremy Rubin]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[email]

[-- 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 --]

Re: [bitcoin-dev] Does Bitcoin require or have an honest majority or a rational one? (re rbf)

[S kang]

[-- 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 --]