diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2021-05-23 09:10:50 -1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-05-23 19:11:18 +0000 |
| commit | 537cbd5e92184af3c81e37bc9fd3631cb3383851 (patch) | |
| tree | 56d8afcf8b046048a006eb2b25cb019473b59613 | |
| parent | a7f555b6788963a7a781ea8e0b2df530951e7d6b (diff) | |
| download | pi-bitcoindev-537cbd5e92184af3c81e37bc9fd3631cb3383851.tar.gz pi-bitcoindev-537cbd5e92184af3c81e37bc9fd3631cb3383851.zip | |
Re: [bitcoin-dev] Opinion on proof of stake in future
| -rw-r--r-- | 9a/794d020eaba1796c8ea870396bdf3f194a5f23 | 992 |
1 files changed, 992 insertions, 0 deletions
diff --git a/9a/794d020eaba1796c8ea870396bdf3f194a5f23 b/9a/794d020eaba1796c8ea870396bdf3f194a5f23 new file mode 100644 index 000000000..c3059f239 --- /dev/null +++ b/9a/794d020eaba1796c8ea870396bdf3f194a5f23 @@ -0,0 +1,992 @@ +Return-Path: <fresheneesz@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id C8B20C0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 23 May 2021 19:11:18 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 9E644403A0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 23 May 2021 19:11:18 +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: smtp4.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 3j3lKuBeHvij + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 23 May 2021 19:11:10 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 7E3414039B + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 23 May 2021 19:11:10 +0000 (UTC) +Received: by mail-ej1-x62e.google.com with SMTP id i7so20457888ejc.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 23 May 2021 12:11:10 -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=rdODStxSNlvhYYqG17s5LkZbvFM6qamFfRet9c7NQoU=; + b=deS2RvE5QWbY3chmAdgx+hFU79FV8fJtDUslQvzFiv7m/nioI7bQp+hIMXDGL+kVdc + ds7W3oTL7QAEsrwM5u3dRhwt+sgVbRQtq5ildKoGJ+hqCrQ7BfLvYTleJUhmq2H+Wy/n + BM7NzRggXYvsTtfUTShsqR7TKypcBbWpB2LTmuLkBGJrs5oRlv3dvWaJD43KygBxg8G9 + jyeSGKfReg61rDKzcozZbidyIXdoDGIhh7tWJ0/4iOFERxnhDo7HmnUYKheDzNQPj/Kh + FHRHHxJvsywKBbnVLl7c6V6F1KbBZWxTB0k35pG7faYyEfNbUCgCWH+Kln9IDJW08yz8 + PW0Q== +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=rdODStxSNlvhYYqG17s5LkZbvFM6qamFfRet9c7NQoU=; + b=Ulhgrxmxa9JJ3lDqeMeD7IdubCB/1oJYBl1RGYSzlXKdeavVXsIdR59DRuy3fze1+d + DdPe8Fe5WVJuuhB4kWiwjrYLwB9j2hvuR5K1cWjSboZ88Qo1eGvTAQSM0SfqkvYWpcKF + WveGCITn26gFSY1dMhEnzUG0WX261daKwhj2992OdrKVGcLmHv1U4kAyD5Uxx8QrPfHb + gjW1zFP5opsK3EG8K119Wg83V3kg+B6BKYJa/7TKDdiyFsdoHXCUfaqOEKU/1622uQUj + MUxM7BmljUZ5crKGhTkber6xjPPuLHrzDmUzX0Dbg2OujYqa74kEHgCnlw97NqKPS+TW + iu3A== +X-Gm-Message-State: AOAM531ithaNjWh3xTSNgEVm2un9Pnz/oqliK3xc/g7SPC3zEmCNvRrs + 8epaw6b1jMHv4NR/dVT7mp3VeMa1TxNDxe9wIAA= +X-Google-Smtp-Source: ABdhPJyxCQUiZf4gH6NtsWPSKvwN6HfkhocFIfuT+dqy3FqwmQ0r8jf2Qmfhqh2BqsgepBx7FAYnLuxdYbMAJVFqztE= +X-Received: by 2002:a17:907:76b8:: with SMTP id + jw24mr19633964ejc.359.1621797068591; + Sun, 23 May 2021 12:11:08 -0700 (PDT) +MIME-Version: 1.0 +References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com> + <CAJowKg+QM94g+JcC-E-NGD4J9-nXHWt5kBw14bXTAWaqZz=bYw@mail.gmail.com> + <CALeFGL02d9NVp+yobrtc2g6k2nBjBj0Qb==3Ukkbi8C_zb5qMg@mail.gmail.com> + <CAD5xwhi1G3Jj3FAAWQP3BXTK34ugDQY32hq-cQnt8Ny8JP4eGQ@mail.gmail.com> + <CAJowKgJ1x5YKWS1S-sgdU3Tn+hPT64iiUCwG8qh-JS0xqS7ieA@mail.gmail.com> + <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com> + <CAJ4-pEBYJNuNMUCt5J5DbKU4RC9JXcO7gZdKh2Vq6PHCmddaeg@mail.gmail.com> + <hASF-iYeGlsq3EhNWY0EWhk5S8R1Wwn534cWsrwLInd8K7f7bUDCAP4GgTj8_ZNsKtgv8y09GJovcS6KXhYRHODC5N_88fvCAF1Z-r2TUFg=@protonmail.com> + <CAJ4-pECb9QSUDPax8SU+-KGwPgVju=YKax9eb-iRwAmZGcMcPg@mail.gmail.com> + <CAJowKgJ3DOrtO+_XzoEnqQUQdge=zCopg2mvuy5F=RSeaVPJYQ@mail.gmail.com> + <CAKy8i-17Snk7ZeTL_U8ULDm3S5fYRXf412p1NpS_6CTT4Fhm0A@mail.gmail.com> + <CAKy8i-0efmC_AmAK6oLy1FooXd6WeSeOvRUOJ8Lb6BJoqduDTQ@mail.gmail.com> + <CAGpPWDaiGdgrECZzvM67O6t-kVieL4uR4ydEkHr+gwUB7Ahykg@mail.gmail.com> + <CAH5Bsr2WaOhSObNX-=61md6tF49auaH7wUB08qKv5baiFutxSw@mail.gmail.com> +In-Reply-To: <CAH5Bsr2WaOhSObNX-=61md6tF49auaH7wUB08qKv5baiFutxSw@mail.gmail.com> +From: Billy Tetrud <billy.tetrud@gmail.com> +Date: Sun, 23 May 2021 09:10:50 -1000 +Message-ID: <CAGpPWDaBZ3Zx9VnSt01Rs5G9z1RsZgez+dF4P=PCP=jYN8M1Xg@mail.gmail.com> +To: Lloyd Fournier <lloyd.fourn@gmail.com> +Content-Type: multipart/alternative; boundary="0000000000002bd5b605c3040e1c" +X-Mailman-Approved-At: Sun, 23 May 2021 19:37:19 +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: Sun, 23 May 2021 19:11:18 -0000 + +--0000000000002bd5b605c3040e1c +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +@Lloyd + +> Proof-of-SquareSpace + +I agree with your points about delegated proof of stake. I wrote my own +critique about that +<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#a= +nalysis-of-delegated-proof-of-stake-dpos> +as +well. And your point, that other forms of PoS devolve to DPoS by virtue of +people wanting to actively mint blocks without exposing their coins in hot +wallets, is an interesting one. + +> how are the users meant to redelegate their stake to honest pools? + +This could be mitigated partially if delegation didn't require any kind of +blockchain transaction. For example, users could simply send a signed +message saying "this other key can mint blocks with my coins", and then +minting a block using those coins would require presenting the delegation +signature. This only partially mitigates the problem since the dishonest +pool would still be able to use those coins as well, so it would be a race +at that point. Still better than nothing. And pools could simply require +full custody of the coins. + +From what you mentioned, it sounds like maybe Algorand does something +similar to this. + +> 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. + +There are a couple solutions you didn't mention. One is your "traditional" +locked-stake kind of systems, where participants are required to lock their +stake for long periods of time. Since normal users aren't likely to want to +do this, it will likely be left to more sophisticated stakers likely +staking very large amounts. + +Both mechanisms you mentioned allow delegation, and it might seem like +maybe there'd be a way to disallow delegation, however since users can +always give custody of their coins to trusted pools, that would be a +delgation mechanism of last resort that can't be removed. So you can do +things that make it hard (for both users and pool operators) to delegate +trustlessly, but you can't get rid of the ability to delgate entirely. + +In general, the situations where I see people not pooling are: + +A. They are entirely prevented by technical means. It seems reasonably +clear that this is impossible. +B. The downsides are more than unsophisticated users are willing to incur +(eg stake locking). +C. The rewards are so small that it isn't worth it for people to put in +much effort to gain them. +D. The rewards are so frequent that pooling is unnecessary. + +B excludes a lot of people from being able to help secure the chain, but +this is not materially different from PoW mining in that regard. D is a bit +border line. With 1 billion people attempting to participate and 10 minute +blocks, 232 people would need to share the block reward in order to expect +a payout on average once per month. With 8 billion people that would turn +into more like 1700 people. This seems potentially doable (eg via cosigner +requirements on minted blocks), but it is a lot of participants per block. + +I think options C and D combined would be an ideal approach here. Because +minting uses very few real resources, minting could be pretty much have +arbitrarily low ongoing costs. This means fees can be low and blocks can +have low payouts. If the reward was low and people could expect to see it +once every couple years, people could simply treat it like a lottery. Great +if they win it now, but nothing that anyone needs to rely on (which would +incentivize the pools to reduce variance that we want to avoid). If there +is no locked stake or other major barriers in place to minting blocks, that +would also help avoid the compultion to use a pool. + +In any case, you bring up good points, and they certainly complicate the +issue. By the way, if you were confused as to what VPoS was in the section +from my above link, this might satisfy your curiosity +<https://github.com/fresheneesz/ValidatedProofOfStake>. + +Cheers + + + + +On Sat, May 22, 2021 at 5:41 PM Lloyd Fournier <lloyd.fourn@gmail.com> +wrote: + +> Hi Billy, +> +> I was going to write a post which started by dismissing many of the weak +> arguments that are made against PoS made in this thread and elsewhere. +> Although I don't agree with all your points you have done a decent job +> here so I'll focus on the second part: why I think Proof-of-Stake is +> inappropriate for a Bitcoin-like system. +> +> Proof of stake is not fit for purpose for a global settlement layer in a +> pure digital asset (i.e. "digital gold") which is what Bitcoin is trying = +to +> be. +> PoS necessarily gives responsibilities to the holders of coins that they +> do not want and cannot handle. +> In Bitcoin, large unsophisticated coin holders can put their coins in col= +d +> storage without a second thought given to the health of the underlying +> ledger. +> As much as hardcore Bitcoiners try to convince them to run their own node= +, +> most don't, and that's perfectly acceptable. +> At no point do their personal decisions affect the underlying consensus -= +- +> it only affects their personal security assurance (not that of the system +> itself). +> In PoS systems this clean separation of responsibilities does not exist. +> +> I think that the more rigorously studied PoS protocols will work fine +> within the security claims made in their papers. +> People who believe that these protocols are destined for catastrophic +> consensus failure are certainly in for a surprise. +> But the devil is in the detail. +> Let's look at what the implications of using the leading proof of stake +> protocols would have on Bitcoin: +> +> ### Proof of SquareSpace (Cardano, Polkdadot) +> +> Cardano is a UTXO based PoS coin based on Ouroboros 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 will choose a +> pool by looking around for one with a nice website and offering the large= +st +> share of the block reward. +> On the surface this might sound no different than someone with an mining +> rig shopping around for a good mining pool but there are crucial +> differences: +> +> 1. The person making the decision is forced into it just because they own +> the currency -- someone with a mining rig has purchased it with the inten= +t +> 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 stil= +l +> see every block that you help create and *you never help create a block +> without seeing it first*. +> +> 3. If by SquareSpace sybil attack you gain a dishonest majority and start +> censoring transactions how are the users meant to redelegate their stake = +to +> honest pools? +> I guess they can just send a transaction delegating to another pool...oh +> wait I guess that might be censored too! This seems really really bad. +> In Bitcoin, miners can just join a different pool at a whim. There is +> nothing the attacker can do to stop them. A temporary dishonest majority +> heals relatively well. +> +> There is another severe disadvantage to this on-chain delegation system: +> every UTXO must indicate which staking account this UTXO belongs to so th= +e +> 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 th= +e +> protocol. +> Theoretically, This means that keys holding funds have to be online in +> order for them to author blocks when they are chosen. +> Of course in reality no one wants to keep their coin holding keys online +> so in Alogorand you can authorize a set of "participation keys"[1] that +> will be used to create blocks on your coin holding key's behalf. +> Hopefully you've spotted the problem. +> You can send your participation keys to any malicious party with a nice +> website (see random example [2]) offering you a good return. +> Damn it's still Proof-of-SquareSpace! +> The minor advantage is that at least the participation keys expire after = +a +> certain amount of time so eventually the SquareSpace attacker will lose +> their hold on consensus. +> Importantly there is also less junk on the blockchain because the +> participation keys are delegated off-chain and so are not making as much = +of +> a mess. +> +> ### Conclusion +> +> I don't see a way to get around the conflicting requirement that the keys +> for large amounts of coins should be kept offline but those are exactly t= +he +> coins we need online to make the scheme secure. +> If we allow delegation then we open up a new social attack surface and it +> degenerates to Proof-of-SquareSpace. +> +> For a "digital gold" like system like Bitcoin we optimize for simplicity +> and desperately want to avoid extraneous responsibilities for the holder = +of +> the coin. +> After all, gold is an inert element on the periodic table that doesn't +> confer responsibilities on the holder to maintain the quality of all the +> other bars of gold out there. +> Bitcoin feels like this too and in many ways is more inert and beautifull= +y +> boring than gold. +> For Bitcoin to succeed I think we need to keep it that way and +> Proof-of-Stake makes everything a bit too exciting. +> +> I suppose in the end the market will decide what is real digital gold and +> whether these bad technical trade offs are worth being able to say it use= +s +> less electricity. It goes without saying that making bad technical +> decisions to appease the current political climate is an anathema to +> Bitcoin. +> +> Would be interested to know if you or others think differently on these +> points. +> +> [1]: +> https://developer.algorand.org/docs/run-a-node/participate/generate_keys/ +> [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-bc7f-= +805f0e53a8d9_theoretical.pdf +> [5]: +> https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf +> +> Cheers, +> +> LL +> +> On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> I think there is a lot of misinformation and bias against Proof of Stake= +. +>> Yes there have been lots of shady coins that use insecure PoS mechanisms= +. +>> Yes there have been massive issues with distribution of PoS coins (of +>> course there have also been massive issues with PoW coins as well). +>> However, I want to remind everyone that there is a difference between +>> "proved to be impossible" and "have not achieved recognized success yet"= +. +>> Most of the arguments levied against PoS are out of date or rely on +>> unproven assumptions or extrapolation from the analysis of a particular = +PoS +>> system. I certainly don't think we should experiment with bitcoin by +>> switching to PoS, but from my research, it seems very likely that there = +is +>> a proof of stake consensus protocol we could build that has substantiall= +y +>> 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 disagreemen= +ts +>> 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) affe= +ct +>> 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 a= +s +>> well if the attack is successful. +>> * The effectiveness of paying miners to raise the honest fraction of +>> miners above 50% may be quite bad. +>> * Allowing a 51% attack is already unacceptable. It should be considered +>> whether what happens in the case of a 51% may not be significantly +>> different. The currency would likely be critically damaged in a 51% atta= +ck +>> regardless of consensus mechanism. +>> +>> > Proof-of-stake tends towards oligopolistic control +>> +>> People repeat this often, but the facts support this. There is no +>> centralization pressure in any proof of stake mechanism that I'm aware o= +f. +>> IE if you have 10 times as much coin that you use to mint blocks, you +>> should expect to earn 10x as much minting revenue - not more than 10x. 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 +>> centralization pressure remains insignifiant. Proof of work also clearly +>> has a lot more barriers to entry than any proof of stake system does. Bo= +th +>> of these mean the tendency towards oligopolistic control is worse for Po= +W. +>> +>> > Energy usage, in-and-of-itself, is nothing to be ashamed of!! +>> +>> I certainly agree. Bitcoin's energy usage at the moment is I think quite +>> warranted. However, the question is: can we do substantially better. I +>> think if we can, we probably should... eventually. +>> +>> > Proof of Stake is only resilient to =E2=85=93 of the network demonstra= +ting a +>> Byzantine Fault, whilst Proof of Work is resilient up to the =C2=BD thre= +shold +>> +>> I see no mention of this in the pos.pdf +>> <https://download.wpsoftware.net/bitcoin/pos.pdf> you linked to. I'm not +>> aware of any proof that *all *PoS systems have a failure threshold of +>> 1/3. I know that staking systems like Casper do in fact have that 1/3 +>> requirement. However there are PoS designs that should exceed that up to +>> nearly 50% as far as I'm aware. Proof of work is not in fact resilient u= +p +>> to the 1/2 threshold in the way you would think. IE, if 100% of miners a= +re +>> currently honest and have a collective 100 exahashes/s hashpower, an +>> attacker does not need to obtain 100 exahashes/s, but actually only need= +s +>> to accumulate 50 exahashes/s. This is because as the attacker accumulate= +s +>> hashpower, it drives honest miners out of the market as the difficulty +>> increases to beyond what is economically sustainable. Also, its been sho= +wn +>> that the best proof of work can do is require an attacker to obtain 33% = +of +>> the hashpower because of the selfish mining attack +>> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurit= +y#the-selfish-economic-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 specifica= +lly the +>> famous "security vs. liveness" guarantee +>> +>> Do you have a good source that talks about why you think proof of stake +>> cannot be used for a trustless digital cash? +>> +>> > You cannot gain tokens without someone choosing to give up those coins +>> - a form of permission. +>> +>> This is not a practical constraint. Just like in mining, some nodes may +>> reject you, but there will likely be more that will accept you, some +>> sellers may reject you, but most would accept your money as payment for +>> bitcoins. I don't think requiring the "permission" of one of millions of +>> people in the market can be reasonably considered a "permissioned +>> currency". +>> +>> > 2. Proof of stake must have a trusted means of timestamping to regulat= +e +>> 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 the BIP +>>>> itself. PoS, VDFs, and so on are interesting but I guess there are oth= +er +>>>> threads going on these topics already where they would be relevant. +>>>> +>>>> Also, it's important to distinguish between oPoW and these other +>>>> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't = +alter +>>>> the core game theory or security assumptions of Hashcash and actually +>>>> contains SHA (can be SHA3, SHA256, etc hash is interchangeable). +>>>> +>>>> Cheers, +>>>> Mike +>>>> +>>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev < +>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: +>>>> +>>>>> 1. i never suggested vdf's to replace pow. +>>>>> +>>>>> 2. my suggestion was specifically *in the context of* a working +>>>>> proof-of-burn protocol +>>>>> +>>>>> - vdfs used only for timing (not block height) +>>>>> - blind-burned coins of a specific age used to replace proof of work +>>>>> - the required "work" per block would simply be a competition to +>>>>> acquire rewards, and so miners would have to burn coins, well in +>>>>> advance, and hope that their burned coins got rewarded in some far +>>>>> future +>>>>> - the point of burned coins is to mimic, in every meaningful way, the +>>>>> value gained from proof of work... without some of the security +>>>>> drawbacks +>>>>> - the miner risks losing all of his burned coins (like all miners ris= +k +>>>>> losing their work in each block) +>>>>> - new burns can't be used +>>>>> - old burns age out (like ASICs do) +>>>>> - other requirements on burns might be needed to properly mirror the +>>>>> properties of PoW and the incentives Bitcoin uses to mine honestly. +>>>>> +>>>>> 3. i do believe it is *possible* that a "burned coin + vdf system" +>>>>> might be more secure in the long run, and that if the entire space +>>>>> agreed that such an endeavor was worthwhile, a test net could be spun +>>>>> up, and a hard-fork could be initiated. +>>>>> +>>>>> 4. i would never suggest such a thing unless i believed it was +>>>>> possible that consensus was possible. so no, this is not an "alt +>>>>> coin" +>>>>> +>>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <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 the +>>>>> property of VDFs, miners are able show proof of work. +>>>>> >> > +>>>>> >> > 2. Use current PoW mechanism with lower difficulty so finding a +>>>>> block takes 1 minute on average, again subject to as-is difficulty +>>>>> adjustments. +>>>>> >> > +>>>>> >> > As a result, variation in block times will be greatly reduced. +>>>>> >> +>>>>> >> As I understand it, another weakness of VDFs is that they are not +>>>>> inherently progress-free (their sequential nature prevents that; they= + are +>>>>> inherently progress-requiring). +>>>>> >> +>>>>> >> Thus, a miner which focuses on improving the amount of energy that +>>>>> it can pump into the VDF circuitry (by overclocking and freezing the +>>>>> circuitry), could potentially get into a winner-takes-all situation, +>>>>> possibly leading to even *worse* competition and even *more* energy +>>>>> consumption. +>>>>> >> After all, if you can start mining 0.1s faster than the +>>>>> competition, that is a 0.1s advantage where *only you* can mine *in t= +he +>>>>> 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 <http://www.powx.org/> +>>>> +>>> +>>> +>>> -- +>>> Michael Dubrovsky +>>> Founder; PoWx +>>> www.PoWx.org <http://www.powx.org/> +>>> _______________________________________________ +>>> bitcoin-dev mailing list +>>> bitcoin-dev@lists.linuxfoundation.org +>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>> +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> + +--0000000000002bd5b605c3040e1c +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>@Lloyd</div><div><br></div>>=C2=A0 + +Proof-of-SquareSpace<div><br></div><div>I agree with your points about dele= +gated proof of stake. I wrote <a href=3D"https://github.com/fresheneesz/qua= +ntificationOfConsensusProtocolSecurity#analysis-of-delegated-proof-of-stake= +-dpos">my own critique about that</a>=C2=A0as well. And your point, that ot= +her forms of PoS devolve to DPoS by virtue of people wanting to actively mi= +nt blocks without exposing their coins in hot wallets, is an interesting on= +e.=C2=A0</div><div><br></div><div>> how are the users meant to redelegat= +e their stake to honest pools?<br></div><div><br></div><div>This could be m= +itigated partially if delegation=C2=A0didn't require any kind of blockc= +hain transaction. For example, users could simply send a signed message say= +ing "this other key can mint blocks with my coins", and then mint= +ing a block using those coins would require presenting the delegation signa= +ture. This only partially mitigates the problem since the dishonest pool wo= +uld still be able to use those coins as well, so it would be a race at that= + point. Still better than nothing. And pools could simply require full cust= +ody of the coins.</div><div><br></div><div>From what you mentioned, it soun= +ds like maybe Algorand does something similar to this.=C2=A0</div><div><br>= +</div><div>> I don't see a way to get around the conflicting require= +ment that the keys for large amounts of coins should be kept offline but th= +ose are exactly the coins we need online to make the scheme secure.</div><d= +iv><br></div><div>There are a couple solutions you didn't mention. One = +is your "traditional" locked-stake kind of systems, where partici= +pants are required to lock their stake for long periods of time. Since norm= +al users aren't likely to want to do this, it will likely be left to mo= +re sophisticated stakers likely staking very large amounts.=C2=A0</div><div= +><br></div><div>Both mechanisms you mentioned allow delegation, and it migh= +t seem like maybe there'd be a way to disallow delegation, however sinc= +e users can always give custody of their coins to trusted pools, that would= + be a delgation mechanism of last resort that can't be removed. So you = +can do things that make it hard (for both users and pool operators) to dele= +gate trustlessly, but you can't get rid of the ability to delgate entir= +ely.</div><div><br></div><div>In general, the situations where I see people= + not pooling are:</div><div><br></div><div>A. They are entirely prevented b= +y technical means. It seems reasonably clear that this is impossible.</div>= +<div>B. The downsides are more than unsophisticated users are willing to in= +cur (eg stake locking).</div><div>C. The rewards are so small that it isn&#= +39;t worth it for people to put in much effort to gain them.</div><div>D. T= +he rewards are so frequent that pooling is unnecessary.</div><div><br></div= +><div>B excludes a lot of people from being able to help secure the chain, = +but this is not materially different from PoW mining in that regard. D is a= + bit border line. With 1 billion people attempting to participate and 10 mi= +nute blocks, 232 people would need to share the block reward in order to ex= +pect a payout on average once per month. With 8 billion people that would t= +urn into more like 1700 people. This seems potentially doable (eg via cosig= +ner requirements on minted blocks), but it is a lot of participants per blo= +ck.=C2=A0</div><div><br></div><div>I think options C and D combined would b= +e an ideal approach here. Because minting uses very few real resources, min= +ting could be pretty much have arbitrarily low ongoing costs. This means fe= +es can be low and blocks can have low payouts. If the reward was low and pe= +ople could expect to see it once every couple years, people could simply tr= +eat it like a lottery. Great if they win it now, but nothing that anyone ne= +eds to rely on (which would incentivize the pools to reduce variance that w= +e want to avoid). If there is no locked stake or other major barriers in pl= +ace to minting blocks, that would also help avoid the compultion to use a p= +ool.</div><div><br></div><div>In any case, you bring up good points, and th= +ey certainly complicate the issue. By the way, if you were confused as to w= +hat VPoS was in the section from my above link, <a href=3D"https://github.c= +om/fresheneesz/ValidatedProofOfStake">this might satisfy your curiosity</a>= +.</div><div><br></div><div>Cheers</div><div><br></div><div><br></div><div><= +br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma= +il_attr">On Sat, May 22, 2021 at 5:41 PM Lloyd Fournier <<a href=3D"mail= +to:lloyd.fourn@gmail.com">lloyd.fourn@gmail.com</a>> wrote:<br></div><bl= +ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= +t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Bil= +ly,</div><br>I was going to write a post which started by dismissing many o= +f the weak arguments that are made against PoS made in this thread and else= +where.<br>Although I don't agree with all your points you have done a d= +ecent job here so I'll focus on the second part: why I think Proof-of-S= +take is inappropriate for a Bitcoin-like system.<br><br>Proof of stake is n= +ot fit for purpose for a global settlement layer in a pure digital asset (i= +.e. "digital gold") which is what Bitcoin is trying to be.<br>PoS= + necessarily gives responsibilities to the holders of coins that they do no= +t want and cannot handle.<br>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>As much as hardcore Bitcoiners try to c= +onvince them to run their own node, most don't, and that's perfectl= +y acceptable.<br>At no point do their personal decisions affect the underly= +ing consensus -- it only affects their personal security assurance (not tha= +t of the system itself).<br>In PoS systems this clean separation of respons= +ibilities does not exist.<br><div><br></div><div>I think that the more rigo= +rously studied PoS protocols will work fine within the security claims made= + in their papers.</div><div>People who believe that these protocols are des= +tined for catastrophic consensus failure are certainly in for a surprise.</= +div><div>But the devil is in the detail.<br></div>Let's look at what th= +e implications of using the leading proof of stake protocols would have on = +Bitcoin:<br><br>### Proof of SquareSpace (Cardano, Polkdadot)<br><br>Cardan= +o is a UTXO based PoS coin based on Ouroboros Praos[3] with an inbuilt on-c= +hain delegation system[5].<br>In these protocols, coin holders who do not w= +ant to run their node with their hot keys in it delegate it to a "Stak= +e Pool".<br>I call the resulting system Proof-of-SquareSpace since mos= +t will choose a pool by looking around for one with a nice website and offe= +ring the largest share of the block reward.<br>On the surface this might so= +und no different than someone with an mining rig shopping around for a good= + mining pool but there are crucial differences:<br><br>1. The person making= + the decision is forced into it just because they own the currency -- someo= +ne with a mining rig has purchased it with the intent to make profit by par= +ticipating in consensus.<br><br>2. When you join a mining pool your systems= + are very much still online. You are just partaking in a pool to reduce you= +r profit variance. You still see every block that you help create and *you = +never help create a block without seeing it first*.<br><br>3. If by SquareS= +pace sybil attack you gain a dishonest majority and start censoring transac= +tions how are the users meant to redelegate their stake to honest pools?<br= +>I guess they can just send a transaction delegating to another pool...oh w= +ait I guess that might be censored too! This seems really really bad.<br>In= + Bitcoin, miners can just join a different pool at a whim. There is nothing= + the attacker can do to stop them. A temporary dishonest majority heals rel= +atively well.<br><br>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 th= +ere.<br>Being able to associate every UTXO to an account ruins one of the m= +ain privacy advantages of the UTXO model.<br>It also grows the size of the = +blockchain significantly.<br><br>### "Pure" proof of stake (Algor= +and)<br><br>Algorand's[4] approach is to only allow online stake to par= +ticipate in the protocol.<br>Theoretically, This means that keys holding fu= +nds have to be online in order for them to author blocks when they are chos= +en.<br>Of course in reality no one wants to keep their coin holding keys on= +line so in Alogorand you can authorize a set of "participation keys&qu= +ot;[1] that will be used to create blocks on your coin holding key's be= +half.<br>Hopefully you've spotted the problem.<br>You can send your par= +ticipation keys to any malicious party with a nice website (see random exam= +ple [2]) offering you a good return.<br>Damn it's still Proof-of-Square= +Space!<br>The minor advantage is that at least the participation keys expir= +e after a certain amount of time so eventually the SquareSpace attacker wil= +l lose their hold on consensus.<br>Importantly there is also less junk on t= +he blockchain because the participation keys are delegated off-chain and so= + are not making as much of a mess.<br><br>### Conclusion<br><br>I don't= + see a way to get around the conflicting requirement that the keys for larg= +e amounts of coins should be kept offline but those are exactly the coins w= +e need online to make the scheme secure.<br><div>If we allow delegation the= +n we open up a new social attack surface and it degenerates to Proof-of-Squ= +areSpace.</div><div><br></div>For a "digital gold" like system li= +ke Bitcoin we optimize for simplicity and desperately want to avoid extrane= +ous responsibilities for the holder of the coin.<br>After all, gold is an i= +nert element on the periodic table that doesn't confer responsibilities= + on the holder to maintain the quality of all the other bars of gold out th= +ere.<br>Bitcoin feels like this too and in many ways is more inert and beau= +tifully boring than gold.<br><div>For Bitcoin to succeed I think we need to= + keep it that way and Proof-of-Stake makes everything a bit too exciting.</= +div><div><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 bei= +ng able to say it uses less electricity. It goes without saying that making= + bad technical decisions to appease the current political climate is an ana= +thema to Bitcoin.<br></div><div><br></div><div>Would be interested to know = +if you or others think differently on these points.<br></div><br>[1]: <a hr= +ef=3D"https://developer.algorand.org/docs/run-a-node/participate/generate_k= +eys/" target=3D"_blank">https://developer.algorand.org/docs/run-a-node/part= +icipate/generate_keys/</a><br>[2]: <a href=3D"https://staking.staked.us/alg= +orand-staking" target=3D"_blank">https://staking.staked.us/algorand-staking= +</a><br>[3]: <a href=3D"https://eprint.iacr.org/2017/573.pdf" target=3D"_bl= +ank">https://eprint.iacr.org/2017/573.pdf</a><br>[4]: <a href=3D"https://al= +gorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9= +_theoretical.pdf" target=3D"_blank">https://algorandcom.cdn.prismic.io/algo= +randcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf</a><br><div>= +[5]: <a href=3D"https://hydra.iohk.io/build/790053/download/1/delegation_de= +sign_spec.pdf" target=3D"_blank">https://hydra.iohk.io/build/790053/downloa= +d/1/delegation_design_spec.pdf</a></div><div><br></div><div>Cheers,<br></di= +v><br>LL<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"= +gmail_attr">On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <= +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote c= +lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli= +d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I think there is= + a lot of misinformation and bias against Proof of Stake. Yes there have be= +en lots of shady coins that use insecure PoS mechanisms. Yes there have bee= +n 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 ever= +yone that there is a difference between "proved to be impossible"= + and "have not achieved recognized success yet". Most of the argu= +ments levied against PoS are out of date or rely on unproven assumptions or= + extrapolation from the analysis of a particular PoS system. I certainly do= +n't think we should experiment with bitcoin by switching to PoS, but fr= +om my research, it seems very likely that there is a proof of stake consens= +us protocol we could build that has substantially higher security (cost / c= +apital required to execute an attack) while at the same time costing far le= +ss resources (which do translate to fees on the network) *without* compromi= +sing any of the critical security properties bitcoin relies on. I think the= + critical piece of this is the disagreements around hardcoded checkpoints, = +which is a critical piece solving=C2=A0attacks that=C2=A0could be levied on= + a PoS chain, and how that does (or doesn't) affect the security model.= +=C2=A0</div><div><br></div>@Eric Your proof of stake fallacy seems to be sa= +ying that PoS is worse when a 51% attack happens. While I agree, I think th= +at line of thinking omits important facts:<br>* The capital=C2=A0required t= +o 51% attack a PoS chain can be made substantially greater than on a PoS ch= +ain.=C2=A0<div>* The capital the attacker stands to lose can be substantial= +ly greater as well if the attack is successful.<br><div>* The effectiveness= + of paying miners to raise the honest fraction of miners above 50% may be q= +uite bad.</div><div>* Allowing a 51% attack is already unacceptable. It sho= +uld be considered whether what happens in the case of a 51% may not be sign= +ificantly different. The currency would likely be critically damaged in a 5= +1% attack regardless of consensus mechanism.</div><div><br></div><div>>= +=C2=A0<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-seri= +f">Proof-of-stake tends towards oligopolistic control</span></div><div><spa= +n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></s= +pan></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,= +sans-serif">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, yo= +u should expect to earn 10x as much minting revenue - not more than 10x. By= + contrast, proof of work does in fact have clear centralization pressure - = +this is not disputed. Our goal in relation to that is to ensure that the ce= +ntralization pressure remains insignifiant. Proof of work also clearly has = +a lot more barriers to entry than any proof of stake system does. Both of t= +hese mean the tendency towards oligopolistic control is worse for PoW.</spa= +n></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sa= +ns-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family= +:arial,helvetica,sans-serif">>=C2=A0</span>Energy usage, in-and-of-itsel= +f, is nothing to be ashamed of!!</div><div><br></div><div>I certainly agree= +. Bitcoin's=C2=A0energy usage at the moment is I think quite warranted.= + However, the question is: can we do substantially better. I think if we ca= +n, we probably should... eventually.</div><div><div><br></div><div>> Pro= +of of Stake is only resilient to=C2=A0=E2=85=93 of the network demonstratin= +g a Byzantine Fault, whilst Proof of Work is resilient up to the=C2=A0=C2= +=BD threshold</div><div><br></div><div>I see no mention of this in the=C2= +=A0<a href=3D"https://download.wpsoftware.net/bitcoin/pos.pdf" target=3D"_b= +lank">pos.pdf</a>=C2=A0you linked to. I'm not aware of any proof that <= +b>all </b>PoS systems have a failure threshold of 1/3. I know that staking = +systems like Casper do in fact have that 1/3 requirement. However there are= + PoS designs that should exceed that up to nearly 50% as far as I'm awa= +re. Proof of work is not in fact resilient up to the 1/2 threshold in the w= +ay you would think. IE, if 100% of miners are currently honest and have a c= +ollective 100 exahashes/s hashpower, an attacker does not need to obtain 10= +0 exahashes/s, but actually only needs to accumulate 50 exahashes/s. This i= +s because as the attacker accumulates hashpower, it drives honest miners ou= +t 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 req= +uire an attacker to obtain 33% of the hashpower because of the <a href=3D"h= +ttps://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the= +-selfish-economic-attack" target=3D"_blank">selfish mining attack</a>=C2=A0= +discussed in depth in this paper: <a href=3D"https://arxiv.org/abs/1311.024= +3" target=3D"_blank">https://arxiv.org/abs/1311.0243</a>. Together, both of= + these things reduce PoW's security by a factor of about 83% (1 - 50%*3= +3%).</div><div><br></div><div>=C2=A0> Proof of Stake requires other trad= +e-offs which are incompatible with Bitcoin's objective (to be a trustle= +ss digital cash) =E2=80=94 specifically the famous "security vs. liven= +ess" guarantee</div><div><br></div><div>Do you have a good source that= + talks about why you think proof of stake cannot be used for a trustless di= +gital cash?=C2=A0</div><div><br></div><div>> You cannot gain tokens with= +out someone choosing to give up those coins - a form of permission.</div><d= +iv><br></div><div>This is not a practical constraint. Just like in mining, = +some nodes may reject you, but there will likely be more that will accept y= +ou, some sellers may reject you, but most would accept your money as paymen= +t for bitcoins. I don't think requiring the "permission" of o= +ne of millions of people in the market can be reasonably considered a "= +;permissioned currency".=C2=A0=C2=A0</div><div><br></div></div><div>&g= +t; 2. Proof of stake must have a trusted means of timestamping to regulate = +overproduction of blocks</div><div><br></div><div>Both PoW and PoS could mi= +ne/mint blocks twice as fast if everyone agreed to double their clock speed= +s. Both systems rely on an honest majority sticking to standard time.=C2=A0= +=C2=A0</div><div><br></div></div></div><br><div class=3D"gmail_quote"><div = +dir=3D"ltr" class=3D"gmail_attr">On Wed, May 19, 2021 at 5:32 AM Michael Du= +brovsky via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfounda= +tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> w= +rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= +x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= +=3D"ltr">Ah sorry, I didn't realize this was, in fact, a different thre= +ad! :)</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_= +attr">On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <<a href=3D"mai= +lto:mike@powx.org" target=3D"_blank">mike@powx.org</a>> wrote:<br></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 dir=3D"ltr">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 th= +ese topics already where they would be relevant.=C2=A0<div><br></div><div>A= +lso, it's important=C2=A0to distinguish between oPoW and these other &q= +uot;alternatives" to Hashcash. oPoW is a true Proof of Work that doesn= +'t alter the core game theory or security assumptions of Hashcash and a= +ctually contains SHA (can be SHA3, SHA256, etc hash is interchangeable).</d= +iv><div><br></div><div>Cheers,</div><div>Mike=C2=A0</div></div><br><div cla= +ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 18, 20= +21 at 4:55 PM Erik Aronesty via bitcoin-dev <<a href=3D"mailto:bitcoin-d= +ev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoun= +dation.org</a>> wrote:<br></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">1. i never suggested vdf's to replace pow.<br> +<br> +2. my suggestion was specifically *in the context of* a working<br> +proof-of-burn protocol<br> +<br> +- vdfs used only for timing (not block height)<br> +- blind-burned coins of a specific age used to replace proof of work<br> +- the required "work" per block would simply be a competition to<= +br> +acquire rewards, and so miners would have to burn coins, well in<br> +advance, and hope that their burned coins got rewarded in some far<br> +future<br> +- the point of burned coins is to mimic, in every meaningful way, the<br> +value gained from proof of work... without some of the security<br> +drawbacks<br> +- the miner risks losing all of his burned coins (like all miners risk<br> +losing their work in each block)<br> +- new burns can't be used<br> +- old burns age out (like ASICs do)<br> +- other requirements on burns might be needed to properly mirror the<br> +properties of PoW and the incentives Bitcoin uses to mine honestly.<br> +<br> +3. i do believe it is *possible* that a "burned coin + vdf system"= +;<br> +might be more secure in the long run, and that if the entire space<br> +agreed that such an endeavor was worthwhile, a test net could be spun<br> +up, and a hard-fork could be initiated.<br> +<br> +4. i would never suggest such a thing unless i believed it was<br> +possible that consensus was possible.=C2=A0 so no, this is not an "alt= +<br> +coin"<br> +<br> +On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <<a href=3D"mailto:zachgr= +w@gmail.com" target=3D"_blank">zachgrw@gmail.com</a>> wrote:<br> +><br> +> Hi ZmnSCPxj,<br> +><br> +> Please note that I am not suggesting VDFs as a means to save energy, b= +ut solely as a means to make the time between blocks more constant.<br> +><br> +> Zac<br> +><br> +><br> +> On Tue, 18 May 2021 at 12:42, ZmnSCPxj <<a href=3D"mailto:ZmnSCPxj@= +protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>> wrote:<br= +> +>><br> +>> Good morning Zac,<br> +>><br> +>> > VDFs might enable more constant block times, for instance by = +having a two-step PoW:<br> +>> ><br> +>> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being s= +ubject to difficulty adjustments similar to the as-is). As per the property= + of VDFs, miners are able show proof of work.<br> +>> ><br> +>> > 2. Use current PoW mechanism with lower difficulty so finding= + a block takes 1 minute on average, again subject to as-is difficulty adjus= +tments.<br> +>> ><br> +>> > As a result, variation in block times will be greatly reduced= +.<br> +>><br> +>> As I understand it, another weakness of VDFs is that they are not = +inherently progress-free (their sequential nature prevents that; they are i= +nherently progress-requiring).<br> +>><br> +>> Thus, a miner which focuses on improving the amount of energy that= + it can pump into the VDF circuitry (by overclocking and freezing the circu= +itry), could potentially get into a winner-takes-all situation, possibly le= +ading to even *worse* competition and even *more* energy consumption.<br> +>> After all, if you can start mining 0.1s faster than the competitio= +n, that is a 0.1s advantage where *only you* can mine *in the entire world*= +.<br> +>><br> +>> Regards,<br> +>> ZmnSCPxj<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= +><div dir=3D"ltr"><div><div dir=3D"ltr"><div style=3D"font-size:small">Mich= +ael Dubrovsky<br></div><div style=3D"font-size:small">Founder; PoWx</div><d= +iv style=3D"font-size:small"><a href=3D"http://www.powx.org/" style=3D"colo= +r:rgb(17,85,204)" target=3D"_blank">www.PoWx.org</a></div></div></div></div= +></div> +</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"= +><div dir=3D"ltr"><div><div dir=3D"ltr"><div style=3D"font-size:small">Mich= +ael Dubrovsky<br></div><div style=3D"font-size:small">Founder; PoWx</div><d= +iv style=3D"font-size:small"><a href=3D"http://www.powx.org/" style=3D"colo= +r:rgb(17,85,204)" target=3D"_blank">www.PoWx.org</a></div></div></div></div= +></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div> + +--0000000000002bd5b605c3040e1c-- + + |