diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2021-05-27 00:08:57 -1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-05-27 10:09:21 +0000 |
| commit | e370ee0374c9feff1495e94af28b65ebe6d86bc8 (patch) | |
| tree | 02976447502e4ec8539ea3855007d99ce47a85df | |
| parent | fdb9ad8865a57a297ca9b53881d0e87cfba9c307 (diff) | |
| download | pi-bitcoindev-e370ee0374c9feff1495e94af28b65ebe6d86bc8.tar.gz pi-bitcoindev-e370ee0374c9feff1495e94af28b65ebe6d86bc8.zip | |
Re: [bitcoin-dev] Opinion on proof of stake in future
| -rw-r--r-- | 77/2707393abc932060523b8bed6a6cb6e82bd66b | 2065 |
1 files changed, 2065 insertions, 0 deletions
diff --git a/77/2707393abc932060523b8bed6a6cb6e82bd66b b/77/2707393abc932060523b8bed6a6cb6e82bd66b new file mode 100644 index 000000000..aa2efc6fc --- /dev/null +++ b/77/2707393abc932060523b8bed6a6cb6e82bd66b @@ -0,0 +1,2065 @@ +Return-Path: <fresheneesz@gmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 59D4DC0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 27 May 2021 10:09:21 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 31A79400DD + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 27 May 2021 10:09:21 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.099 +X-Spam-Level: +X-Spam-Status: No, score=-2.099 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, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp2.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id QZHglCZxV67P + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 27 May 2021 10:09:16 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com + [IPv6:2a00:1450:4864:20::62e]) + by smtp2.osuosl.org (Postfix) with ESMTPS id E2B9E400C4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 27 May 2021 10:09:15 +0000 (UTC) +Received: by mail-ej1-x62e.google.com with SMTP id gb17so7126273ejc.8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 27 May 2021 03:09:15 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=x8Ox9Lv+Tw9PBXAvqHsFj1UyRIoEIyPsPOVJi7jSd44=; + b=ABhFhCSAcrsmxAyIvRp7ET2yHch1mwMu6YIdePafWS7mbNIgKm+Hkm6nnClMp6oIyN + ak9rBKspN2+QhPLQTgKN+8V3Nh2IcRpoM4vwouCHr2AaTq/N7ZaIghSKnHHQzozTe3l2 + xRTNFTLb7asOiVQY5gMxZ0IdjJIgiX1zwsgv6E6wX75vDqHSq9fd0q0BeM4C4c8u5IUT + muEmZlFAwLi9dKUH7ADT6xpkMAc6ZiLhmfQqbxffhs7Q3la7X09N6tlAD4vQb8lX/dVz + oQgDw+9lr88TPKS/gdBi29wHmE0Vjg5mKpptNAHRPwU6TLROZqMCNoDFsqwfB9MU5zgO + UjWA== +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; + bh=x8Ox9Lv+Tw9PBXAvqHsFj1UyRIoEIyPsPOVJi7jSd44=; + b=oTQpPyloz7ilwqVQDWPWZjGHKoMWeV/5cU/HzhVC1mSJobjGuWO60nMlDoqSJuuheq + ORW3ZbQbSxjwzff7AX9I/tpBorLf+m4V5dJe3vxViEoqcH9dgj5fLwtpNylDwH2D+38m + GyxU8GSS704YY1lXTDDb61EBe7MzzuEjO8MRPaYffV7PeyYwJ3w1Eew9MDvNl0koMK6U + PY+jzcxELVeGl3kcvheczpMI1stXrPCo4e4e2YTvF6g0qj6YmEd/dnBMroNT5EOq84DH + wEY99tX5SMFhkN/s8dH+9TVnTZY4HPcIDDLpHg3NH/xO9BEejMq6yg5SFV7JnSck9AKN + OiDA== +X-Gm-Message-State: AOAM532Y/ev/ygw1XyX45pnX3NwlNyTGOZ8Cg6LV2Fhyl/1L/u8TMM7a + Cr78pri7wEb5R1joSCCIvuLhhCUEGDWMXLI4s4I0o7x44UAskA== +X-Google-Smtp-Source: ABdhPJwHVG6HvtqAY3xKE0vktyrVchJBRbK22UvK8lMeSKpZ9RfdWBTwKUmLVTfanwhZ8J71M25IWRw2ur75OiRrfLE= +X-Received: by 2002:a17:907:76b8:: with SMTP id + jw24mr2943885ejc.359.1622110153785; + Thu, 27 May 2021 03:09:13 -0700 (PDT) +MIME-Version: 1.0 +References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com> + <CAJowKgJOZwb0PgW93Y+Jy+yi1kv09Gu7-gjWvt7eUqWfJ_zJuw@mail.gmail.com> + <CAGpPWDbWvBQd3xh8fx+Le8br2LmsqC_Tds5R=wvw1EmiLk42Xw@mail.gmail.com> + <CAJowKgJYUkxJ4htPvCLtARRr0Db13+BKzWtG40DEv6uEOh5yXw@mail.gmail.com> + <CAGpPWDY4KgNVEoMDAJkWReX4zUUjDuB5SwB0Ap6OU98fuK4DxA@mail.gmail.com> + <CAJowKgJWZ++6NkbYk15NBtA7x37of0n3_qF1UjCbV0Ui7XG8zA@mail.gmail.com> + <CAGpPWDZs5Y10Fjbt8OPx3jEqjgNdQLODNdTW4iRyXTrpuNGFQQ@mail.gmail.com> + <3TVoontwJmoMv0tp1S5MU_U8icxcQZfajtbNEXqOjuvO7GpfUQdh9pEGSIbLEYJndrDa_dJQqa0sSwY-BmuCmyHMRWqa9lEaUjZJSP5Vbyw=@protonmail.com> + <CAGpPWDbqZLzMog4s9SPVm5xstbJbsHwND6x3qWHR-dh6naCnNQ@mail.gmail.com> + <L1IhpSfDNx5OPXYnHfcFDiOzJa8jihbR8YE4MBRaYjuQt2GQsrNd0UnJaJg_mCgHNOcG6QE1Wrwp6zZ-YxOgDNu_aBE67HJkbemHz5Nz9c4=@protonmail.com> +In-Reply-To: <L1IhpSfDNx5OPXYnHfcFDiOzJa8jihbR8YE4MBRaYjuQt2GQsrNd0UnJaJg_mCgHNOcG6QE1Wrwp6zZ-YxOgDNu_aBE67HJkbemHz5Nz9c4=@protonmail.com> +From: Billy Tetrud <billy.tetrud@gmail.com> +Date: Thu, 27 May 2021 00:08:57 -1000 +Message-ID: <CAGpPWDZhxd_dGyFX1E5cPf_00LwyF_DqosvJm4QOr9X9TCyioQ@mail.gmail.com> +To: befreeandopen <befreeandopen@protonmail.com> +Content-Type: multipart/alternative; boundary="00000000000080c6f005c34cf331" +X-Mailman-Approved-At: Thu, 27 May 2021 21:10:33 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + SatoshiSingh <SatoshiSingh@protonmail.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: Thu, 27 May 2021 10:09:21 -0000 + +--00000000000080c6f005c34cf331 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +> using nothing at stake + +I see from the way you're using this term now that you mean something +completely different by it than I usually understand the phrase. You seem +to mean it as that minters can check whether they can mint a block without +any cost. By contrast, I generally understand the phrase to mean the +problem where there is no cost to broadcasting blocks on many different +chains. + +> she gained an extra block over the honest strategy which would only give +her block D + +I think I see what you're saying now. It actually sounds quite similar to +the selfish mining attack in proof of work. However I do acknowledge that +the ability to secretly mint on both your secret chain(s) and the public +chain makes it worse in PoS. How much worse is something that should be +quantified. This is also a solvable problem. Designing a secure system can +be kind of like whack a mole. You fix the weakest link in the chain, and +there is inevitably now a new weakest link that is stronger than the link +you fixed. Bitcoin is no different, as development continues, more security +improvements are implemented. + +In this case, there's a number of possible solutions, some of which can be +combined. Eg you can program all honest clients to mint selfishly. You'd +likely need to lengthen the number of blocks that constitute a finalized +transaction, but you can probably reduce the block time to compensate, so +finalization doesn't actually take longer. You could also require many +additional signatures on each block from outside validators. + +> How is that relevant to our discussion? + +It is relevant because the benefits of proof of stake must be compared to +an alternative, and the alternative of reference here is clearly PoW. I'm +pointing out that the vulnerability you're describing in the type of PoS +you're talking about also exists in what its being compared against. To +know whether PoS or PoW is better on this particular aspect, you need to +compare the levels of advantage that can be obtained in each, and how this +affects the cost of attacking the system. Its not as straight forward as +saying "PoS is bad because it has this vulnerability" when the system you +compare it to also has a very similar vulnerability. You need to quantify +the difference at that point. + +> the list of producers for next epoch is known up front and you confirmed +that this is what you meant with "quorum" system + +Known by public key, not by IP address. + +> (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT COMPLETELY) + +I agree that claiming that Y is a solved problem would be misleading if the +solution creates problems that are of greater significance than the +original problem. I would also agree that if the solution creates +significant problems that are substantially less significant than the +problem it solves, it would be misleading to say its a "solved problem" - +saying "partially solved" would be more accurate there. + +However, I do not agree that it is at all misleading to say "nothing at +stake is a solved problem" just because solving that specific problem +doesn't solve all the problems with proof of stake. Its unreasonable to +expect that when someone claims problem X is solved, that it also implies +all problems related to X are solved. + +I maintain that nothing at stake is a solved problem. There are solutions +that do not create other problems of anywhere near the same level of +significance. + +> 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 + +I don't believe we're in agreement there. I don't know how what you said +refutes my point. + +> I'm afraid you've not realized the burden of proof is on your side if you +vouch for a design that is not believed and trusted to be secure. + +You were the one that claimed proof of stake cannot be made secure. The +burden of proof is on you to support your own claims. + +> You have not described a system that would solve it + +I would be curious to hear a full critique from you about this protocol +<https://github.com/fresheneesz/ValidatedProofOfStake>. + +On Wed, May 26, 2021 at 3:12 AM befreeandopen <befreeandopen@protonmail.com= +> +wrote: + +> +> +> @befreeandopen I guess I misunderstood your selfish minting attack. Let m= +e +> make sure I understand it. You're saying it would go as follows?: +> +> 1. The malicious actor comes across an opportunity to mint the next 3 +> blocks. But they hold off and don't release their blocks just yet. +> 2. They receive a new block minted by someone else. +> 3. The malicious actor then chooses to release their other 2 blocks on on +> the second from the top block if it gives them more blocks in the future +> than minting on the top block. And instead lets the top block proceed if = +it +> gives them more blocks in the future (also figuring in the 3 blocks they'= +re +> missing out on minting). +> 4. Profit! +> +> The problem with this attack is that any self respecting PoS system +> wouldn't have the information available for minters to know how blocks wi= +ll +> affect their future prospects of minting. Otherwise this would introduce +> the problem of stake grinding. This can be done using collaborative +> randomness (where numbers from many parties are combined to create a rand= +om +> number that no individual party could predict). In fact, that's what the +> Casper protocol does to decide quorums. In a non quorum case, you can do +> something like record a hash of a number in the block header, and then ha= +ve +> a second step to release that number later. Rewards can be given can be +> used to ensure minters act honestly here by minting messages that release +> these numbers and not releasing their secret numbers too early. +> +> +> Yes, you misunderstood it. First, let me say that the above thoughts of +> yours are incorrect, at least for non-quorum case. Since the transition i= +n +> the blockchain system from S1 to S2 is only by adding new block, and sinc= +e +> stakers always need to be able to decide whether or not they can add the +> next block, it follows that if a staker creates a new block locally, she +> can decide whether the new state allows her to add another block on top. = +As +> you mentioned, this COULD introduce problem of staking, that you are +> incorrect in that it is a necessity. Usual prevention of the grinding +> problem in this case is that an "old enough" source of randomness applies +> for the current block production process. Of course this, as it is typica= +l +> for PoS, introduces other problems, but let's discard those. +> +> I will try to explain in detail what you misunderstood before. You start +> with a chain ending with blocks A-B-C, C being the top, the common featur= +e +> 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 amou= +nt +> 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 w= +ho +> has 1 coin. +> +> What i was claiming is that using the technique I have described, this +> linearity is violated. Why? Well, it works for honest stakers among the +> competition of honest stakers - they really do have the chance of K to fi= +nd +> the next block. However, the attacker, using nothing at stake, checks her +> ability to build block D (at some timestamp). If she is successful, she +> does not propagate D immediately, but instead she also checks whether she +> can build on top of B and on top of A. Since with every new timestamp, +> usually, there is a new chance to build the block, it is not uncommon tha= +t +> 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 i= +n +> 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 producin= +g +> C (which chance was limited by other stakers in the system and the +> discovery of block C by one of them). Now suppose that she found such C' +> and now she continues by trying to prolong this chain by finding D'. And +> again here, it is quite likely that her chance to find such D' is greater +> than was her chance of finding D because again there are likely multiple +> timestamps she could try. This all was possible just because nothing at +> stake allows you to just try if you can produce a block in certain state = +of +> block chain or not. Now if she actually was able to find D', she discards= + D +> and only publishes chain A-B-C'-D', which can not be punished despite the +> fact that she indeed produced two different forks. She can not be punishe= +d +> because this production was local and only the final result of A-B-C'-D' +> was published, in which case she gained an extra block over the honest +> strategy which would only give her block D. +> +> +> +> Fun fact tho: there is an attack called the "selfish mining attack" for +> proof of work, and it reduces the security of PoW by at least 1/3rd +> <https://bitcoinmagazine.com/technical/selfish-mining-a-25-attack-against= +-the-bitcoin-network-1383578440> +> . +> +> +> How is that relevant to our discussion? This is known research that has +> nothing to do with PoS except that it is often worse on PoS. +> +> +> +> > the problem is not as hard as you think +> +> I don't claim to know just how hard finding the IP address associated wit= +h +> a bitcoin address is. However, the DOS risk can be solved more completely +> by only allowing the owner of coins themselves to know whether they can +> mint a block. Eg by determining whether someone can mint a block based on +> their public key hidden behind hashes (as normal in addresses). Only when +> someone does in fact mint a block do they reveal their hidden public key = +in +> order to prove they are allowed to mint the block. +> +> +> This is true, but you are mixing quorum and non-quorum systems. My +> objection here was towards such system where I specifically said that the +> list of producers for next epoch is known up front and you confirmed that +> this is what you meant with "quorum" system. So in such system, I claimed= +, +> the known producer is the only target at any given point of time. This of +> course does not apply to any other type of system where future producers +> are not known. No need to dispute, again, something that was not claimed. +> +> +> +> +> > I agree that introduction of punishment itself does not imply +> introducing a problem elsewhere (which I did not claim if you reread my +> previous message) +> +> I'm glad we agree there. Perhaps I misunderstood what you meant by "you +> should not omit to mention that by doing so, typically, you have introduc= +ed +> another problem elsewhere." +> +> +> Perhaps you should quote the full sentence and not just a part of it: +> +> "Of course you can always change the rules in a way that a certain +> specific attack is not doable, but you should not omit to mention that by +> doing so, typically, you have introduced another problem elsewhere, or yo= +u +> have not solved it completely." +> +> You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT +> COMPLETELY) +> In case of the punishment it was meant to be the not solve it completely +> part. +> Also "typically" does not imply always. +> But this parsing of English sentences for you seems very off topic here. +> My point is, in context of Bitcoin, reject such unsupported claims that P= +oS +> is a reasonable alternative to PoW, let's stick to that. +> +> +> +> > As long as the staker makes sure (which is not that hard) that she does +> not miss a chance to create a block, her significance in the system will +> always increase in time. It will increase relative to all normal users wh= +o +> do not stake +> +> Well, if you're in the closed system of the cryptocurrency, sure. But we +> don't live in that closed system. Minters will earn some ROI from minting +> just like any other financial activity. Others may find more success +> spending their time doing things other than figuring out how to mint coin= +s. +> 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 wit= +h +> all existing coins participating is just theoretical, the attacker's +> position will ever so improve. It seems we are in agreement here, great. +> +> +> +> +> > Just because of the above we must reject PoS as being critically +> insecure +> +> I think the only thing we can conclude from this is that you have come up +> with an insecure proof of stake protocol. I don't see how anything you've +> brought up amounts to substantial evidence that all possible PoS protocol= +s +> are insecure. +> +> +> I have not come up with anything. I'm afraid you've not realized the +> burden of proof is on your side if you vouch for a design that is not +> believed and trusted to be secure. It is up to you to show that you know +> how to solve every problem that people throw at you. So far we have just +> demonstrated that your claim that nothing at stake is solved was +> unjustified. You have not described a system that would solve it (and not +> introduce critical DDOS attack vector as it is in quorum based systems - +> per the prior definition of such systems). +> +> Of course the list of problems of PoS systems do not end with just nothin= +g +> at stake, but it is good enough example that by itself prevents its +> adoption in decentralized consensus. No need to go to other hard problems +> without solving nothing at stake. +> +> +> +> +> +> On Tue, May 25, 2021 at 11:10 AM befreeandopen < +> befreeandopen@protonmail.com> wrote: +> +>> +>> @befreeandopen " An attacker can calculate whether or not she can prolon= +g +>> this chain or not and if so with what timestamp." +>> +>> The scenario you describe would only be likely to happen at all if the +>> malicious actor has a very large fraction of the stake - probably quite +>> close to 50%. At that point, you're talking about a 51% attack, not the +>> nothing at stake problem. The nothing at stake problem is the problem wh= +ere +>> 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 m= +int +>> on old blocks (until and if it becomes the heaviest chain). Because the +>> attacker would need probably >45% of the active stake (take a look at th= +e reasoning +>> here +>> <https://github.com/fresheneesz/ValidatedProofOfStake#security-the-minim= +um-cost-of-attack> +>> for a deeper analysis of that statement), I don't agree that punishment = +is +>> not a sufficient mitigation of the nothing at stake problem. To exploit = +the +>> nothing at stake problem, you basically need to 51% attack, at which poi= +nt +>> you've exceeded the operating conditions of the system, so of course its +>> gonna have problems, just like a 51% attack would cause with PoW. +>> +>> +>> This is not at all the case. The attacker benefits using the described +>> technique at any size of the stake and significantly so with just 5% of = +the +>> stake. By significantly, I do not mean that the attacker is able to +>> completely take control the network (in short term), but rather that the +>> attacker has significant advantage in the number of blocks she creates +>> compared to what she "should be able to create". This means the attacker= +'s +>> stake increases significantly faster than of the honest nodes, which in +>> long term is very serious in PoS system. If you believe close to 50% is +>> needed for that, you need to redo your math. So no, you are wrong statin= +g +>> that "to exploit nothing at stake problem you basically need to 51% +>> attack". It is rather the opposite - eventually, nothing at stake attack +>> leads to ability to perform 51% attack. +>> +>> +>> +>> > I am not sure if this is what you call quorum-based PoS +>> +>> Yes, pre-selected minters is exactly what I mean by that. +>> +>> > it allows the attacker to know who to attack at which point with +>> powerful DDOS in order to hurt liveness of such system +>> +>> Just like in bitcoin, associating keys with IP addresses isn't generally +>> an easy thing to do on the fly like that. If you know someone's IP addre= +ss, +>> you can target them. But if you only know their address or public key, t= +he +>> reverse isn't as easy. With a quorum-based PoS system, you can see their +>> public key and address, but finding out their IP to DOS would be a huge +>> challenge I think. +>> +>> +>> I do not dispute that the problem is not trivial, but the problem is not +>> as hard as you think. The network graph analysis is a known technique an= +d +>> it is not trivial, but not very hard either. Introducing a large number = +of +>> nodes to the system to achieve very good success rate of analysis of are= +a +>> of origin of blocks is doable and has been done in past. So again, I ver= +y +>> much disagree with your conclusion that this is somehow secure. It is +>> absolutely insecure. +>> +>> +>> +>> Note, tho, that quorum-based PoS generally also have punishments as part +>> of the protocol. The introduction of punishments do indeed handily solve +>> the nothing at stake problem. And you didn't mention a single problem th= +at +>> the punishments introduce that weren't already there before punishments. +>> There are tradeoffs with introducing punishments (eg in some cases you +>> might punish honest actors), but they are minor in comparison to solving +>> the nothing at stake problem. +>> +>> +>> While I agree that introduction of punishment itself does not imply +>> introducing a problem elsewhere (which I did not claim if you reread my +>> previous message), it does introduce additional complexity which may +>> introduce problem, but more importantly, while it slightly improves +>> resistance against the nothing at stake attack, it solves absolutely +>> nothing. Your claim is based on wrong claim of needed close to 50% stake= +, +>> but that could not be farther from the truth. It is not true even in +>> optimal conditions when all participants of the network stake or delegat= +e +>> their stake. These optimal conditions rarely, if ever, occur. And that's +>> another thing that we have not mention in our debate, so please allow me= + to +>> introduce another problem to PoS. +>> +>> Consider what is needed for such optimal conditions to occur - all coins +>> are always part of the stake, which means that they need to somehow +>> automatically part of the staking process even when they are moved. But = +in +>> many PoS systems you usually require some age (in terms of confirmations= +) +>> of the coin before you allow it to be used for participation in staking +>> process and that is for a good reason - to prevent various grinding +>> attacks. In some systems the coin must be specifically registered before= + it +>> can be staked, in others, simply waiting for enough confirmations enable= +s +>> you to stake with the coin. I am not sure if there is a system which doe= +s +>> 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 featur= +e. +>> +>> Then if we admit that achieving the optimal condition is rather +>> theoretical. Then if we do not have the optimal condition, it means that= + a +>> staker with K% of the total available supply increases it's percentage o= +ver +>> time to some amounts >K%. As long as the staker makes sure (which is not +>> that hard) that she does not miss a chance to create a block, her +>> significance in the system will always increase in time. It will increas= +e +>> relative to all normal users who do not stake (if there are any) and +>> relative to all other stakers who make mistakes or who are not wealthy +>> enough to afford not selling any position ever. But powerful attacker is +>> exactly in such position and thus she will gain significance in such a +>> system. The technique I have described, and that you mistakenly think is +>> viable only with huge amounts of stake, only puts the attacker to even +>> greater advantage. But even without the described attack (which exploits +>> nothing at stake), the PoS system converges to a system more and more +>> controlled by powerful entity, which we can assume is the attacker. +>> +>> +>> So I don't think it is at all misleading to claim that "nothing at stake= +" +>> is a solved problem. I do in fact mean that the solutions to that proble= +m +>> don't introduce any other problems with anywhere near the same level of +>> significance. +>> +>> +>> It still stands as truly misleading claim. I disagree that introducing +>> DDOS opportunity with medium level of difficulty for the attacker to +>> implement it, in case of "quorum-based PoS" is not a problem anywhere ne= +ar +>> the same level of significance. Such an attack vector allows you to turn +>> off the network if you spend some time and money. That is hardly accepta= +ble. +>> +>> Just because of the above we must reject PoS as being critically insecur= +e +>> until someone invents and demonstrates an actual way of solving these +>> 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, minimi= +zing +>>> their cost of attack. +>>> +>>> could be right. the original idea was to have burns decay over time, +>>> like ASIC's. +>>> +>>> anyway the point was not that "i had a magic formula" +>>> +>>> the point was that proof of burn is almost always better than proof of +>>> stake - simply because the "proof" is on-chain, not sitting on a node +>>> somewhere waiting to be stolen. +>>> +>>> On Mon, May 24, 2021 at 9:53 PM Billy Tetrud <billy.tetrud@gmail.com> +>>> wrote: +>>> > +>>> > Is this the kind of proof of burn you're talking about? +>>> > +>>> > > if i have a choice between two chains, one longer and one shorter= +, +>>> i can only choose one... deterministically +>>> > +>>> > What prevents you from attempting to mine block 553 on both chains? +>>> > +>>> > > miners have a very strong, long-term, investment in the stability o= +f +>>> the chain. +>>> > +>>> > Yes, but the same can be said of any coin, even ones that do have the +>>> nothing at stake problem. This isn't sufficient tho because the chain i= +s 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, minimi= +zing +>>> their cost of attack. +>>> > +>>> > > i can imagine scenarios where large stakeholders can collude to +>>> punish smaller stakeholders simply to drive them out of business, for +>>> example +>>> > +>>> > Are you talking about a 51% attack? This is possible in any +>>> decentralized cryptocurrency. +>>> > +>>> > +>>> > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty <erik@q32.com> wrote: +>>> >> +>>> >> > > your burn investment is always "at stake", any redaction can +>>> result in a loss-of-burn, because burns can be tied, precisely, to +>>> block-heights +>>> >> > I'm fuzzy on how proof of burn works. +>>> >> +>>> >> when you burn coins, you burn them to be used at a future particular +>>> >> block height: so if i'm burning for block 553, i can only use them t= +o +>>> >> mine block 553. if i have a choice between two chains, one longer +>>> >> and one shorter, i can only choose one... deterministically, for tha= +t +>>> >> burn: the chain with the height 553. if we fix the "lead time" for +>>> >> burned coins to be weeks or even months in advance, miners have a ve= +ry +>>> >> strong, long-term, investment in the stability of the chain. +>>> >> +>>> >> therefore there is no "nothing at stake" problem. it's +>>> >> deterministic, so miners have no choice. they can *only* choose the +>>> >> transactions that go into the block. they cannot choose which chain +>>> >> to mine, and it's time-locked, so rollbacks and instability always +>>> >> hurt miners the most. +>>> >> +>>> >> the "punishment" systems of PoS are "weird at best", certainly +>>> >> unproven. i can imagine scenarios where large stakeholders can +>>> >> collude to punish smaller stakeholders simply to drive them out of +>>> >> business, for example. and then you have to put checks in place to +>>> >> prevent that, and more checks for those prevention system... +>>> >> +>>> >> in PoB, there is no complexity. simpler systems like this are +>>> >> typically more secure. +>>> >> +>>> >> PoB also solves problems caused by "energy dependence", which could +>>> >> lead to state monopolies on mining (like the new Bitcoin Mining +>>> >> Council). these consortiums, if state sanctioned, could become a +>>> >> source of censorship, for example. Since PoB doesn't require you t= +o +>>> >> have a live, well-connected node, it's harder to censor & harder to +>>> >> trace. +>>> >> +>>> >> Eliminating this weakness seems to be in the best interests of +>>> >> existing stakeholders +>>> >> +>>> >> +>>> >> +>>> >> +>>> >> On Mon, May 24, 2021 at 4:44 PM Billy Tetrud <billy.tetrud@gmail.com= +> +>>> wrote: +>>> >> > +>>> >> > > proof of burn clearly solves this, since nothing is held online +>>> >> > +>>> >> > Well.. the coins to be burned need to be online when they're +>>> burned. But yes, only a small fraction of the total coins need to be on= +line. +>>> >> > +>>> >> > > your burn investment is always "at stake", any redaction can +>>> result in a loss-of-burn, because burns can be tied, precisely, to +>>> block-heights +>>> >> > +>>> >> > So you're saying that if say someone tries to mine a block on a +>>> shorter chain, that requires them to send a transaction burning their +>>> coins, and that transaction could also be spent on the longest chain, w= +hich +>>> means their coins are burned even if the chain they tried to mine on +>>> doesn't win? I'm fuzzy on how proof of burn works. +>>> >> > +>>> >> > > proof of burn can be more secure than proof-of-stake +>>> >> > +>>> >> > FYI, proof of stake can be done without the "nothing at stake" +>>> problem. You can simply punish people who mint on shorter chains (by +>>> rewarding people who publish proofs of this happening on the main chain= +). +>>> In quorum-based PoS, you can punish people in the quorum that propose o= +r +>>> sign multiple blocks for the same height. The "nothing at stake" proble= +m is +>>> a solved 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 requirement tha= +t +>>> the keys for large amounts of coins should be kept offline but those ar= +e +>>> exactly the coins we need online to make the scheme secure. +>>> >> >> +>>> >> >> proof of burn clearly solves this, since nothing is held online +>>> >> >> +>>> >> >> > how does proof of burn solve the "nothing at stake" problem in +>>> your view? +>>> >> >> +>>> >> >> definition of nothing at stake: in the event of a fork, whether t= +he +>>> >> >> fork is accidental or a malicious, the optimal strategy for any +>>> miner +>>> >> >> is to mine on every chain, so that the miner gets their reward no +>>> >> >> matter which fork wins. indeed in proof-of-stake, the proofs ar= +e +>>> >> >> published on the very chains mines, so the incentive is magnified= +. +>>> >> >> +>>> >> >> in proof-of-burn, your burn investment is always "at stake", any +>>> >> >> redaction can result in a loss-of-burn, because burns can be tied= +, +>>> >> >> precisely, to block-heights +>>> >> >> +>>> >> >> as a result, miners no longer have an incentive to mine all chain= +s +>>> >> >> +>>> >> >> in this way proof of burn can be more secure than proof-of-stake, +>>> and +>>> >> >> even more secure than proof of work +>>> >> >> +>>> >> >> +>>> >> >> +>>> >> >> +>>> >> >> +>>> >> >> +>>> >> >> +>>> >> >> > +>>> >> >> +>>> >> >> On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev +>>> >> >> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>>> >> >> > +>>> >> >> > Hi Billy, +>>> >> >> > +>>> >> >> > I was going to write a post which started by dismissing many of +>>> the weak arguments that are made against PoS made in this thread and +>>> elsewhere. +>>> >> >> > Although I don't agree with all your points you have done a +>>> decent job here so I'll focus on the second part: why I think +>>> Proof-of-Stake is inappropriate for a Bitcoin-like system. +>>> >> >> > +>>> >> >> > Proof of stake is not fit for purpose for a global settlement +>>> layer in a pure digital asset (i.e. "digital gold") which is what Bitco= +in +>>> is trying to be. +>>> >> >> > PoS necessarily gives responsibilities to the holders of coins +>>> that they do not want and cannot handle. +>>> >> >> > In Bitcoin, large unsophisticated coin holders can put their +>>> coins in cold storage without a second thought given to the health of t= +he +>>> underlying ledger. +>>> >> >> > As much as hardcore Bitcoiners try to convince them to run thei= +r +>>> own node, most don't, and that's perfectly acceptable. +>>> >> >> > At no point do their personal decisions affect the underlying +>>> consensus -- it only affects their personal security assurance (not tha= +t of +>>> the system itself). +>>> >> >> > In PoS systems this clean separation of responsibilities does +>>> not exist. +>>> >> >> > +>>> >> >> > I think that the more rigorously studied PoS protocols will wor= +k +>>> fine within the security claims made in their papers. +>>> >> >> > People who believe that these protocols are destined for +>>> catastrophic consensus failure are certainly in for a surprise. +>>> >> >> > But the devil is in the detail. +>>> >> >> > Let's look at what the implications of using the leading proof +>>> of stake protocols would have on Bitcoin: +>>> >> >> > +>>> >> >> > ### Proof of SquareSpace (Cardano, Polkdadot) +>>> >> >> > +>>> >> >> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] +>>> with an inbuilt on-chain delegation system[5]. +>>> >> >> > In these protocols, coin holders who do not want to run their +>>> node with their hot keys in it delegate it to a "Stake Pool". +>>> >> >> > I call the resulting system Proof-of-SquareSpace since most wil= +l +>>> choose a pool by looking around for one with a nice website and offerin= +g +>>> the largest share of the block reward. +>>> >> >> > On the surface this might sound no different than someone with +>>> an mining rig shopping around for a good mining pool but there are cruc= +ial +>>> differences: +>>> >> >> > +>>> >> >> > 1. The person making the decision is forced into it just becaus= +e +>>> they own the currency -- someone with a mining rig has purchased it wit= +h +>>> the intent to make profit by participating in consensus. +>>> >> >> > +>>> >> >> > 2. When you join a mining pool your systems are very much still +>>> online. You are just partaking in a pool to reduce your profit variance= +. +>>> You still see every block that you help create and *you never help crea= +te a +>>> block without seeing it first*. +>>> >> >> > +>>> >> >> > 3. If by SquareSpace sybil attack you gain a dishonest majority +>>> and start censoring transactions how are the users meant to redelegate +>>> their stake to honest pools? +>>> >> >> > I guess they can just send a transaction delegating to another +>>> pool...oh wait I guess that might be censored too! This seems really re= +ally +>>> bad. +>>> >> >> > In Bitcoin, miners can just join a different pool at a whim. +>>> There is nothing the attacker can do to stop them. A temporary dishones= +t +>>> majority heals relatively well. +>>> >> >> > +>>> >> >> > There is another severe disadvantage to this on-chain delegatio= +n +>>> system: every UTXO must indicate which staking account this UTXO belong= +s to +>>> so the appropriate share of block rewards can be transferred there. +>>> >> >> > Being able to associate every UTXO to an account ruins one of +>>> the main privacy advantages of the UTXO model. +>>> >> >> > It also grows the size of the blockchain significantly. +>>> >> >> > +>>> >> >> > ### "Pure" proof of stake (Algorand) +>>> >> >> > +>>> >> >> > Algorand's[4] approach is to only allow online stake to +>>> participate in the protocol. +>>> >> >> > Theoretically, This means that keys holding funds have to be +>>> online in order for them to author blocks when they are chosen. +>>> >> >> > Of course in reality no one wants to keep their coin holding +>>> keys online so in Alogorand you can authorize a set of "participation +>>> keys"[1] that will be used to create blocks on your coin holding key's +>>> behalf. +>>> >> >> > Hopefully you've spotted the problem. +>>> >> >> > You can send your participation keys to any malicious party wit= +h +>>> a nice website (see random example [2]) offering you a good return. +>>> >> >> > Damn it's still Proof-of-SquareSpace! +>>> >> >> > The minor advantage is that at least the participation keys +>>> expire after a certain amount of time so eventually the SquareSpace +>>> attacker will lose their hold on consensus. +>>> >> >> > Importantly there is also less junk on the blockchain because +>>> the participation keys are delegated off-chain and so are not making as +>>> much of a mess. +>>> >> >> > +>>> >> >> > ### Conclusion +>>> >> >> > +>>> >> >> > I don't see a way to get around the conflicting requirement tha= +t +>>> the keys for large amounts of coins should be kept offline but those ar= +e +>>> exactly the coins we need online to make the scheme secure. +>>> >> >> > If we allow delegation then we open up a new social attack +>>> surface and it degenerates to Proof-of-SquareSpace. +>>> >> >> > +>>> >> >> > For a "digital gold" like system like Bitcoin we optimize for +>>> simplicity and desperately want to avoid extraneous responsibilities fo= +r +>>> the holder of the coin. +>>> >> >> > After all, gold is an inert element on the periodic table that +>>> doesn't confer responsibilities on the holder to maintain the quality o= +f +>>> all the other bars of gold out there. +>>> >> >> > Bitcoin feels like this too and in many ways is more inert and +>>> beautifully boring than gold. +>>> >> >> > For Bitcoin to succeed I think we need to keep it that way and +>>> Proof-of-Stake makes everything a bit too exciting. +>>> >> >> > +>>> >> >> > I suppose in the end the market will decide what is real digita= +l +>>> gold and whether these bad technical trade offs are worth being able to= + say +>>> it uses less electricity. It goes without saying that making bad techni= +cal +>>> decisions to appease the current political climate is an anathema to +>>> Bitcoin. +>>> >> >> > +>>> >> >> > Would be interested to know if you or others think differently +>>> on these points. +>>> >> >> > +>>> >> >> > [1]: +>>> https://developer.algorand.org/docs/run-a-node/participate/generate_key= +s/ +>>> >> >> > [2]: https://staking.staked.us/algorand-staking +>>> >> >> > [3]: https://eprint.iacr.org/2017/573.pdf +>>> >> >> > [4]: +>>> https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7= +f-805f0e53a8d9_theoretical.pdf +>>> >> >> > [5]: +>>> https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pd= +f +>>> >> >> > +>>> >> >> > Cheers, +>>> >> >> > +>>> >> >> > LL +>>> >> >> > +>>> >> >> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev < +>>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>>> >> >> >> +>>> >> >> >> I think there is a lot of misinformation and bias against Proo= +f +>>> of Stake. Yes there have been lots of shady coins that use insecure PoS +>>> mechanisms. Yes there have been massive issues with distribution of PoS +>>> coins (of course there have also been massive issues with PoW coins as +>>> well). However, I want to remind everyone that there is a difference +>>> between "proved to be impossible" and "have not achieved recognized suc= +cess +>>> yet". Most of the arguments levied against PoS are out of date or rely = +on +>>> unproven assumptions or extrapolation from the analysis of a particular= + PoS +>>> system. I certainly don't think we should experiment with bitcoin by +>>> switching to PoS, but from my research, it seems very likely that there= + is +>>> a proof of stake consensus protocol we could build that has substantial= +ly +>>> higher security (cost / capital required to execute an attack) while at= + the +>>> same time costing far less resources (which do translate to fees on the +>>> network) *without* compromising any of the critical security properties +>>> bitcoin relies on. I think the critical piece of this is the disagreeme= +nts +>>> around hardcoded checkpoints, which is a critical piece solving attacks +>>> that could be levied on a PoS chain, and how that does (or doesn't) aff= +ect +>>> the security model. +>>> >> >> >> +>>> >> >> >> @Eric Your proof of stake fallacy seems to be saying that PoS +>>> is worse when a 51% attack happens. While I agree, I think that line of +>>> thinking omits important facts: +>>> >> >> >> * The capital required to 51% attack a PoS chain can be made +>>> substantially greater than on a PoS chain. +>>> >> >> >> * The capital the attacker stands to lose can be substantially +>>> greater as well if the attack is successful. +>>> >> >> >> * The effectiveness of paying miners to raise the honest +>>> fraction of miners above 50% may be quite bad. +>>> >> >> >> * Allowing a 51% attack is already unacceptable. It should be +>>> considered whether what happens in the case of a 51% may not be +>>> significantly different. The currency would likely be critically damage= +d 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 awa= +re +>>> of. IE if you have 10 times as much coin that you use to mint blocks, y= +ou +>>> 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 th= +e +>>> centralization pressure remains insignifiant. Proof of work also clearl= +y +>>> has a lot more barriers to entry than any proof of stake system does. B= +oth +>>> of these mean the tendency towards oligopolistic control is worse for P= +oW. +>>> >> >> >> +>>> >> >> >> > Energy usage, in-and-of-itself, is nothing to be ashamed of!= +! +>>> >> >> >> +>>> >> >> >> I certainly agree. Bitcoin's energy usage at the moment is I +>>> think quite warranted. However, the question is: can we do substantiall= +y +>>> 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 t= +o +>>> 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 requirem= +ent. +>>> However there are PoS designs that should exceed that up to nearly 50% = +as +>>> far as I'm aware. Proof of work is not in fact resilient up to the 1/2 +>>> threshold in the way you would think. IE, if 100% of miners are current= +ly +>>> honest and have a collective 100 exahashes/s hashpower, an attacker doe= +s +>>> not need to obtain 100 exahashes/s, but actually only needs to accumula= +te +>>> 50 exahashes/s. This is because as the attacker accumulates hashpower, = +it +>>> drives honest miners out of the market as the difficulty increases to +>>> beyond what is economically sustainable. Also, its been shown that the = +best +>>> proof of work can do is require an attacker to obtain 33% of the hashpo= +wer +>>> because of the selfish mining attack discussed in depth in this paper: +>>> https://arxiv.org/abs/1311.0243. Together, both of these things reduce +>>> PoW's security by a factor of about 83% (1 - 50%*33%). +>>> >> >> >> +>>> >> >> >> > Proof of Stake requires other trade-offs which are +>>> incompatible with Bitcoin's objective (to be a trustless digital cash) = +=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 choosing to give up +>>> those coins - a form of permission. +>>> >> >> >> +>>> >> >> >> This is not a practical constraint. Just like in mining, some +>>> nodes may reject you, but there will likely be more that will accept yo= +u, +>>> some sellers may reject you, but most would accept your money as paymen= +t +>>> for bitcoins. I don't think requiring the "permission" of one of millio= +ns +>>> of people in the market can be reasonably considered a "permissioned +>>> currency". +>>> >> >> >> +>>> >> >> >> > 2. Proof of stake must have a trusted means of timestamping +>>> to regulate overproduction of blocks +>>> >> >> >> +>>> >> >> >> Both PoW and PoS could mine/mint blocks twice as fast if +>>> everyone agreed to double their clock speeds. Both systems rely on an +>>> honest majority sticking to standard time. +>>> >> >> >> +>>> >> >> >> +>>> >> >> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via +>>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: +>>> >> >> >>> +>>> >> >> >>> Ah sorry, I didn't realize this was, in fact, a different +>>> thread! :) +>>> >> >> >>> +>>> >> >> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky < +>>> mike@powx.org> wrote: +>>> >> >> >>>> +>>> >> >> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and th= +e +>>> BIP itself. PoS, VDFs, and so on are interesting but I guess there are +>>> other threads going on these topics already where they would be relevan= +t. +>>> >> >> >>>> +>>> >> >> >>>> Also, it's important to distinguish between oPoW and these +>>> other "alternatives" to Hashcash. oPoW is a true Proof of Work that doe= +sn't +>>> alter the core game theory or security assumptions of Hashcash and actu= +ally +>>> 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-de= +v +>>> <bitcoin-dev@lists.linuxfoundation.org> wrote: +>>> >> >> >>>>> +>>> >> >> >>>>> 1. i never suggested vdf's to replace pow. +>>> >> >> >>>>> +>>> >> >> >>>>> 2. my suggestion was specifically *in the context of* a +>>> working +>>> >> >> >>>>> proof-of-burn protocol +>>> >> >> >>>>> +>>> >> >> >>>>> - vdfs used only for timing (not block height) +>>> >> >> >>>>> - blind-burned coins of a specific age used to replace proo= +f +>>> of work +>>> >> >> >>>>> - the required "work" per block would simply be a +>>> competition to +>>> >> >> >>>>> acquire rewards, and so miners would have to burn coins, +>>> well in +>>> >> >> >>>>> advance, and hope that their burned coins got rewarded in +>>> some far +>>> >> >> >>>>> future +>>> >> >> >>>>> - the point of burned coins is to mimic, in every meaningfu= +l +>>> way, the +>>> >> >> >>>>> value gained from proof of work... without some of the +>>> security +>>> >> >> >>>>> drawbacks +>>> >> >> >>>>> - the miner risks losing all of his burned coins (like all +>>> miners risk +>>> >> >> >>>>> losing their work in each block) +>>> >> >> >>>>> - new burns can't be used +>>> >> >> >>>>> - old burns age out (like ASICs do) +>>> >> >> >>>>> - other requirements on burns might be needed to properly +>>> mirror the +>>> >> >> >>>>> properties of PoW and the incentives Bitcoin uses to mine +>>> honestly. +>>> >> >> >>>>> +>>> >> >> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf +>>> system" +>>> >> >> >>>>> might be more secure in the long run, and that if the entir= +e +>>> 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 a= +n +>>> "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 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 block times, for +>>> instance by having a two-step PoW: +>>> >> >> >>>>> >> > +>>> >> >> >>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF +>>> being subject to difficulty adjustments similar to the as-is). As per t= +he +>>> property of VDFs, miners are able show proof of work. +>>> >> >> >>>>> >> > +>>> >> >> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so +>>> finding a block takes 1 minute on average, again subject to as-is +>>> difficulty adjustments. +>>> >> >> >>>>> >> > +>>> >> >> >>>>> >> > As a result, variation in block times will be greatly +>>> reduced. +>>> >> >> >>>>> >> +>>> >> >> >>>>> >> As I understand it, another weakness of VDFs is that the= +y +>>> are not inherently progress-free (their sequential nature prevents that= +; +>>> they are inherently progress-requiring). +>>> >> >> >>>>> >> +>>> >> >> >>>>> >> Thus, a miner which focuses on improving the amount of +>>> energy that it can pump into the VDF circuitry (by overclocking and +>>> freezing the circuitry), could potentially get into a winner-takes-all +>>> situation, possibly leading to even *worse* competition and even *more* +>>> energy consumption. +>>> >> >> >>>>> >> After all, if you can start mining 0.1s faster than the +>>> competition, that is a 0.1s advantage where *only you* can mine *in the +>>> entire world*. +>>> >> >> >>>>> >> +>>> >> >> >>>>> >> Regards, +>>> >> >> >>>>> >> ZmnSCPxj +>>> >> >> >>>>> _______________________________________________ +>>> >> >> >>>>> bitcoin-dev mailing list +>>> >> >> >>>>> bitcoin-dev@lists.linuxfoundation.org +>>> >> >> >>>>> +>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>> >> >> >>>> +>>> >> >> >>>> +>>> >> >> >>>> +>>> >> >> >>>> -- +>>> >> >> >>>> Michael Dubrovsky +>>> >> >> >>>> Founder; PoWx +>>> >> >> >>>> www.PoWx.org +>>> >> >> >>> +>>> >> >> >>> +>>> >> >> >>> +>>> >> >> >>> -- +>>> >> >> >>> Michael Dubrovsky +>>> >> >> >>> Founder; PoWx +>>> >> >> >>> www.PoWx.org +>>> >> >> >>> _______________________________________________ +>>> >> >> >>> bitcoin-dev mailing list +>>> >> >> >>> bitcoin-dev@lists.linuxfoundation.org +>>> >> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de= +v +>>> >> >> >> +>>> >> >> >> _______________________________________________ +>>> >> >> >> bitcoin-dev mailing list +>>> >> >> >> bitcoin-dev@lists.linuxfoundation.org +>>> >> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>> >> >> > +>>> >> >> > _______________________________________________ +>>> >> >> > bitcoin-dev mailing list +>>> >> >> > bitcoin-dev@lists.linuxfoundation.org +>>> >> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>> +>> +>> +> + +--00000000000080c6f005c34cf331 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">>=C2=A0 + +using nothing at stake<div><br></div><div>I see from the way you're usi= +ng this term now that you mean something completely different by it than I = +usually understand the phrase. You seem to mean it as that minters can chec= +k whether=C2=A0they can mint a block without any cost. By contrast, I gener= +ally understand the phrase to mean the problem where there is no cost to br= +oadcasting blocks on many different chains.=C2=A0</div><div><br></div><div>= +> she gained an extra block over the honest strategy which would only gi= +ve her block D</div><div><br></div><div>I think I see what you're sayin= +g now. It actually sounds quite similar to the selfish mining attack in pro= +of of work. However I do acknowledge=C2=A0that the ability to secretly mint= + on both your secret chain(s) and the public chain makes it worse in PoS. H= +ow much worse is something that should be quantified. This is also a solvab= +le problem. Designing a secure system can be kind of like whack a mole. You= + fix the weakest link in the chain, and there is inevitably now a new weake= +st link that is stronger than the link you fixed. Bitcoin is no different, = +as development continues, more security improvements are implemented.=C2=A0= +</div><div><br></div><div>In this case, there's a number of possible so= +lutions, some of which can be combined. Eg you can program all honest clien= +ts to mint selfishly. You'd likely need to lengthen the number of block= +s that constitute a finalized transaction, but you can probably reduce the = +block time to compensate, so finalization doesn't actually take longer.= + You could also require many additional signatures on each block from outsi= +de validators.</div><div><div></div><div><br></div><div>> How is that re= +levant to our discussion?</div><div><br></div><div>It is relevant because t= +he benefits of proof of stake must be compared to an alternative, and the a= +lternative of reference here is clearly PoW. I'm pointing out that the = +vulnerability you're describing in the type of PoS you're talking a= +bout also exists in what its being compared against. To know whether PoS or= + PoW is better on this particular aspect, you need to compare the levels of= + advantage that can be obtained in each, and how this affects the cost of a= +ttacking the system. Its not as straight forward as saying "PoS is bad= + because it has this vulnerability" when the system you compare it to = +also has a very similar vulnerability. You need to quantify the difference = +at that point.=C2=A0</div></div><div><br></div><div>> the list of produc= +ers for next epoch is known up front and you confirmed that this is what yo= +u meant with "quorum" system</div><div><br></div><div>Known by pu= +blic key, not by IP address.</div><div><br></div><div>> (CREATE PROBLEM = +ELSEWHERE) OR (NOT SOLVE IT COMPLETELY)</div><div><br></div><div>I agree th= +at claiming that Y is a solved problem would be misleading if the solution = +creates problems that are of greater significance than the original problem= +. I would also agree that if the solution creates significant problems that= + are substantially less significant than the problem it solves, it would be= + misleading to say its a "solved problem" - saying "partiall= +y solved" would be more accurate there.</div><div><br></div><div>Howev= +er, I do not agree that it is at all misleading to say "nothing at sta= +ke is a solved problem" just because solving that specific problem doe= +sn't solve all the problems with proof of stake. Its unreasonable to ex= +pect that when someone claims problem X is solved, that it also implies all= + problems related to X are solved.=C2=A0</div><div><br></div><div>I maintai= +n that nothing at stake is a solved problem. There are solutions that do no= +t create other problems of=C2=A0anywhere near the same level of significanc= +e.</div><div><br></div><div>> Since the optimal scenario with all existi= +ng coins participating is just theoretical, the attacker's position wil= +l ever so improve. It seems we are in agreement here, great</div><div><br><= +/div><div>I don't believe we're in agreement there. I don't kno= +w how what you said refutes my point.=C2=A0</div><div><br></div><div>> I= +'m afraid you've not realized the burden of proof is on your side i= +f you vouch for a design that is not believed and trusted to be secure.</di= +v><div><br></div><div>You were the one that claimed proof of stake cannot b= +e made secure. The burden of proof is on you to support your own claims.=C2= +=A0</div><div><br></div><div>> You have not described a system that woul= +d solve it=C2=A0</div><div><br></div><div>I would be curious to hear a full= + critique from you about=C2=A0<a href=3D"https://github.com/fresheneesz/Val= +idatedProofOfStake" target=3D"_blank">this protocol</a>.=C2=A0<br></div></d= +iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On = +Wed, May 26, 2021 at 3:12 AM befreeandopen <<a href=3D"mailto:befreeando= +pen@protonmail.com" target=3D"_blank">befreeandopen@protonmail.com</a>> = +wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= +px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>= +</div><div> <br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div>@befr= +eeandopen I guess I misunderstood your selfish minting attack. Let me make = +sure I understand it. You're saying it would go as follows?:<br></div><= +div><br></div><div>1. The malicious actor comes across an opportunity to mi= +nt the next 3 blocks. But they hold off and don't release their blocks = +just yet.<br></div><div>2. They receive a new block minted by someone else.= +=C2=A0<br></div><div>3. The + +malicious actor then chooses to release their other 2 blocks on on the seco= +nd from the top block if it gives them more blocks in the future than minti= +ng on the top block. And instead lets the=C2=A0top block proceed if it give= +s them more blocks in the future (also figuring in the 3 blocks they're= + missing out on minting).<br></div><div>4. Profit!<br></div><div><br></div>= +<div>The problem with this attack is that any self respecting PoS system wo= +uldn't have the information available for minters to know how blocks wi= +ll affect their future prospects of minting. Otherwise this would introduce= + the problem of stake grinding. This can be done using collaborative random= +ness (where numbers from many parties are combined to create a random numbe= +r that no individual party could predict). In fact, that's what the Cas= +per protocol does to decide quorums. In a non quorum case, you can do somet= +hing like record a hash of a number in the block header, and then have a se= +cond step to release that number later. + +Rewards can be given can be used to ensure minters act honestly here by min= +ting messages that release these numbers and not releasing their secret num= +bers too early.<br></div></div></blockquote><div><br></div><div>Yes, you mi= +sunderstood it. First, let me say that the above thoughts of yours are inco= +rrect, at least for non-quorum case. Since the transition in the blockchain= + system from S1 to S2 is only by adding new block, and since stakers always= + need to be able to decide whether or not they can add the next block, it f= +ollows that if a staker creates a new block locally, she can decide whether= + the new state allows her to add another block on top. As you mentioned, th= +is COULD introduce problem of staking, that you are incorrect in that it is= + a necessity. Usual prevention of the grinding problem in this case is that= + an "old enough" source of randomness applies for the current blo= +ck production process. Of course this, as it is typical for PoS, introduces= + other problems, but let's discard those.<br></div><div><br></div><div>= +I will try to explain in detail what you misunderstood before. You start wi= +th a chain ending with blocks A-B-C, C being the top, the common feature of= + PoS system (non-quorum), roughly speaking, is that if N is the total amoun= +t of coins that participate in the staking process to create a new block on= + top of C (let's call that D), then a participant having K*N amount of = +stake has chance K to be the one who will create the next stake. In other w= +ords, the power of stakers is supposed to be linear in the system - you own= + 10 coins gives you 10x the chance of finding block over someone who has 1 = +coin.<br></div><div><br></div><div>What i was claiming is that using the te= +chnique I have described, this linearity is violated. Why? Well, it works f= +or 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 n= +othing at stake, checks her ability to build block D (at some timestamp). I= +f she is successful, she does not propagate D immediately, but instead she = +also checks whether she can build on top of B and on top of A. Since with e= +very new timestamp, usually, there is a new chance to build the block, it i= +s 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 rel= +atively 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 timestam= +ps up to t(B) (usually that's the consensus rule, but it may depend on = +a specific consensus). So her chance to produce such C' is greater than= + her previous chance of producing C (which chance was limited by other stak= +ers 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 chan= +ce to find such D' is greater than was her chance of finding D because = +again there are likely multiple timestamps she could try. This all was poss= +ible just because nothing at stake allows you to just try if you can produc= +e a block in certain state of block chain or not. Now if she actually was a= +ble to find D', she discards D and only publishes chain A-B-C'-D= +9;, which can not be punished despite the fact that she indeed produced two= + different forks. She can not be punished because this production was local= + and only the final result of A-B-C'-D' was published, in which cas= +e she gained an extra block over the honest strategy which would only give = +her block D. <br></div><div><br></div><div><br></div><div><br></div><blockq= +uote type=3D"cite"><div dir=3D"ltr"><div>Fun fact tho: there is an attack c= +alled the "selfish mining attack" for proof of work, and it reduc= +es the security of PoW by <a href=3D"https://bitcoinmagazine.com/technical/= +selfish-mining-a-25-attack-against-the-bitcoin-network-1383578440" target= +=3D"_blank">at least 1/3rd</a>.=C2=A0<br></div></div></blockquote><div><br>= +</div><div>How is that relevant to our discussion? This is known research t= +hat has nothing to do with PoS except that it is often worse on PoS.<br></d= +iv><div><br></div><div><br></div><div><br></div><blockquote type=3D"cite"><= +div dir=3D"ltr"><div>>=C2=A0 + +=C2=A0the problem is not as hard as you think<br></div><div><br></div><div>= +I don't claim to know just how hard finding the IP address associated w= +ith a bitcoin address is. However, the DOS risk can be solved more complete= +ly by only allowing the owner of coins themselves to know whether they can = +mint a block. Eg by determining whether someone can mint a block based on t= +heir public key hidden behind hashes (as normal in addresses). Only when so= +meone does in fact mint a block do they reveal their hidden public key in o= +rder to prove they are allowed to mint the block.=C2=A0<br></div></div></bl= +ockquote><div><br></div><div>This is true, but you are mixing quorum and no= +n-quorum systems. My objection here was towards such system where I specifi= +cally said that the list of producers for next epoch is known up front and = +you confirmed that this is what you meant with "quorum" system. S= +o in such system, I claimed, the known producer is the only target at any g= +iven point of time. This of course does not apply to any other type of syst= +em where future producers are not known. No need to dispute, again, somethi= +ng that was not claimed.<br></div><div><br></div><div><br></div><div><br></= +div><blockquote type=3D"cite"><div dir=3D"ltr"><div><br></div><div>> I a= +gree that introduction of punishment itself does not imply introducing a pr= +oblem elsewhere (which I did not claim if you reread my previous message)<b= +r></div><div><br></div><div>I'm glad we agree there. Perhaps I misunder= +stood what you meant by "you should not omit to mention that by doing = +so, typically, you have introduced another problem elsewhere."<br></di= +v></div></blockquote><div><br></div><div>Perhaps you should quote the full = +sentence and not just a part of it:<br></div><div><br></div><div>"Of c= +ourse you can always change the rules in a way that a certain +specific attack is not doable, but you should not omit to mention that +by doing so, typically, you have introduced another problem elsewhere, +or you have not solved it completely."<br></div><div><br></div><div>Yo= +u can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT COMPLETELY= +)<br></div><div>In case of the punishment it was meant to be the not solve = +it completely part.<br></div><div>Also "typically" does not imply= + always.<br></div><div>But this parsing of English sentences for you seems = +very off topic here. My point is, in context of Bitcoin, reject such unsupp= +orted claims that PoS is a reasonable alternative to PoW, let's stick t= +o that. <br></div><div><br></div><div><br></div><div><br></div><blockquote = +type=3D"cite"><div dir=3D"ltr"><div>> 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 increa= +se relative to all normal users who do not stake<br></div><div><br></div><d= +iv>Well, if you're in the closed system of the cryptocurrency, sure. Bu= +t 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 succes= +s spending their time doing things other than figuring out how to mint coin= +s. In that case, they'll be able to earn more coin that they could late= +r decide to use to mint blocks if they decide to.=C2=A0<br></div></div></bl= +ockquote><div><br></div><div>This only supports the point I was making. Sin= +ce the optimal scenario with all existing coins participating is just theor= +etical, the attacker's position will ever so improve. It seems we are i= +n agreement here, great.<br></div><div><br></div><div><br></div><div><br></= +div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div>> Jus= +t because of the above we must reject PoS as being critically insecure=C2= +=A0<br></div><div><br></div><div>I think the only thing we can conclude fro= +m this is that you have come up with an insecure proof of stake protocol. I= + don't see how anything you've brought up amounts to substantial ev= +idence that all possible PoS protocols are insecure.=C2=A0<br></div></div><= +/blockquote><div><br></div><div>I have not come up with anything. I'm a= +fraid you've not realized the burden of proof is on your side if you vo= +uch for a design that is not believed and trusted to be secure. It is up to= + you to show that you know how to solve every problem that people throw at = +you. So far we have just demonstrated that your claim that nothing at stake= + is solved was unjustified. You have not described a system that would solv= +e it (and not introduce critical DDOS attack vector as it is in quorum base= +d systems - per the prior definition of such systems). <br></div><div><br><= +/div><div>Of course the list of problems of PoS systems do not end with jus= +t nothing at stake, but it is good enough example that by itself prevents i= +ts adoption in decentralized consensus. No need to go to other hard problem= +s without solving nothing at stake.<br></div><div><br></div><div><br></div>= +<div><br></div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><d= +iv><br></div></div><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, May = +25, 2021 at 11:10 AM befreeandopen <<a href=3D"mailto:befreeandopen@prot= +onmail.com" target=3D"_blank">befreeandopen@protonmail.com</a>> wrote:<b= +r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= +;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><b= +lockquote type=3D"cite"><div dir=3D"ltr"><div>@befreeandopen " + +An attacker can calculate whether or not she can prolong this chain or not = +and if so with what timestamp."<br></div><div><br></div><div>The scena= +rio you describe would only be likely to happen at all if the malicious act= +or 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 stak= +e problem. The nothing at stake problem is the problem where anyone will mi= +nt 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 wi= +thout a significant fraction of the stake will be honest and not attempt to= + mint on old blocks or support someone else's attempt to mint on old bl= +ocks (until and if it becomes the heaviest chain). Because the attacker wou= +ld need probably >45% of the active stake (take a look at the <a href=3D= +"https://github.com/fresheneesz/ValidatedProofOfStake#security-the-minimum-= +cost-of-attack" target=3D"_blank">reasoning here</a> for a deeper analysis = +of that statement), I don't agree that punishment=C2=A0is not a suffici= +ent mitigation of the nothing at stake problem. To exploit the nothing at s= +take problem, you basically need to 51% attack, at which point you've e= +xceeded the operating conditions of the system, so of course its gonna have= + problems, just like a 51% attack would cause with PoW.<br></div></div></bl= +ockquote><div><br></div><div>This is not at all the case. The attacker bene= +fits using the described technique at any size of the stake and significant= +ly so with just 5% of the stake. By significantly, I do not mean that the a= +ttacker is able to completely take control the network (in short term), but= + rather that the attacker has significant advantage in the number of blocks= + she creates compared to what she "should be able to create". Thi= +s means the attacker's stake increases significantly faster than of the= + honest nodes, which in long term is very serious in PoS system. If you bel= +ieve close to 50% is needed for that, you need to redo your math. So no, y= +ou are wrong stating that "to exploit nothing at stake problem you bas= +ically need to 51% attack". It is rather the opposite - eventually, no= +thing at stake attack leads to ability to perform 51% attack.<br></div><div= +><br></div><div><br></div><div><br></div><blockquote type=3D"cite"><div dir= +=3D"ltr"><div>> I am not sure if this is what you call quorum-based PoS<= +br></div><div><br></div><div>Yes, pre-selected minters is exactly what I me= +an by that.<br></div><div><br></div><div>> it allows the attacker to kno= +w who to attack at which point with powerful DDOS in order to hurt liveness= + of such system<br></div><div><br></div><div>Just like in bitcoin, associat= +ing keys with IP addresses isn't generally an easy thing to do on the f= +ly like that. If you know someone's IP address, you can target them. Bu= +t if you only know their address or public key, the reverse isn't as ea= +sy. With a quorum-based PoS system, you can see their public key and addres= +s, but finding out their IP to DOS would be a huge challenge I think.=C2=A0= +<br></div></div></blockquote><div><br></div><div>I do not dispute that the = +problem is not trivial, but the problem is not as hard as you think. The ne= +twork graph analysis is a known technique and it is not trivial, but not ve= +ry hard either. Introducing a large number of nodes to the system to achiev= +e very good success rate of analysis of area of origin of blocks is doable = +and has been done in past. So again, I very much disagree with your conclus= +ion that this is somehow secure. It is absolutely insecure.<br></div><div><= +br></div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div><br= +></div><div>Note, tho, that quorum-based PoS generally also have punishment= +s as part of the protocol. The introduction of punishments do indeed handil= +y solve the nothing at stake problem. And you didn't mention a single p= +roblem that the punishments introduce that weren't already there before= + punishments. There are tradeoffs with introducing punishments (eg in some = +cases you might punish honest actors), but they are minor in comparison to = +solving the nothing at stake problem.<br></div></div></blockquote><div><br>= +</div><div>While I agree that introduction of punishment itself does not im= +ply introducing a problem elsewhere (which I did not claim if you reread my= + previous message), it does introduce additional complexity which may intro= +duce problem, but more importantly, while it slightly improves resistance a= +gainst the nothing at stake attack, it solves absolutely nothing. Your clai= +m is based on wrong claim of needed close to 50% stake, but that could not = +be farther from the truth. It is not true even in optimal conditions when a= +ll participants of the network stake or delegate their stake. These optimal= + conditions rarely, if ever, occur. And that's another thing that we ha= +ve not mention in our debate, so please allow me to introduce another probl= +em to PoS.<br></div><div><br></div><div>Consider what is needed for such op= +timal conditions to occur - all coins are always part of the stake, which m= +eans that they need to somehow automatically part of the staking process ev= +en when they are moved. But in many PoS systems you usually require some ag= +e (in terms of confirmations) of the coin before you allow it to be used fo= +r participation in staking process and that is for a good reason - to preve= +nt various grinding attacks. In some systems the coin must be specifically = +registered before it can be staked, in others, simply waiting for enough co= +nfirmations 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 mo= +ved. Maybe it is possible though, but AFAIK it is not common and not battle= + tested feature.<br></div><div><br></div><div>Then if we admit that achievi= +ng the optimal condition is rather theoretical. Then if we do not have the = +optimal condition, it means that a staker with K% of the total available su= +pply increases it's percentage over time to some amounts >K%. As lon= +g 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 incr= +ease in time. It will increase relative to all normal users who do not stak= +e (if there are any) and relative to all other stakers who make mistakes or= + who are not wealthy enough to afford not selling any position ever. But po= +werful attacker is exactly in such position and thus she will gain signific= +ance in such a system. The technique I have described, and that you mistake= +nly think is viable only with huge amounts of stake, only puts the attacker= + to even greater advantage. But even without the described attack (which ex= +ploits nothing at stake), the PoS system converges to a system more and mor= +e controlled by powerful entity, which we can assume is the attacker.<br></= +div><div><br></div><div><br></div><blockquote type=3D"cite"><div dir=3D"ltr= +"><div>So I don't think it is at all misleading to claim that "not= +hing at stake" is a solved problem. I do in fact mean that the solutio= +ns to that problem don't introduce any other problems with anywhere nea= +r the same level of significance.=C2=A0<br></div></div></blockquote><div><b= +r></div><div>It still stands as truly misleading claim. I disagree that int= +roducing DDOS opportunity with medium level of difficulty for the attacker = +to implement it, in case of "quorum-based PoS" is not a problem a= +nywhere near the same level of significance. Such an attack vector allows y= +ou to turn off the network if you spend some time and money. That is hardly= + acceptable.<br></div><div><br></div><div>Just because of the above we must= + reject PoS as being critically insecure until someone invents and demonstr= +ates an actual way of solving these issues. <br></div><div><br></div><div><= +br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div><br></div></div><d= +iv class=3D"gmail_quote"><div dir=3D"ltr">On Tue, May 25, 2021 at 3:00 AM E= +rik Aronesty <<a href=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32= +.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar= +gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1= +ex"><div>> > you burn them to be used at a future particular block he= +ight<br></div><div><br></div><div>> This sounds exploitable. It seems li= +ke an attacker could simply focus all their burns on a particular set of 6 = +blocks to double spend, minimizing their cost of attack.<br></div><div><br>= +</div><div>could be right.=C2=A0 =C2=A0the original idea was to have burns = +decay over time,<br></div><div>like ASIC's.<br></div><div><br></div><di= +v>anyway the point was not that "i had a magic formula"<br></div>= +<div><br></div><div>the point was that proof of burn is almost always bette= +r than proof of<br></div><div>stake - simply because the "proof" = +is on-chain, not sitting on a node<br></div><div>somewhere waiting to be st= +olen.<br></div><div><br></div><div>On Mon, May 24, 2021 at 9:53 PM Billy Te= +trud <<a href=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">billy.= +tetrud@gmail.com</a>> wrote:<br></div><div>><br></div><div>> Is th= +is the kind of proof of burn you're talking about?<br></div><div>><b= +r></div><div>> >=C2=A0 =C2=A0if i have a choice between two chains, o= +ne longer and one shorter, i can only choose one... deterministically<br></= +div><div>><br></div><div>> What prevents you from attempting to mine = +block 553 on both chains?<br></div><div>><br></div><div>> > miners= + have a very strong, long-term, investment in the stability of the chain.<b= +r></div><div>><br></div><div>> Yes, but the same can be said of any c= +oin, even ones that do have the nothing at stake problem. This isn't su= +fficient tho because the chain is a common good, and the tragedy of the com= +mons holds for it.<br></div><div>><br></div><div>> > you burn them= + to be used at a future particular block height<br></div><div>><br></div= +><div>> This sounds exploitable. It seems like an attacker could simply = +focus all their burns on a particular set of 6 blocks to double spend, mini= +mizing their cost of attack.<br></div><div>><br></div><div>> > i c= +an imagine scenarios where large stakeholders can collude to punish smaller= + stakeholders simply to drive them out of business, for example<br></div><d= +iv>><br></div><div>> Are you talking about a 51% attack? This is poss= +ible in any decentralized cryptocurrency.<br></div><div>><br></div><div>= +><br></div><div>> On Mon, May 24, 2021 at 11:49 AM Erik Aronesty <= +<a href=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>> wrot= +e:<br></div><div>>><br></div><div>>> > > your burn invest= +ment is always "at stake", any redaction can result in a loss-of-= +burn, because burns can be tied, precisely, to block-heights<br></div><div>= +>> > I'm fuzzy on how proof of burn works.<br></div><div>>&= +gt;<br></div><div>>> when you burn coins, you burn them to be used at= + a future particular<br></div><div>>> block height: so if i'm bur= +ning for block 553, i can only use them to<br></div><div>>> mine bloc= +k 553.=C2=A0 =C2=A0if i have a choice between two chains, one longer<br></d= +iv><div>>> and one shorter, i can only choose one... deterministicall= +y, for that<br></div><div>>> burn: the chain with the height 553.=C2= +=A0 =C2=A0if we fix the "lead time" for<br></div><div>>> bu= +rned coins to be weeks or even months in advance, miners have a very<br></d= +iv><div>>> strong, long-term, investment in the stability of the chai= +n.<br></div><div>>><br></div><div>>> therefore there is no &quo= +t;nothing at stake" problem.=C2=A0 =C2=A0it's<br></div><div>>&g= +t; deterministic, so miners have no choice.=C2=A0 they can *only* choose th= +e<br></div><div>>> transactions that go into the block.=C2=A0 they ca= +nnot choose which chain<br></div><div>>> to mine, and it's time-l= +ocked, so rollbacks and instability always<br></div><div>>> hurt mine= +rs the most.<br></div><div>>><br></div><div>>> the "punish= +ment" systems of PoS are "weird at best", certainly<br></div= +><div>>> unproven.=C2=A0 =C2=A0i can imagine scenarios where large st= +akeholders can<br></div><div>>> collude to punish smaller stakeholder= +s simply to drive them out of<br></div><div>>> business, for example.= +=C2=A0 =C2=A0and then you have to put checks in place to<br></div><div>>= +> prevent that, and more checks for those prevention system...<br></div>= +<div>>><br></div><div>>> in PoB, there is no complexity.=C2=A0 = +simpler systems like this are<br></div><div>>> typically more secure.= +<br></div><div>>><br></div><div>>> PoB also solves problems cau= +sed by "energy dependence", which could<br></div><div>>> le= +ad to state monopolies on mining (like the new Bitcoin Mining<br></div><div= +>>> Council).=C2=A0 =C2=A0these consortiums, if state sanctioned, cou= +ld become a<br></div><div>>> source of censorship, for example.=C2=A0= + =C2=A0Since PoB doesn't require you to<br></div><div>>> have a l= +ive, well-connected node, it's harder to censor & harder to<br></di= +v><div>>> trace.<br></div><div>>><br></div><div>>> Elimin= +ating this weakness seems to be in the best interests of<br></div><div>>= +> existing stakeholders<br></div><div>>><br></div><div>>><br= +></div><div>>><br></div><div>>><br></div><div>>> On Mon, = +May 24, 2021 at 4:44 PM Billy Tetrud <<a href=3D"mailto:billy.tetrud@gma= +il.com" target=3D"_blank">billy.tetrud@gmail.com</a>> wrote:<br></div><d= +iv>>> ><br></div><div>>> > >=C2=A0 proof of burn clear= +ly solves this, since nothing is held online<br></div><div>>> ><br= +></div><div>>> > Well.. the coins to be burned need to be online w= +hen they're burned. But yes, only a small fraction of the total coins n= +eed to be online.<br></div><div>>> ><br></div><div>>> > &= +gt; your burn investment is always "at stake", any redaction can = +result in a loss-of-burn, because burns can be tied, precisely, to block-he= +ights<br></div><div>>> ><br></div><div>>> > 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 transacti= +on could also be spent on the longest chain, which means their coins are bu= +rned even if the chain they tried to mine on doesn't win? I'm fuzzy= + on how proof of burn works.<br></div><div>>> ><br></div><div>>= +> > > proof of burn can be more secure than proof-of-stake<br></di= +v><div>>> ><br></div><div>>> > FYI, proof of stake can be= + done without the "nothing at stake" problem. You can simply puni= +sh people who mint on shorter chains (by rewarding people who publish proof= +s 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 hei= +ght. The "nothing at stake" problem is a solved problem at this p= +oint for PoS.<br></div><div>>> ><br></div><div>>> ><br></= +div><div>>> ><br></div><div>>> > On Mon, May 24, 2021 at = +3:47 AM Erik Aronesty <<a href=3D"mailto:erik@q32.com" target=3D"_blank"= +>erik@q32.com</a>> wrote:<br></div><div>>> >><br></div><div>= +>> >> > I don't see a way to get around the conflicting = +requirement that the keys for large amounts of coins should be kept offline= + but those are exactly the coins we need online to make the scheme secure.<= +br></div><div>>> >><br></div><div>>> >> proof of bu= +rn clearly solves this, since nothing is held online<br></div><div>>>= + >><br></div><div>>> >> >=C2=A0 how does proof of burn= + solve the "nothing at stake" problem in your view?<br></div><div= +>>> >><br></div><div>>> >> definition of nothing at= + stake: in the event of a fork, whether the<br></div><div>>> >>= + fork is accidental or a malicious, the optimal strategy for any miner<br><= +/div><div>>> >> is to mine on every chain, so that the miner ge= +ts their reward no<br></div><div>>> >> matter which fork wins.= +=C2=A0 =C2=A0indeed in proof-of-stake, the proofs are<br></div><div>>>= +; >> published on the very chains mines, so the incentive is magnifie= +d.<br></div><div>>> >><br></div><div>>> >> in proof= +-of-burn, your burn investment is always "at stake", any<br></div= +><div>>> >> redaction can result in a loss-of-burn, because bur= +ns can be tied,<br></div><div>>> >> precisely, to block-heights= +<br></div><div>>> >><br></div><div>>> >> as a resul= +t, miners no longer have an incentive to mine all chains<br></div><div>>= +> >><br></div><div>>> >> in this way proof of burn can= + be more secure than proof-of-stake, and<br></div><div>>> >> ev= +en more secure than proof of work<br></div><div>>> >><br></div>= +<div>>> >><br></div><div>>> >><br></div><div>>&g= +t; >><br></div><div>>> >><br></div><div>>> >>= +<br></div><div>>> >><br></div><div>>> >> ><br></= +div><div>>> >><br></div><div>>> >> On Sun, May 23, = +2021 at 3:52 AM Lloyd Fournier via bitcoin-dev<br></div><div>>> >&= +gt; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"= +_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><div>= +>> >> ><br></div><div>>> >> > Hi Billy,<br></= +div><div>>> >> ><br></div><div>>> >> > I was = +going to write a post which started by dismissing many of the weak argument= +s that are made against PoS made in this thread and elsewhere.<br></div><di= +v>>> >> > Although I don't agree with all your points yo= +u have done a decent job here so I'll focus on the second part: why I t= +hink Proof-of-Stake is inappropriate for a Bitcoin-like system.<br></div><d= +iv>>> >> ><br></div><div>>> >> > Proof of sta= +ke is not fit for purpose for a global settlement layer in a pure digital a= +sset (i.e. "digital gold") which is what Bitcoin is trying to be.= +<br></div><div>>> >> > PoS necessarily gives responsibilitie= +s to the holders of coins that they do not want and cannot handle.<br></div= +><div>>> >> > 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.<br></div><div>>> >> > As mu= +ch as hardcore Bitcoiners try to convince them to run their own node, most = +don't, and that's perfectly acceptable.<br></div><div>>> >= +> > At no point do their personal decisions affect the underlying con= +sensus -- it only affects their personal security assurance (not that of th= +e system itself).<br></div><div>>> >> > In PoS systems this = +clean separation of responsibilities does not exist.<br></div><div>>>= + >> ><br></div><div>>> >> > I think that the more r= +igorously studied PoS protocols will work fine within the security claims m= +ade in their papers.<br></div><div>>> >> > People who believ= +e that these protocols are destined for catastrophic consensus failure are = +certainly in for a surprise.<br></div><div>>> >> > But the d= +evil is in the detail.<br></div><div>>> >> > Let's look = +at what the implications of using the leading proof of stake protocols woul= +d have on Bitcoin:<br></div><div>>> >> ><br></div><div>>&= +gt; >> > ### Proof of SquareSpace (Cardano, Polkdadot)<br></div><d= +iv>>> >> ><br></div><div>>> >> > Cardano is a= + UTXO based PoS coin based on Ouroboros Praos[3] with an inbuilt on-chain d= +elegation system[5].<br></div><div>>> >> > In these protocol= +s, coin holders who do not want to run their node with their hot keys in it= + delegate it to a "Stake Pool".<br></div><div>>> >> &= +gt; 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 larg= +est share of the block reward.<br></div><div>>> >> > On the = +surface this might sound no different than someone with an mining rig shopp= +ing around for a good mining pool but there are crucial differences:<br></d= +iv><div>>> >> ><br></div><div>>> >> > 1. The = +person making the decision is forced into it just because they own the curr= +ency -- someone with a mining rig has purchased it with the intent to make = +profit by participating in consensus.<br></div><div>>> >> ><= +br></div><div>>> >> > 2. When you join a mining pool your sy= +stems are very much still online. You are just partaking in a pool to reduc= +e your profit variance. You still see every block that you help create and = +*you never help create a block without seeing it first*.<br></div><div>>= +> >> ><br></div><div>>> >> > 3. If by SquareSpac= +e sybil attack you gain a dishonest majority and start censoring transactio= +ns how are the users meant to redelegate their stake to honest pools?<br></= +div><div>>> >> > I guess they can just send a transaction de= +legating to another pool...oh wait I guess that might be censored too! This= + seems really really bad.<br></div><div>>> >> > In Bitcoin, = +miners can just join a different pool at a whim. There is nothing the attac= +ker can do to stop them. A temporary dishonest majority heals relatively we= +ll.<br></div><div>>> >> ><br></div><div>>> >> &g= +t; There is another severe disadvantage to this on-chain delegation system:= + every UTXO must indicate which staking account this UTXO belongs to so the= + appropriate share of block rewards can be transferred there.<br></div><div= +>>> >> > Being able to associate every UTXO to an account ru= +ins one of the main privacy advantages of the UTXO model.<br></div><div>>= +;> >> > It also grows the size of the blockchain significantly.= +<br></div><div>>> >> ><br></div><div>>> >> > = +### "Pure" proof of stake (Algorand)<br></div><div>>> >&= +gt; ><br></div><div>>> >> > Algorand's[4] approach is= + to only allow online stake to participate in the protocol.<br></div><div>&= +gt;> >> > Theoretically, This means that keys holding funds hav= +e to be online in order for them to author blocks when they are chosen.<br>= +</div><div>>> >> > Of course in reality no one wants to keep= + their coin holding keys online so in Alogorand you can authorize a set of = +"participation keys"[1] that will be used to create blocks on you= +r coin holding key's behalf.<br></div><div>>> >> > Hopef= +ully you've spotted the problem.<br></div><div>>> >> > Y= +ou can send your participation keys to any malicious party with a nice webs= +ite (see random example [2]) offering you a good return.<br></div><div>>= +> >> > Damn it's still Proof-of-SquareSpace!<br></div><div>= +>> >> > The minor advantage is that at least the participati= +on keys expire after a certain amount of time so eventually the SquareSpace= + attacker will lose their hold on consensus.<br></div><div>>> >>= +; > Importantly there is also less junk on the blockchain because the pa= +rticipation keys are delegated off-chain and so are not making as much of a= + mess.<br></div><div>>> >> ><br></div><div>>> >>= + > ### Conclusion<br></div><div>>> >> ><br></div><div>>= +;> >> > I don't see a way to get around the conflicting req= +uirement that the keys for large amounts of coins should be kept offline bu= +t those are exactly the coins we need online to make the scheme secure.<br>= +</div><div>>> >> > If we allow delegation then we open up a = +new social attack surface and it degenerates to Proof-of-SquareSpace.<br></= +div><div>>> >> ><br></div><div>>> >> > For a = +"digital gold" like system like Bitcoin we optimize for simplicit= +y and desperately want to avoid extraneous responsibilities for the holder = +of the coin.<br></div><div>>> >> > After all, gold is an ine= +rt element on the periodic table that doesn't confer responsibilities o= +n the holder to maintain the quality of all the other bars of gold out ther= +e.<br></div><div>>> >> > Bitcoin feels like this too and in = +many ways is more inert and beautifully boring than gold.<br></div><div>>= +;> >> > For Bitcoin to succeed I think we need to keep it that = +way and Proof-of-Stake makes everything a bit too exciting.<br></div><div>&= +gt;> >> ><br></div><div>>> >> > I suppose in the= + end the market will decide what is real digital gold and whether these bad= + technical trade offs are worth being able to say it uses less electricity.= + It goes without saying that making bad technical decisions to appease the = +current political climate is an anathema to Bitcoin.<br></div><div>>>= + >> ><br></div><div>>> >> > Would be interested to = +know if you or others think differently on these points.<br></div><div>>= +> >> ><br></div><div>>> >> > [1]: <a href=3D"htt= +ps://developer.algorand.org/docs/run-a-node/participate/generate_keys/" rel= +=3D"noreferrer" target=3D"_blank">https://developer.algorand.org/docs/run-a= +-node/participate/generate_keys/</a><br></div><div>>> >> > [= +2]: <a href=3D"https://staking.staked.us/algorand-staking" rel=3D"noreferre= +r" target=3D"_blank">https://staking.staked.us/algorand-staking</a><br></di= +v><div>>> >> > [3]: <a href=3D"https://eprint.iacr.org/2017/= +573.pdf" rel=3D"noreferrer" target=3D"_blank">https://eprint.iacr.org/2017/= +573.pdf</a><br></div><div>>> >> > [4]: <a href=3D"https://al= +gorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9= +_theoretical.pdf" rel=3D"noreferrer" target=3D"_blank">https://algorandcom.= +cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretic= +al.pdf</a><br></div><div>>> >> > [5]: <a href=3D"https://hyd= +ra.iohk.io/build/790053/download/1/delegation_design_spec.pdf" rel=3D"noref= +errer" target=3D"_blank">https://hydra.iohk.io/build/790053/download/1/dele= +gation_design_spec.pdf</a><br></div><div>>> >> ><br></div><d= +iv>>> >> > Cheers,<br></div><div>>> >> ><br><= +/div><div>>> >> > LL<br></div><div>>> >> ><br= +></div><div>>> >> > On Fri, 21 May 2021 at 19:21, Billy Tetr= +ud via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.= +org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:= +<br></div><div>>> >> >><br></div><div>>> >> &= +gt;> I think there is a lot of misinformation and bias against Proof of = +Stake. Yes there have been lots of shady coins that use insecure PoS mechan= +isms. Yes there have been massive issues with distribution of PoS coins (of= + course there have also been massive issues with PoW coins as well). Howeve= +r, I want to remind everyone that there is a difference between "prove= +d to be impossible" and "have not achieved recognized success yet= +". Most of the arguments levied against PoS are out of date or rely on= + unproven assumptions or extrapolation from the analysis of a particular Po= +S system. I certainly don't think we should experiment with bitcoin by = +switching to PoS, but from my research, it seems very likely that there is = +a proof of stake consensus protocol we could build that has substantially h= +igher security (cost / capital required to execute an attack) while at the = +same time costing far less resources (which do translate to fees on the net= +work) *without* compromising any of the critical security properties bitcoi= +n relies on. I think the critical piece of this is the disagreements around= + hardcoded checkpoints, which is a critical piece solving attacks that coul= +d be levied on a PoS chain, and how that does (or doesn't) affect the s= +ecurity model.<br></div><div>>> >> >><br></div><div>>&= +gt; >> >> @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:<br></div><div>>> >> >&= +gt; * The capital required to 51% attack a PoS chain can be made substantia= +lly greater than on a PoS chain.<br></div><div>>> >> >> *= + The capital the attacker stands to lose can be substantially greater as we= +ll if the attack is successful.<br></div><div>>> >> >> * = +The effectiveness of paying miners to raise the honest fraction of miners a= +bove 50% may be quite bad.<br></div><div>>> >> >> * Allow= +ing a 51% attack is already unacceptable. It should be considered whether w= +hat happens in the case of a 51% may not be significantly different. The cu= +rrency would likely be critically damaged in a 51% attack regardless of con= +sensus mechanism.<br></div><div>>> >> >><br></div><div>&g= +t;> >> >> > Proof-of-stake tends towards oligopolistic co= +ntrol<br></div><div>>> >> >><br></div><div>>> >&= +gt; >> People repeat this often, but the facts support this. There is= + no centralization pressure in any proof of stake mechanism that I'm aw= +are of. IE if you have 10 times as much coin that you use to mint blocks, y= +ou should expect to earn 10x as much minting revenue - not more than 10x. B= +y 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 c= +entralization pressure remains insignifiant. Proof of work also clearly has= + a lot more barriers to entry than any proof of stake system does. Both of = +these mean the tendency towards oligopolistic control is worse for PoW.<br>= +</div><div>>> >> >><br></div><div>>> >> >&= +gt; > Energy usage, in-and-of-itself, is nothing to be ashamed of!!<br><= +/div><div>>> >> >><br></div><div>>> >> >&g= +t; I certainly agree. Bitcoin's energy usage at the moment is I think q= +uite warranted. However, the question is: can we do substantially better. I= + think if we can, we probably should... eventually.<br></div><div>>> = +>> >><br></div><div>>> >> >> > Proof of St= +ake 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<br></d= +iv><div>>> >> >><br></div><div>>> >> >>= + I see no mention of this in the pos.pdf you linked to. I'm not aware o= +f any proof that all PoS systems have a failure threshold of 1/3. I know th= +at staking systems like Casper do in fact have that 1/3 requirement. Howeve= +r there are PoS designs that should exceed that up to nearly 50% as far as = +I'm aware. Proof of work is not in fact resilient up to the 1/2 thresho= +ld in the way you would think. IE, if 100% of miners are currently honest a= +nd have a collective 100 exahashes/s hashpower, an attacker does not need t= +o obtain 100 exahashes/s, but actually only needs to accumulate 50 exahashe= +s/s. This is because as the attacker accumulates hashpower, it drives hones= +t miners out of the market as the difficulty increases to beyond what is ec= +onomically sustainable. Also, its been shown that the best proof of work ca= +n do is require an attacker to obtain 33% of the hashpower because of the s= +elfish mining attack discussed in depth in this paper: <a href=3D"https://a= +rxiv.org/abs/1311.0243" rel=3D"noreferrer" target=3D"_blank">https://arxiv.= +org/abs/1311.0243</a>. Together, both of these things reduce PoW's secu= +rity by a factor of about 83% (1 - 50%*33%).<br></div><div>>> >>= +; >><br></div><div>>> >> >>=C2=A0 > Proof of Sta= +ke requires other trade-offs which are incompatible with Bitcoin's obje= +ctive (to be a trustless digital cash) =E2=80=94 specifically the famous &q= +uot;security vs. liveness" guarantee<br></div><div>>> >> &= +gt;><br></div><div>>> >> >> Do you have a good source = +that talks about why you think proof of stake cannot be used for a trustles= +s digital cash?<br></div><div>>> >> >><br></div><div>>= +> >> >> > You cannot gain tokens without someone choosing= + to give up those coins - a form of permission.<br></div><div>>> >= +> >><br></div><div>>> >> >> This is not a practi= +cal constraint. Just like in mining, some nodes may reject you, but there w= +ill likely be more that will accept you, some sellers may reject you, but m= +ost would accept your money as payment for bitcoins. I don't think requ= +iring the "permission" of one of millions of people in the market= + can be reasonably considered a "permissioned currency".<br></div= +><div>>> >> >><br></div><div>>> >> >> &= +gt; 2. Proof of stake must have a trusted means of timestamping to regulate= + overproduction of blocks<br></div><div>>> >> >><br></div= +><div>>> >> >> Both PoW and PoS could mine/mint blocks tw= +ice as fast if everyone agreed to double their clock speeds. Both systems r= +ely on an honest majority sticking to standard time.<br></div><div>>>= + >> >><br></div><div>>> >> >><br></div><div>&= +gt;> >> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky= + via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or= +g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<b= +r></div><div>>> >> >>><br></div><div>>> >>= + >>> Ah sorry, I didn't realize this was, in fact, a different= + thread! :)<br></div><div>>> >> >>><br></div><div>>= +> >> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovs= +ky <<a href=3D"mailto:mike@powx.org" target=3D"_blank">mike@powx.org</a>= +> wrote:<br></div><div>>> >> >>>><br></div><div>= +>> >> >>>> Folks, I suggest we keep the discussion = +to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but = +I guess there are other threads going on these topics already where they wo= +uld be relevant.<br></div><div>>> >> >>>><br></div>= +<div>>> >> >>>> Also, it's important to disting= +uish between oPoW and these other "alternatives" to Hashcash. oPo= +W is a true Proof of Work that doesn't alter the core game theory or se= +curity assumptions of Hashcash and actually contains SHA (can be SHA3, SHA2= +56, etc hash is interchangeable).<br></div><div>>> >> >>&= +gt;><br></div><div>>> >> >>>> Cheers,<br></div><= +div>>> >> >>>> Mike<br></div><div>>> >>= + >>>><br></div><div>>> >> >>>> On Tue, = +May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <<a href=3D"mailto= +:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists= +.linuxfoundation.org</a>> wrote:<br></div><div>>> >> >>= +;>>><br></div><div>>> >> >>>>> 1. i nev= +er suggested vdf's to replace pow.<br></div><div>>> >> >= +>>>><br></div><div>>> >> >>>>> 2. my= + suggestion was specifically *in the context of* a working<br></div><div>&g= +t;> >> >>>>> proof-of-burn protocol<br></div><div>&= +gt;> >> >>>>><br></div><div>>> >> >&= +gt;>>> - vdfs used only for timing (not block height)<br></div><di= +v>>> >> >>>>> - blind-burned coins of a specific= + age used to replace proof of work<br></div><div>>> >> >>= +>>> - the required "work" per block would simply be a co= +mpetition to<br></div><div>>> >> >>>>> acquire r= +ewards, and so miners would have to burn coins, well in<br></div><div>>&= +gt; >> >>>>> advance, and hope that their burned coins= + got rewarded in some far<br></div><div>>> >> >>>>&= +gt; future<br></div><div>>> >> >>>>> - the point= + of burned coins is to mimic, in every meaningful way, the<br></div><div>&g= +t;> >> >>>>> value gained from proof of work... wit= +hout some of the security<br></div><div>>> >> >>>>&= +gt; drawbacks<br></div><div>>> >> >>>>> - the mi= +ner risks losing all of his burned coins (like all miners risk<br></div><di= +v>>> >> >>>>> losing their work in each block)<b= +r></div><div>>> >> >>>>> - new burns can't b= +e used<br></div><div>>> >> >>>>> - old burns age= + out (like ASICs do)<br></div><div>>> >> >>>>> -= + other requirements on burns might be needed to properly mirror the<br></di= +v><div>>> >> >>>>> properties of PoW and the inc= +entives Bitcoin uses to mine honestly.<br></div><div>>> >> >= +>>>><br></div><div>>> >> >>>>> 3. i = +do believe it is *possible* that a "burned coin + vdf system"<br>= +</div><div>>> >> >>>>> might be more secure in t= +he long run, and that if the entire space<br></div><div>>> >> &= +gt;>>>> agreed that such an endeavor was worthwhile, a test net= + could be spun<br></div><div>>> >> >>>>> up, and= + a hard-fork could be initiated.<br></div><div>>> >> >>&g= +t;>><br></div><div>>> >> >>>>> 4. i would = +never suggest such a thing unless i believed it was<br></div><div>>> = +>> >>>>> possible that consensus was possible.=C2=A0 s= +o no, this is not an "alt<br></div><div>>> >> >>>= +>> coin"<br></div><div>>> >> >>>>><br= +></div><div>>> >> >>>>> On Tue, May 18, 2021 at = +10:02 AM Zac Greenwood <<a href=3D"mailto:zachgrw@gmail.com" target=3D"_= +blank">zachgrw@gmail.com</a>> wrote:<br></div><div>>> >> >= +;>>>> ><br></div><div>>> >> >>>>>= + > Hi ZmnSCPxj,<br></div><div>>> >> >>>>> >= +;<br></div><div>>> >> >>>>> > Please note tha= +t I am not suggesting VDFs as a means to save energy, but solely as a means= + to make the time between blocks more constant.<br></div><div>>> >= +> >>>>> ><br></div><div>>> >> >>>= +>> > Zac<br></div><div>>> >> >>>>> >= +<br></div><div>>> >> >>>>> ><br></div><div>&g= +t;> >> >>>>> > On Tue, 18 May 2021 at 12:42, Zmn= +SCPxj <<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnS= +CPxj@protonmail.com</a>> wrote:<br></div><div>>> >> >>= +>>> >><br></div><div>>> >> >>>>> = +>> Good morning Zac,<br></div><div>>> >> >>>>= +> >><br></div><div>>> >> >>>>> >>= + > VDFs might enable more constant block times, for instance by having a= + two-step PoW:<br></div><div>>> >> >>>>> >>= +; ><br></div><div>>> >> >>>>> >> > 1= +. Use a VDF that takes say 9 minutes to resolve (VDF being subject to diffi= +culty adjustments similar to the as-is). As per the property of VDFs, miner= +s are able show proof of work.<br></div><div>>> >> >>>= +>> >> ><br></div><div>>> >> >>>>>= + >> > 2. Use current PoW mechanism with lower difficulty so findin= +g a block takes 1 minute on average, again subject to as-is difficulty adju= +stments.<br></div><div>>> >> >>>>> >> >= +<br></div><div>>> >> >>>>> >> > As a re= +sult, variation in block times will be greatly reduced.<br></div><div>>&= +gt; >> >>>>> >><br></div><div>>> >> = +>>>>> >> As I understand it, another weakness of VDFs = +is that they are not inherently progress-free (their sequential nature prev= +ents that; they are inherently progress-requiring).<br></div><div>>> = +>> >>>>> >><br></div><div>>> >> >= +>>>> >> Thus, a miner which focuses on improving the amou= +nt of energy that it can pump into the VDF circuitry (by overclocking and f= +reezing the circuitry), could potentially get into a winner-takes-all situa= +tion, possibly leading to even *worse* competition and even *more* energy c= +onsumption.<br></div><div>>> >> >>>>> >> A= +fter 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*.<br></div= +><div>>> >> >>>>> >><br></div><div>>>= +; >> >>>>> >> Regards,<br></div><div>>> &g= +t;> >>>>> >> ZmnSCPxj<br></div><div>>> >&g= +t; >>>>> _______________________________________________<br>= +</div><div>>> >> >>>>> bitcoin-dev mailing list<= +br></div><div>>> >> >>>>> <a href=3D"mailto:bitc= +oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu= +xfoundation.org</a><br></div><div>>> >> >>>>> <a= + href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" re= +l=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma= +n/listinfo/bitcoin-dev</a><br></div><div>>> >> >>>>= +<br></div><div>>> >> >>>><br></div><div>>> &g= +t;> >>>><br></div><div>>> >> >>>> --= +<br></div><div>>> >> >>>> Michael Dubrovsky<br></di= +v><div>>> >> >>>> Founder; PoWx<br></div><div>>&= +gt; >> >>>> <a href=3D"http://www.PoWx.org" rel=3D"norefe= +rrer" target=3D"_blank">www.PoWx.org</a><br></div><div>>> >> &g= +t;>><br></div><div>>> >> >>><br></div><div>>&= +gt; >> >>><br></div><div>>> >> >>> --<b= +r></div><div>>> >> >>> Michael Dubrovsky<br></div><div= +>>> >> >>> Founder; PoWx<br></div><div>>> >&g= +t; >>> <a href=3D"http://www.PoWx.org" rel=3D"noreferrer" target= +=3D"_blank">www.PoWx.org</a><br></div><div>>> >> >>> _= +______________________________________________<br></div><div>>> >&= +gt; >>> bitcoin-dev mailing list<br></div><div>>> >> &= +gt;>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= +=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br></div><div>>>= +; >> >>> <a href=3D"https://lists.linuxfoundation.org/mailma= +n/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.= +linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div><div>>>= + >> >><br></div><div>>> >> >> _______________= +________________________________<br></div><div>>> >> >> b= +itcoin-dev mailing list<br></div><div>>> >> >> <a href=3D= +"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de= +v@lists.linuxfoundation.org</a><br></div><div>>> >> >> <a= + href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" re= +l=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma= +n/listinfo/bitcoin-dev</a><br></div><div>>> >> ><br></div><d= +iv>>> >> > _______________________________________________<b= +r></div><div>>> >> > bitcoin-dev mailing list<br></div><div>= +>> >> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.= +org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br></div><= +div>>> >> > <a href=3D"https://lists.linuxfoundation.org/mai= +lman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lis= +ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></blockquo= +te></div></blockquote><div><br></div></blockquote></div></blockquote><div><= +br></div></blockquote></div> + +--00000000000080c6f005c34cf331-- + |