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