Re: [bitcoin-dev] Additional BIPs related to other proposals

[Luke Dashjr via bitcoin-dev]

On Friday 21 May 2021 07:56:51 Billy Tetrud via bitcoin-dev wrote:
> These look like relatively well put together documents. However, they seem
> relatively orthogonal to Bitcoin in that they look like protocols that
> build on top of the bitcoin platform but aren't directly related to
> changing how bitcoin operates at its base layer. Am I miss reading these?

BIPs are not limited to the base layer. Anything that coordinates between 
Bitcoin software at any layer can use BIPs.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Billy Tetrud via bitcoin-dev]

@Erik
>  it also solves the "nothing at stake" problem

A. the "nothing at stake" problem can be and has been solved by PoS
consensus mechanisms (unless you mean it more broadly than I'm taking it),
and B. Proof of Burn should have just as much "nothing at stake" issues as
PoS. Both consensus mechanisms depend on the current state of the chain to
determine whether someone's stake or burn would allow the creation of a
block. But I am curious, how does proof of burn solve the "nothing at
stake" problem in your view?

On Fri, May 21, 2021 at 10:58 AM Erik Aronesty  wrote:

> proof of burn has all the benefits of proof of stake (if there are any)
>
> but it also solves the "nothing at stake" problem
>
> the incentive in POB is that you're making a long-term investment in
> mining, and you want a stable protocol, quality network, etc to
> pay off your investment.
>
> On Thu, May 20, 2021 at 8:04 PM Billy Tetrud 
> wrote:
> >
> > I think there is a lot of misinformation and bias against Proof of
> Stake. Yes there have been lots of shady coins that use insecure PoS
> mechanisms. Yes there have been massive issues with distribution of PoS
> coins (of course there have also been massive issues with PoW coins as
> well). However, I want to remind everyone that there is a difference
> between "proved to be impossible" and "have not achieved recognized success
> yet". Most of the arguments levied against PoS are out of date or rely on
> unproven assumptions or extrapolation from the analysis of a particular PoS
> system. I certainly don't think we should experiment with bitcoin by
> switching to PoS, but from my research, it seems very likely that there is
> a proof of stake consensus protocol we could build that has substantially
> higher security (cost / capital required to execute an attack) while at the
> same time costing far less resources (which do translate to fees on the
> network) *without* compromising any of the critical security properties
> bitcoin relies on. I think the critical piece of this is the disagreements
> around hardcoded checkpoints, which is a critical piece solving attacks
> that could be levied on a PoS chain, and how that does (or doesn't) affect
> the security model.
> >
> > @Eric Your proof of stake fallacy seems to be saying that PoS is worse
> when a 51% attack happens. While I agree, I think that line of thinking
> omits important facts:
> > * The capital required to 51% attack a PoS chain can be made
> substantially greater than on a PoS chain.
> > * The capital the attacker stands to lose can be substantially greater
> as well if the attack is successful.
> > * The effectiveness of paying miners to raise the honest fraction of
> miners above 50% may be quite bad.
> > * Allowing a 51% attack is already unacceptable. It should be considered
> whether what happens in the case of a 51% may not be significantly
> different. The currency would likely be critically damaged in a 51% attack
> regardless of consensus mechanism.
> >
> > > Proof-of-stake tends towards oligopolistic control
> >
> > People repeat this often, but the facts support this. There is no
> centralization pressure in any proof of stake mechanism that I'm aware of.
> IE if you have 10 times as much coin that you use to mint blocks, you
> should expect to earn 10x as much minting revenue - not more than 10x. By
> contrast, proof of work does in fact have clear centralization pressure -
> this is not disputed. Our goal in relation to that is to ensure that the
> centralization pressure remains insignifiant. Proof of work also clearly
> has a lot more barriers to entry than any proof of stake system does. Both
> of these mean the tendency towards oligopolistic control is worse for PoW.
> >
> > > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
> >
> > I certainly agree. Bitcoin's energy usage at the moment is I think quite
> warranted. However, the question is: can we do substantially better. I
> think if we can, we probably should... eventually.
> >
> > > Proof of Stake is only resilient to ⅓ of the network demonstrating a
> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
> >
> > I see no mention of this in the pos.pdf you linked to. I'm not aware of
> any proof that all PoS systems have a failure threshold of 1/3. I know that
> staking systems like Casper do in fact have that 1/3 requirement. However
> there are PoS designs that should exceed that up to nearly 50% as far as
> I'm aware. Proof of work is not in fact resilient up to the 1/2 threshold
> in the way you would think. IE, if 100% of miners are currently honest and
> have a collective 100 exahashes/s hashpower, an attacker does not need to
> obtain 100 exahashes/s, but actually only needs to accumulate 50
> exahashes/s. This is because as the attacker accumulates hashpower, it
> drives honest miners out of the market as the difficulty increases to
> beyond what is economically sustainable. Also, its been shown that the 

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

[Erik Aronesty via bitcoin-dev]

the original argument was correct: has to be a hard fork.

otherwise there's nothing to prevent a miner with leftover asics from
"tricking" old nodes to following another chain.

a hard fork is a really, really high bar - there would have to be
something very broken to justify it.

quantum-hashing or whatever (proof-of burn of course is as
quantum-safe as the underlying chain is... so it's nice to switch to,
should it be necessary)

On Fri, May 21, 2021 at 4:11 PM Billy Tetrud  wrote:
>
> The way I would think of doing this kind of thing (switching consensus 
> protocol), which includes switching to a different hash function for proof of 
> work, is to have a transitionary period where both consensus mechanisms are 
> used to mine. This transitionary period should be long (perhaps years) to 
> give miners time to manage the logistics of switching over. However, because 
> there would be no trustless mechanism to automatically relate the amount of 
> work (or burn, or whatever) done between the two consensus mechanisms, there 
> would need to be some manually determined estimate of equivalence hard coded 
> into the software. Eg, if we're talking about a different hash function, we 
> could define in software that 100 current hashes is about equal to 10 hashes 
> using the new algorithm. This could even be set such that its marginally (but 
> significantly) favorable to use the new hash function, to give additional 
> incentive to miners to switch. The risk with that is that hardware that 
> processes tha
 t new hash function might innovate arbitrarily more quickly than the old hash 
function (which is likely to have somewhat plateaued), and this might make the 
manually estimated equivalence become inaccurate in a way that could 
significantly reduce the security of the network. a change like this could be 
fraught with perils if the miners using each mechanism don't end up cooperating 
to ensure that equivalence is set fairly, and instead make efforts to attempt 
to unfairly increase their share.
>
> In any case, the idea is that you'd have a smooth switch over from (blocks 
> the old mechanism creates / blocks the new mechanism creates) 100%/0% -> 
> 75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total 
> hashpower, (eg 95%) the old consensus mechanism could simply be shut off - 
> which would give additional incentive for miners to switch sooner rather than 
> later. However, it would probably be best to make this cut off more like 99% 
> than 95%, since screwing over 5% of the hashpower for a few months is 
> probably not necessary or ideal. It might actually just be better to have a 
> time-based cutoff. Or have the final switch over lock in at 95% with a few 
> months to give the other 5% time to switch over (and if they don't then its 
> on them).
>
> I would think this could work for switch between any consensus mechanism. 
> However, how to do this in a soft fork is another story. It sounds like its 
> doable from other people's comments.
>
> On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev 
>  wrote:
>>
>> On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev 
>> wrote:
>> > The transition *could* look like this:
>> >  - validating nodes begin to require proof-of-burn, in addition to
>> > proof-of-work (soft fork)
>> >  - the extra expense makes it more expensive for miners, so POW slowly 
>> > drops
>> >  - on a predefined schedule, POB required is increased to 100% of the
>> > "required work" to mine
>> > Given all of that, am I correct in thinking that a hard fork would not
>> > be necessary?
>>
>> It depends what you mean by a "hard fork". By the definition that
>> "the old software will consider the chain followed by new versions of
>> the software as valid" it's a soft fork. But it doesn't maintain the
>> property "old software continues to follow the same chain as new software,
>> provided the economic majority has adopted the new software" -- because
>> after the PoW part has dropped its difficulty substantitally, people can
>> easily/cheaply make a new chain that doesn't include proof-of-burn, and
>> has weak proof-of-work that's nevertheless higher than the proof-of-burn
>> chain, so old nodes will switch to it, while new nodes will continue to
>> follow the proof-of-burn chain.
>>
>> So I think that means it needs to be treated as a hard fork: everyone
>> needs to be running the new software by some date to ensure they follow
>> the same chain.
>>
>> (The same argument applies to trying to switch to a different PoW
>> algorithm via a soft fork; I forget who explained this to me)
>>
>> Jeremy wrote:
>> > I think you need to hard deprecate the PoW for this to work, otherwise
>> > all old miners are like "toxic waste".
>> >
>> > Imagine one miner turns on a S9 and then ramps up difficulty for
>> > everyone else.
>>
>> If it's a soft-fork, you could only ramp up the PoW difficulty by mining
>> more than one block every ten minutes, but 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Erik Aronesty via bitcoin-dev]

proof of burn has all the benefits of proof of stake (if there are any)

but it also solves the "nothing at stake" problem

the incentive in POB is that you're making a long-term investment in
mining, and you want a stable protocol, quality network, etc to
pay off your investment.

On Thu, May 20, 2021 at 8:04 PM Billy Tetrud  wrote:
>
> I think there is a lot of misinformation and bias against Proof of Stake. Yes 
> there have been lots of shady coins that use insecure PoS mechanisms. Yes 
> there have been massive issues with distribution of PoS coins (of course 
> there have also been massive issues with PoW coins as well). However, I want 
> to remind everyone that there is a difference between "proved to be 
> impossible" and "have not achieved recognized success yet". Most of the 
> arguments levied against PoS are out of date or rely on unproven assumptions 
> or extrapolation from the analysis of a particular PoS system. I certainly 
> don't think we should experiment with bitcoin by switching to PoS, but from 
> my research, it seems very likely that there is a proof of stake consensus 
> protocol we could build that has substantially higher security (cost / 
> capital required to execute an attack) while at the same time costing far 
> less resources (which do translate to fees on the network) *without* 
> compromising any of the critical security properties bitcoin relies on. I 
> think the critical piece of this is the disagreements around hardcoded 
> checkpoints, which is a critical piece solving attacks that could be levied 
> on a PoS chain, and how that does (or doesn't) affect the security model.
>
> @Eric Your proof of stake fallacy seems to be saying that PoS is worse when a 
> 51% attack happens. While I agree, I think that line of thinking omits 
> important facts:
> * The capital required to 51% attack a PoS chain can be made substantially 
> greater than on a PoS chain.
> * The capital the attacker stands to lose can be substantially greater as 
> well if the attack is successful.
> * The effectiveness of paying miners to raise the honest fraction of miners 
> above 50% may be quite bad.
> * Allowing a 51% attack is already unacceptable. It should be considered 
> whether what happens in the case of a 51% may not be significantly different. 
> The currency would likely be critically damaged in a 51% attack regardless of 
> consensus mechanism.
>
> > Proof-of-stake tends towards oligopolistic control
>
> People repeat this often, but the facts support this. There is no 
> centralization pressure in any proof of stake mechanism that I'm aware of. IE 
> if you have 10 times as much coin that you use to mint blocks, you should 
> expect to earn 10x as much minting revenue - not more than 10x. By contrast, 
> proof of work does in fact have clear centralization pressure - this is not 
> disputed. Our goal in relation to that is to ensure that the centralization 
> pressure remains insignifiant. Proof of work also clearly has a lot more 
> barriers to entry than any proof of stake system does. Both of these mean the 
> tendency towards oligopolistic control is worse for PoW.
>
> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>
> I certainly agree. Bitcoin's energy usage at the moment is I think quite 
> warranted. However, the question is: can we do substantially better. I think 
> if we can, we probably should... eventually.
>
> > Proof of Stake is only resilient to ⅓ of the network demonstrating a 
> > Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
>
> I see no mention of this in the pos.pdf you linked to. I'm not aware of any 
> proof that all PoS systems have a failure threshold of 1/3. I know that 
> staking systems like Casper do in fact have that 1/3 requirement. However 
> there are PoS designs that should exceed that up to nearly 50% as far as I'm 
> aware. Proof of work is not in fact resilient up to the 1/2 threshold in the 
> way you would think. IE, if 100% of miners are currently honest and have a 
> collective 100 exahashes/s hashpower, an attacker does not need to obtain 100 
> exahashes/s, but actually only needs to accumulate 50 exahashes/s. This is 
> because as the attacker accumulates hashpower, it drives honest miners out of 
> the market as the difficulty increases to beyond what is economically 
> sustainable. Also, its been shown that the best proof of work can do is 
> require an attacker to obtain 33% of the hashpower because of the selfish 
> mining attack discussed in depth in this paper: 
> https://arxiv.org/abs/1311.0243. Together, both of these things reduce PoW's 
> security by a factor of about 83% (1 - 50%*33%).
>
>  > Proof of Stake requires other trade-offs which are incompatible with 
> Bitcoin's objective (to be a trustless digital cash) — specifically the 
> famous "security vs. liveness" guarantee
>
> Do you have a good source that talks about why you think proof of stake 
> cannot be used for a 

Re: [bitcoin-dev] Gradual transition to an alternate proof without a hard fork.

[Billy Tetrud via bitcoin-dev]

The way I would think of doing this kind of thing (switching consensus
protocol), which includes switching to a different hash function for proof
of work, is to have a transitionary period where both consensus mechanisms
are used to mine. This transitionary period should be long (perhaps years)
to give miners time to manage the logistics of switching over. However,
because there would be no trustless mechanism to automatically relate the
amount of work (or burn, or whatever) done between the two consensus
mechanisms, there would need to be some manually determined estimate of
equivalence hard coded into the software. Eg, if we're talking about a
different hash function, we could define in software that 100 current
hashes is about equal to 10 hashes using the new algorithm. This could even
be set such that its marginally (but significantly) favorable to use the
new hash function, to give additional incentive to miners to switch. The
risk with that is that hardware that processes that new hash function might
innovate arbitrarily more quickly than the old hash function (which is
likely to have somewhat plateaued), and this might make the manually
estimated equivalence become inaccurate in a way that could significantly
reduce the security of the network. a change like this could be fraught
with perils if the miners using each mechanism don't end up cooperating to
ensure that equivalence is set fairly, and instead make efforts to attempt
to unfairly increase their share.

In any case, the idea is that you'd have a smooth switch over from (blocks
the old mechanism creates / blocks the new mechanism creates) 100%/0% ->
75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total
hashpower, (eg 95%) the old consensus mechanism could simply be shut off -
which would give additional incentive for miners to switch sooner rather
than later. However, it would probably be best to make this cut off more
like 99% than 95%, since screwing over 5% of the hashpower for a few months
is probably not necessary or ideal. It might actually just be better to
have a time-based cutoff. Or have the final switch over lock in at 95% with
a few months to give the other 5% time to switch over (and if they don't
then its on them).

I would think this could work for switch between any consensus mechanism.
However, how to do this in a soft fork is another story. It sounds like its
doable from other people's comments.

On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev
> wrote:
> > The transition *could* look like this:
> >  - validating nodes begin to require proof-of-burn, in addition to
> > proof-of-work (soft fork)
> >  - the extra expense makes it more expensive for miners, so POW slowly
> drops
> >  - on a predefined schedule, POB required is increased to 100% of the
> > "required work" to mine
> > Given all of that, am I correct in thinking that a hard fork would not
> > be necessary?
>
> It depends what you mean by a "hard fork". By the definition that
> "the old software will consider the chain followed by new versions of
> the software as valid" it's a soft fork. But it doesn't maintain the
> property "old software continues to follow the same chain as new software,
> provided the economic majority has adopted the new software" -- because
> after the PoW part has dropped its difficulty substantitally, people can
> easily/cheaply make a new chain that doesn't include proof-of-burn, and
> has weak proof-of-work that's nevertheless higher than the proof-of-burn
> chain, so old nodes will switch to it, while new nodes will continue to
> follow the proof-of-burn chain.
>
> So I think that means it needs to be treated as a hard fork: everyone
> needs to be running the new software by some date to ensure they follow
> the same chain.
>
> (The same argument applies to trying to switch to a different PoW
> algorithm via a soft fork; I forget who explained this to me)
>
> Jeremy wrote:
> > I think you need to hard deprecate the PoW for this to work, otherwise
> > all old miners are like "toxic waste".
> >
> > Imagine one miner turns on a S9 and then ramps up difficulty for
> > everyone else.
>
> If it's a soft-fork, you could only ramp up the PoW difficulty by mining
> more than one block every ten minutes, but presumably the proof-of-burn
> scheme would have its own way of preventing burners from mining blocks
> too fast (it was assumption 2).
>
> Cheers,
> aj
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[vizeet srivastava via bitcoin-dev]

It is difficult to understand how energy usage is a bad thing.
At one end we talk about energy usage as a bad thing and we also talk about
global warming.
If Earth is receiving extra energy which is causing global warming
shouldn't we use extra energy to do something useful.


On Fri, May 21, 2021 at 2:52 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I think there is a lot of misinformation and bias against Proof of Stake.
> Yes there have been lots of shady coins that use insecure PoS mechanisms.
> Yes there have been massive issues with distribution of PoS coins (of
> course there have also been massive issues with PoW coins as well).
> However, I want to remind everyone that there is a difference between
> "proved to be impossible" and "have not achieved recognized success yet".
> Most of the arguments levied against PoS are out of date or rely on
> unproven assumptions or extrapolation from the analysis of a particular PoS
> system. I certainly don't think we should experiment with bitcoin by
> switching to PoS, but from my research, it seems very likely that there is
> a proof of stake consensus protocol we could build that has substantially
> higher security (cost / capital required to execute an attack) while at the
> same time costing far less resources (which do translate to fees on the
> network) *without* compromising any of the critical security properties
> bitcoin relies on. I think the critical piece of this is the disagreements
> around hardcoded checkpoints, which is a critical piece solving attacks
> that could be levied on a PoS chain, and how that does (or doesn't) affect
> the security model.
>
> @Eric Your proof of stake fallacy seems to be saying that PoS is worse
> when a 51% attack happens. While I agree, I think that line of thinking
> omits important facts:
> * The capital required to 51% attack a PoS chain can be made substantially
> greater than on a PoS chain.
> * The capital the attacker stands to lose can be substantially greater as
> well if the attack is successful.
> * The effectiveness of paying miners to raise the honest fraction of
> miners above 50% may be quite bad.
> * Allowing a 51% attack is already unacceptable. It should be considered
> whether what happens in the case of a 51% may not be significantly
> different. The currency would likely be critically damaged in a 51% attack
> regardless of consensus mechanism.
>
> > Proof-of-stake tends towards oligopolistic control
>
> People repeat this often, but the facts support this. There is no
> centralization pressure in any proof of stake mechanism that I'm aware of.
> IE if you have 10 times as much coin that you use to mint blocks, you
> should expect to earn 10x as much minting revenue - not more than 10x. By
> contrast, proof of work does in fact have clear centralization pressure -
> this is not disputed. Our goal in relation to that is to ensure that the
> centralization pressure remains insignifiant. Proof of work also clearly
> has a lot more barriers to entry than any proof of stake system does. Both
> of these mean the tendency towards oligopolistic control is worse for PoW.
>
> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>
> I certainly agree. Bitcoin's energy usage at the moment is I think quite
> warranted. However, the question is: can we do substantially better. I
> think if we can, we probably should... eventually.
>
> > Proof of Stake is only resilient to ⅓ of the network demonstrating a
> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
>
> I see no mention of this in the pos.pdf
>  you linked to. I'm not
> aware of any proof that *all *PoS systems have a failure threshold of
> 1/3. I know that staking systems like Casper do in fact have that 1/3
> requirement. However there are PoS designs that should exceed that up to
> nearly 50% as far as I'm aware. Proof of work is not in fact resilient up
> to the 1/2 threshold in the way you would think. IE, if 100% of miners are
> currently honest and have a collective 100 exahashes/s hashpower, an
> attacker does not need to obtain 100 exahashes/s, but actually only needs
> to accumulate 50 exahashes/s. This is because as the attacker accumulates
> hashpower, it drives honest miners out of the market as the difficulty
> increases to beyond what is economically sustainable. Also, its been shown
> that the best proof of work can do is require an attacker to obtain 33% of
> the hashpower because of the selfish mining attack
> 
>  discussed
> in depth in this paper: https://arxiv.org/abs/1311.0243. Together, both
> of these things reduce PoW's security by a factor of about 83% (1 -
> 50%*33%).
>
>  > Proof of Stake requires other trade-offs which are incompatible with
> Bitcoin's objective (to be a trustless digital cash) — 

Re: [bitcoin-dev] Opinion on proof of stake in future

[Billy Tetrud via bitcoin-dev]

I think there is a lot of misinformation and bias against Proof of Stake.
Yes there have been lots of shady coins that use insecure PoS mechanisms.
Yes there have been massive issues with distribution of PoS coins (of
course there have also been massive issues with PoW coins as well).
However, I want to remind everyone that there is a difference between
"proved to be impossible" and "have not achieved recognized success yet".
Most of the arguments levied against PoS are out of date or rely on
unproven assumptions or extrapolation from the analysis of a particular PoS
system. I certainly don't think we should experiment with bitcoin by
switching to PoS, but from my research, it seems very likely that there is
a proof of stake consensus protocol we could build that has substantially
higher security (cost / capital required to execute an attack) while at the
same time costing far less resources (which do translate to fees on the
network) *without* compromising any of the critical security properties
bitcoin relies on. I think the critical piece of this is the disagreements
around hardcoded checkpoints, which is a critical piece solving attacks
that could be levied on a PoS chain, and how that does (or doesn't) affect
the security model.

@Eric Your proof of stake fallacy seems to be saying that PoS is worse when
a 51% attack happens. While I agree, I think that line of thinking omits
important facts:
* The capital required to 51% attack a PoS chain can be made substantially
greater than on a PoS chain.
* The capital the attacker stands to lose can be substantially greater as
well if the attack is successful.
* The effectiveness of paying miners to raise the honest fraction of miners
above 50% may be quite bad.
* Allowing a 51% attack is already unacceptable. It should be considered
whether what happens in the case of a 51% may not be significantly
different. The currency would likely be critically damaged in a 51% attack
regardless of consensus mechanism.

> Proof-of-stake tends towards oligopolistic control

People repeat this often, but the facts support this. There is no
centralization pressure in any proof of stake mechanism that I'm aware of.
IE if you have 10 times as much coin that you use to mint blocks, you
should expect to earn 10x as much minting revenue - not more than 10x. By
contrast, proof of work does in fact have clear centralization pressure -
this is not disputed. Our goal in relation to that is to ensure that the
centralization pressure remains insignifiant. Proof of work also clearly
has a lot more barriers to entry than any proof of stake system does. Both
of these mean the tendency towards oligopolistic control is worse for PoW.

> Energy usage, in-and-of-itself, is nothing to be ashamed of!!

I certainly agree. Bitcoin's energy usage at the moment is I think quite
warranted. However, the question is: can we do substantially better. I
think if we can, we probably should... eventually.

> Proof of Stake is only resilient to ⅓ of the network demonstrating a
Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold

I see no mention of this in the pos.pdf
 you linked to. I'm not
aware of any proof that *all *PoS systems have a failure threshold of 1/3.
I know that staking systems like Casper do in fact have that 1/3
requirement. However there are PoS designs that should exceed that up to
nearly 50% as far as I'm aware. Proof of work is not in fact resilient up
to the 1/2 threshold in the way you would think. IE, if 100% of miners are
currently honest and have a collective 100 exahashes/s hashpower, an
attacker does not need to obtain 100 exahashes/s, but actually only needs
to accumulate 50 exahashes/s. This is because as the attacker accumulates
hashpower, it drives honest miners out of the market as the difficulty
increases to beyond what is economically sustainable. Also, its been shown
that the best proof of work can do is require an attacker to obtain 33% of
the hashpower because of the selfish mining attack

discussed
in depth in this paper: https://arxiv.org/abs/1311.0243. Together, both of
these things reduce PoW's security by a factor of about 83% (1 - 50%*33%).

 > Proof of Stake requires other trade-offs which are incompatible with
Bitcoin's objective (to be a trustless digital cash) — specifically the
famous "security vs. liveness" guarantee

Do you have a good source that talks about why you think proof of stake
cannot be used for a trustless digital cash?

> You cannot gain tokens without someone choosing to give up those coins -
a form of permission.

This is not a practical constraint. Just like in mining, some nodes may
reject you, but there will likely be more that will accept you, some
sellers may reject you, but most would accept your money as payment for
bitcoins. I don't think requiring the "permission" 

Re: [bitcoin-dev] Additional BIPs related to other proposals

[Billy Tetrud via bitcoin-dev]

These look like relatively well put together documents. However, they seem
relatively orthogonal to Bitcoin in that they look like protocols that
build on top of the bitcoin platform but aren't directly related to
changing how bitcoin operates at its base layer. Am I miss reading these?

On Sat, Apr 24, 2021 at 12:08 AM Christopher Gilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have created three additional BIPs that are associated with my recent
> proposals. They can be found here:
>
> https://github.com/cgilliard/bips/blob/notification/bip-.mediawiki
>
> and here:
>
> https://github.com/cgilliard/bips/blob/moderation/bip-.mediawiki
>
> and here:
>
> https://github.com/cgilliard/bips/blob/wot/bip-.mediawiki
>
> Please reply with any feedback, questions, or comments.
>
> Regards,
> Chris
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev