diff options
| author | befreeandopen <befreeandopen@protonmail.com> | 2021-06-01 19:26:36 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-06-01 19:26:48 +0000 |
| commit | 1fc4e6f0da70dbbdd14fff45455557ad2f6fc415 (patch) | |
| tree | 8401c3bcdf82c6e336693f14193cb76233b5a899 | |
| parent | fe15bcb870952167b950aeb0f6c25d27ff4403e1 (diff) | |
| download | pi-bitcoindev-1fc4e6f0da70dbbdd14fff45455557ad2f6fc415.tar.gz pi-bitcoindev-1fc4e6f0da70dbbdd14fff45455557ad2f6fc415.zip | |
Re: [bitcoin-dev] Opinion on proof of stake in future
| -rw-r--r-- | b2/842e1165f21226b709b1a6079f61c3bde3bc50 | 1092 |
1 files changed, 1092 insertions, 0 deletions
diff --git a/b2/842e1165f21226b709b1a6079f61c3bde3bc50 b/b2/842e1165f21226b709b1a6079f61c3bde3bc50 new file mode 100644 index 000000000..ac38d9366 --- /dev/null +++ b/b2/842e1165f21226b709b1a6079f61c3bde3bc50 @@ -0,0 +1,1092 @@ +Return-Path: <befreeandopen@protonmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 01BE5C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 1 Jun 2021 19:26:48 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id C3A5640426 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 1 Jun 2021 19:26:48 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.102 +X-Spam-Level: +X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp4.osuosl.org (amavisd-new); + dkim=pass (1024-bit key) header.d=protonmail.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id xzpoZRG4eO4V + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 1 Jun 2021 19:26:44 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch + [185.70.40.130]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 98F3940417 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 1 Jun 2021 19:26:43 +0000 (UTC) +Date: Tue, 01 Jun 2021 19:26:36 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail; t=1622575597; + bh=BQKmEwuYBeuQHlvHM7qSV8zY3OOgMZu3fSsYZkiSOMY=; + h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; + b=g/WlJCD1H0n3fnvhqNsfu8BZ7erUD1W/kp0wJwsXtLRCWAor3RjX4gurYM0PKC5OS + mXEfZp5kt9ZIJMrPwi0qBm1FnFrY8dBzur9w6cLn/bOATfvVHwgk1tHbTBoN67F/hQ + WyrqCelU8AfE8YO6SDEsABUf290Miv9DNr6c2Hb0= +To: Erik Aronesty <erik@q32.com> +From: befreeandopen <befreeandopen@protonmail.com> +Reply-To: befreeandopen <befreeandopen@protonmail.com> +Message-ID: <RgxuE0JLcjQQOuVPxCGdSy-GU4oZx3kmuErGtUCM27rhHKLc47kO7A4M0VQBxc8fj3Y026J7PC4wU0onWlm4tgKycTZTFAN_8PQX3-Tl0j4=@protonmail.com> +In-Reply-To: <CAJowKgK+i6WDXQcXnEEt+Y7Bq3vr64cTkSvPjraYiYhNRkBP1w@mail.gmail.com> +References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com> + <3TVoontwJmoMv0tp1S5MU_U8icxcQZfajtbNEXqOjuvO7GpfUQdh9pEGSIbLEYJndrDa_dJQqa0sSwY-BmuCmyHMRWqa9lEaUjZJSP5Vbyw=@protonmail.com> + <CAGpPWDbqZLzMog4s9SPVm5xstbJbsHwND6x3qWHR-dh6naCnNQ@mail.gmail.com> + <L1IhpSfDNx5OPXYnHfcFDiOzJa8jihbR8YE4MBRaYjuQt2GQsrNd0UnJaJg_mCgHNOcG6QE1Wrwp6zZ-YxOgDNu_aBE67HJkbemHz5Nz9c4=@protonmail.com> + <CAJowKgKgGynQ9NYe_7xEai0tcBW4b=tQnNpv9vndx1hLCowfWg@mail.gmail.com> + <J3_n3ygIuQf54KXVl8jlbyahX5WJIzffVeDD3yt0RkRbPRyD56OPj3DT05wGJoEfI6XfLOq2DiaN-vdnXSdi7Q23NWrZ-Tg9jzM9jtx8-hg=@protonmail.com> + <CAJowKgJTEHLeHpKUOavAY9hHZ_3hChkJnMX13K-pSUhch7JwdQ@mail.gmail.com> + <EdKK1tb2px2G--ianlCQpRjsn7vdXkSr60sV18NpVw-uVuKSA-ag9xXch_rYDkhtaJTH36zDMuVGZyYrKagMNNw_0OrLF8QsPiuo-YIxTaE=@protonmail.com> + <CAJowKgK+i6WDXQcXnEEt+Y7Bq3vr64cTkSvPjraYiYhNRkBP1w@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +X-Mailman-Approved-At: Tue, 01 Jun 2021 22:05:19 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + SatoshiSingh <SatoshiSingh@protonmail.com>, + Billy Tetrud <billy.tetrud@gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 01 Jun 2021 19:26:49 -0000 + +Comments inline. + + + +> > Could you explain what am I missing here, because this actually does no= +t 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, the= +n 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 whic= +h 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 fee= +s 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 th= +e case after switching to PoB that the cost of producing the block should r= +oughly converge to to the revenue? Because I do not see why would miners sp= +end 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 att= +ack PoW. +> Any attack you propose for a "assumed well designed PoB" can also att= +ack PoS. +> +> But there are some things PoB can do that PoS can't... which is reall= +y +> 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 classi= +cal debate with PoS supporters - I explain an attack and they "patch it", c= +reating problem elsewhere. Then I explain an attack against that and they p= +atch it there. And this goes infinitely. + +So if there is some other version, better one than the one described in wik= +i, please let me know. If there is not, there is nothing to talk about real= +ly. You'd first need to define your model properly and describe very detail= +s of how it should work and then we can analyze it. It does not make much s= +ense to me to analyze a ghost protocol that I always only see a tiny part o= +f. + +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 i= +n the wiki, then I have no idea what it is. I do not say that I can't imagi= +ne 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 befor= +e 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 +> befreeandopen@protonmail.com wrote: +> +> +> > Erik, thanks for the link. So referring to https://en.bitcoin.it/wiki/P= +roof_of_burn, I do not really understand how this is supposed to be that mu= +ch 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 articl= +e and my comments are purely related to this only. +> > I hope we can agree that the idea with manual insertion of entropy ever= +y 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 implementati= +ons 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 c= +reation process by first doing some action followed by some inaction for so= +me time; the difference here is that if later you use such coin in PoS, the= +n 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 po= +wer 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 th= +is 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 ma= +king attacks easier. PoB reverses the idea, but I don't think that helps th= +at 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 p= +roduction. 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 abilit= +y of the coin to produce blocks with the size of the coin (more BTC you bur= +n/stake, the better your chance) +> > +> > +> > This characteristic of PoB does not suggest that it would have that muc= +h 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 diff= +iculty adjustment - this seems crucial, but likely solvable, I'm just sayin= +g 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 us= +ed 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 ca= +n't see at the moment how is this different from PoS nothing at stake probl= +em. 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 num= +ber of burned coins or the cumulative "strength" of the "lowest" hashes, th= +en 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 yo= +u just "try for free" all your 20 UTXOs, whether or not they can build on t= +op of block A (which has 5 confs on top, F is the tip of the main chain). S= +ince you have big UTXOs, your chances should be good, of course you can alw= +ays 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 c= +an'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 no= +t seem better, but rather worse than some PoS schemes? +> > 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 Origina= +l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80= +=90 +> > On Friday, May 28, 2021 9:06 PM, Erik Aronesty erik@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 +> > > befreeandopen@protonmail.com wrote: +> > > +> > > > Erik, I am sorry, I have little knowledge about proof-of-burn, I ne= +ver found it interesting up until now. Some of your recent claims seem quit= +e 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 b= +asic idea description (that much is clear to me), I mean a fully detailed p= +roposal 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 Ori= +ginal 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 erik@q32.com wro= +te: +> > > > +> > > > > note: the "nothing at stake" problem you propose is not broken fo= +r +> > > > > 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 im= +prove +> > > > > 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 att= +ack. 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 b= +locks on on the second from the top block if it gives them more blocks in t= +he future than minting on the top block. And instead lets the top block pro= +ceed if it gives them more blocks in the future (also figuring in the 3 blo= +cks they're missing out on minting). +> > > > > > 4. Profit! +> > > > > > +> > > > > > The problem with this attack is that any self respecting PoS sy= +stem wouldn't have the information available for minters to know how blocks= + will affect their future prospects of minting. Otherwise this would introd= +uce the problem of stake grinding. This can be done using collaborative ran= +domness (where numbers from many parties are combined to create a random nu= +mber that no individual party could predict). In fact, that's what the Casp= +er protocol does to decide quorums. In a non quorum case, you can do someth= +ing like record a hash of a number in the block header, and then have a sec= +ond 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 num= +bers and not releasing their secret numbers too early. +> > > > > > Yes, you misunderstood it. First, let me say that the above tho= +ughts of yours are incorrect, at least for non-quorum case. Since the trans= +ition in the blockchain system from S1 to S2 is only by adding new block, a= +nd since stakers always need to be able to decide whether or not they can a= +dd 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 to= +p. As you mentioned, this COULD introduce problem of staking, that you are = +incorrect in that it is a necessity. Usual prevention of the grinding probl= +em in this case is that an "old enough" source of randomness applies for th= +e current block production process. Of course this, as it is typical for Po= +S, 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 commo= +n 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 am= +ount 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 wh= +o has 1 coin. +> > > > > > What i was claiming is that using the technique I have describe= +d, 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, sh= +e 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, usu= +ally, 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 li= +kely t(C') > t(C) as the attacker has relatively low stake. Note that in or= +der 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 cons= +ensus rule, but it may depend on a specific consensus). So her chance to pr= +oduce such C' is greater than her previous chance of producing C (which cha= +nce 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 fi= +nding D because again there are likely multiple timestamps she could try. T= +his all was possible just because nothing at stake allows you to just try i= +f you can produce a block in certain state of block chain or not. Now if sh= +e 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 l= +ocal and only the final result of A-B-C'-D' was published, in which case sh= +e 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 att= +ack" for proof of work, and it reduces the security of PoW by at least 1/3r= +d. +> > > > > > 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 asso= +ciated 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 t= +hey can mint a block. Eg by determining whether someone can mint a block ba= +sed 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 t= +he list of producers for next epoch is known up front and you confirmed tha= +t 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 a= +re 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 pr= +evious 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 i= +ntroduced 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 cert= +ain specific attack is not doable, but you should not omit to mention that = +by doing so, typically, you have introduced another problem elsewhere, or y= +ou 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 c= +ompletely part. +> > > > > > Also "typically" does not imply always. +> > > > > > But this parsing of English sentences for you seems very off to= +pic here. My point is, in context of Bitcoin, reject such unsupported claim= +s 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) tha= +t she does not miss a chance to create a block, her significance in the sys= +tem will always increase in time. It will increase relative to all normal u= +sers who do not stake +> > > > > > +> > > > > > Well, if you're in the closed system of the cryptocurrency, sur= +e. 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 succe= +ss spending their time doing things other than figuring out how to mint coi= +ns. In that case, they'll be able to earn more coin that they could later d= +ecide to use to mint blocks if they decide to. +> > > > > > This only supports the point I was making. Since the optimal sc= +enario with all existing coins participating is just theoretical, the attac= +ker's position will ever so improve. It seems we are in agreement here, gre= +at. +> > > > > > +> > > > > > > Just because of the above we must reject PoS as being critica= +lly insecure +> > > > > > +> > > > > > I think the only thing we can conclude from this is that you ha= +ve come up with an insecure proof of stake protocol. I don't see how anythi= +ng 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 realize= +d 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 h= +ow to solve every problem that people throw at you. So far we have just dem= +onstrated that your claim that nothing at stake is solved was unjustified. = +You have not described a system that would solve it (and not introduce crit= +ical DDOS attack vector as it is in quorum based systems - per the prior de= +finition of such systems). +> > > > > > Of course the list of problems of PoS systems do not end with j= +ust 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 probl= +ems without solving nothing at stake. +> > > > > > On Tue, May 25, 2021 at 11:10 AM befreeandopen befreeandopen@pr= +otonmail.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 a= +ll 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 w= +here 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 min= +t on old blocks (until and if it becomes the heaviest chain). Because the a= +ttacker would need probably >45% of the active stake (take a look at the re= +asoning here for a deeper analysis of that statement), I don't agree that p= +unishment is not a sufficient mitigation of the nothing at stake problem. T= +o exploit the nothing at stake problem, you basically need to 51% attack, a= +t 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 Po= +W. +> > > > > > > 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 th= +e attacker has significant advantage in the number of blocks she creates co= +mpared to what she "should be able to create". This means the attacker's st= +ake 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 f= +or 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 r= +ather the opposite - eventually, nothing at stake attack leads to ability t= +o 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 pub= +lic 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 pro= +blem is not as hard as you think. The network graph analysis is a known tec= +hnique 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 analysi= +s 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 punishme= +nts as part of the protocol. The introduction of punishments do indeed hand= +ily solve the nothing at stake problem. And you didn't mention a single pro= +blem that the punishments introduce that weren't already there before punis= +hments. There are tradeoffs with introducing punishments (eg in some cases = +you might punish honest actors), but they are minor in comparison to solvin= +g 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 in= +troduce problem, but more importantly, while it slightly improves resistanc= +e against the nothing at stake attack, it solves absolutely nothing. Your c= +laim is based on wrong claim of needed close to 50% stake, but that could n= +ot be farther from the truth. It is not true even in optimal conditions whe= +n all participants of the network stake or delegate their stake. These opti= +mal conditions rarely, if ever, occur. And that's another thing that we hav= +e not mention in our debate, so please allow me to introduce another proble= +m 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 som= +ehow automatically part of the staking process even when they are moved. Bu= +t in many PoS systems you usually require some age (in terms of confirmatio= +ns) 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 attack= +s. In some systems the coin must be specifically registered before it can b= +e 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 hav= +e 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 rath= +er 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 o= +ver time to some amounts >K%. As long as the staker makes sure (which is no= +t that hard) that she does not miss a chance to create a block, her signifi= +cance 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 al= +l other stakers who make mistakes or who are not wealthy enough to afford n= +ot selling any position ever. But powerful attacker is exactly in such posi= +tion 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 amou= +nts of stake, only puts the attacker to even greater advantage. But even wi= +thout the described attack (which exploits nothing at stake), the PoS syste= +m 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 "nothi= +ng at stake" is a solved problem. I do in fact mean that the solutions to t= +hat 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 in= +troducing DDOS opportunity with medium level of difficulty for the attacker= + to implement it, in case of "quorum-based PoS" is not a problem anywhere n= +ear the same level of significance. Such an attack vector allows you to tur= +n off the network if you spend some time and money. That is hardly acceptab= +le. +> > > > > > > Just because of the above we must reject PoS as being critica= +lly insecure until someone invents and demonstrates an actual way of solvin= +g these issues. +> > > > > > > On Tue, May 25, 2021 at 3:00 AM Erik Aronesty erik@q32.com wr= +ote: +> > > > > > > +> > > > > > > > > > you burn them to be used at a future particular block h= +eight +> > > > > > > > +> > > > > > > > > This sounds exploitable. It seems like an attacker could = +simply focus all their burns on a particular set of 6 blocks to double spen= +d, minimizing their cost of attack. +> > > > > > > > +> > > > > > > > could be right. the original idea was to have burns decay o= +ver 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 th= +an 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.tetrud@g= +mail.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 o= +ne shorter, i can only choose one... deterministically +> > > > > > > > > +> > > > > > > > > What prevents you from attempting to mine block 553 on bo= +th 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 th= +e 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 h= +eight +> > > > > > > > > +> > > > > > > > > This sounds exploitable. It seems like an attacker could = +simply focus all their burns on a particular set of 6 blocks to double spen= +d, minimizing their cost of attack. +> > > > > > > > > +> > > > > > > > > > i can imagine scenarios where large stakeholders can co= +llude to punish smaller stakeholders simply to drive them out of business, = +for example +> > > > > > > > > +> > > > > > > > > Are you talking about a 51% attack? This is possible in a= +ny decentralized cryptocurrency. +> > > > > > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik@q32.c= +om wrote: +> > > > > > > > > +> > > > > > > > > > > > your burn investment is always "at stake", any reda= +ction can result in a loss-of-burn, because burns can be tied, precisely, t= +o block-heights +> > > > > > > > > > > > I'm fuzzy on how proof of burn works. +> > > > > > > > > > +> > > > > > > > > > when you burn coins, you burn them to be used at a futu= +re particular +> > > > > > > > > > block height: so if i'm burning for block 553, i can on= +ly use them to +> > > > > > > > > > mine block 553. if i have a choice between two chains, = +one longer +> > > > > > > > > > and one shorter, i can only choose one... deterministic= +ally, for that +> > > > > > > > > > burn: the chain with the height 553. if we fix the "lea= +d time" for +> > > > > > > > > > burned coins to be weeks or even months in advance, min= +ers have a very +> > > > > > > > > > strong, long-term, investment in the stability of the c= +hain. +> > > > > > > > > > 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 instabi= +lity always +> > > > > > > > > > hurt miners the most. +> > > > > > > > > > the "punishment" systems of PoS are "weird at best", ce= +rtainly +> > > > > > > > > > unproven. i can imagine scenarios where large stakehold= +ers 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 syst= +em... +> > > > > > > > > > in PoB, there is no complexity. simpler systems like th= +is are +> > > > > > > > > > typically more secure. +> > > > > > > > > > PoB also solves problems caused by "energy dependence",= + which could +> > > > > > > > > > lead to state monopolies on mining (like the new Bitcoi= +n Mining +> > > > > > > > > > Council). these consortiums, if state sanctioned, could= + become a +> > > > > > > > > > source of censorship, for example. Since PoB doesn't re= +quire 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 inter= +ests of +> > > > > > > > > > existing stakeholders +> > > > > > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud billy.tetr= +ud@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 b= +e online. +> > > > > > > > > > > +> > > > > > > > > > > > your burn investment is always "at stake", any reda= +ction can result in a loss-of-burn, because burns can be tied, precisely, t= +o 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-stak= +e +> > > > > > > > > > > +> > > > > > > > > > > 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 i= +s a solved problem at this point for PoS. +> > > > > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik@q3= +2.com wrote: +> > > > > > > > > > > +> > > > > > > > > > > > > I don't see a way to get around the conflicting r= +equirement 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 stak= +e" problem in your view? +> > > > > > > > > > > > +> > > > > > > > > > > > definition of nothing at stake: in the event of a f= +ork, whether the +> > > > > > > > > > > > fork is accidental or a malicious, the optimal stra= +tegy for any miner +> > > > > > > > > > > > is to mine on every chain, so that the miner gets t= +heir reward no +> > > > > > > > > > > > matter which fork wins. indeed in proof-of-stake, t= +he proofs are +> > > > > > > > > > > > published on the very chains mines, so the incentiv= +e is magnified. +> > > > > > > > > > > > in proof-of-burn, your burn investment is always "a= +t stake", any +> > > > > > > > > > > > redaction can result in a loss-of-burn, because bur= +ns 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 p= +roof-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 dism= +issing many of the weak arguments that are made against PoS made in this th= +read and elsewhere. +> > > > > > > > > > > > > Although I don't agree with all your points you h= +ave done a decent job here so I'll focus on the second part: why I think Pr= +oof-of-Stake is inappropriate for a Bitcoin-like system. +> > > > > > > > > > > > > Proof of stake is not fit for purpose for a globa= +l settlement layer in a pure digital asset (i.e. "digital gold") which is w= +hat Bitcoin is trying to be. +> > > > > > > > > > > > > PoS necessarily gives responsibilities to the hol= +ders of coins that they do not want and cannot handle. +> > > > > > > > > > > > > In Bitcoin, large unsophisticated coin holders ca= +n put their coins in cold storage without a second thought given to the hea= +lth of the underlying ledger. +> > > > > > > > > > > > > As much as hardcore Bitcoiners try to convince th= +em to run their own node, most don't, and that's perfectly acceptable. +> > > > > > > > > > > > > At no point do their personal decisions affect th= +e underlying consensus -- it only affects their personal security assurance= + (not that of the system itself). +> > > > > > > > > > > > > In PoS systems this clean separation of responsib= +ilities does not exist. +> > > > > > > > > > > > > I think that the more rigorously studied PoS prot= +ocols will work fine within the security claims made in their papers. +> > > > > > > > > > > > > People who believe that these protocols are desti= +ned 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 Ourobor= +os 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 ther= +e 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 pur= +chased 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 pro= +fit 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 dis= +honest 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 dele= +gating to another pool...oh wait I guess that might be censored too! This s= +eems 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 tempor= +ary dishonest majority heals relatively well. +> > > > > > > > > > > > > +> > > > > > > > > > > > > +> > > > > > > > > > > > > There is another severe disadvantage to this on-c= +hain delegation system: every UTXO must indicate which staking account this= + UTXO belongs to so the appropriate share of block rewards can be transferr= +ed 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 signific= +antly. +> > > > > > > > > > > > > +> > > > > > > > > > > > > ### "Pure" proof of stake (Algorand) +> > > > > > > > > > > > > +> > > > > > > > > > > > > Algorand's4 approach is to only allow online stak= +e 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 c= +oin holding keys online so in Alogorand you can authorize a set of "partici= +pation 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 malic= +ious party with a nice website (see random example 2) offering you a good r= +eturn. +> > > > > > > > > > > > > Damn it's still Proof-of-SquareSpace! +> > > > > > > > > > > > > The minor advantage is that at least the particip= +ation keys expire after a certain amount of time so eventually the SquareSp= +ace attacker will lose their hold on consensus. +> > > > > > > > > > > > > Importantly there is also less junk on the blockc= +hain 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 r= +equirement 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 soci= +al 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 responsibi= +lities for the holder of the coin. +> > > > > > > > > > > > > After all, gold is an inert element on the period= +ic 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 m= +ore 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 b= +eing able to say it uses less electricity. It goes without saying that maki= +ng bad technical decisions to appease the current political climate is an a= +nathema to Bitcoin. +> > > > > > > > > > > > > Would be interested to know if you or others thin= +k differently on these points. +> > > > > > > > > > > > > Cheers, +> > > > > > > > > > > > > LL +> > > > > > > > > > > > > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bi= +tcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: +> > > > > > > > > > > > > +> > > > > > > > > > > > > > I think there is a lot of misinformation and bi= +as against Proof of Stake. Yes there have been lots of shady coins that use= + insecure PoS mechanisms. Yes there have been massive issues with distribut= +ion of PoS coins (of course there have also been massive issues with PoW co= +ins as well). However, I want to remind everyone that there is a difference= + between "proved to be impossible" and "have not achieved recognized succes= +s 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 Po= +S system. I certainly don't think we should experiment with bitcoin by swit= +ching to PoS, but from my research, it seems very likely that there is a pr= +oof of stake consensus protocol we could build that has substantially highe= +r 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 reli= +es on. I think the critical piece of this is the disagreements around hardc= +oded checkpoints, which is a critical piece solving attacks that could be l= +evied on a PoS chain, and how that does (or doesn't) affect the security mo= +del. +> > > > > > > > > > > > > > @Eric Your proof of stake fallacy seems to be s= +aying that PoS is worse when a 51% attack happens. While I agree, I think t= +hat line of thinking omits important facts: +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > - The capital required to 51% attack a PoS ch= +ain 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 unacceptab= +le. It should be considered whether what happens in the case of a 51% may n= +ot be significantly different. The currency would likely be critically dama= +ged in a 51% attack regardless of consensus mechanism. +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > > Proof-of-stake tends towards oligopolistic co= +ntrol +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > 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 min= +t 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 doe= +s. Both of these mean the tendency towards oligopolistic control is worse f= +or PoW. +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > > Energy usage, in-and-of-itself, is nothing to= + be ashamed of!! +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > I certainly agree. Bitcoin's energy usage at th= +e moment is I think quite warranted. However, the question is: can we do su= +bstantially better. I think if we can, we probably should... eventually. +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > > Proof of Stake is only resilient to =E2=85= +=93 of the network demonstrating a Byzantine Fault, whilst Proof of Work is= + resilient up to the =C2=BD threshold +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > I see no mention of this in the pos.pdf you lin= +ked to. I'm not aware of any proof that all PoS systems have a failure thre= +shold 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 t= +o 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 attac= +ker does not need to obtain 100 exahashes/s, but actually only needs to acc= +umulate 50 exahashes/s. This is because as the attacker accumulates hashpow= +er, it drives honest miners out of the market as the difficulty increases t= +o beyond what is economically sustainable. Also, its been shown that the be= +st proof of work can do is require an attacker to obtain 33% of the hashpow= +er because of the selfish mining attack discussed in depth in this paper: h= +ttps://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 whic= +h 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 think proof of stake cannot be used for a trustless digital cash? +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > > You cannot gain tokens without someone choosi= +ng to give up those coins - a form of permission. +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > This is not a practical constraint. Just like i= +n mining, some nodes may reject you, but there will likely be more that wil= +l 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 o= +f millions of people in the market can be reasonably considered a "permissi= +oned 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 a= +s fast if everyone agreed to double their clock speeds. Both systems rely o= +n an honest majority sticking to standard time. +> > > > > > > > > > > > > > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovs= +ky 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 Dubr= +ovsky mike@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 g= +uess 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 W= +ork that doesn't alter the core game theory or security assumptions of Hash= +cash and actually contains SHA (can be SHA3, SHA256, etc hash is interchang= +eable). +> > > > > > > > > > > > > > > > Cheers, +> > > > > > > > > > > > > > > > Mike +> > > > > > > > > > > > > > > > On Tue, May 18, 2021 at 4:55 PM Erik Arones= +ty via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: +> > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > 1. i never suggested vdf's to replace po= +w. +> > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > 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 s= +imply be a competition to +> > > > > > > > > > > > > > > > > acquire rewards, and so miners would = +have to burn coins, well in +> > > > > > > > > > > > > > > > > advance, and hope that their burned c= +oins 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... wi= +thout some of the security +> > > > > > > > > > > > > > > > > drawbacks +> > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > - the miner risks losing all of his bur= +ned 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 "b= +urned coin + vdf system" +> > > > > > > > > > > > > > > > > might be more secure in the long run,= + and that if the entire space +> > > > > > > > > > > > > > > > > agreed that such an endeavor was wort= +hwhile, a test net could be spun +> > > > > > > > > > > > > > > > > up, and a hard-fork could be initiate= +d. +> > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > 4. i would never suggest such a thing un= +less 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 Gree= +nwood zachgrw@gmail.com wrote: +> > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > > Hi ZmnSCPxj, +> > > > > > > > > > > > > > > > > > Please note that I am not suggesting VD= +Fs as a means to save energy, but solely as a means to make the time betwee= +n blocks more constant. +> > > > > > > > > > > > > > > > > > Zac +> > > > > > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj = +ZmnSCPxj@protonmail.com wrote: +> > > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > > > Good morning Zac, +> > > > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > > > > VDFs might enable more constant blo= +ck times, for instance by having a two-step PoW: +> > > > > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > > > > 1. Use a VDF that takes say 9 minu= +tes 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 subjec= +t to as-is difficulty adjustments. +> > > > > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > > > > As a result, variation in block tim= +es will be greatly reduced. +> > > > > > > > > > > > > > > > > > > +> > > > > > > > > > > > > > > > > > > As I understand it, another weakness = +of VDFs is that they are not inherently progress-free (their sequential nat= +ure prevents that; they are inherently progress-requiring). +> > > > > > > > > > > > > > > > > > > Thus, a miner which focuses on improv= +ing the amount of energy that it can pump into the VDF circuitry (by overcl= +ocking and freezing the circuitry), could potentially get into a winner-tak= +es-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/lis= +tinfo/bitcoin-dev +> > > > > > > > > > > > > > +> > > > > > > > > > > > > > bitcoin-dev mailing list +> > > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org +> > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listi= +nfo/bitcoin-dev +> > > > > > > > > > > > > +> > > > > > > > > > > > > bitcoin-dev mailing list +> > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org +> > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinf= +o/bitcoin-dev + + + |