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

[Billy Tetrud <billy.tetrud@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 47948 bytes --]

@befreeandopen   "If you want to make some arbitrary very narrow
definitions of what nothing at stake is so that you can claim your false
statement that it is a solved problem"

Wow, you are really unnecessarily hostile. This isn't r/bitcoin my friend.
Please assume some good faith. I simply pointed out my misunderstanding.
But it sounds like you're not willing to explain yourself clearly nor
actually have a reasoned discussion and prefer to insult me. So I think our
conversation is indeed over.

On Fri, May 28, 2021 at 10:06 AM Erik Aronesty <erik@q32.com> wrote:

> best writeup i know of is here:
>
> https://en.bitcoin.it/wiki/Proof_of_burn
>
> no formal proposals or proofs that i know of.
>
> On Fri, May 28, 2021 at 10:40 AM befreeandopen
> <befreeandopen@protonmail.com> wrote:
> >
> > Erik, I am sorry, I have little knowledge about proof-of-burn, I never
> found it interesting up until now. Some of your recent claims seem quite
> strong to me and I'd like to read more.
> >
> > Forgive me if this has been mentioned recently, but is there a full
> specification of the concept you are referring to? I don't mean just the
> basic idea description (that much is clear to me), I mean a fully detailed
> proposal or technical documentation that would give me a precise
> information about what exactly it is that you are talking about.
> >
> >
> > Sent with ProtonMail Secure Email.
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Wednesday, May 26, 2021 11:07 PM, Erik Aronesty <erik@q32.com> wrote:
> >
> > > note: the "nothing at stake" problem you propose is not broken for
> > > proof-of-burn, because the attacker
> > >
> > > a) has no idea which past transactions are burns
> > > b) has no way to use his mining power, even 5%, to maliciously improve
> > > his odds of being selected
> > >
> > > On Wed, May 26, 2021 at 9:12 AM befreeandopen
> > > befreeandopen@protonmail.com wrote:
> > >
> > > > @befreeandopen I guess I misunderstood your selfish minting attack.
> Let me make sure I understand it. You're saying it would go as follows?:
> > > >
> > > > 1.  The malicious actor comes across an opportunity to mint the next
> 3 blocks. But they hold off and don't release their blocks just yet.
> > > > 2.  They receive a new block minted by someone else.
> > > > 3.  The malicious actor then chooses to release their other 2 blocks
> on on the second from the top block if it gives them more blocks in the
> future than minting on the top block. And instead lets the top block
> proceed if it gives them more blocks in the future (also figuring in the 3
> blocks they're missing out on minting).
> > > > 4.  Profit!
> > > >
> > > > The problem with this attack is that any self respecting PoS system
> wouldn't have the information available for minters to know how blocks will
> affect their future prospects of minting. Otherwise this would introduce
> the problem of stake grinding. This can be done using collaborative
> randomness (where numbers from many parties are combined to create a random
> number that no individual party could predict). In fact, that's what the
> Casper protocol does to decide quorums. In a non quorum case, you can do
> something like record a hash of a number in the block header, and then have
> a second step to release that number later. Rewards can be given can be
> used to ensure minters act honestly here by minting messages that release
> these numbers and not releasing their secret numbers too early.
> > > > Yes, you misunderstood it. First, let me say that the above thoughts
> of yours are incorrect, at least for non-quorum case. Since the transition
> in the blockchain system from S1 to S2 is only by adding new block, and
> since stakers always need to be able to decide whether or not they can add
> the next block, it follows that if a staker creates a new block locally,
> she can decide whether the new state allows her to add another block on
> top. As you mentioned, this COULD introduce problem of staking, that you
> are incorrect in that it is a necessity. Usual prevention of the grinding
> problem in this case is that an "old enough" source of randomness applies
> for the current block production process. Of course this, as it is typical
> for PoS, introduces other problems, but let's discard those.
> > > > I will try to explain in detail what you misunderstood before. You
> start with a chain ending with blocks A-B-C, C being the top, the common
> feature of PoS system (non-quorum), roughly speaking, is that if N is the
> total amount of coins that participate in the staking process to create a
> new block on top of C (let's call that D), then a participant having K*N
> amount of stake has chance K to be the one who will create the next stake.
> In other words, the power of stakers is supposed to be linear in the system
> - you own 10 coins gives you 10x the chance of finding block over someone
> who has 1 coin.
> > > > What i was claiming is that using the technique I have described,
> this linearity is violated. Why? Well, it works for honest stakers among
> the competition of honest stakers - they really do have the chance of K to
> find the next block. However, the attacker, using nothing at stake, checks
> her ability to build block D (at some timestamp). If she is successful, she
> does not propagate D immediately, but instead she also checks whether she
> can build on top of B and on top of A. Since with every new timestamp,
> usually, there is a new chance to build the block, it is not uncommon that
> she finds she is indeed able to build such block C' on top of B. Here it is
> likely t(C') > t(C) as the attacker has relatively low stake. Note that in
> order to produce such C', she not only could have tried the current
> timestamp t(D), but also all previous timestamps up to t(B) (usually that's
> the consensus rule, but it may depend on a specific consensus). So her
> chance to produce such C' is greater than her previous chance of producing
> C (which chance was limited by other stakers in the system and the
> discovery of block C by one of them). Now suppose that she found such C'
> and now she continues by trying to prolong this chain by finding D'. And
> again here, it is quite likely that her chance to find such D' is greater
> than was her chance of finding D because again there are likely multiple
> timestamps she could try. This all was possible just because nothing at
> stake allows you to just try if you can produce a block in certain state of
> block chain or not. Now if she actually was able to find D', she discards D
> and only publishes chain A-B-C'-D', which can not be punished despite the
> fact that she indeed produced two different forks. She can not be punished
> because this production was local and only the final result of A-B-C'-D'
> was published, in which case she gained an extra block over the honest
> strategy which would only give her block D.
> > > > Fun fact tho: there is an attack called the "selfish mining attack"
> for proof of work, and it reduces the security of PoW by at least 1/3rd.
> > > > How is that relevant to our discussion? This is known research that
> has nothing to do with PoS except that it is often worse on PoS.
> > > >
> > > > > the problem is not as hard as you think
> > > >
> > > > I don't claim to know just how hard finding the IP address
> associated with a bitcoin address is. However, the DOS risk can be solved
> more completely by only allowing the owner of coins themselves to know
> whether they can mint a block. Eg by determining whether someone can mint a
> block based on their public key hidden behind hashes (as normal in
> addresses). Only when someone does in fact mint a block do they reveal
> their hidden public key in order to prove they are allowed to mint the
> block.
> > > > This is true, but you are mixing quorum and non-quorum systems. My
> objection here was towards such system where I specifically said that the
> list of producers for next epoch is known up front and you confirmed that
> this is what you meant with "quorum" system. So in such system, I claimed,
> the known producer is the only target at any given point of time. This of
> course does not apply to any other type of system where future producers
> are not known. No need to dispute, again, something that was not claimed.
> > > >
> > > > > I agree that introduction of punishment itself does not imply
> introducing a problem elsewhere (which I did not claim if you reread my
> previous message)
> > > >
> > > > I'm glad we agree there. Perhaps I misunderstood what you meant by
> "you should not omit to mention that by doing so, typically, you have
> introduced another problem elsewhere."
> > > > Perhaps you should quote the full sentence and not just a part of it:
> > > > "Of course you can always change the rules in a way that a certain
> specific attack is not doable, but you should not omit to mention that by
> doing so, typically, you have introduced another problem elsewhere, or you
> have not solved it completely."
> > > > You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT
> COMPLETELY)
> > > > In case of the punishment it was meant to be the not solve it
> completely part.
> > > > Also "typically" does not imply always.
> > > > But this parsing of English sentences for you seems very off topic
> here. My point is, in context of Bitcoin, reject such unsupported claims
> that PoS is a reasonable alternative to PoW, let's stick to that.
> > > >
> > > > > As long as the staker makes sure (which is not that hard) that she
> does not miss a chance to create a block, her significance in the system
> will always increase in time. It will increase relative to all normal users
> who do not stake
> > > >
> > > > Well, if you're in the closed system of the cryptocurrency, sure.
> But we don't live in that closed system. Minters will earn some ROI from
> minting just like any other financial activity. Others may find more
> success spending their time doing things other than figuring out how to
> mint coins. In that case, they'll be able to earn more coin that they could
> later decide to use to mint blocks if they decide to.
> > > > This only supports the point I was making. Since the optimal
> scenario with all existing coins participating is just theoretical, the
> attacker's position will ever so improve. It seems we are in agreement
> here, great.
> > > >
> > > > > Just because of the above we must reject PoS as being critically
> insecure
> > > >
> > > > I think the only thing we can conclude from this is that you have
> come up with an insecure proof of stake protocol. I don't see how anything
> you've brought up amounts to substantial evidence that all possible PoS
> protocols are insecure.
> > > > I have not come up with anything. I'm afraid you've not realized the
> burden of proof is on your side if you vouch for a design that is not
> believed and trusted to be secure. It is up to you to show that you know
> how to solve every problem that people throw at you. So far we have just
> demonstrated that your claim that nothing at stake is solved was
> unjustified. You have not described a system that would solve it (and not
> introduce critical DDOS attack vector as it is in quorum based systems -
> per the prior definition of such systems).
> > > > Of course the list of problems of PoS systems do not end with just
> nothing at stake, but it is good enough example that by itself prevents its
> adoption in decentralized consensus. No need to go to other hard problems
> without solving nothing at stake.
> > > > On Tue, May 25, 2021 at 11:10 AM befreeandopen
> befreeandopen@protonmail.com wrote:
> > > >
> > > > > @befreeandopen " An attacker can calculate whether or not she can
> prolong this chain or not and if so with what timestamp."
> > > > > The scenario you describe would only be likely to happen at all if
> the malicious actor has a very large fraction of the stake - probably quite
> close to 50%. At that point, you're talking about a 51% attack, not the
> nothing at stake problem. The nothing at stake problem is the problem where
> anyone will mint on any chain. Its clear that if there's a substantial
> punishment for minting on chains other than the one that eventually wins,
> every minter without a significant fraction of the stake will be honest and
> not attempt to mint on old blocks or support someone else's attempt to mint
> on old blocks (until and if it becomes the heaviest chain). Because the
> attacker would need probably >45% of the active stake (take a look at the
> reasoning here for a deeper analysis of that statement), I don't agree that
> punishment is not a sufficient mitigation of the nothing at stake problem.
> To exploit the nothing at stake problem, you basically need to 51% attack,
> at which point you've exceeded the operating conditions of the system, so
> of course its gonna have problems, just like a 51% attack would cause with
> PoW.
> > > > > This is not at all the case. The attacker benefits using the
> described technique at any size of the stake and significantly so with just
> 5% of the stake. By significantly, I do not mean that the attacker is able
> to completely take control the network (in short term), but rather that the
> attacker has significant advantage in the number of blocks she creates
> compared to what she "should be able to create". This means the attacker's
> stake increases significantly faster than of the honest nodes, which in
> long term is very serious in PoS system. If you believe close to 50% is
> needed for that, you need to redo your math. So no, you are wrong stating
> that "to exploit nothing at stake problem you basically need to 51%
> attack". It is rather the opposite - eventually, nothing at stake attack
> leads to ability to perform 51% attack.
> > > > >
> > > > > > I am not sure if this is what you call quorum-based PoS
> > > > >
> > > > > Yes, pre-selected minters is exactly what I mean by that.
> > > > >
> > > > > > it allows the attacker to know who to attack at which point with
> powerful DDOS in order to hurt liveness of such system
> > > > >
> > > > > Just like in bitcoin, associating keys with IP addresses isn't
> generally an easy thing to do on the fly like that. If you know someone's
> IP address, you can target them. But if you only know their address or
> public key, the reverse isn't as easy. With a quorum-based PoS system, you
> can see their public key and address, but finding out their IP to DOS would
> be a huge challenge I think.
> > > > > I do not dispute that the problem is not trivial, but the problem
> is not as hard as you think. The network graph analysis is a known
> technique and it is not trivial, but not very hard either. Introducing a
> large number of nodes to the system to achieve very good success rate of
> analysis of area of origin of blocks is doable and has been done in past.
> So again, I very much disagree with your conclusion that this is somehow
> secure. It is absolutely insecure.
> > > > > Note, tho, that quorum-based PoS generally also have punishments
> as part of the protocol. The introduction of punishments do indeed handily
> solve the nothing at stake problem. And you didn't mention a single problem
> that the punishments introduce that weren't already there before
> punishments. There are tradeoffs with introducing punishments (eg in some
> cases you might punish honest actors), but they are minor in comparison to
> solving the nothing at stake problem.
> > > > > While I agree that introduction of punishment itself does not
> imply introducing a problem elsewhere (which I did not claim if you reread
> my previous message), it does introduce additional complexity which may
> introduce problem, but more importantly, while it slightly improves
> resistance against the nothing at stake attack, it solves absolutely
> nothing. Your claim is based on wrong claim of needed close to 50% stake,
> but that could not be farther from the truth. It is not true even in
> optimal conditions when all participants of the network stake or delegate
> their stake. These optimal conditions rarely, if ever, occur. And that's
> another thing that we have not mention in our debate, so please allow me to
> introduce another problem to PoS.
> > > > > Consider what is needed for such optimal conditions to occur - all
> coins are always part of the stake, which means that they need to somehow
> automatically part of the staking process even when they are moved. But in
> many PoS systems you usually require some age (in terms of confirmations)
> of the coin before you allow it to be used for participation in staking
> process and that is for a good reason - to prevent various grinding
> attacks. In some systems the coin must be specifically registered before it
> can be staked, in others, simply waiting for enough confirmations enables
> you to stake with the coin. I am not sure if there is a system which does
> not have this cooling period for a coin that has been moved. Maybe it is
> possible though, but AFAIK it is not common and not battle tested feature.
> > > > > Then if we admit that achieving the optimal condition is rather
> theoretical. Then if we do not have the optimal condition, it means that a
> staker with K% of the total available supply increases it's percentage over
> time to some amounts >K%. As long as the staker makes sure (which is not
> that hard) that she does not miss a chance to create a block, her
> significance in the system will always increase in time. It will increase
> relative to all normal users who do not stake (if there are any) and
> relative to all other stakers who make mistakes or who are not wealthy
> enough to afford not selling any position ever. But powerful attacker is
> exactly in such position and thus she will gain significance in such a
> system. The technique I have described, and that you mistakenly think is
> viable only with huge amounts of stake, only puts the attacker to even
> greater advantage. But even without the described attack (which exploits
> nothing at stake), the PoS system converges to a system more and more
> controlled by powerful entity, which we can assume is the attacker.
> > > > > So I don't think it is at all misleading to claim that "nothing at
> stake" is a solved problem. I do in fact mean that the solutions to that
> problem don't introduce any other problems with anywhere near the same
> level of significance.
> > > > > It still stands as truly misleading claim. I disagree that
> introducing DDOS opportunity with medium level of difficulty for the
> attacker to implement it, in case of "quorum-based PoS" is not a problem
> anywhere near the same level of significance. Such an attack vector allows
> you to turn off the network if you spend some time and money. That is
> hardly acceptable.
> > > > > Just because of the above we must reject PoS as being critically
> insecure until someone invents and demonstrates an actual way of solving
> these issues.
> > > > > On Tue, May 25, 2021 at 3:00 AM Erik Aronesty erik@q32.com wrote:
> > > > >
> > > > > > > > you burn them to be used at a future particular block height
> > > > > >
> > > > > > > This sounds exploitable. It seems like an attacker could
> simply focus all their burns on a particular set of 6 blocks to double
> spend, minimizing their cost of attack.
> > > > > >
> > > > > > could be right. the original idea was to have burns decay over
> time,
> > > > > > like ASIC's.
> > > > > > anyway the point was not that "i had a magic formula"
> > > > > > the point was that proof of burn is almost always better than
> proof of
> > > > > > stake - simply because the "proof" is on-chain, not sitting on a
> node
> > > > > > somewhere waiting to be stolen.
> > > > > > On Mon, May 24, 2021 at 9:53 PM Billy Tetrud
> billy.tetrud@gmail.com wrote:
> > > > > >
> > > > > > > Is this the kind of proof of burn you're talking about?
> > > > > > >
> > > > > > > > if i have a choice between two chains, one longer and one
> shorter, i can only choose one... deterministically
> > > > > > >
> > > > > > > What prevents you from attempting to mine block 553 on both
> chains?
> > > > > > >
> > > > > > > > miners have a very strong, long-term, investment in the
> stability of the chain.
> > > > > > >
> > > > > > > Yes, but the same can be said of any coin, even ones that do
> have the nothing at stake problem. This isn't sufficient tho because the
> chain is a common good, and the tragedy of the commons holds for it.
> > > > > > >
> > > > > > > > you burn them to be used at a future particular block height
> > > > > > >
> > > > > > > This sounds exploitable. It seems like an attacker could
> simply focus all their burns on a particular set of 6 blocks to double
> spend, minimizing their cost of attack.
> > > > > > >
> > > > > > > > i can imagine scenarios where large stakeholders can collude
> to punish smaller stakeholders simply to drive them out of business, for
> example
> > > > > > >
> > > > > > > Are you talking about a 51% attack? This is possible in any
> decentralized cryptocurrency.
> > > > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik@q32.com
> wrote:
> > > > > > >
> > > > > > > > > > your burn investment is always "at stake", any redaction
> can result in a loss-of-burn, because burns can be tied, precisely, to
> block-heights
> > > > > > > > > > I'm fuzzy on how proof of burn works.
> > > > > > > >
> > > > > > > > when you burn coins, you burn them to be used at a future
> particular
> > > > > > > > block height: so if i'm burning for block 553, i can only
> use them to
> > > > > > > > mine block 553. if i have a choice between two chains, one
> longer
> > > > > > > > and one shorter, i can only choose one... deterministically,
> for that
> > > > > > > > burn: the chain with the height 553. if we fix the "lead
> time" for
> > > > > > > > burned coins to be weeks or even months in advance, miners
> have a very
> > > > > > > > strong, long-term, investment in the stability of the chain.
> > > > > > > > therefore there is no "nothing at stake" problem. it's
> > > > > > > > deterministic, so miners have no choice. they can only
> choose the
> > > > > > > > transactions that go into the block. they cannot choose
> which chain
> > > > > > > > to mine, and it's time-locked, so rollbacks and instability
> always
> > > > > > > > hurt miners the most.
> > > > > > > > the "punishment" systems of PoS are "weird at best",
> certainly
> > > > > > > > unproven. i can imagine scenarios where large stakeholders
> can
> > > > > > > > collude to punish smaller stakeholders simply to drive them
> out of
> > > > > > > > business, for example. and then you have to put checks in
> place to
> > > > > > > > prevent that, and more checks for those prevention system...
> > > > > > > > in PoB, there is no complexity. simpler systems like this are
> > > > > > > > typically more secure.
> > > > > > > > PoB also solves problems caused by "energy dependence",
> which could
> > > > > > > > lead to state monopolies on mining (like the new Bitcoin
> Mining
> > > > > > > > Council). these consortiums, if state sanctioned, could
> become a
> > > > > > > > source of censorship, for example. Since PoB doesn't require
> you to
> > > > > > > > have a live, well-connected node, it's harder to censor &
> harder to
> > > > > > > > trace.
> > > > > > > > Eliminating this weakness seems to be in the best interests
> of
> > > > > > > > existing stakeholders
> > > > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud
> billy.tetrud@gmail.com wrote:
> > > > > > > >
> > > > > > > > > > proof of burn clearly solves this, since nothing is held
> online
> > > > > > > > >
> > > > > > > > > Well.. the coins to be burned need to be online when
> they're burned. But yes, only a small fraction of the total coins need to
> be online.
> > > > > > > > >
> > > > > > > > > > your burn investment is always "at stake", any redaction
> can result in a loss-of-burn, because burns can be tied, precisely, to
> block-heights
> > > > > > > > >
> > > > > > > > > So you're saying that if say someone tries to mine a block
> on a shorter chain, that requires them to send a transaction burning their
> coins, and that transaction could also be spent on the longest chain, which
> means their coins are burned even if the chain they tried to mine on
> doesn't win? I'm fuzzy on how proof of burn works.
> > > > > > > > >
> > > > > > > > > > proof of burn can be more secure than proof-of-stake
> > > > > > > > >
> > > > > > > > > FYI, proof of stake can be done without the "nothing at
> stake" problem. You can simply punish people who mint on shorter chains (by
> rewarding people who publish proofs of this happening on the main chain).
> In quorum-based PoS, you can punish people in the quorum that propose or
> sign multiple blocks for the same height. The "nothing at stake" problem is
> a solved problem at this point for PoS.
> > > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik@q32.com
> wrote:
> > > > > > > > >
> > > > > > > > > > > I don't see a way to get around the conflicting
> requirement that the keys for large amounts of coins should be kept offline
> but those are exactly the coins we need online to make the scheme secure.
> > > > > > > > > >
> > > > > > > > > > proof of burn clearly solves this, since nothing is held
> online
> > > > > > > > > >
> > > > > > > > > > > how does proof of burn solve the "nothing at stake"
> problem in your view?
> > > > > > > > > >
> > > > > > > > > > definition of nothing at stake: in the event of a fork,
> whether the
> > > > > > > > > > fork is accidental or a malicious, the optimal strategy
> for any miner
> > > > > > > > > > is to mine on every chain, so that the miner gets their
> reward no
> > > > > > > > > > matter which fork wins. indeed in proof-of-stake, the
> proofs are
> > > > > > > > > > published on the very chains mines, so the incentive is
> magnified.
> > > > > > > > > > in proof-of-burn, your burn investment is always "at
> stake", any
> > > > > > > > > > redaction can result in a loss-of-burn, because burns
> can be tied,
> > > > > > > > > > precisely, to block-heights
> > > > > > > > > > as a result, miners no longer have an incentive to mine
> all chains
> > > > > > > > > > in this way proof of burn can be more secure than
> proof-of-stake, and
> > > > > > > > > > even more secure than proof of work
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via
> bitcoin-dev
> > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Billy,
> > > > > > > > > > > I was going to write a post which started by
> dismissing many of the weak arguments that are made against PoS made in
> this thread and elsewhere.
> > > > > > > > > > > Although I don't agree with all your points you have
> done a decent job here so I'll focus on the second part: why I think
> Proof-of-Stake is inappropriate for a Bitcoin-like system.
> > > > > > > > > > > Proof of stake is not fit for purpose for a global
> settlement layer in a pure digital asset (i.e. "digital gold") which is
> what Bitcoin is trying to be.
> > > > > > > > > > > PoS necessarily gives responsibilities to the holders
> of coins that they do not want and cannot handle.
> > > > > > > > > > > In Bitcoin, large unsophisticated coin holders can put
> their coins in cold storage without a second thought given to the health of
> the underlying ledger.
> > > > > > > > > > > As much as hardcore Bitcoiners try to convince them to
> run their own node, most don't, and that's perfectly acceptable.
> > > > > > > > > > > At no point do their personal decisions affect the
> underlying consensus -- it only affects their personal security assurance
> (not that of the system itself).
> > > > > > > > > > > In PoS systems this clean separation of
> responsibilities does not exist.
> > > > > > > > > > > I think that the more rigorously studied PoS protocols
> will work fine within the security claims made in their papers.
> > > > > > > > > > > People who believe that these protocols are destined
> for catastrophic consensus failure are certainly in for a surprise.
> > > > > > > > > > > But the devil is in the detail.
> > > > > > > > > > > Let's look at what the implications of using the
> leading proof of stake protocols would have on Bitcoin:
> > > > > > > > > > >
> > > > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot)
> > > > > > > > > > >
> > > > > > > > > > > Cardano is a UTXO based PoS coin based on Ouroboros
> Praos3 with an inbuilt on-chain delegation system5.
> > > > > > > > > > > In these protocols, coin holders who do not want to
> run their node with their hot keys in it delegate it to a "Stake Pool".
> > > > > > > > > > > I call the resulting system Proof-of-SquareSpace since
> most will choose a pool by looking around for one with a nice website and
> offering the largest share of the block reward.
> > > > > > > > > > > On the surface this might sound no different than
> someone with an mining rig shopping around for a good mining pool but there
> are crucial differences:
> > > > > > > > > > >
> > > > > > > > > > > 1.  The person making the decision is forced into it
> just because they own the currency -- someone with a mining rig has
> purchased it with the intent to make profit by participating in consensus.
> > > > > > > > > > >
> > > > > > > > > > > 2.  When you join a mining pool your systems are very
> much still online. You are just partaking in a pool to reduce your profit
> variance. You still see every block that you help create and you never help
> create a block without seeing it first.
> > > > > > > > > > >
> > > > > > > > > > > 3.  If by SquareSpace sybil attack you gain a
> dishonest majority and start censoring transactions how are the users meant
> to redelegate their stake to honest pools?
> > > > > > > > > > >     I guess they can just send a transaction
> delegating to another pool...oh wait I guess that might be censored too!
> This seems really really bad.
> > > > > > > > > > >     In Bitcoin, miners can just join a different pool
> at a whim. There is nothing the attacker can do to stop them. A temporary
> dishonest majority heals relatively well.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > There is another severe disadvantage to this on-chain
> delegation system: every UTXO must indicate which staking account this UTXO
> belongs to so the appropriate share of block rewards can be transferred
> there.
> > > > > > > > > > > Being able to associate every UTXO to an account ruins
> one of the main privacy advantages of the UTXO model.
> > > > > > > > > > > It also grows the size of the blockchain significantly.
> > > > > > > > > > >
> > > > > > > > > > > ### "Pure" proof of stake (Algorand)
> > > > > > > > > > >
> > > > > > > > > > > Algorand's4 approach is to only allow online stake to
> participate in the protocol.
> > > > > > > > > > > Theoretically, This means that keys holding funds have
> to be online in order for them to author blocks when they are chosen.
> > > > > > > > > > > Of course in reality no one wants to keep their coin
> holding keys online so in Alogorand you can authorize a set of
> "participation keys"1 that will be used to create blocks on your coin
> holding key's behalf.
> > > > > > > > > > > Hopefully you've spotted the problem.
> > > > > > > > > > > You can send your participation keys to any malicious
> party with a nice website (see random example 2) offering you a good return.
> > > > > > > > > > > Damn it's still Proof-of-SquareSpace!
> > > > > > > > > > > The minor advantage is that at least the participation
> keys expire after a certain amount of time so eventually the SquareSpace
> attacker will lose their hold on consensus.
> > > > > > > > > > > Importantly there is also less junk on the blockchain
> because the participation keys are delegated off-chain and so are not
> making as much of a mess.
> > > > > > > > > > >
> > > > > > > > > > > ### Conclusion
> > > > > > > > > > >
> > > > > > > > > > > I don't see a way to get around the conflicting
> requirement that the keys for large amounts of coins should be kept offline
> but those are exactly the coins we need online to make the scheme secure.
> > > > > > > > > > > If we allow delegation then we open up a new social
> attack surface and it degenerates to Proof-of-SquareSpace.
> > > > > > > > > > > For a "digital gold" like system like Bitcoin we
> optimize for simplicity and desperately want to avoid extraneous
> responsibilities for the holder of the coin.
> > > > > > > > > > > After all, gold is an inert element on the periodic
> table that doesn't confer responsibilities on the holder to maintain the
> quality of all the other bars of gold out there.
> > > > > > > > > > > Bitcoin feels like this too and in many ways is more
> inert and beautifully boring than gold.
> > > > > > > > > > > For Bitcoin to succeed I think we need to keep it that
> way and Proof-of-Stake makes everything a bit too exciting.
> > > > > > > > > > > I suppose in the end the market will decide what is
> real digital gold and whether these bad technical trade offs are worth
> being able to say it uses less electricity. It goes without saying that
> making bad technical decisions to appease the current political climate is
> an anathema to Bitcoin.
> > > > > > > > > > > Would be interested to know if you or others think
> differently on these points.
> > > > > > > > > > > Cheers,
> > > > > > > > > > > LL
> > > > > > > > > > > On Fri, 21 May 2021 at 19:21, 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) —
> 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" of one of
> millions of people in the market can be reasonably considered a
> "permissioned currency".
> > > > > > > > > > > >
> > > > > > > > > > > > > 2.  Proof of stake must have a trusted means of
> timestamping to regulate overproduction of blocks
> > > > > > > > > > > >
> > > > > > > > > > > > Both PoW and PoS could mine/mint blocks twice as
> fast if everyone agreed to double their clock speeds. Both systems rely on
> an honest majority sticking to standard time.
> > > > > > > > > > > > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky
> via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Ah sorry, I didn't realize this was, in fact, a
> different thread! :)
> > > > > > > > > > > > > On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky
> mike@powx.org wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Folks, I suggest we keep the discussion to PoW,
> oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess
> there are other threads going on these topics already where they would be
> relevant.
> > > > > > > > > > > > > > Also, it's important to distinguish between oPoW
> and these other "alternatives" to Hashcash. oPoW is a true Proof of Work
> that doesn't alter the core game theory or security assumptions of Hashcash
> and actually contains SHA (can be SHA3, SHA256, etc hash is
> interchangeable).
> > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > Mike
> > > > > > > > > > > > > > On Tue, May 18, 2021 at 4:55 PM Erik Aronesty
> via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1.  i never suggested vdf's to replace pow.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2.  my suggestion was specifically in the
> context of a working
> > > > > > > > > > > > > > >     proof-of-burn protocol
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   vdfs used only for timing (not block
> height)
> > > > > > > > > > > > > > > -   blind-burned coins of a specific age used
> to replace proof of work
> > > > > > > > > > > > > > > -   the required "work" per block would simply
> be a competition to
> > > > > > > > > > > > > > >     acquire rewards, and so miners would have
> to burn coins, well in
> > > > > > > > > > > > > > >     advance, and hope that their burned coins
> got rewarded in some far
> > > > > > > > > > > > > > >     future
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   the point of burned coins is to mimic, in
> every meaningful way, the
> > > > > > > > > > > > > > >     value gained from proof of work... without
> some of the security
> > > > > > > > > > > > > > >     drawbacks
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   the miner risks losing all of his burned
> coins (like all miners risk
> > > > > > > > > > > > > > >     losing their work in each block)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   new burns can't be used
> > > > > > > > > > > > > > > -   old burns age out (like ASICs do)
> > > > > > > > > > > > > > > -   other requirements on burns might be
> needed to properly mirror the
> > > > > > > > > > > > > > >     properties of PoW and the incentives
> Bitcoin uses to mine honestly.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3.  i do believe it is possible that a "burned
> coin + vdf system"
> > > > > > > > > > > > > > >     might be more secure in the long run, and
> that if the entire space
> > > > > > > > > > > > > > >     agreed that such an endeavor was
> worthwhile, a test net could be spun
> > > > > > > > > > > > > > >     up, and a hard-fork could be initiated.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 4.  i would never suggest such a thing unless
> i believed it was
> > > > > > > > > > > > > > >     possible that consensus was possible. so
> no, this is not an "alt
> > > > > > > > > > > > > > >     coin"
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, May 18, 2021 at 10:02 AM Zac Greenwood
> zachgrw@gmail.com wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi ZmnSCPxj,
> > > > > > > > > > > > > > > > Please note that I am not suggesting VDFs as
> a means to save energy, but solely as a means to make the time between
> blocks more constant.
> > > > > > > > > > > > > > > > Zac
> > > > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj
> ZmnSCPxj@protonmail.com wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Good morning Zac,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > VDFs might enable more constant block
> times, for instance by having a two-step PoW:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 1.  Use a VDF that takes say 9 minutes
> to resolve (VDF being subject to difficulty adjustments similar to the
> as-is). As per the property of VDFs, miners are able show proof of work.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2.  Use current PoW mechanism with lower
> difficulty so finding a block takes 1 minute on average, again subject to
> as-is difficulty adjustments.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > As a result, variation in block times
> will be greatly reduced.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As I understand it, another weakness of
> VDFs is that they are not inherently progress-free (their sequential nature
> prevents that; they are inherently progress-requiring).
> > > > > > > > > > > > > > > > > Thus, a miner which focuses on improving
> the amount of energy that it can pump into the VDF circuitry (by
> overclocking and freezing the circuitry), could potentially get into a
> winner-takes-all situation, possibly leading to even worse competition and
> even more energy consumption.
> > > > > > > > > > > > > > > > > After all, if you can start mining 0.1s
> faster than the competition, that is a 0.1s advantage where only you can
> mine in the entire world.
> > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > ZmnSCPxj
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > > > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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
> > > > > > > > > > >
> > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 60224 bytes --]