> the classical debate with PoS supporters - I explain an attack and they > "patch it", creating problem elsewhere
i agree. my original post was: "assume that we can accurately mimic the investment in ASIC's and the expenditure of electricity with "burns" of coin representing that investment" only given that assumption can i state with confidence: - proof of burn is better than proof of stake and only because - your stake is sitting on a node somewhere, able to be stolen everything else is speculation about my original assumption. overall a good PoB would have a - large, up front buy-in event (buying the ASIC) - delay function (timing) - block-specific burn (electricity use... lost if burn is not selected) - burns linked to specific buy-ins (can only burn the ASIC's i bought in) - max-burn === max-buy-in (ASICs have capacity) - max-burn decays over time (ASIC's become less valuable over time) block-height === sum of block-specific burn On Tue, Jun 1, 2021 at 3:26 PM befreeandopen <befreeando...@protonmail.com> wrote: > > Comments inline. > > > > > > Could you explain what am I missing here, because this actually does not > > > seem better, but rather worse than some PoS schemes? > > > > Given your example, if !BTC is needed to burn, that's a $50k > > investment in an ASIC needed to mine a block. That's not anywhere > > near current levels. It's not even approaching the current PoW. A > > $50k investment to be a large amount of hash power is ... well, > > somewhere more than 10 years ago. > > This is +- true with todays prices, that was not my point. We all know that > today's total block revenue is nowhere near 1 BTC. If it is say 7 BTC, then > we would expect that the miners spend roughly just about 7 BTC to produce the > block - in long term, on average. Right? Today, this 7 BTC is supposed to be > some average of investment into the mining rig, the building in which the rig > exists (or its rent) and then some electricity. So when I said 1 BTC I meant > that amount of BTC that is the sum of the block subsidy and fees at the time > of this imagined switch to PoB. Use 7 BTC if you want to talk today. And yes, > that seems very weak. But can you explain why it is not the case after > switching to PoB that the cost of producing the block should roughly converge > to to the revenue? Because I do not see why would miners spend more than what > they can earn. > > > > > > > My original proof-of-burn concept was designed to mimic ASICs as much > > as possible: > > > > 1. large initial investment (burn to acquire power) > > 2. continued investment (burn to activate power in each block, lost if > > block is not found) > > > > Ideally, the attacker would have to keep burning for each lottery > > ticket, which can only be used once. Committing that burn to a > > particular block for example. > > > > Any attack you propose for a "assumed well designed PoB" can also > > attack PoW. > > Any attack you propose for a "assumed well designed PoB" can also > > attack PoS. > > > > But there are some things PoB can do that PoS can't... which is really > > my original point. > > This is the problem that I wanted to avoid. You refer to some "my original > PoB", but I am strictly talking about the concept described in wiki because > nothing else was provided to me. If we do not have a reference description of > what you are talking about the debate will quickly turn into the classical > debate with PoS supporters - I explain an attack and they "patch it", > creating problem elsewhere. Then I explain an attack against that and they > patch it there. And this goes infinitely. > > So if there is some other version, better one than the one described in wiki, > please let me know. If there is not, there is nothing to talk about really. > You'd first need to define your model properly and describe very details of > how it should work and then we can analyze it. It does not make much sense to > me to analyze a ghost protocol that I always only see a tiny part of. > > For example here above in the quoted text you mention some continual lost (if > block is not found). If that is not the exponential decay as described in the > wiki, then I have no idea what it is. I do not say that I can't imagine for > myself what it could be, but it is up to you to define it, so we can be sure > we are talking about the same thing. > > Same with those early unblinding of burns - nothing about that in the wiki, > so that concept is alien to me and it can not be subject to a debate before > it is precisely described. > > > > > > > > > > - sunk costs/lost investment > > - "hashpower" is "offline", and cannot be seized. > > > > On Tue, Jun 1, 2021 at 4:21 AM befreeandopen > > befreeando...@protonmail.com wrote: > > > > > > > Erik, thanks for the link. So referring to > > > https://en.bitcoin.it/wiki/Proof_of_burn, I do not really understand how > > > this is supposed to be that much better over many proof of stake > > > proposals. If there is more research on PoB, please note I'm not > > > commenting on that as I only read this wiki article and my comments are > > > purely related to this only. > > > I hope we can agree that the idea with manual insertion of entropy every > > > week can be discarded, but at the same time I don't think it is a crucial > > > point of the whole idea. So we can just focus on the rest of it. > > > Then the whole idea seems just like certain proof of stake > > > implementations with just small differences, which I try to summarize: > > > > > > - in PoB, in order to use the coin for block production, you burn it in > > > the past and wait some time -- in the certain PoS I'm talking about, in > > > order to use the coin, you do not move the coin for some time - so in > > > both there is the same idea - you somehow make the coin eligible for the > > > block creation process by first doing some action followed by some > > > inaction for some time; the difference here is that if later you use such > > > coin in PoS, then after waiting more time, you can use the coin again > > > (for whatever purpose), while in PoB the coin is gone forever (it is > > > burned); this does not seem to be fundamentally different > > > > > > - in PoB, the author suggests there is an exponential decay of the > > > power of the coin to create a block; in some PoS schemas, there > > > historically was an era of so called CoinAge mechanism, which was > > > somewhat inverse to this exponential decay, it was that the coin gets > > > more power the older it is untouched, some implementations were for > > > linear increase in the power, some exponential. Usually there was a > > > certain limit - i.e. a maximum power the coin may have reached. It turned > > > out quite quickly that such property is making attacks easier. PoB > > > reverses the idea, but I don't think that helps that much. In any case, > > > there seems to be an optimal period of time for each used coin, in both > > > PoS and PoB, where the coin is most suitable for block production. I > > > admit PoB version is better, but the crucial property here is that some > > > coins are more powerful than other. > > > > > > - in both PoB and PoS it seems there is linear increase of the ability > > > of the coin to produce blocks with the size of the coin (more BTC you > > > burn/stake, the better your chance) > > > > > > > > > This characteristic of PoB does not suggest that it would have that much > > > different properties than PoS. So it should suffer from same problems as > > > PoS. Namely, the problems I see now, with the given proposal from wiki, > > > are: > > > > > > - there seems to be lack of definition of the heaviest chain and > > > difficulty adjustment - this seems crucial, but likely solvable, I'm just > > > saying it is importantly missing in the description > > > > > > - there seems to be a problem with nothing at stake (nothing at burn > > > maybe?) - How that can be? Again, it seems that every burned coin can be > > > used for free checks at any time after the initial waiting period. These > > > free checks are indeed free and are the core of the nothing at stake > > > problem in PoS. You seem to make those checks for free and you seem to be > > > able to use those burned coins to create arbitrary number of forks build > > > on any parent blocks of your choice, not just the last block of the > > > heaviest chain. I can't see at the moment how is this different from PoS > > > nothing at stake problem. Maybe you can explain? > > > > > > - it seems to me that there is a trivial attack against the scheme by a > > > wealthy attacker. Suppose a common size of the burn is 1 BTC per block, > > > suppose you define the heaviest chain rule somehow in relation to total > > > number of burned coins or the cumulative "strength" of the "lowest" > > > hashes, then you can just burn 20 UTXOs, each being 10 BTC in value, so > > > you spent 200 BTC on this attack, but you are in very strong position > > > because after you wait the needed time, you should be able to do pretty > > > nasty reorg. Suppose that the main chain is A-B-C-D-E-F, so what you do > > > at that point is that you just "try for free" all your 20 UTXOs, whether > > > or not they can build on top of block A (which has 5 confs on top, F is > > > the tip of the main chain). Since you have big UTXOs, your chances should > > > be good, of course you can always try many times because you have a > > > "lottery ticket" for every timestampt t. So with this you should be able, > > > with good chance, to find such B' and then you have 19 UTXOs remaining to > > > try to build on B' in the same way. I can't see what prevents this attack > > > in the described scheme. > > > > > > - the ability to retroactively try all different kids of timestamp t > > > seems devastating - you again get super easy and somewhat cheap attack > > > (due to nothing at burn problem) that allows you to rewrite even long > > > chains at will. > > > > > > > > > Could you explain what am I missing here, because this actually does not > > > seem better, but rather worse than some PoS schemes? > > > Sent with ProtonMail Secure Email. > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > > On Friday, May 28, 2021 9:06 PM, Erik Aronesty e...@q32.com wrote: > > > > > > > best writeup i know of is here: > > > > https://en.bitcoin.it/wiki/Proof_of_burn > > > > no formal proposals or proofs that i know of. > > > > On Fri, May 28, 2021 at 10:40 AM befreeandopen > > > > 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
