path: root/3f/d1c30809f874cad40355efda613b4e6041f8f9

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 23FFFC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 19:29:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 1B3C1832C2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 19:29:06 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wyHZHPN44mwq
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 19:29:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D5B76832E6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 19:29:02 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id s6so29330474edu.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 23 May 2021 12:29:02 -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=nfFfKbUHdX9SAnkao2GD9TungHjGO27NVsUrDRcfZKw=;
 b=eV5pMTMYfXtpvv18I7+hXCCQvIeJyejX0Y7aKV3C+p/sSxnJzZLMBuzzxFpYdFvyky
 21D/aVlOkLiF7DWjjfsprLpcSgm0/ySF5oeLdaAMg1N/PZ1gy9L+OQTBr2O1o1Y5KA+Q
 q/Rl3G/SVqrqH1eWyvimANRTsQtvT7FMz4jOJE3ymNKIF7/Wi6KPrkLgZJ+5fHdflf+8
 LZHlPhVdzguGOEd9/thEcAkOEVeeUFVS8K8jN+3EaJq6FavPPnf2M8W8OieTKBN7Nhax
 fGmrUwknNuRx2X9LylKWq/Gb4geC8PVK1CNKjR/VFKHiYin/5JS0fejvLi9Eir+PFUJQ
 B5nw==
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=nfFfKbUHdX9SAnkao2GD9TungHjGO27NVsUrDRcfZKw=;
 b=TGldNLV7s3FafBWaJuDBk3o2CZlpij9ayoca6VGNkURnTQ3cdDt7Pe1MvHWYNsUlWq
 gcpDslTv/3ZyLSFVSg7ko4CMroR20HxlJZyOeL0SC07mI2UxDqJnDkwhSX+4Qv0tUvDK
 +x9drtuHTKxAUp9F3fzisx6ZfmNCdHzgd07n8G+NVzOU3h4zWqFPllMR01Nq3md5ewQf
 Dqxj4jCXBaX1DrImsGCaCa0J7TLJuxESYwQ5plUlIhVrZbV2c9E+ssOnxqBQRor/MDLQ
 toZSMuBDJchgmiGRX5vOb9fKMaWJuTrKj6GDoyAo7VhBaBb15O+27SS+8CRYYnEOf7fB
 U7JA==
X-Gm-Message-State: AOAM533MRLYgbTkfAPYBTPx/PYRpZr+eoku0/WOogTpab7clKr+9cz/q
 NFs16WquMNPsscadtPIfCK7deG2aku8KnH7l460=
X-Google-Smtp-Source: ABdhPJz0jrQAe42oUyFCO8br3fA1D+MFlUtF39PYtIFCQXeKjLYAwN6REYtKHCBRt4AVX6duzIEkKuLtM2kPw1GI0IE=
X-Received: by 2002:a05:6402:190e:: with SMTP id
 e14mr22118339edz.146.1621798141005; 
 Sun, 23 May 2021 12:29:01 -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>
 <CAGpPWDaBZ3Zx9VnSt01Rs5G9z1RsZgez+dF4P=PCP=jYN8M1Xg@mail.gmail.com>
In-Reply-To: <CAGpPWDaBZ3Zx9VnSt01Rs5G9z1RsZgez+dF4P=PCP=jYN8M1Xg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 23 May 2021 09:28:43 -1000
Message-ID: <CAGpPWDbfZeAMpH6h05nAnxL=2dpNB9E7BJef8eNriQgGctMmaQ@mail.gmail.com>
To: Lloyd Fournier <lloyd.fourn@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000017943c05c3044edf"
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:29:06 -0000

--00000000000017943c05c3044edf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I made a couple typos and mistakes in my couple previous emails:

* "People repeat this often, but the facts support this" -> "the facts *don=
't
*support this"
* "Together, both of these things reduce PoW's security by a factor of
about 83% (1 - 50%*33%)." -> "factor of about 83% (1 - 50%**(50% - 33%)/50%=
*)."
(I made a mistake that happened to come out to an almost identical result
coincidentally).
* "And pools could simply require full custody of the coins." -> "*But *poo=
ls
could..."

On Sun, May 23, 2021 at 9:10 AM Billy Tetrud <billy.tetrud@gmail.com> wrote=
:

> @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=
#analysis-of-delegated-proof-of-stake-dpos> as
> well. And your point, that other forms of PoS devolve to DPoS by virtue o=
f
> people wanting to actively mint blocks without exposing their coins in ho=
t
> 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 o=
f
> 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 rac=
e
> 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 the=
ir
> 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 b=
it
> border line. With 1 billion people attempting to participate and 10 minut=
e
> blocks, 232 people would need to share the block reward in order to expec=
t
> 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 cosigne=
r
> 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. Gre=
at
> 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, th=
at
> 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 sectio=
n
> 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
>> 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 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 larg=
est
>> 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 ow=
n
>> the currency -- someone with a mining rig has purchased it with the inte=
nt
>> 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 sti=
ll
>> 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 star=
t
>> 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 t=
he
>> 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 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 los=
e
>> 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 key=
s
>> for large amounts of coins should be kept offline but those are exactly =
the
>> coins we need online to make the scheme secure.
>> If we allow delegation then we open up a new social attack surface and i=
t
>> 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
>> beautifully boring than gold.
>> For Bitcoin to succeed I think we need to keep it that way and
>> Proof-of-Stake makes everything a bit too exciting.
>>
>> I suppose in the end the market will decide what is real digital gold an=
d
>> whether these bad technical trade offs are worth being able to say it us=
es
>> 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 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 considere=
d
>>> whether what happens in the case of a 51% may not be significantly
>>> different. The currency would likely be critically damaged in a 51% att=
ack
>>> regardless of consensus mechanism.
>>>
>>> > Proof-of-stake tends towards oligopolistic control
>>>
>>> People repeat this often, but the facts support this. There is no
>>> centralization pressure in any proof of stake mechanism that I'm aware =
of.
>>> IE if you have 10 times as much coin that you use to mint blocks, you
>>> should expect to earn 10x as much minting revenue - not more than 10x. =
By
>>> contrast, proof of work does in fact have clear centralization pressure=
 -
>>> this is not disputed. Our goal in relation to that is to ensure that 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 quit=
e
>>> 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 demonstr=
ating a
>>> Byzantine Fault, whilst Proof of Work is resilient up to the =C2=BD thr=
eshold
>>>
>>> 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 t=
o
>>> nearly 50% as far as I'm aware. Proof of work is not in fact resilient =
up
>>> to the 1/2 threshold in the way you would think. IE, if 100% of miners =
are
>>> currently honest and have a collective 100 exahashes/s hashpower, an
>>> attacker does not need to obtain 100 exahashes/s, but actually only nee=
ds
>>> to accumulate 50 exahashes/s. This is because as the attacker accumulat=
es
>>> hashpower, it drives honest miners out of the market as the difficulty
>>> increases to beyond what is economically sustainable. Also, its been sh=
own
>>> 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/quantificationOfConsensusProtocolSecuri=
ty#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 specific=
ally 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 coin=
s
>>> - 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 o=
f
>>> 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 agree=
d
>>> 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 ot=
her
>>>>> 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, th=
e
>>>>>> value gained from proof of work... without some of the security
>>>>>> drawbacks
>>>>>> - the miner risks losing all of his burned coins (like all miners ri=
sk
>>>>>> 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 spu=
n
>>>>>> 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 c=
onstant.
>>>>>> >
>>>>>> > 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; the=
y are
>>>>>> inherently progress-requiring).
>>>>>> >>
>>>>>> >> Thus, a miner which focuses on improving the amount of energy tha=
t
>>>>>> 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 <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
>>>
>>

--00000000000017943c05c3044edf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I made a couple typos and mistakes in my couple previous e=
mails:<div><br></div><div>* &quot;<span style=3D"color:rgb(0,0,0);font-fami=
ly:arial,helvetica,sans-serif">People repeat this often, but the facts supp=
ort this&quot; -&gt; &quot;the facts <b>don&#39;t </b>support this&quot;</s=
pan></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,=
sans-serif">* &quot;</span>Together, both of these things reduce PoW&#39;s =
security by a factor of about 83% (1 - 50%*33%).&quot; -&gt; &quot;factor o=
f about 83% (1 - 50%*<b>(50% - 33%)/50%</b>).&quot; (I made a mistake that =
happened to come out to an almost identical result coincidentally).=C2=A0</=
div><div>* &quot;And pools could simply require full custody of the coins.&=
quot; -&gt; &quot;<b>But </b>pools could...&quot;</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, May 23, 2021=
 at 9:10 AM Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com">bill=
y.tetrud@gmail.com</a>&gt; 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"><div>@Lloyd</div><div><br></div>&gt;=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" target=3D"_blank">my own critique about that</a>=C2=A0as well. And y=
our point, that other forms of PoS devolve to DPoS by virtue of people want=
ing to actively mint blocks without exposing their coins in hot wallets, is=
 an interesting one.=C2=A0</div><div><br></div><div>&gt; how are the users =
meant to redelegate their stake to honest pools?<br></div><div><br></div><d=
iv>This could be mitigated partially if delegation=C2=A0didn&#39;t require =
any kind of blockchain transaction. For example, users could simply send a =
signed message saying &quot;this other key can mint blocks with my coins&qu=
ot;, and then minting a block using those coins would require presenting th=
e 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.</div><div><br></div><div>From what you =
mentioned, it sounds like maybe Algorand does something similar to this.=C2=
=A0</div><div><br></div><div>&gt; I don&#39;t see a way to get around the c=
onflicting requirement that the keys for large amounts of coins should be k=
ept offline but those are exactly the coins we need online to make the sche=
me secure.</div><div><br></div><div>There are a couple solutions you didn&#=
39;t mention. One is your &quot;traditional&quot; locked-stake kind of syst=
ems, where participants are required to lock their stake for long periods o=
f time. Since normal users aren&#39;t likely to want to do this, it will li=
kely be left to more sophisticated stakers likely staking very large amount=
s.=C2=A0</div><div><br></div><div>Both mechanisms you mentioned allow deleg=
ation, and it might seem like maybe there&#39;d be a way to disallow delega=
tion, however since users can always give custody of their coins to trusted=
 pools, that would be a delgation mechanism of last resort that can&#39;t b=
e removed. So you can do things that make it hard (for both users and pool =
operators) to delegate trustlessly, but you can&#39;t get rid of the abilit=
y to delgate entirely.</div><div><br></div><div>In general, the situations =
where I see people not pooling are:</div><div><br></div><div>A. They are en=
tirely prevented by technical means. It seems reasonably clear that this is=
 impossible.</div><div>B. The downsides are more than unsophisticated users=
 are willing to incur (eg stake locking).</div><div>C. The rewards are so s=
mall that it isn&#39;t worth it for people to put in much effort to gain th=
em.</div><div>D. The 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 t=
hat regard. D is a bit border line. With 1 billion people attempting to par=
ticipate and 10 minute blocks, 232 people would need to share the block rew=
ard in order to expect a payout on average once per month. With 8 billion p=
eople that would turn into more like 1700 people. This seems potentially do=
able (eg via cosigner requirements on minted blocks), but it is a lot of pa=
rticipants per block.=C2=A0</div><div><br></div><div>I think options C and =
D combined would be an ideal approach here. Because minting uses very few r=
eal resources, minting could be pretty much have arbitrarily low ongoing co=
sts. This means fees can be low and blocks can have low payouts. If the rew=
ard was low and people could expect to see it once every couple years, peop=
le could simply treat it like a lottery. Great if they win it now, but noth=
ing that anyone needs to rely on (which would incentivize the pools to redu=
ce variance that we want to avoid). If there is no locked stake or other ma=
jor barriers in place to minting blocks, that would also help avoid the com=
pultion to use a pool.</div><div><br></div><div>In any case, you bring up g=
ood points, and they certainly complicate the issue. By the way, if you wer=
e confused as to what VPoS was in the section from my above link, <a href=
=3D"https://github.com/fresheneesz/ValidatedProofOfStake" target=3D"_blank"=
>this might satisfy your curiosity</a>.</div><div><br></div><div>Cheers</di=
v><div><br></div><div><br></div><div><br></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, May 22, 2021 at 5:41=
 PM Lloyd Fournier &lt;<a href=3D"mailto:lloyd.fourn@gmail.com" target=3D"_=
blank">lloyd.fourn@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi Billy,</div><br>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>Although =
I don&#39;t agree with all your points you have done a decent job here so I=
&#39;ll focus on the second part: why I think Proof-of-Stake is inappropria=
te for a Bitcoin-like system.<br><br>Proof of stake is not fit for purpose =
for a global settlement layer in a pure digital asset (i.e. &quot;digital g=
old&quot;) which is what Bitcoin is trying to be.<br>PoS necessarily gives =
responsibilities to the holders of coins that they do not want and cannot h=
andle.<br>In Bitcoin, large unsophisticated coin holders can put their coin=
s in cold storage without a second thought given to the health of the under=
lying ledger.<br>As much as hardcore Bitcoiners try to convince them to run=
 their own node, most don&#39;t, and that&#39;s perfectly acceptable.<br>At=
 no point do their personal decisions affect the underlying consensus -- it=
 only affects their personal security assurance (not that of the system its=
elf).<br>In PoS systems this clean separation of responsibilities does not =
exist.<br><div><br></div><div>I think that the more rigorously studied PoS =
protocols will work fine within the security claims made in their papers.</=
div><div>People who believe that these protocols are destined for catastrop=
hic consensus failure are certainly in for a surprise.</div><div>But the de=
vil is in the detail.<br></div>Let&#39;s look at what the implications of u=
sing the leading proof of stake protocols would have on Bitcoin:<br><br>###=
 Proof of SquareSpace (Cardano, Polkdadot)<br><br>Cardano is a UTXO based P=
oS coin based on Ouroboros Praos[3] with an inbuilt on-chain delegation sys=
tem[5].<br>In these protocols, coin holders who do not want to run their no=
de with their hot keys in it delegate it to a &quot;Stake Pool&quot;.<br>I =
call the resulting system Proof-of-SquareSpace since most will choose a poo=
l by looking around for one with a nice website and offering the largest sh=
are of the block reward.<br>On the surface this might sound no different th=
an someone with an mining rig shopping around for a good mining pool but th=
ere are crucial differences:<br><br>1. The person making the decision is fo=
rced into it just because they own the currency -- someone with a mining ri=
g has purchased it with the intent to make profit by participating in conse=
nsus.<br><br>2. When you join a mining pool your systems are very much stil=
l 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 create a=
 block without seeing it first*.<br><br>3. If by SquareSpace sybil attack y=
ou gain a dishonest majority and start censoring transactions how are the u=
sers meant to redelegate their stake to honest pools?<br>I guess they can j=
ust send a transaction delegating to another pool...oh wait I guess that mi=
ght be censored too! This seems really really bad.<br>In Bitcoin, miners ca=
n just join a different pool at a whim. There is nothing the attacker can d=
o to stop them. A temporary dishonest majority heals relatively well.<br><b=
r>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>Being able =
to associate every UTXO to an account ruins one of the main privacy advanta=
ges of the UTXO model.<br>It also grows the size of the blockchain signific=
antly.<br><br>### &quot;Pure&quot; proof of stake (Algorand)<br><br>Algoran=
d&#39;s[4] approach is to only allow online stake to participate in the pro=
tocol.<br>Theoretically, This means that keys holding funds have to be onli=
ne in order for them to author blocks when they are chosen.<br>Of course in=
 reality no one wants to keep their coin holding keys online so in Alogoran=
d you can authorize a set of &quot;participation keys&quot;[1] that will be=
 used to create blocks on your coin holding key&#39;s behalf.<br>Hopefully =
you&#39;ve spotted the problem.<br>You can send your participation keys to =
any malicious party with a nice website (see random example [2]) offering y=
ou a good return.<br>Damn it&#39;s still Proof-of-SquareSpace!<br>The minor=
 advantage is that at least the participation keys expire after a certain a=
mount of time so eventually the SquareSpace attacker will lose their hold o=
n consensus.<br>Importantly there is also less junk on the blockchain becau=
se the participation keys are delegated off-chain and so are not making as =
much of a mess.<br><br>### Conclusion<br><br>I don&#39;t see a way to get a=
round 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 ma=
ke the scheme secure.<br><div>If we allow delegation then we open up a new =
social attack surface and it degenerates to Proof-of-SquareSpace.</div><div=
><br></div>For a &quot;digital gold&quot; like system like Bitcoin we optim=
ize for simplicity and desperately want to avoid extraneous responsibilitie=
s for the holder of the coin.<br>After all, gold is an inert element on the=
 periodic table that doesn&#39;t confer responsibilities on the holder to m=
aintain the quality of all the other bars of gold out there.<br>Bitcoin fee=
ls like this too and in many ways is more inert and beautifully boring than=
 gold.<br><div>For Bitcoin to succeed I think we need to keep it that way a=
nd 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 being able to say it u=
ses less electricity. It goes without saying that making bad technical deci=
sions to appease the current political climate is an anathema to Bitcoin.<b=
r></div><div><br></div><div>Would be interested to know if you or others th=
ink differently on these points.<br></div><br>[1]: <a href=3D"https://devel=
oper.algorand.org/docs/run-a-node/participate/generate_keys/" target=3D"_bl=
ank">https://developer.algorand.org/docs/run-a-node/participate/generate_ke=
ys/</a><br>[2]: <a href=3D"https://staking.staked.us/algorand-staking" targ=
et=3D"_blank">https://staking.staked.us/algorand-staking</a><br>[3]: <a hre=
f=3D"https://eprint.iacr.org/2017/573.pdf" target=3D"_blank">https://eprint=
.iacr.org/2017/573.pdf</a><br>[4]: <a href=3D"https://algorandcom.cdn.prism=
ic.io/algorandcom%2Fece77f38-75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf" t=
arget=3D"_blank">https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-=
75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf</a><br><div>[5]: <a href=3D"htt=
ps://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf" targ=
et=3D"_blank">https://hydra.iohk.io/build/790053/download/1/delegation_desi=
gn_spec.pdf</a></div><div><br></div><div>Cheers,<br></div><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 &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; 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"><div>I think there is a lot of misinform=
ation and bias against Proof of Stake. Yes there have been lots of shady co=
ins that use insecure PoS mechanisms. Yes there have been massive issues wi=
th 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 &quot;proved to be impossible&quot; and &quot;have not=
 achieved recognized success yet&quot;. Most of the arguments levied agains=
t PoS are out of date or rely on unproven assumptions or extrapolation from=
 the analysis of a particular PoS system. I certainly don&#39;t think we sh=
ould 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 coul=
d build that has substantially 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 cri=
tical 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 h=
ow that does (or doesn&#39;t) affect the security model.=C2=A0</div><div><b=
r></div>@Eric Your proof of stake fallacy seems to be saying that PoS is wo=
rse when a 51% attack happens. While I agree, I think that line of thinking=
 omits important facts:<br>* The capital=C2=A0required to 51% attack a PoS =
chain can be made substantially greater than on a PoS chain.=C2=A0<div>* Th=
e capital the attacker stands to lose can be substantially greater as well =
if the attack is successful.<br><div>* The effectiveness of paying miners t=
o raise the honest fraction of miners above 50% may be quite bad.</div><div=
>* Allowing a 51% attack is already unacceptable. It should be considered w=
hether what happens in the case of a 51% may not be significantly different=
. The currency would likely be critically damaged in a 51% attack regardles=
s of consensus mechanism.</div><div><br></div><div>&gt;=C2=A0<span style=3D=
"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Proof-of-stake te=
nds towards oligopolistic control</span></div><div><span style=3D"color:rgb=
(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><span=
 style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">People r=
epeat this often, but the facts support this. There is no centralization pr=
essure in any proof of stake mechanism that I&#39;m aware of. IE if you hav=
e 10 times as much coin that you use to mint blocks, you should expect to e=
arn 10x as much minting revenue - not more than 10x. By contrast, proof of =
work does in fact have clear centralization pressure - this is not disputed=
. Our goal in relation to that is to ensure that the centralization pressur=
e 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 tenden=
cy towards oligopolistic control is worse for PoW.</span></div><div><span s=
tyle=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span=
></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,san=
s-serif">&gt;=C2=A0</span>Energy usage, in-and-of-itself, is nothing to be =
ashamed of!!</div><div><br></div><div>I certainly agree. Bitcoin&#39;s=C2=
=A0energy usage at the moment is I think quite warranted. However, the ques=
tion is: can we do substantially better. I think if we can, we probably sho=
uld... eventually.</div><div><div><br></div><div>&gt; Proof of Stake is onl=
y resilient to=C2=A0=E2=85=93 of the network demonstrating a Byzantine Faul=
t, 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"_blank">pos.pdf</a>=C2=
=A0you linked to. I&#39;m not aware of any proof that <b>all </b>PoS system=
s 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 sh=
ould exceed that up to nearly 50% as far as I&#39;m aware. Proof of work is=
 not in fact resilient up to the 1/2 threshold in the way you would think. =
IE, if 100% of miners are currently honest and have a collective 100 exahas=
hes/s hashpower, an attacker does not need to obtain 100 exahashes/s, but a=
ctually only needs to accumulate 50 exahashes/s. This is because as the att=
acker accumulates hashpower, it drives honest miners out of the market as t=
he difficulty increases to beyond what is economically sustainable. Also, i=
ts been shown that the best proof of work can do is require an attacker to =
obtain 33% of the hashpower because of the <a href=3D"https://github.com/fr=
esheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-at=
tack" target=3D"_blank">selfish mining attack</a>=C2=A0discussed in depth i=
n this paper: <a href=3D"https://arxiv.org/abs/1311.0243" target=3D"_blank"=
>https://arxiv.org/abs/1311.0243</a>. Together, both of these things reduce=
 PoW&#39;s security by a factor of about 83% (1 - 50%*33%).</div><div><br><=
/div><div>=C2=A0&gt; Proof of Stake requires other trade-offs which are inc=
ompatible with Bitcoin&#39;s objective (to be a trustless digital cash) =E2=
=80=94 specifically the famous &quot;security vs. liveness&quot; 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 digital cash?=C2=A0</d=
iv><div><br></div><div>&gt; You cannot gain tokens without someone choosing=
 to give up those coins - a form of permission.</div><div><br></div><div>Th=
is is not a practical constraint. Just like in mining, some nodes may rejec=
t 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 do=
n&#39;t think requiring the &quot;permission&quot; of one of millions of pe=
ople in the market can be reasonably considered a &quot;permissioned curren=
cy&quot;.=C2=A0=C2=A0</div><div><br></div></div><div>&gt; 2. Proof of stake=
 must have a trusted means of timestamping to regulate overproduction of bl=
ocks</div><div><br></div><div>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.=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 Dubrovsky via bitcoin-=
dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote 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">Ah sorry, I d=
idn&#39;t realize this was, in fact, a different thread! :)</div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 19, =
2021 at 10:07 AM Michael Dubrovsky &lt;<a href=3D"mailto:mike@powx.org" tar=
get=3D"_blank">mike@powx.org</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_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 d=
iscussion to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are intere=
sting but I guess there are other threads going on these topics already whe=
re they would be relevant.=C2=A0<div><br></div><div>Also, it&#39;s importan=
t=C2=A0to distinguish between oPoW and these other &quot;alternatives&quot;=
 to Hashcash. oPoW is a true Proof of Work that doesn&#39;t alter the core =
game theory or security assumptions of Hashcash and actually contains SHA (=
can be SHA3, SHA256, etc hash is interchangeable).</div><div><br></div><div=
>Cheers,</div><div>Mike=C2=A0</div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, May 18, 2021 at 4:55 PM Erik Aro=
nesty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<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 s=
uggested vdf&#39;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 &quot;work&quot; 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&#39;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 &quot;burned coin + vdf system&quot=
;<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 &quot;alt=
<br>
coin&quot;<br>
<br>
On Tue, May 18, 2021 at 10:02 AM Zac Greenwood &lt;<a href=3D"mailto:zachgr=
w@gmail.com" target=3D"_blank">zachgrw@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi ZmnSCPxj,<br>
&gt;<br>
&gt; 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>
&gt;<br>
&gt; Zac<br>
&gt;<br>
&gt;<br>
&gt; On Tue, 18 May 2021 at 12:42, ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@=
protonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br=
>
&gt;&gt;<br>
&gt;&gt; Good morning Zac,<br>
&gt;&gt;<br>
&gt;&gt; &gt; VDFs might enable more constant block times, for instance by =
having a two-step PoW:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 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>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; 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>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; As a result, variation in block times will be greatly reduced=
.<br>
&gt;&gt;<br>
&gt;&gt; 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>
&gt;&gt;<br>
&gt;&gt; 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>
&gt;&gt; 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>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt; 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>
</blockquote></div>

--00000000000017943c05c3044edf--