path: root/78/d34f50e9d884f27d64a7ffb37d3152a07749df

Return-Path: <earonesty@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D6E41C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 13:00:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id B94F3403DF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 13:00:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level: 
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.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 ODuB9cXN6nur
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 13:00:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com
 [IPv6:2607:f8b0:4864:20::1029])
 by smtp4.osuosl.org (Postfix) with ESMTPS id A320C4039A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 13:00:23 +0000 (UTC)
Received: by mail-pj1-x1029.google.com with SMTP id
 j6-20020a17090adc86b02900cbfe6f2c96so13116454pjv.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 25 May 2021 06:00:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=vwdoYEai3bOeWnQ4poDG2cv4sSf252fCFtMqqR4kB80=;
 b=VAv4zAiiWXF4PYkqwEzvXRl0cZgF+A4koMAxvAxEsrW+re5H9/aFGvyN1QVJ+w9ERK
 AafKaN7kroe6yTBLFqfShNUXfmFWXzkPn6l76yZDZ+eXVGjpTn3SjggGtCfFsbV8n0q/
 hKs3qPKr9D9iLKvInGdRKHCqsGb6A4Zzc+f4Y2G0dHAh8TXwan9k7xOtD0kUecM4zSJw
 gkhmvwzcQgWgU7tJCg6QE54Wd9mW5EEluibCPbVOnAYSfIhEhro96D0Uw2JMAHx441Ia
 vvTJMQ7Mfm7Vj5eGxAdBIkb+TYNsWVaVG61AVMOHfeKpwBvvk4eaoZTyfkxldV+JFo3j
 h4Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=vwdoYEai3bOeWnQ4poDG2cv4sSf252fCFtMqqR4kB80=;
 b=XaY23OZAvl3AL3cicd95lKzedMnC8ts8bvcxxMaa1K7a8Arz4cqlfO1+1/rosFyhgW
 fECDIf4y5pIq2I68hFHY2RpxEw9C49rrmFRU390mOrneQ1j64TVq/tSx6lMM0hbS4OdC
 AMfmeyqFGu5oG9w6LzS/EGPuMG5LvHUda+/i2gpX0HCFHqvxsnFAhht8l5Zqe6jfOSZy
 7lio4nu65IJG7QS/1g31x69CIiJ4EpyPKMXWlZukCQCjgUzzfmeHW1WjI/iBbirQDJ7S
 osR4nqurhtj/1scF2ixjjZ1hTISofpIBRd8hUUDIJJl8srvJ3lDW4kZlwZk3O91wpkIN
 QiUw==
X-Gm-Message-State: AOAM533VX6f4C4O/xmwBkaiJ+4DiSP/G0sq48W7UHCVfD1LJAuta/PmQ
 zT8Kj/qD/w2enFrIghirAaXmSwx+CGjE5FbQ3ECmCTk=
X-Google-Smtp-Source: ABdhPJzi5/0//vT07wvPUZgKpeJSU8FyuYgBoOrvQasJwOQDxL++7UW5RdIKpjFCRuQkAIdl+mtSSUdc0tknz1VYVTQ=
X-Received: by 2002:a17:902:ec8a:b029:f8:dd34:25e9 with SMTP id
 x10-20020a170902ec8ab02900f8dd3425e9mr13970775plg.60.1621947622488; Tue, 25
 May 2021 06:00:22 -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>
 <CAJowKgJOZwb0PgW93Y+Jy+yi1kv09Gu7-gjWvt7eUqWfJ_zJuw@mail.gmail.com>
 <CAGpPWDbWvBQd3xh8fx+Le8br2LmsqC_Tds5R=wvw1EmiLk42Xw@mail.gmail.com>
 <CAJowKgJYUkxJ4htPvCLtARRr0Db13+BKzWtG40DEv6uEOh5yXw@mail.gmail.com>
 <CAGpPWDY4KgNVEoMDAJkWReX4zUUjDuB5SwB0Ap6OU98fuK4DxA@mail.gmail.com>
In-Reply-To: <CAGpPWDY4KgNVEoMDAJkWReX4zUUjDuB5SwB0Ap6OU98fuK4DxA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 25 May 2021 09:00:11 -0400
Message-ID: <CAJowKgJWZ++6NkbYk15NBtA7x37of0n3_qF1UjCbV0Ui7XG8zA@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 25 May 2021 14:52:02 +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: Tue, 25 May 2021 13:00:26 -0000

> > you burn them to be used at a future particular block height

> This sounds exploitable. It seems like an attacker could simply focus all=
 their burns on a particular set of 6 blocks to double spend, minimizing th=
eir 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 of th=
e chain.
>
> Yes, but the same can be said of any coin, even ones that do have the not=
hing at stake problem. This isn't sufficient tho because the chain is a com=
mon good, and the tragedy of the commons holds for it.
>
> > you burn them to be used at a future particular block height
>
> This sounds exploitable. It seems like an attacker could simply focus all=
 their burns on a particular set of 6 blocks to double spend, minimizing th=
eir 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 to
>> mine block 553.   if i have a choice between two chains, one longer
>> and one shorter, i can only choose one... deterministically, for that
>> burn: the chain with the height 553.   if we fix the "lead time" for
>> burned coins to be weeks or even months in advance, miners have a very
>> strong, long-term, investment in the stability of the chain.
>>
>> therefore there is no "nothing at stake" problem.   it's
>> deterministic, so miners have no choice.  they can *only* choose the
>> transactions that go into the block.  they cannot choose which chain
>> to mine, and it's time-locked, so rollbacks and instability always
>> hurt miners the most.
>>
>> the "punishment" systems of PoS are "weird at best", certainly
>> unproven.   i can imagine scenarios where large stakeholders can
>> collude to punish smaller stakeholders simply to drive them out of
>> business, for example.   and then you have to put checks in place to
>> prevent that, and more checks for those prevention system...
>>
>> in PoB, there is no complexity.  simpler systems like this are
>> typically more secure.
>>
>> PoB also solves problems caused by "energy dependence", which could
>> lead to state monopolies on mining (like the new Bitcoin Mining
>> Council).   these consortiums, if state sanctioned, could become a
>> source of censorship, for example.   Since PoB doesn't require you to
>> have a live, well-connected node, it's harder to censor & harder to
>> trace.
>>
>> Eliminating this weakness seems to be in the best interests of
>> existing stakeholders
>>
>>
>>
>>
>> On Mon, May 24, 2021 at 4:44 PM Billy Tetrud <billy.tetrud@gmail.com> wr=
ote:
>> >
>> > >  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. B=
ut yes, only a small fraction of the total coins need to be online.
>> >
>> > > your burn investment is always "at stake", any redaction can result =
in a loss-of-burn, because burns can be tied, precisely, to block-heights
>> >
>> > So you're saying that if say someone tries to mine a block on a shorte=
r chain, that requires them to send a transaction burning their coins, and =
that transaction could also be spent on the longest chain, which means thei=
r 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 peo=
ple who publish proofs of this happening on the main chain). In quorum-base=
d PoS, you can punish people in the quorum that propose or sign multiple bl=
ocks for the same height. The "nothing at stake" problem is a solved proble=
m 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 that th=
e keys for large amounts of coins should be kept offline but those are exac=
tly 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 you=
r view?
>> >>
>> >> definition of nothing at stake: in the event of a fork, whether the
>> >> fork is accidental or a malicious, the optimal strategy for any miner
>> >> is to mine on every chain, so that the miner gets their reward no
>> >> matter which fork wins.   indeed in proof-of-stake, the proofs are
>> >> published on the very chains mines, so the incentive is magnified.
>> >>
>> >> in proof-of-burn, your burn investment is always "at stake", any
>> >> redaction can result in a loss-of-burn, because burns can be tied,
>> >> precisely, to block-heights
>> >>
>> >> as a result, miners no longer have an incentive to mine all chains
>> >>
>> >> in this way proof of burn can be more secure than proof-of-stake, and
>> >> even more secure than proof of work
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >>
>> >> On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >> >
>> >> > Hi Billy,
>> >> >
>> >> > I was going to write a post which started by dismissing many of the=
 weak arguments that are made against PoS made in this thread and elsewhere=
.
>> >> > Although I don't agree with all your points you have done a decent =
job here so I'll focus on the second part: why I think Proof-of-Stake is in=
appropriate 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 try=
ing to be.
>> >> > PoS necessarily gives responsibilities to the holders of coins that=
 they do not want and cannot handle.
>> >> > In Bitcoin, large unsophisticated coin holders can put their coins =
in cold storage without a second thought given to the health of the underly=
ing ledger.
>> >> > As much as hardcore Bitcoiners try to convince them to run their ow=
n node, most don't, and that's perfectly acceptable.
>> >> > At no point do their personal decisions affect the underlying conse=
nsus -- it only affects their personal security assurance (not that of the =
system itself).
>> >> > In PoS systems this clean separation of responsibilities does not e=
xist.
>> >> >
>> >> > I think that the more rigorously studied PoS protocols will work fi=
ne within the security claims made in their papers.
>> >> > People who believe that these protocols are destined for catastroph=
ic 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 s=
take protocols would have on Bitcoin:
>> >> >
>> >> > ### Proof of SquareSpace (Cardano, Polkdadot)
>> >> >
>> >> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with a=
n 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 ch=
oose a pool by looking around for one with a nice website and offering the =
largest share of the block reward.
>> >> > On the surface this might sound no different than someone with an m=
ining rig shopping around for a good mining pool but there are crucial diff=
erences:
>> >> >
>> >> > 1. The person making the decision is forced into it just because th=
ey own the currency -- someone with a mining rig has purchased it with the =
intent to make profit by participating in consensus.
>> >> >
>> >> > 2. When you join a mining pool your systems are very much still onl=
ine. You are just partaking in a pool to reduce your profit variance. You s=
till see every block that you help create and *you never help create a bloc=
k 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 s=
take 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 sy=
stem: every UTXO must indicate which staking account this UTXO belongs to s=
o the appropriate share of block rewards can be transferred there.
>> >> > Being able to associate every UTXO to an account ruins one of the m=
ain 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 o=
nline so in Alogorand you can authorize a set of "participation keys"[1] th=
at 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 p=
articipation 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 th=
e keys for large amounts of coins should be kept offline but those are exac=
tly 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 simpl=
icity and desperately want to avoid extraneous responsibilities for the hol=
der of the coin.
>> >> > After all, gold is an inert element on the periodic table that does=
n't confer responsibilities on the holder to maintain the quality of all th=
e other bars of gold out there.
>> >> > Bitcoin feels like this too and in many ways is more inert and beau=
tifully boring than gold.
>> >> > For Bitcoin to succeed I think we need to keep it that way and Proo=
f-of-Stake makes everything a bit too exciting.
>> >> >
>> >> > I suppose in the end the market will decide what is real digital go=
ld and whether these bad technical trade offs are worth being able to say i=
t uses less electricity. It goes without saying that making bad technical d=
ecisions to appease the current political climate is an anathema to Bitcoin=
.
>> >> >
>> >> > Would be interested to know if you or others think differently on t=
hese points.
>> >> >
>> >> > [1]: https://developer.algorand.org/docs/run-a-node/participate/gen=
erate_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_desig=
n_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 mecha=
nisms. Yes there have been massive issues with distribution of PoS coins (o=
f course there have also been massive issues with PoW coins as well). Howev=
er, 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 assumptio=
ns or extrapolation from the analysis of a particular PoS system. I certain=
ly don't think we should experiment with bitcoin by switching to PoS, but f=
rom my research, it seems very likely that there is a proof of stake consen=
sus protocol we could build that has substantially higher security (cost / =
capital required to execute an attack) while at the same time costing far l=
ess resources (which do translate to fees on the network) *without* comprom=
ising any of the critical security properties bitcoin relies on. I think th=
e critical piece of this is the disagreements around hardcoded checkpoints,=
 which is a critical piece solving attacks that could be levied on a PoS ch=
ain, and how that does (or doesn't) affect the security model.
>> >> >>
>> >> >> @Eric Your proof of stake fallacy seems to be saying that PoS is w=
orse when a 51% attack happens. While I agree, I think that line of thinkin=
g omits important facts:
>> >> >> * The capital required to 51% attack a PoS chain can be made subst=
antially greater than on a PoS chain.
>> >> >> * The capital the attacker stands to lose can be substantially gre=
ater 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 cons=
idered whether what happens in the case of a 51% may not be significantly d=
ifferent. The currency would likely be critically damaged in a 51% attack r=
egardless of consensus mechanism.
>> >> >>
>> >> >> > Proof-of-stake tends towards oligopolistic control
>> >> >>
>> >> >> People repeat this often, but the facts support this. There is no =
centralization pressure in any proof of stake mechanism that I'm aware of. =
IE if you have 10 times as much coin that you use to mint blocks, you shoul=
d expect to earn 10x as much minting revenue - not more than 10x. By contra=
st, 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 centraliz=
ation pressure remains insignifiant. Proof of work also clearly has a lot m=
ore barriers to entry than any proof of stake system does. Both of these me=
an the tendency towards oligopolistic control is worse for PoW.
>> >> >>
>> >> >> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>> >> >>
>> >> >> I certainly agree. Bitcoin's energy usage at the moment is I think=
 quite warranted. However, the question is: can we do substantially better.=
 I think if we can, we probably should... eventually.
>> >> >>
>> >> >> > Proof of Stake is only resilient to =E2=85=93 of the network dem=
onstrating a Byzantine Fault, whilst Proof of Work is resilient up to the =
=C2=BD threshold
>> >> >>
>> >> >> I see no mention of this in the pos.pdf you linked to. I'm not awa=
re of any proof that all PoS systems have a failure threshold of 1/3. I kno=
w that staking systems like Casper do in fact have that 1/3 requirement. Ho=
wever 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: https://arxiv.org/ab=
s/1311.0243. Together, both of these things reduce PoW's security by a fact=
or 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 specif=
ically 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 node=
s 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 bit=
coins. I don't think requiring the "permission" of one of millions of peopl=
e in the market can be reasonably considered a "permissioned currency".
>> >> >>
>> >> >> > 2. Proof of stake must have a trusted means of timestamping to r=
egulate 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 majorit=
y 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 BI=
P itself. PoS, VDFs, and so on are interesting but I guess there are other =
threads going on these topics already where they would be relevant.
>> >> >>>>
>> >> >>>> Also, it's important to distinguish between oPoW and these other=
 "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alte=
r the core game theory or security assumptions of Hashcash and actually con=
tains 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 <b=
itcoin-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 t=
o
>> >> >>>>> acquire rewards, and so miners would have to burn coins, well i=
n
>> >> >>>>> advance, and hope that their burned coins got rewarded in some =
far
>> >> >>>>> future
>> >> >>>>> - the point of burned coins is to mimic, in every meaningful wa=
y, the
>> >> >>>>> value gained from proof of work... without some of the security
>> >> >>>>> drawbacks
>> >> >>>>> - the miner risks losing all of his burned coins (like all mine=
rs 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 mirro=
r the
>> >> >>>>> properties of PoW and the incentives Bitcoin uses to mine hones=
tly.
>> >> >>>>>
>> >> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf syst=
em"
>> >> >>>>> might be more secure in the long run, and that if the entire sp=
ace
>> >> >>>>> agreed that such an endeavor was worthwhile, a test net could b=
e 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 "a=
lt
>> >> >>>>> coin"
>> >> >>>>>
>> >> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw@gmail.c=
om> 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.c=
om> 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 bein=
g subject to difficulty adjustments similar to the as-is). As per the prope=
rty of VDFs, miners are able show proof of work.
>> >> >>>>> >> >
>> >> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so find=
ing a block takes 1 minute on average, again subject to as-is difficulty ad=
justments.
>> >> >>>>> >> >
>> >> >>>>> >> > As a result, variation in block times will be greatly redu=
ced.
>> >> >>>>> >>
>> >> >>>>> >> As I understand it, another weakness of VDFs is that they ar=
e not inherently progress-free (their sequential nature prevents that; they=
 are inherently progress-requiring).
>> >> >>>>> >>
>> >> >>>>> >> Thus, a miner which focuses on improving the amount of energ=
y that it can pump into the VDF circuitry (by overclocking and freezing the=
 circuitry), could potentially get into a winner-takes-all situation, possi=
bly leading to even *worse* competition and even *more* energy consumption.
>> >> >>>>> >> After all, if you can start mining 0.1s faster than the comp=
etition, that is a 0.1s advantage where *only you* can mine *in the entire =
world*.
>> >> >>>>> >>
>> >> >>>>> >> Regards,
>> >> >>>>> >> ZmnSCPxj
>> >> >>>>> _______________________________________________
>> >> >>>>> bitcoin-dev mailing list
>> >> >>>>> bitcoin-dev@lists.linuxfoundation.org
>> >> >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> --
>> >> >>>> Michael Dubrovsky
>> >> >>>> Founder; PoWx
>> >> >>>> www.PoWx.org
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Michael Dubrovsky
>> >> >>> Founder; PoWx
>> >> >>> www.PoWx.org
>> >> >>> _______________________________________________
>> >> >>> bitcoin-dev mailing list
>> >> >>> bitcoin-dev@lists.linuxfoundation.org
>> >> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >>
>> >> >> _______________________________________________
>> >> >> bitcoin-dev mailing list
>> >> >> bitcoin-dev@lists.linuxfoundation.org
>> >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >> >
>> >> > _______________________________________________
>> >> > bitcoin-dev mailing list
>> >> > bitcoin-dev@lists.linuxfoundation.org
>> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev