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 <befreeando...@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 <e...@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 > > 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 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 > > > > > > > > > > > > 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
