path: root/86/181c0d33ba452a77a5e48a951521d0ac5132bb

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4DADBC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 20:06:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1D6A8608E7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 20:06:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8KKwwN6Bafof
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 20:06:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com
 [IPv6:2607:f8b0:4864:20::52f])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 4BDCA606B9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 20:06:30 +0000 (UTC)
Received: by mail-pg1-x52f.google.com with SMTP id l70so3370433pga.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 13:06:30 -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=V3te8wo1CKycNpzBXk0SbIsAf+f+PO0TAzs1kkJ4+Yg=;
 b=QsQv7B21Wnwz0d91UkW3+nUcP7jaxgI8k2tEqhSVcyWs0pemJJGIp5jZOktKyCZftB
 ksh5N06r1rmCnk9KQ2wnIKjNb5Itx10V0g6duNJFWVHO4vtqp4SogEzy8MtmKAQgvdzB
 NtqC6FyPXCzD4zA1oSxVIxhY/J4paJQR4PHxIdZQnwnVJEs6oiRWxylzrxkCQ29XveDR
 Qz2TXKEojk06wKyKdA9tVvX8JvpBrAl8PshjxZhoT9Rh/MRK3uA1Vj97cpsqOVkVeJZt
 E3V4qQvuCBSPh5PhA1Hzmv4+nNbofrF+ibNZm8GnC10Mdg3VsnSGVuz2LJboHkKPQZUz
 MVVA==
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=V3te8wo1CKycNpzBXk0SbIsAf+f+PO0TAzs1kkJ4+Yg=;
 b=b1DvBg4FXOOWwyA2avhqYv8baIMfT3rNvU9KGezC1iGSzKDzbfhfuTxJA+psqj4fyZ
 GT5Ij5ozjSoxtbjODx+UxLUvj4POjYX2cqc+6ZBywItHF5wn0ZoiWaSSkr0Mi9dDFnGU
 ZrP0iGKER3upU+T/2HK0Yr4AzeUYXlcp5YKb4caphAuzJyKSlwxmZe0nzZ2l84RFlQz4
 q5yltQil9qIggafBixOoV+uU+sqzUdaL5M7Lqe2XANgt+Lo4USAU2eNTzh28t49avSxv
 twawajsdqWw6E0JrKho+8/BbOR3M/bNO8IbNHF+8OD3fdoomGTOrhw0yvcWTw82Zz7+R
 Z46A==
X-Gm-Message-State: AOAM533RhfOZRIwnmWF0Cnvl9JStuTswWiw26LbzAQgP/jmW+pAmgImp
 6aq+JVhaPRhAQAeiOvTxyUGo5momfx0RIQxZKvAJWiY=
X-Google-Smtp-Source: ABdhPJw/PyCbTqeZM2DIAl+CT+3M38lDilsNZopM8xDKm+FGbV65pWyf1eT8Iz9XV1rjHqXtLEF5EA4912BFsoPx7lw=
X-Received: by 2002:a63:9350:: with SMTP id w16mr10755647pgm.53.1622232388512; 
 Fri, 28 May 2021 13:06:28 -0700 (PDT)
MIME-Version: 1.0
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com>
 <CAJowKgJYUkxJ4htPvCLtARRr0Db13+BKzWtG40DEv6uEOh5yXw@mail.gmail.com>
 <CAGpPWDY4KgNVEoMDAJkWReX4zUUjDuB5SwB0Ap6OU98fuK4DxA@mail.gmail.com>
 <CAJowKgJWZ++6NkbYk15NBtA7x37of0n3_qF1UjCbV0Ui7XG8zA@mail.gmail.com>
 <CAGpPWDZs5Y10Fjbt8OPx3jEqjgNdQLODNdTW4iRyXTrpuNGFQQ@mail.gmail.com>
 <3TVoontwJmoMv0tp1S5MU_U8icxcQZfajtbNEXqOjuvO7GpfUQdh9pEGSIbLEYJndrDa_dJQqa0sSwY-BmuCmyHMRWqa9lEaUjZJSP5Vbyw=@protonmail.com>
 <CAGpPWDbqZLzMog4s9SPVm5xstbJbsHwND6x3qWHR-dh6naCnNQ@mail.gmail.com>
 <L1IhpSfDNx5OPXYnHfcFDiOzJa8jihbR8YE4MBRaYjuQt2GQsrNd0UnJaJg_mCgHNOcG6QE1Wrwp6zZ-YxOgDNu_aBE67HJkbemHz5Nz9c4=@protonmail.com>
 <CAJowKgKgGynQ9NYe_7xEai0tcBW4b=tQnNpv9vndx1hLCowfWg@mail.gmail.com>
 <J3_n3ygIuQf54KXVl8jlbyahX5WJIzffVeDD3yt0RkRbPRyD56OPj3DT05wGJoEfI6XfLOq2DiaN-vdnXSdi7Q23NWrZ-Tg9jzM9jtx8-hg=@protonmail.com>
In-Reply-To: <J3_n3ygIuQf54KXVl8jlbyahX5WJIzffVeDD3yt0RkRbPRyD56OPj3DT05wGJoEfI6XfLOq2DiaN-vdnXSdi7Q23NWrZ-Tg9jzM9jtx8-hg=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 28 May 2021 16:06:16 -0400
Message-ID: <CAJowKgJTEHLeHpKUOavAY9hHZ_3hChkJnMX13K-pSUhch7JwdQ@mail.gmail.com>
To: befreeandopen <befreeandopen@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 28 May 2021 20:07:34 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 SatoshiSingh <SatoshiSingh@protonmail.com>,
 Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 20:06:33 -0000

best writeup i know of is here:

https://en.bitcoin.it/wiki/Proof_of_burn

no formal proposals or proofs that i know of.

On Fri, May 28, 2021 at 10:40 AM befreeandopen
<befreeandopen@protonmail.com> wrote:
>
> Erik, I am sorry, I have little knowledge about proof-of-burn, I never fo=
und it interesting up until now. Some of your recent claims seem quite stro=
ng to me and I'd like to read more.
>
> Forgive me if this has been mentioned recently, but is there a full speci=
fication of the concept you are referring to? I don't mean just the basic i=
dea description (that much is clear to me), I mean a fully detailed proposa=
l or technical documentation that would give me a precise information about=
 what exactly it is that you are talking about.
>
>
> Sent with ProtonMail Secure Email.
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Wednesday, May 26, 2021 11:07 PM, Erik Aronesty <erik@q32.com> wrote:
>
> > note: the "nothing at stake" problem you propose is not broken for
> > proof-of-burn, because the attacker
> >
> > a) has no idea which past transactions are burns
> > b) has no way to use his mining power, even 5%, to maliciously improve
> > his odds of being selected
> >
> > On Wed, May 26, 2021 at 9:12 AM befreeandopen
> > befreeandopen@protonmail.com wrote:
> >
> > > @befreeandopen I guess I misunderstood your selfish minting attack. L=
et me make sure I understand it. You're saying it would go as follows?:
> > >
> > > 1.  The malicious actor comes across an opportunity to mint the next =
3 blocks. But they hold off and don't release their blocks just yet.
> > > 2.  They receive a new block minted by someone else.
> > > 3.  The malicious actor then chooses to release their other 2 blocks =
on on the second from the top block if it gives them more blocks in the fut=
ure than minting on the top block. And instead lets the top block proceed i=
f it gives them more blocks in the future (also figuring in the 3 blocks th=
ey're missing out on minting).
> > > 4.  Profit!
> > >
> > > The problem with this attack is that any self respecting PoS system w=
ouldn't have the information available for minters to know how blocks will =
affect their future prospects of minting. Otherwise this would introduce th=
e problem of stake grinding. This can be done using collaborative randomnes=
s (where numbers from many parties are combined to create a random number t=
hat no individual party could predict). In fact, that's what the Casper pro=
tocol does to decide quorums. In a non quorum case, you can do something li=
ke record a hash of a number in the block header, and then have a second st=
ep to release that number later. Rewards can be given can be used to ensure=
 minters act honestly here by minting messages that release these numbers a=
nd not releasing their secret numbers too early.
> > > Yes, you misunderstood it. First, let me say that the above thoughts =
of yours are incorrect, at least for non-quorum case. Since the transition =
in the blockchain system from S1 to S2 is only by adding new block, and sin=
ce stakers always need to be able to decide whether or not they can add the=
 next block, it follows that if a staker creates a new block locally, she c=
an decide whether the new state allows her to add another block on top. As =
you mentioned, this COULD introduce problem of staking, that you are incorr=
ect in that it is a necessity. Usual prevention of the grinding problem in =
this case is that an "old enough" source of randomness applies for the curr=
ent block production process. Of course this, as it is typical for PoS, int=
roduces other problems, but let's discard those.
> > > I will try to explain in detail what you misunderstood before. You st=
art with a chain ending with blocks A-B-C, C being the top, the common feat=
ure of PoS system (non-quorum), roughly speaking, is that if N is the total=
 amount of coins that participate in the staking process to create a new bl=
ock on top of C (let's call that D), then a participant having K*N amount o=
f stake has chance K to be the one who will create the next stake. In other=
 words, the power of stakers is supposed to be linear in the system - you o=
wn 10 coins gives you 10x the chance of finding block over someone who has =
1 coin.
> > > What i was claiming is that using the technique I have described, thi=
s linearity is violated. Why? Well, it works for honest stakers among the c=
ompetition of honest stakers - they really do have the chance of K to find =
the next block. However, the attacker, using nothing at stake, checks her a=
bility to build block D (at some timestamp). If she is successful, she does=
 not propagate D immediately, but instead she also checks whether she can b=
uild on top of B and on top of A. Since with every new timestamp, usually, =
there is a new chance to build the block, it is not uncommon that she finds=
 she is indeed able to build such block C' on top of B. Here it is likely t=
(C') > t(C) as the attacker has relatively low stake. Note that in order to=
 produce such C', she not only could have tried the current timestamp t(D),=
 but also all previous timestamps up to t(B) (usually that's the consensus =
rule, but it may depend on a specific consensus). So her chance to produce =
such C' is greater than her previous chance of producing C (which chance wa=
s limited by other stakers in the system and the discovery of block C by on=
e of them). Now suppose that she found such C' and now she continues by try=
ing to prolong this chain by finding D'. And again here, it is quite likely=
 that her chance to find such D' is greater than was her chance of finding =
D because again there are likely multiple timestamps she could try. This al=
l was possible just because nothing at stake allows you to just try if you =
can produce a block in certain state of block chain or not. Now if she actu=
ally was able to find D', she discards D and only publishes chain A-B-C'-D'=
, which can not be punished despite the fact that she indeed produced two d=
ifferent forks. She can not be punished because this production was local a=
nd only the final result of A-B-C'-D' was published, in which case she gain=
ed an extra block over the honest strategy which would only give her block =
D.
> > > Fun fact tho: there is an attack called the "selfish mining attack" f=
or proof of work, and it reduces the security of PoW by at least 1/3rd.
> > > How is that relevant to our discussion? This is known research that h=
as nothing to do with PoS except that it is often worse on PoS.
> > >
> > > > the problem is not as hard as you think
> > >
> > > I don't claim to know just how hard finding the IP address associated=
 with a bitcoin address is. However, the DOS risk can be solved more comple=
tely by only allowing the owner of coins themselves to know whether they ca=
n mint a block. Eg by determining whether someone can mint a block based on=
 their public key hidden behind hashes (as normal in addresses). Only when =
someone does in fact mint a block do they reveal their hidden public key in=
 order to prove they are allowed to mint the block.
> > > This is true, but you are mixing quorum and non-quorum systems. My ob=
jection here was towards such system where I specifically said that the lis=
t of producers for next epoch is known up front and you confirmed that this=
 is what you meant with "quorum" system. So in such system, I claimed, the =
known producer is the only target at any given point of time. This of cours=
e does not apply to any other type of system where future producers are not=
 known. No need to dispute, again, something that was not claimed.
> > >
> > > > I agree that introduction of punishment itself does not imply intro=
ducing a problem elsewhere (which I did not claim if you reread my previous=
 message)
> > >
> > > I'm glad we agree there. Perhaps I misunderstood what you meant by "y=
ou should not omit to mention that by doing so, typically, you have introdu=
ced another problem elsewhere."
> > > Perhaps you should quote the full sentence and not just a part of it:
> > > "Of course you can always change the rules in a way that a certain sp=
ecific attack is not doable, but you should not omit to mention that by doi=
ng so, typically, you have introduced another problem elsewhere, or you hav=
e not solved it completely."
> > > You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT CO=
MPLETELY)
> > > In case of the punishment it was meant to be the not solve it complet=
ely part.
> > > Also "typically" does not imply always.
> > > But this parsing of English sentences for you seems very off topic he=
re. My point is, in context of Bitcoin, reject such unsupported claims that=
 PoS is a reasonable alternative to PoW, let's stick to that.
> > >
> > > > As long as the staker makes sure (which is not that hard) that she =
does not miss a chance to create a block, her significance in the system wi=
ll always increase in time. It will increase relative to all normal users w=
ho do not stake
> > >
> > > Well, if you're in the closed system of the cryptocurrency, sure. But=
 we don't live in that closed system. Minters will earn some ROI from minti=
ng just like any other financial activity. Others may find more success spe=
nding their time doing things other than figuring out how to mint coins. In=
 that case, they'll be able to earn more coin that they could later decide =
to use to mint blocks if they decide to.
> > > This only supports the point I was making. Since the optimal scenario=
 with all existing coins participating is just theoretical, the attacker's =
position will ever so improve. It seems we are in agreement here, great.
> > >
> > > > Just because of the above we must reject PoS as being critically in=
secure
> > >
> > > I think the only thing we can conclude from this is that you have com=
e up with an insecure proof of stake protocol. I don't see how anything you=
've brought up amounts to substantial evidence that all possible PoS protoc=
ols are insecure.
> > > I have not come up with anything. I'm afraid you've not realized the =
burden of proof is on your side if you vouch for a design that is not belie=
ved and trusted to be secure. It is up to you to show that you know how to =
solve every problem that people throw at you. So far we have just demonstra=
ted that your claim that nothing at stake is solved was unjustified. You ha=
ve not described a system that would solve it (and not introduce critical D=
DOS attack vector as it is in quorum based systems - per the prior definiti=
on of such systems).
> > > Of course the list of problems of PoS systems do not end with just no=
thing at stake, but it is good enough example that by itself prevents its a=
doption in decentralized consensus. No need to go to other hard problems wi=
thout solving nothing at stake.
> > > On Tue, May 25, 2021 at 11:10 AM befreeandopen befreeandopen@protonma=
il.com wrote:
> > >
> > > > @befreeandopen " An attacker can calculate whether or not she can p=
rolong this chain or not and if so with what timestamp."
> > > > The scenario you describe would only be likely to happen at all if =
the malicious actor has a very large fraction of the stake - probably quite=
 close to 50%. At that point, you're talking about a 51% attack, not the no=
thing at stake problem. The nothing at stake problem is the problem where a=
nyone will mint on any chain. Its clear that if there's a substantial punis=
hment for minting on chains other than the one that eventually wins, every =
minter without a significant fraction of the stake will be honest and not a=
ttempt to mint on old blocks or support someone else's attempt to mint on o=
ld blocks (until and if it becomes the heaviest chain). Because the attacke=
r would need probably >45% of the active stake (take a look at the reasonin=
g here for a deeper analysis of that statement), I don't agree that punishm=
ent is not a sufficient mitigation of the nothing at stake problem. To expl=
oit the nothing at stake problem, you basically need to 51% attack, at whic=
h point you've exceeded the operating conditions of the system, so of cours=
e its gonna have problems, just like a 51% attack would cause with PoW.
> > > > This is not at all the case. The attacker benefits using the descri=
bed technique at any size of the stake and significantly so with just 5% of=
 the stake. By significantly, I do not mean that the attacker is able to co=
mpletely take control the network (in short term), but rather that the atta=
cker has significant advantage in the number of blocks she creates compared=
 to what she "should be able to create". This means the attacker's stake in=
creases significantly faster than of the honest nodes, which in long term i=
s very serious in PoS system. If you believe close to 50% is needed for tha=
t, you need to redo your math. So no, you are wrong stating that "to exploi=
t nothing at stake problem you basically need to 51% attack". It is rather =
the opposite - eventually, nothing at stake attack leads to ability to perf=
orm 51% attack.
> > > >
> > > > > I am not sure if this is what you call quorum-based PoS
> > > >
> > > > Yes, pre-selected minters is exactly what I mean by that.
> > > >
> > > > > it allows the attacker to know who to attack at which point with =
powerful DDOS in order to hurt liveness of such system
> > > >
> > > > Just like in bitcoin, associating keys with IP addresses isn't gene=
rally an easy thing to do on the fly like that. If you know someone's IP ad=
dress, you can target them. But if you only know their address or public ke=
y, the reverse isn't as easy. With a quorum-based PoS system, you can see t=
heir public key and address, but finding out their IP to DOS would be a hug=
e challenge I think.
> > > > I do not dispute that the problem is not trivial, but the problem i=
s not as hard as you think. The network graph analysis is a known technique=
 and it is not trivial, but not very hard either. Introducing a large numbe=
r of nodes to the system to achieve very good success rate of analysis of a=
rea of origin of blocks is doable and has been done in past. So again, I ve=
ry much disagree with your conclusion that this is somehow secure. It is ab=
solutely insecure.
> > > > Note, tho, that quorum-based PoS generally also have punishments as=
 part of the protocol. The introduction of punishments do indeed handily so=
lve the nothing at stake problem. And you didn't mention a single problem t=
hat the punishments introduce that weren't already there before punishments=
. There are tradeoffs with introducing punishments (eg in some cases you mi=
ght punish honest actors), but they are minor in comparison to solving the =
nothing at stake problem.
> > > > While I agree that introduction of punishment itself does not imply=
 introducing a problem elsewhere (which I did not claim if you reread my pr=
evious message), it does introduce additional complexity which may introduc=
e problem, but more importantly, while it slightly improves resistance agai=
nst the nothing at stake attack, it solves absolutely nothing. Your claim i=
s based on wrong claim of needed close to 50% stake, but that could not be =
farther from the truth. It is not true even in optimal conditions when all =
participants of the network stake or delegate their stake. These optimal co=
nditions rarely, if ever, occur. And that's another thing that we have not =
mention in our debate, so please allow me to introduce another problem to P=
oS.
> > > > Consider what is needed for such optimal conditions to occur - all =
coins are always part of the stake, which means that they need to somehow a=
utomatically part of the staking process even when they are moved. But in m=
any PoS systems you usually require some age (in terms of confirmations) of=
 the coin before you allow it to be used for participation in staking proce=
ss and that is for a good reason - to prevent various grinding attacks. In =
some systems the coin must be specifically registered before it can be stak=
ed, in others, simply waiting for enough confirmations enables you to stake=
 with the coin. I am not sure if there is a system which does not have this=
 cooling period for a coin that has been moved. Maybe it is possible though=
, but AFAIK it is not common and not battle tested feature.
> > > > Then if we admit that achieving the optimal condition is rather the=
oretical. Then if we do not have the optimal condition, it means that a sta=
ker with K% of the total available supply increases it's percentage over ti=
me to some amounts >K%. As long as the staker makes sure (which is not that=
 hard) that she does not miss a chance to create a block, her significance =
in the system will always increase in time. It will increase relative to al=
l normal users who do not stake (if there are any) and relative to all othe=
r stakers who make mistakes or who are not wealthy enough to afford not sel=
ling any position ever. But powerful attacker is exactly in such position a=
nd thus she will gain significance in such a system. The technique I have d=
escribed, and that you mistakenly think is viable only with huge amounts of=
 stake, only puts the attacker to even greater advantage. But even without =
the described attack (which exploits nothing at stake), the PoS system conv=
erges to a system more and more controlled by powerful entity, which we can=
 assume is the attacker.
> > > > So I don't think it is at all misleading to claim that "nothing at =
stake" is a solved problem. I do in fact mean that the solutions to that pr=
oblem don't introduce any other problems with anywhere near the same level =
of significance.
> > > > It still stands as truly misleading claim. I disagree that introduc=
ing DDOS opportunity with medium level of difficulty for the attacker to im=
plement it, in case of "quorum-based PoS" is not a problem anywhere near th=
e same level of significance. Such an attack vector allows you to turn off =
the network if you spend some time and money. That is hardly acceptable.
> > > > Just because of the above we must reject PoS as being critically in=
secure until someone invents and demonstrates an actual way of solving thes=
e issues.
> > > > On Tue, May 25, 2021 at 3:00 AM Erik Aronesty erik@q32.com wrote:
> > > >
> > > > > > > you burn them to be used at a future particular block height
> > > > >
> > > > > > This sounds exploitable. It seems like an attacker could simply=
 focus all their burns on a particular set of 6 blocks to double spend, min=
imizing their cost of attack.
> > > > >
> > > > > could be right. the original idea was to have burns decay over ti=
me,
> > > > > 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 pro=
of 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.c=
om 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 sho=
rter, i can only choose one... deterministically
> > > > > >
> > > > > > What prevents you from attempting to mine block 553 on both cha=
ins?
> > > > > >
> > > > > > > miners have a very strong, long-term, investment in the stabi=
lity of the chain.
> > > > > >
> > > > > > Yes, but the same can be said of any coin, even ones that do ha=
ve the nothing at stake problem. This isn't sufficient tho because the chai=
n is a common good, and the tragedy of the commons holds for it.
> > > > > >
> > > > > > > you burn them to be used at a future particular block height
> > > > > >
> > > > > > This sounds exploitable. It seems like an attacker could simply=
 focus all their burns on a particular set of 6 blocks to double spend, min=
imizing their cost of attack.
> > > > > >
> > > > > > > i can imagine scenarios where large stakeholders can collude =
to punish smaller stakeholders simply to drive them out of business, for ex=
ample
> > > > > >
> > > > > > Are you talking about a 51% attack? This is possible in any dec=
entralized cryptocurrency.
> > > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik@q32.com wro=
te:
> > > > > >
> > > > > > > > > your burn investment is always "at stake", any redaction =
can result in a loss-of-burn, because burns can be tied, precisely, to bloc=
k-heights
> > > > > > > > > I'm fuzzy on how proof of burn works.
> > > > > > >
> > > > > > > when you burn coins, you burn them to be used at a future par=
ticular
> > > > > > > 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 lo=
nger
> > > > > > > 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 ha=
ve 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 a=
lways
> > > > > > > hurt miners the most.
> > > > > > > the "punishment" systems of PoS are "weird at best", certainl=
y
> > > > > > > unproven. i can imagine scenarios where large stakeholders ca=
n
> > > > > > > collude to punish smaller stakeholders simply to drive them o=
ut of
> > > > > > > business, for example. and then you have to put checks in pla=
ce 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 Mini=
ng
> > > > > > > Council). these consortiums, if state sanctioned, could becom=
e a
> > > > > > > source of censorship, for example. Since PoB doesn't require =
you to
> > > > > > > have a live, well-connected node, it's harder to censor & har=
der to
> > > > > > > trace.
> > > > > > > Eliminating this weakness seems to be in the best interests o=
f
> > > > > > > existing stakeholders
> > > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud billy.tetrud@gma=
il.com wrote:
> > > > > > >
> > > > > > > > > proof of burn clearly solves this, since nothing is held =
online
> > > > > > > >
> > > > > > > > Well.. the coins to be burned need to be online when they'r=
e burned. But yes, only a small fraction of the total coins need to be onli=
ne.
> > > > > > > >
> > > > > > > > > your burn investment is always "at stake", any redaction =
can result in a loss-of-burn, because burns can be tied, precisely, to bloc=
k-heights
> > > > > > > >
> > > > > > > > So you're saying that if say someone tries to mine a block =
on a shorter chain, that requires them to send a transaction burning their =
coins, and that transaction could also be spent on the longest chain, which=
 means their coins are burned even if the chain they tried to mine on doesn=
't win? I'm fuzzy on how proof of burn works.
> > > > > > > >
> > > > > > > > > proof of burn can be more secure than proof-of-stake
> > > > > > > >
> > > > > > > > FYI, proof of stake can be done without the "nothing at sta=
ke" problem. You can simply punish people who mint on shorter chains (by re=
warding people who publish proofs of this happening on the main chain). In =
quorum-based PoS, you can punish people in the quorum that propose or sign =
multiple blocks for the same height. The "nothing at stake" problem is a so=
lved problem at this point for PoS.
> > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik@q32.com =
wrote:
> > > > > > > >
> > > > > > > > > > I don't see a way to get around the conflicting 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.
> > > > > > > > >
> > > > > > > > > proof of burn clearly solves this, since nothing is held =
online
> > > > > > > > >
> > > > > > > > > > how does proof of burn solve the "nothing at stake" pro=
blem in your view?
> > > > > > > > >
> > > > > > > > > definition of nothing at stake: in the event of a fork, w=
hether the
> > > > > > > > > fork is accidental or a malicious, the optimal strategy f=
or any miner
> > > > > > > > > is to mine on every chain, so that the miner gets their r=
eward no
> > > > > > > > > matter which fork wins. indeed in proof-of-stake, the pro=
ofs are
> > > > > > > > > published on the very chains mines, so the incentive is m=
agnified.
> > > > > > > > > in proof-of-burn, your burn investment is always "at stak=
e", 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 a=
ll chains
> > > > > > > > > in this way proof of burn can be more secure than proof-o=
f-stake, and
> > > > > > > > > even more secure than proof of work
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoi=
n-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 a=
nd elsewhere.
> > > > > > > > > > Although I don't agree with all your points you have do=
ne 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 sett=
lement layer in a pure digital asset (i.e. "digital gold") which is what Bi=
tcoin is trying to be.
> > > > > > > > > > PoS necessarily gives responsibilities to the holders o=
f 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 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 unde=
rlying consensus -- it only affects their personal security assurance (not =
that of the system itself).
> > > > > > > > > > In PoS systems this clean separation of responsibilitie=
s 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 fo=
r 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 leadin=
g proof of stake protocols would have on Bitcoin:
> > > > > > > > > >
> > > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot)
> > > > > > > > > >
> > > > > > > > > > Cardano is a UTXO based PoS coin based on Ouroboros Pra=
os3 with an inbuilt on-chain delegation system5.
> > > > > > > > > > In these protocols, coin holders who do not want to run=
 their node with their hot keys in it delegate it to a "Stake Pool".
> > > > > > > > > > I call the resulting system Proof-of-SquareSpace since =
most will choose a pool by looking around for one with a nice website and o=
ffering the largest share of the block reward.
> > > > > > > > > > On the surface this might sound no different than someo=
ne 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 ju=
st because they 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 m=
uch still online. You are just partaking in a pool to reduce your profit va=
riance. You still see every block that you help create and you never help c=
reate 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 redel=
egate 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 r=
eally really bad.
> > > > > > > > > >     In Bitcoin, miners can just join a different pool a=
t a whim. There is nothing the attacker can do to stop them. A temporary di=
shonest majority heals relatively well.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > There is another severe disadvantage to this on-chain d=
elegation system: every UTXO must indicate which staking account this UTXO =
belongs to so the appropriate share of block rewards can be transferred the=
re.
> > > > > > > > > > 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's4 approach is to only allow online stake to p=
articipate 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 ho=
lding 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 behal=
f.
> > > > > > > > > > Hopefully you've spotted the problem.
> > > > > > > > > > You can send your participation keys to any malicious p=
arty 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 at=
tacker will lose their hold on consensus.
> > > > > > > > > > Importantly there is also less junk on the blockchain b=
ecause 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 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.
> > > > > > > > > > If we allow delegation then we open up a new social att=
ack surface and it degenerates to Proof-of-SquareSpace.
> > > > > > > > > > For a "digital gold" like system like Bitcoin we optimi=
ze 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 tab=
le that doesn't confer responsibilities on the holder to maintain the quali=
ty of all the other bars of gold out there.
> > > > > > > > > > Bitcoin feels like this too and in many ways is more in=
ert 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 rea=
l digital gold and whether these bad technical trade offs are worth being a=
ble to say it uses less electricity. It goes without saying that making bad=
 technical decisions to appease the current political climate is an anathem=
a to Bitcoin.
> > > > > > > > > > Would be interested to know if you or others think diff=
erently on these points.
> > > > > > > > > > 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 aga=
inst Proof of Stake. Yes there have been lots of shady coins that use insec=
ure 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 betwe=
en "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 unpro=
ven assumptions or extrapolation from the analysis of a particular PoS syst=
em. I certainly don't think we should experiment with bitcoin by switching =
to PoS, but from my research, it seems very likely that there is a proof of=
 stake consensus protocol we could build that has substantially higher secu=
rity (cost / capital required to execute an attack) while at the same time =
costing far less resources (which do translate to fees on the network) with=
out compromising any of the critical security properties bitcoin relies on.=
 I think the critical piece of this is the disagreements around hardcoded c=
heckpoints, which is a critical piece solving attacks that could be levied =
on a PoS chain, and how that does (or doesn't) affect 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 li=
ne of thinking omits important facts:
> > > > > > > > > > >
> > > > > > > > > > > -   The capital required to 51% attack a PoS chain ca=
n be made substantially greater than on a PoS chain.
> > > > > > > > > > > -   The capital the attacker stands to lose can be su=
bstantially greater as well if the attack is successful.
> > > > > > > > > > > -   The effectiveness of paying miners to raise the h=
onest 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% attack regardless of consensus mechanism.
> > > > > > > > > > >
> > > > > > > > > > > > Proof-of-stake tends towards oligopolistic control
> > > > > > > > > > >
> > > > > > > > > > > People repeat this often, but the facts support this.=
 There is no centralization pressure in any proof of stake mechanism that I=
'm aware of. IE if you have 10 times as much coin that you use to mint bloc=
ks, you should expect to earn 10x as much minting revenue - not more than 1=
0x. By contrast, proof of work does in fact have clear centralization press=
ure - this is not disputed. Our goal in relation to that is to ensure that =
the centralization pressure remains insignifiant. Proof of work also clearl=
y has a lot more barriers to entry than any proof of stake system does. Bot=
h of these mean the tendency towards oligopolistic control is worse for PoW=
.
> > > > > > > > > > >
> > > > > > > > > > > > Energy usage, in-and-of-itself, is nothing to be as=
hamed of!!
> > > > > > > > > > >
> > > > > > > > > > > I certainly agree. Bitcoin's energy usage at the mome=
nt is I think quite warranted. However, the question is: can we do substant=
ially better. I think if we can, we probably should... eventually.
> > > > > > > > > > >
> > > > > > > > > > > > Proof of Stake is only resilient to =E2=85=93 of th=
e network demonstrating a Byzantine Fault, whilst Proof of Work is resilien=
t up to the =C2=BD threshold
> > > > > > > > > > >
> > > > > > > > > > > I see no mention of this in the pos.pdf you linked to=
. I'm not aware of any proof that all PoS systems have a failure threshold =
of 1/3. I know that staking systems like Casper do in fact have that 1/3 re=
quirement. However there are PoS designs that should exceed that up to near=
ly 50% as far as I'm aware. Proof of work is not in fact resilient up to th=
e 1/2 threshold in the way you would think. IE, if 100% of miners are curre=
ntly honest and have a collective 100 exahashes/s hashpower, an attacker do=
es not need to obtain 100 exahashes/s, but actually only needs to accumulat=
e 50 exahashes/s. This is because as the attacker accumulates hashpower, it=
 drives honest miners out of the market as the difficulty increases to beyo=
nd what is economically sustainable. Also, its been shown that the best pro=
of of work can do is require an attacker to obtain 33% of the hashpower bec=
ause of the selfish mining attack discussed in depth in this paper: https:/=
/arxiv.org/abs/1311.0243. Together, both of these things reduce PoW's secur=
ity by a factor of about 83% (1 - 50%*33%).
> > > > > > > > > > >
> > > > > > > > > > > > Proof of Stake requires other trade-offs which are =
incompatible with Bitcoin's objective (to be a trustless digital cash) =E2=
=80=94 specifically the famous "security vs. liveness" guarantee
> > > > > > > > > > >
> > > > > > > > > > > Do you have a good source that talks about why you th=
ink 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 mini=
ng, some nodes may reject you, but there will likely be more that will acce=
pt you, some sellers may reject you, but most would accept your money as pa=
yment for bitcoins. I don't think requiring the "permission" of one of mill=
ions of people in the market can be reasonably considered a "permissioned c=
urrency".
> > > > > > > > > > >
> > > > > > > > > > > > 2.  Proof of stake must have a trusted means of tim=
estamping to regulate overproduction of blocks
> > > > > > > > > > >
> > > > > > > > > > > Both PoW and PoS could mine/mint blocks twice as fast=
 if everyone agreed to double their clock speeds. Both systems rely on an h=
onest 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 dif=
ferent 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, o=
PoW, and the BIP itself. PoS, VDFs, and so on are interesting but I guess t=
here are other threads going on these topics already where they would be re=
levant.
> > > > > > > > > > > > > Also, it's important to distinguish between oPoW =
and these other "alternatives" to Hashcash. oPoW is a true Proof of Work th=
at doesn't alter the core game theory or security assumptions of Hashcash a=
nd 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 conte=
xt of a working
> > > > > > > > > > > > > >     proof-of-burn protocol
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -   vdfs used only for timing (not block height=
)
> > > > > > > > > > > > > > -   blind-burned coins of a specific age used t=
o replace proof of work
> > > > > > > > > > > > > > -   the required "work" per block would simply =
be a competition to
> > > > > > > > > > > > > >     acquire rewards, and so miners would have t=
o burn coins, well in
> > > > > > > > > > > > > >     advance, and hope that their burned coins g=
ot rewarded in some far
> > > > > > > > > > > > > >     future
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -   the point of burned coins is to mimic, in e=
very meaningful way, the
> > > > > > > > > > > > > >     value gained from proof of work... without =
some of the security
> > > > > > > > > > > > > >     drawbacks
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -   the miner risks losing all of his burned co=
ins (like all miners risk
> > > > > > > > > > > > > >     losing their work in each block)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -   new burns can't be used
> > > > > > > > > > > > > > -   old burns age out (like ASICs do)
> > > > > > > > > > > > > > -   other requirements on burns might be needed=
 to properly mirror the
> > > > > > > > > > > > > >     properties of PoW and the incentives Bitcoi=
n 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 t=
hat 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 bloc=
ks more constant.
> > > > > > > > > > > > > > > Zac
> > > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj ZmnSCP=
xj@protonmail.com wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Good morning Zac,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > VDFs might enable more constant block tim=
es, 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 a=
s-is difficulty adjustments.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As a result, variation in block times wil=
l be greatly reduced.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As I understand it, another weakness of VDF=
s is that they are not inherently progress-free (their sequential nature pr=
events that; they are inherently progress-requiring).
> > > > > > > > > > > > > > > > Thus, a miner which focuses on improving th=
e 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 fas=
ter 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/listi=
nfo/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/bi=
tcoin-dev
> > > > > > > > > >
> > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev
>
>