From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4DADBC0001 for ; Fri, 28 May 2021 20:06:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1D6A8608E7 for ; Fri, 28 May 2021 20:06:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KKwwN6Bafof for ; Fri, 28 May 2021 20:06:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4BDCA606B9 for ; Fri, 28 May 2021 20:06:30 +0000 (UTC) Received: by mail-pg1-x52f.google.com with SMTP id l70so3370433pga.1 for ; Fri, 28 May 2021 13:06:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=V3te8wo1CKycNpzBXk0SbIsAf+f+PO0TAzs1kkJ4+Yg=; b=QsQv7B21Wnwz0d91UkW3+nUcP7jaxgI8k2tEqhSVcyWs0pemJJGIp5jZOktKyCZftB ksh5N06r1rmCnk9KQ2wnIKjNb5Itx10V0g6duNJFWVHO4vtqp4SogEzy8MtmKAQgvdzB NtqC6FyPXCzD4zA1oSxVIxhY/J4paJQR4PHxIdZQnwnVJEs6oiRWxylzrxkCQ29XveDR Qz2TXKEojk06wKyKdA9tVvX8JvpBrAl8PshjxZhoT9Rh/MRK3uA1Vj97cpsqOVkVeJZt E3V4qQvuCBSPh5PhA1Hzmv4+nNbofrF+ibNZm8GnC10Mdg3VsnSGVuz2LJboHkKPQZUz MVVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=V3te8wo1CKycNpzBXk0SbIsAf+f+PO0TAzs1kkJ4+Yg=; b=b1DvBg4FXOOWwyA2avhqYv8baIMfT3rNvU9KGezC1iGSzKDzbfhfuTxJA+psqj4fyZ GT5Ij5ozjSoxtbjODx+UxLUvj4POjYX2cqc+6ZBywItHF5wn0ZoiWaSSkr0Mi9dDFnGU ZrP0iGKER3upU+T/2HK0Yr4AzeUYXlcp5YKb4caphAuzJyKSlwxmZe0nzZ2l84RFlQz4 q5yltQil9qIggafBixOoV+uU+sqzUdaL5M7Lqe2XANgt+Lo4USAU2eNTzh28t49avSxv twawajsdqWw6E0JrKho+8/BbOR3M/bNO8IbNHF+8OD3fdoomGTOrhw0yvcWTw82Zz7+R Z46A== X-Gm-Message-State: AOAM533RhfOZRIwnmWF0Cnvl9JStuTswWiw26LbzAQgP/jmW+pAmgImp 6aq+JVhaPRhAQAeiOvTxyUGo5momfx0RIQxZKvAJWiY= X-Google-Smtp-Source: ABdhPJw/PyCbTqeZM2DIAl+CT+3M38lDilsNZopM8xDKm+FGbV65pWyf1eT8Iz9XV1rjHqXtLEF5EA4912BFsoPx7lw= X-Received: by 2002:a63:9350:: with SMTP id w16mr10755647pgm.53.1622232388512; Fri, 28 May 2021 13:06:28 -0700 (PDT) MIME-Version: 1.0 References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com> <3TVoontwJmoMv0tp1S5MU_U8icxcQZfajtbNEXqOjuvO7GpfUQdh9pEGSIbLEYJndrDa_dJQqa0sSwY-BmuCmyHMRWqa9lEaUjZJSP5Vbyw=@protonmail.com> In-Reply-To: From: Erik Aronesty Date: Fri, 28 May 2021 16:06:16 -0400 Message-ID: To: befreeandopen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 28 May 2021 20:07:34 +0000 Cc: Bitcoin Protocol Discussion , SatoshiSingh , Billy Tetrud Subject: Re: [bitcoin-dev] Opinion on proof of stake in future X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2021 20:06:33 -0000 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 wrote: > > Erik, I am sorry, I have little knowledge about proof-of-burn, I never fo= und it interesting up until now. Some of your recent claims seem quite stro= ng to me and I'd like to read more. > > Forgive me if this has been mentioned recently, but is there a full speci= fication of the concept you are referring to? I don't mean just the basic i= dea description (that much is clear to me), I mean a fully detailed proposa= l 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. > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Wednesday, May 26, 2021 11:07 PM, Erik Aronesty wrote: > > > note: the "nothing at stake" problem you propose is not broken for > > proof-of-burn, because the attacker > > > > a) has no idea which past transactions are burns > > b) has no way to use his mining power, even 5%, to maliciously improve > > his odds of being selected > > > > On Wed, May 26, 2021 at 9:12 AM befreeandopen > > befreeandopen@protonmail.com wrote: > > > > > @befreeandopen I guess I misunderstood your selfish minting attack. L= et 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 fut= ure than minting on the top block. And instead lets the top block proceed i= f it gives them more blocks in the future (also figuring in the 3 blocks th= ey're missing out on minting). > > > 4. Profit! > > > > > > The problem with this attack is that any self respecting PoS system w= ouldn't have the information available for minters to know how blocks will = affect their future prospects of minting. Otherwise this would introduce th= e problem of stake grinding. This can be done using collaborative randomnes= s (where numbers from many parties are combined to create a random number t= hat no individual party could predict). In fact, that's what the Casper pro= tocol does to decide quorums. In a non quorum case, you can do something li= ke record a hash of a number in the block header, and then have a second st= ep 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 a= nd 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 sin= ce 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 c= an 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 incorr= ect 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 curr= ent block production process. Of course this, as it is typical for PoS, int= roduces other problems, but let's discard those. > > > I will try to explain in detail what you misunderstood before. You st= art with a chain ending with blocks A-B-C, C being the top, the common feat= ure 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 bl= ock on top of C (let's call that D), then a participant having K*N amount o= f 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 o= wn 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, thi= s linearity is violated. Why? Well, it works for honest stakers among the c= ompetition 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 a= bility 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 b= uild 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 wa= s limited by other stakers in the system and the discovery of block C by on= e of them). Now suppose that she found such C' and now she continues by try= ing 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 al= l 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 actu= ally 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 d= ifferent forks. She can not be punished because this production was local a= nd only the final result of A-B-C'-D' was published, in which case she gain= ed 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" f= or 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 h= as 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 comple= tely by only allowing the owner of coins themselves to know whether they ca= n 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 ob= jection here was towards such system where I specifically said that the lis= t 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 cours= e 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 intro= ducing 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 "y= ou should not omit to mention that by doing so, typically, you have introdu= ced 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 sp= ecific attack is not doable, but you should not omit to mention that by doi= ng so, typically, you have introduced another problem elsewhere, or you hav= e not solved it completely." > > > You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT CO= MPLETELY) > > > In case of the punishment it was meant to be the not solve it complet= ely part. > > > Also "typically" does not imply always. > > > But this parsing of English sentences for you seems very off topic he= re. 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 wi= ll always increase in time. It will increase relative to all normal users w= ho 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 minti= ng just like any other financial activity. Others may find more success spe= nding 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 in= secure > > > > > > I think the only thing we can conclude from this is that you have com= e 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 protoc= ols 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 belie= ved 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 demonstra= ted that your claim that nothing at stake is solved was unjustified. You ha= ve not described a system that would solve it (and not introduce critical D= DOS attack vector as it is in quorum based systems - per the prior definiti= on of such systems). > > > Of course the list of problems of PoS systems do not end with just no= thing at stake, but it is good enough example that by itself prevents its a= doption in decentralized consensus. No need to go to other hard problems wi= thout solving nothing at stake. > > > On Tue, May 25, 2021 at 11:10 AM befreeandopen befreeandopen@protonma= il.com wrote: > > > > > > > @befreeandopen " An attacker can calculate whether or not she can p= rolong 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 no= thing at stake problem. The nothing at stake problem is the problem where a= nyone will mint on any chain. Its clear that if there's a substantial punis= hment 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 a= ttempt to mint on old blocks or support someone else's attempt to mint on o= ld blocks (until and if it becomes the heaviest chain). Because the attacke= r would need probably >45% of the active stake (take a look at the reasonin= g here for a deeper analysis of that statement), I don't agree that punishm= ent is not a sufficient mitigation of the nothing at stake problem. To expl= oit the nothing at stake problem, you basically need to 51% attack, at whic= h point you've exceeded the operating conditions of the system, so of cours= e 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 descri= bed 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 co= mpletely take control the network (in short term), but rather that the atta= cker 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 in= creases significantly faster than of the honest nodes, which in long term i= s very serious in PoS system. If you believe close to 50% is needed for tha= t, you need to redo your math. So no, you are wrong stating that "to exploi= t nothing at stake problem you basically need to 51% attack". It is rather = the opposite - eventually, nothing at stake attack leads to ability to perf= orm 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 gene= rally an easy thing to do on the fly like that. If you know someone's IP ad= dress, you can target them. But if you only know their address or public ke= y, the reverse isn't as easy. With a quorum-based PoS system, you can see t= heir public key and address, but finding out their IP to DOS would be a hug= e challenge I think. > > > > I do not dispute that the problem is not trivial, but the problem i= s 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 numbe= r of nodes to the system to achieve very good success rate of analysis of a= rea of origin of blocks is doable and has been done in past. So again, I ve= ry much disagree with your conclusion that this is somehow secure. It is ab= solutely insecure. > > > > Note, tho, that quorum-based PoS generally also have punishments as= part of the protocol. The introduction of punishments do indeed handily so= lve the nothing at stake problem. And you didn't mention a single problem t= hat the punishments introduce that weren't already there before punishments= . There are tradeoffs with introducing punishments (eg in some cases you mi= ght 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 pr= evious message), it does introduce additional complexity which may introduc= e problem, but more importantly, while it slightly improves resistance agai= nst the nothing at stake attack, it solves absolutely nothing. Your claim i= s 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 co= nditions 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 P= oS. > > > > 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 a= utomatically part of the staking process even when they are moved. But in m= any 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 proce= ss 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 stak= ed, 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 the= oretical. Then if we do not have the optimal condition, it means that a sta= ker with K% of the total available supply increases it's percentage over ti= me 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 al= l normal users who do not stake (if there are any) and relative to all othe= r stakers who make mistakes or who are not wealthy enough to afford not sel= ling any position ever. But powerful attacker is exactly in such position a= nd thus she will gain significance in such a system. The technique I have d= escribed, 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 conv= erges 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 pr= oblem don't introduce any other problems with anywhere near the same level = of significance. > > > > It still stands as truly misleading claim. I disagree that introduc= ing DDOS opportunity with medium level of difficulty for the attacker to im= plement it, in case of "quorum-based PoS" is not a problem anywhere near th= e 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 in= secure until someone invents and demonstrates an actual way of solving thes= e issues. > > > > On Tue, May 25, 2021 at 3:00 AM Erik Aronesty erik@q32.com wrote: > > > > > > > > > > > you burn them to be used at a future particular block height > > > > > > > > > > > This sounds exploitable. It seems like an attacker could simply= focus all their burns on a particular set of 6 blocks to double spend, min= imizing their cost of attack. > > > > > > > > > > could be right. the original idea was to have burns decay over ti= me, > > > > > 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 pro= of of > > > > > stake - simply because the "proof" is on-chain, not sitting on a = node > > > > > somewhere waiting to be stolen. > > > > > On Mon, May 24, 2021 at 9:53 PM Billy Tetrud billy.tetrud@gmail.c= om 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 sho= rter, i can only choose one... deterministically > > > > > > > > > > > > What prevents you from attempting to mine block 553 on both cha= ins? > > > > > > > > > > > > > miners have a very strong, long-term, investment in the stabi= lity of the chain. > > > > > > > > > > > > Yes, but the same can be said of any coin, even ones that do ha= ve the nothing at stake problem. This isn't sufficient tho because the chai= n 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, min= imizing 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 ex= ample > > > > > > > > > > > > Are you talking about a 51% attack? This is possible in any dec= entralized cryptocurrency. > > > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik@q32.com wro= te: > > > > > > > > > > > > > > > your burn investment is always "at stake", any redaction = can result in a loss-of-burn, because burns can be tied, precisely, to bloc= k-heights > > > > > > > > > I'm fuzzy on how proof of burn works. > > > > > > > > > > > > > > when you burn coins, you burn them to be used at a future par= ticular > > > > > > > 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 lo= nger > > > > > > > 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 ha= ve 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 a= lways > > > > > > > hurt miners the most. > > > > > > > the "punishment" systems of PoS are "weird at best", certainl= y > > > > > > > unproven. i can imagine scenarios where large stakeholders ca= n > > > > > > > collude to punish smaller stakeholders simply to drive them o= ut of > > > > > > > business, for example. and then you have to put checks in pla= ce 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 Mini= ng > > > > > > > Council). these consortiums, if state sanctioned, could becom= e a > > > > > > > source of censorship, for example. Since PoB doesn't require = you to > > > > > > > have a live, well-connected node, it's harder to censor & har= der to > > > > > > > trace. > > > > > > > Eliminating this weakness seems to be in the best interests o= f > > > > > > > existing stakeholders > > > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud billy.tetrud@gma= il.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'r= e burned. But yes, only a small fraction of the total coins need to be onli= ne. > > > > > > > > > > > > > > > > > your burn investment is always "at stake", any redaction = can result in a loss-of-burn, because burns can be tied, precisely, to bloc= k-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 sta= ke" problem. You can simply punish people who mint on shorter chains (by re= warding 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 so= lved problem at this point for PoS. > > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik@q32.com = wrote: > > > > > > > > > > > > > > > > > > I don't see a way to get around the conflicting require= ment that the keys for large amounts of coins should be kept offline but th= ose 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" pro= blem in your view? > > > > > > > > > > > > > > > > > > definition of nothing at stake: in the event of a fork, w= hether the > > > > > > > > > fork is accidental or a malicious, the optimal strategy f= or any miner > > > > > > > > > is to mine on every chain, so that the miner gets their r= eward no > > > > > > > > > matter which fork wins. indeed in proof-of-stake, the pro= ofs are > > > > > > > > > published on the very chains mines, so the incentive is m= agnified. > > > > > > > > > in proof-of-burn, your burn investment is always "at stak= e", 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 a= ll chains > > > > > > > > > in this way proof of burn can be more secure than proof-o= f-stake, and > > > > > > > > > even more secure than proof of work > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoi= n-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 a= nd elsewhere. > > > > > > > > > > Although I don't agree with all your points you have do= ne 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 sett= lement layer in a pure digital asset (i.e. "digital gold") which is what Bi= tcoin is trying to be. > > > > > > > > > > PoS necessarily gives responsibilities to the holders o= f 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 unde= rlying consensus -- it only affects their personal security assurance (not = that of the system itself). > > > > > > > > > > In PoS systems this clean separation of responsibilitie= s 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 fo= r 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 leadin= g proof of stake protocols would have on Bitcoin: > > > > > > > > > > > > > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot) > > > > > > > > > > > > > > > > > > > > Cardano is a UTXO based PoS coin based on Ouroboros Pra= os3 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 o= ffering the largest share of the block reward. > > > > > > > > > > On the surface this might sound no different than someo= ne 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 ju= st 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 m= uch still online. You are just partaking in a pool to reduce your profit va= riance. You still see every block that you help create and you never help c= reate 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 redel= egate 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 r= eally really bad. > > > > > > > > > > In Bitcoin, miners can just join a different pool a= t a whim. There is nothing the attacker can do to stop them. A temporary di= shonest majority heals relatively well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > There is another severe disadvantage to this on-chain d= elegation system: every UTXO must indicate which staking account this UTXO = belongs to so the appropriate share of block rewards can be transferred the= re. > > > > > > > > > > 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 p= articipate 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 ho= lding 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 behal= f. > > > > > > > > > > Hopefully you've spotted the problem. > > > > > > > > > > You can send your participation keys to any malicious p= arty 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 at= tacker will lose their hold on consensus. > > > > > > > > > > Importantly there is also less junk on the blockchain b= ecause 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 require= ment that the keys for large amounts of coins should be kept offline but th= ose are exactly the coins we need online to make the scheme secure. > > > > > > > > > > If we allow delegation then we open up a new social att= ack surface and it degenerates to Proof-of-SquareSpace. > > > > > > > > > > For a "digital gold" like system like Bitcoin we optimi= ze 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 tab= le that doesn't confer responsibilities on the holder to maintain the quali= ty of all the other bars of gold out there. > > > > > > > > > > Bitcoin feels like this too and in many ways is more in= ert 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 rea= l digital gold and whether these bad technical trade offs are worth being a= ble to say it uses less electricity. It goes without saying that making bad= technical decisions to appease the current political climate is an anathem= a to Bitcoin. > > > > > > > > > > Would be interested to know if you or others think diff= erently 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 aga= inst Proof of Stake. Yes there have been lots of shady coins that use insec= ure 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 betwe= en "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 unpro= ven assumptions or extrapolation from the analysis of a particular PoS syst= em. 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 secu= rity (cost / capital required to execute an attack) while at the same time = costing far less resources (which do translate to fees on the network) with= out compromising any of the critical security properties bitcoin relies on.= I think the critical piece of this is the disagreements around hardcoded c= heckpoints, 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 li= ne of thinking omits important facts: > > > > > > > > > > > > > > > > > > > > > > - The capital required to 51% attack a PoS chain ca= n be made substantially greater than on a PoS chain. > > > > > > > > > > > - The capital the attacker stands to lose can be su= bstantially greater as well if the attack is successful. > > > > > > > > > > > - The effectiveness of paying miners to raise the h= onest 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 bloc= ks, you should expect to earn 10x as much minting revenue - not more than 1= 0x. By contrast, proof of work does in fact have clear centralization press= ure - this is not disputed. Our goal in relation to that is to ensure that = the centralization pressure remains insignifiant. Proof of work also clearl= y has a lot more barriers to entry than any proof of stake system does. Bot= h of these mean the tendency towards oligopolistic control is worse for PoW= . > > > > > > > > > > > > > > > > > > > > > > > Energy usage, in-and-of-itself, is nothing to be as= hamed of!! > > > > > > > > > > > > > > > > > > > > > > I certainly agree. Bitcoin's energy usage at the mome= nt is I think quite warranted. However, the question is: can we do substant= ially better. I think if we can, we probably should... eventually. > > > > > > > > > > > > > > > > > > > > > > > Proof of Stake is only resilient to =E2=85=93 of th= e network demonstrating a Byzantine Fault, whilst Proof of Work is resilien= t up to the =C2=BD 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 re= quirement. However there are PoS designs that should exceed that up to near= ly 50% as far as I'm aware. Proof of work is not in fact resilient up to th= e 1/2 threshold in the way you would think. IE, if 100% of miners are curre= ntly honest and have a collective 100 exahashes/s hashpower, an attacker do= es not need to obtain 100 exahashes/s, but actually only needs to accumulat= e 50 exahashes/s. This is because as the attacker accumulates hashpower, it= drives honest miners out of the market as the difficulty increases to beyo= nd what is economically sustainable. Also, its been shown that the best pro= of of work can do is require an attacker to obtain 33% of the hashpower bec= ause 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 secur= ity 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) =E2= =80=94 specifically the famous "security vs. liveness" guarantee > > > > > > > > > > > > > > > > > > > > > > Do you have a good source that talks about why you th= ink 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 mini= ng, some nodes may reject you, but there will likely be more that will acce= pt you, some sellers may reject you, but most would accept your money as pa= yment for bitcoins. I don't think requiring the "permission" of one of mill= ions of people in the market can be reasonably considered a "permissioned c= urrency". > > > > > > > > > > > > > > > > > > > > > > > 2. Proof of stake must have a trusted means of tim= estamping 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 h= onest 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 dif= ferent thread! :) > > > > > > > > > > > > On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky = mike@powx.org wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Folks, I suggest we keep the discussion to PoW, o= PoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess t= here are other threads going on these topics already where they would be re= levant. > > > > > > > > > > > > > Also, it's important to distinguish between oPoW = and these other "alternatives" to Hashcash. oPoW is a true Proof of Work th= at doesn't alter the core game theory or security assumptions of Hashcash a= nd 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 conte= xt of a working > > > > > > > > > > > > > > proof-of-burn protocol > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - vdfs used only for timing (not block height= ) > > > > > > > > > > > > > > - blind-burned coins of a specific age used t= o replace proof of work > > > > > > > > > > > > > > - the required "work" per block would simply = be a competition to > > > > > > > > > > > > > > acquire rewards, and so miners would have t= o burn coins, well in > > > > > > > > > > > > > > advance, and hope that their burned coins g= ot rewarded in some far > > > > > > > > > > > > > > future > > > > > > > > > > > > > > > > > > > > > > > > > > > > - the point of burned coins is to mimic, in e= very meaningful way, the > > > > > > > > > > > > > > value gained from proof of work... without = some of the security > > > > > > > > > > > > > > drawbacks > > > > > > > > > > > > > > > > > > > > > > > > > > > > - the miner risks losing all of his burned co= ins (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 Bitcoi= n 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 t= hat if the entire space > > > > > > > > > > > > > > agreed that such an endeavor was worthwhile= , a test net could be spun > > > > > > > > > > > > > > up, and a hard-fork could be initiated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. i would never suggest such a thing unless i= believed it was > > > > > > > > > > > > > > possible that consensus was possible. so no= , this is not an "alt > > > > > > > > > > > > > > coin" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 18, 2021 at 10:02 AM Zac Greenwood = zachgrw@gmail.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi ZmnSCPxj, > > > > > > > > > > > > > > > Please note that I am not suggesting VDFs as = a means to save energy, but solely as a means to make the time between bloc= ks more constant. > > > > > > > > > > > > > > > Zac > > > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj ZmnSCP= xj@protonmail.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Zac, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > VDFs might enable more constant block tim= es, 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 a= s-is difficulty adjustments. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As a result, variation in block times wil= l be greatly reduced. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As I understand it, another weakness of VDF= s is that they are not inherently progress-free (their sequential nature pr= events that; they are inherently progress-requiring). > > > > > > > > > > > > > > > > Thus, a miner which focuses on improving th= e 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 fas= ter 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/listi= nfo/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/bi= tcoin-dev > > > > > > > > > > > > > > > > > > > > bitcoin-dev mailing list > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitc= oin-dev > >