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 <befreeando...@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 <befreeando...@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 <e...@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.tet...@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 <e...@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.tet...@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 <e...@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 Praos[3] with >>> >> >> > an inbuilt on-chain delegation system[5]. >>> >> >> > 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's[4] 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. >>> >> >> > >>> >> >> > [1]: >>> >> >> > https://developer.algorand.org/docs/run-a-node/participate/generate_keys/ >>> >> >> > [2]: https://staking.staked.us/algorand-staking >>> >> >> > [3]: https://eprint.iacr.org/2017/573.pdf >>> >> >> > [4]: >>> >> >> > https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf >>> >> >> > [5]: >>> >> >> > https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf >>> >> >> > >>> >> >> > 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 >>> >> >> >>> <m...@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 >>> >> >> >>>>> <zach...@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 >>> >> >> >>>>> > <zmnsc...@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 >> >> > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
