path: root/9f/732bb43430b054ce6f8477ae7ebedce6c5d641

Return-Path: <befreeandopen@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 764CBC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Jun 2021 08:21:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4CBB7402D4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Jun 2021 08:21:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id gHUDnggXqntr
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Jun 2021 08:21:38 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0D6C140234
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Jun 2021 08:21:37 +0000 (UTC)
Date: Tue, 01 Jun 2021 08:21:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1622535691;
 bh=+cimHxZ1Gbp9EumCt9j7q1smhxaziHL2i6OY53JlN8w=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=fqXZjeZqVMi90ud4dMwNW0ly79sxAQQDURFNO59y3G0MRbDkOB/RxLiRJ1GgTEz4k
 IVOVwsuofBayVS9RGjXq9Zy/2/P6TFAFU+v3efLTvFoFGgA5bFJ49EzjB/qr6F6CR3
 N3HEK/akHXnUwU/BKBifRPE9DauiwbzbZOTKiMUI=
To: Erik Aronesty <erik@q32.com>
From: befreeandopen <befreeandopen@protonmail.com>
Reply-To: befreeandopen <befreeandopen@protonmail.com>
Message-ID: <EdKK1tb2px2G--ianlCQpRjsn7vdXkSr60sV18NpVw-uVuKSA-ag9xXch_rYDkhtaJTH36zDMuVGZyYrKagMNNw_0OrLF8QsPiuo-YIxTaE=@protonmail.com>
In-Reply-To: <CAJowKgJTEHLeHpKUOavAY9hHZ_3hChkJnMX13K-pSUhch7JwdQ@mail.gmail.com>
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.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>
 <CAJowKgJTEHLeHpKUOavAY9hHZ_3hChkJnMX13K-pSUhch7JwdQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 01 Jun 2021 08:31:36 +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: Tue, 01 Jun 2021 08:21:43 -0000

Erik, thanks for the link. So referring to https://en.bitcoin.it/wiki/Proof=
_of_burn, I do not really understand how this is supposed to be that much b=
etter over many proof of stake proposals. If there is more research on PoB,=
 please note I'm not commenting on that as I only read this wiki article an=
d my comments are purely related to this only.

I hope we can agree that the idea with manual insertion of entropy every we=
ek can be discarded, but at the same time I don't think it is a crucial poi=
nt of the whole idea. So we can just focus on the rest of it.

Then the whole idea seems just like certain proof of stake implementations =
with just small differences, which I try to summarize:

- in PoB, in order to use the coin for block production, you burn it in the=
 past and wait some time -- in the certain PoS I'm talking about, in order =
to use the coin, you do not move the coin for some time - so in both there =
is the same idea - you somehow make the coin eligible for the block creatio=
n process by first doing some action followed by some inaction for some tim=
e; the difference here is that if later you use such coin in PoS, then afte=
r waiting more time, you can use the coin again (for whatever purpose), whi=
le in PoB the coin is gone forever (it is burned); this does not seem to be=
 fundamentally different

- in PoB, the author suggests there is an exponential decay of the power of=
 the coin to create a block; in some PoS schemas, there historically was an=
 era of so called CoinAge mechanism, which was somewhat inverse to this exp=
onential decay, it was that the coin gets more power the older it is untouc=
hed, some implementations were for linear increase in the power, some expon=
ential. Usually there was a certain limit - i.e. a maximum power the coin m=
ay have reached. It turned out quite quickly that such property is making a=
ttacks easier. PoB reverses the idea, but I don't think that helps that muc=
h. In any case, there seems to be an optimal period of time for each used c=
oin, in both PoS and PoB, where the coin is most suitable for block product=
ion. I admit PoB version is better, but the crucial property here is that s=
ome coins are more powerful than other.

- in both PoB and PoS it seems there is linear increase of the ability of t=
he coin to produce blocks with the size of the coin (more BTC you burn/stak=
e, the better your chance)

This characteristic of PoB does not suggest that it would have that much di=
fferent properties than PoS. So it should suffer from same problems as PoS.=
 Namely, the problems I see now, with the given proposal from wiki, are:

- there seems to be lack of definition of the heaviest chain and difficulty=
 adjustment - this seems crucial, but likely solvable, I'm just saying it i=
s importantly missing in the description

- there seems to be a problem with nothing at stake (nothing at burn maybe?=
) - How that can be? Again, it seems that every burned coin can be used for=
 free checks at any time after the initial waiting period. These free check=
s are indeed free and are the core of the nothing at stake problem in PoS. =
You seem to make those checks for free and you seem to be able to use those=
 burned coins to create arbitrary number of forks build on any parent block=
s of your choice, not just the last block of the heaviest chain. I can't se=
e at the moment how is this different from PoS nothing at stake problem. Ma=
ybe you can explain?

- it seems to me that there is a trivial attack against the scheme by a wea=
lthy attacker. Suppose a common size of the burn is 1 BTC per block, suppos=
e you define the heaviest chain rule somehow in relation to total number of=
 burned coins or the cumulative "strength" of the "lowest" hashes, then you=
 can just burn 20 UTXOs, each being 10 BTC in value, so you spent 200 BTC o=
n this attack, but you are in very strong position because after you wait t=
he needed time, you should be able to do pretty nasty reorg. Suppose that t=
he main chain is A-B-C-D-E-F, so what you do at that point is that you just=
 "try for free" all your 20 UTXOs, whether or not they can build on top of =
block A (which has 5 confs on top, F is the tip of the main chain). Since y=
ou have big UTXOs, your chances should be good, of course you can always tr=
y many times because you have a "lottery ticket" for every timestampt t. So=
 with this you should be able, with good chance, to find such B' and then y=
ou have 19 UTXOs remaining to try to build on B' in the same way. I can't s=
ee what prevents this attack in the described scheme.

- the ability to retroactively try all different kids of timestamp t seems =
devastating - you again get super easy and somewhat cheap attack (due to no=
thing at burn problem) that allows you to rewrite even long chains at will.


Could you explain what am I missing here, because this actually does not se=
em better, but rather worse than some PoS schemes?




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 Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Friday, May 28, 2021 9:06 PM, Erik Aronesty <erik@q32.com> wrote:

> 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 =
found it interesting up until now. Some of your recent claims seem quite st=
rong to me and I'd like to read more.
> > Forgive me if this has been mentioned recently, but is there a full spe=
cification of the concept you are referring to? I don't mean just the basic=
 idea description (that much is clear to me), I mean a fully detailed propo=
sal or technical documentation that would give me a precise information abo=
ut 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 Origina=
l 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 improv=
e
> > > 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.=
 Let 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 nex=
t 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 block=
s on on the second from the top block if it gives them more blocks in the f=
uture than minting on the top block. And instead lets the top block proceed=
 if it gives them more blocks in the future (also figuring in the 3 blocks =
they're missing out on minting).
> > > > 4.  Profit!
> > > >
> > > > The problem with this attack is that any self respecting PoS system=
 wouldn't have the information available for minters to know how blocks wil=
l affect their future prospects of minting. Otherwise this would introduce =
the problem of stake grinding. This can be done using collaborative randomn=
ess (where numbers from many parties are combined to create a random number=
 that no individual party could predict). In fact, that's what the Casper p=
rotocol does to decide quorums. In a non quorum case, you can do something =
like record a hash of a number in the block header, and then have a second =
step to release that number later. Rewards can be given can be used to ensu=
re minters act honestly here by minting messages that release these numbers=
 and not releasing their secret numbers too early.
> > > > Yes, you misunderstood it. First, let me say that the above thought=
s of yours are incorrect, at least for non-quorum case. Since the transitio=
n in the blockchain system from S1 to S2 is only by adding new block, and s=
ince stakers always need to be able to decide whether or not they can add t=
he next block, it follows that if a staker creates a new block locally, she=
 can decide whether the new state allows her to add another block on top. A=
s you mentioned, this COULD introduce problem of staking, that you are inco=
rrect in that it is a necessity. Usual prevention of the grinding problem i=
n this case is that an "old enough" source of randomness applies for the cu=
rrent block production process. Of course this, as it is typical for PoS, i=
ntroduces other problems, but let's discard those.
> > > > I will try to explain in detail what you misunderstood before. You =
start with a chain ending with blocks A-B-C, C being the top, the common fe=
ature of PoS system (non-quorum), roughly speaking, is that if N is the tot=
al amount of coins that participate in the staking process to create a new =
block on top of C (let's call that D), then a participant having K*N amount=
 of stake has chance K to be the one who will create the next stake. In oth=
er words, the power of stakers is supposed to be linear in the system - you=
 own 10 coins gives you 10x the chance of finding block over someone who ha=
s 1 coin.
> > > > What i was claiming is that using the technique I have described, t=
his linearity is violated. Why? Well, it works for honest stakers among the=
 competition of honest stakers - they really do have the chance of K to fin=
d the next block. However, the attacker, using nothing at stake, checks her=
 ability to build block D (at some timestamp). If she is successful, she do=
es not propagate D immediately, but instead she also checks whether she can=
 build on top of B and on top of A. Since with every new timestamp, usually=
, there is a new chance to build the block, it is not uncommon that she fin=
ds 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 consensu=
s rule, but it may depend on a specific consensus). So her chance to produc=
e such C' is greater than her previous chance of producing C (which chance =
was limited by other stakers in the system and the discovery of block C by =
one of them). Now suppose that she found such C' and now she continues by t=
rying to prolong this chain by finding D'. And again here, it is quite like=
ly that her chance to find such D' is greater than was her chance of findin=
g D because again there are likely multiple timestamps she could try. This =
all was possible just because nothing at stake allows you to just try if yo=
u can produce a block in certain state of block chain or not. Now if she ac=
tually was able to find D', she discards D and only publishes chain A-B-C'-=
D', which can not be punished despite the fact that she indeed produced two=
 different forks. She can not be punished because this production was local=
 and only the final result of A-B-C'-D' was published, in which case she ga=
ined an extra block over the honest strategy which would only give her bloc=
k D.
> > > > Fun fact tho: there is an attack called the "selfish mining attack"=
 for proof of work, and it reduces the security of PoW by at least 1/3rd.
> > > > How is that relevant to our discussion? This is known research that=
 has nothing to do with PoS except that it is often worse on PoS.
> > > >
> > > > > the problem is not as hard as you think
> > > >
> > > > I don't claim to know just how hard finding the IP address associat=
ed with a bitcoin address is. However, the DOS risk can be solved more comp=
letely by only allowing the owner of coins themselves to know whether they =
can mint a block. Eg by determining whether someone can mint a block based =
on their public key hidden behind hashes (as normal in addresses). Only whe=
n someone does in fact mint a block do they reveal their hidden public key =
in order to prove they are allowed to mint the block.
> > > > This is true, but you are mixing quorum and non-quorum systems. My =
objection here was towards such system where I specifically said that the l=
ist of producers for next epoch is known up front and you confirmed that th=
is is what you meant with "quorum" system. So in such system, I claimed, th=
e known producer is the only target at any given point of time. This of cou=
rse does not apply to any other type of system where future producers are n=
ot known. No need to dispute, again, something that was not claimed.
> > > >
> > > > > I agree that introduction of punishment itself does not imply int=
roducing a problem elsewhere (which I did not claim if you reread my previo=
us message)
> > > >
> > > > I'm glad we agree there. Perhaps I misunderstood what you meant by =
"you should not omit to mention that by doing so, typically, you have intro=
duced another problem elsewhere."
> > > > Perhaps you should quote the full sentence and not just a part of i=
t:
> > > > "Of course you can always change the rules in a way that a certain =
specific attack is not doable, but you should not omit to mention that by d=
oing so, typically, you have introduced another problem elsewhere, or you h=
ave not solved it completely."
> > > > You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT =
COMPLETELY)
> > > > In case of the punishment it was meant to be the not solve it compl=
etely part.
> > > > Also "typically" does not imply always.
> > > > But this parsing of English sentences for you seems very off topic =
here. My point is, in context of Bitcoin, reject such unsupported claims th=
at 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 sh=
e does not miss a chance to create a block, her significance in the system =
will always increase in time. It will increase relative to all normal users=
 who do not stake
> > > >
> > > > Well, if you're in the closed system of the cryptocurrency, sure. B=
ut we don't live in that closed system. Minters will earn some ROI from min=
ting just like any other financial activity. Others may find more success s=
pending 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 decid=
e to use to mint blocks if they decide to.
> > > > This only supports the point I was making. Since the optimal scenar=
io 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 =
insecure
> > > >
> > > > I think the only thing we can conclude from this is that you have c=
ome up with an insecure proof of stake protocol. I don't see how anything y=
ou've brought up amounts to substantial evidence that all possible PoS prot=
ocols are insecure.
> > > > I have not come up with anything. I'm afraid you've not realized th=
e burden of proof is on your side if you vouch for a design that is not bel=
ieved and trusted to be secure. It is up to you to show that you know how t=
o solve every problem that people throw at you. So far we have just demonst=
rated that your claim that nothing at stake is solved was unjustified. You =
have not described a system that would solve it (and not introduce critical=
 DDOS attack vector as it is in quorum based systems - per the prior defini=
tion of such systems).
> > > > Of course the list of problems of PoS systems do not end with just =
nothing at stake, but it is good enough example that by itself prevents its=
 adoption in decentralized consensus. No need to go to other hard problems =
without solving nothing at stake.
> > > > On Tue, May 25, 2021 at 11:10 AM befreeandopen befreeandopen@proton=
mail.com wrote:
> > > >
> > > > > @befreeandopen " An attacker can calculate whether or not she can=
 prolong this chain or not and if so with what timestamp."
> > > > > The scenario you describe would only be likely to happen at all i=
f the malicious actor has a very large fraction of the stake - probably qui=
te close to 50%. At that point, you're talking about a 51% attack, not the =
nothing at stake problem. The nothing at stake problem is the problem where=
 anyone will mint on any chain. Its clear that if there's a substantial pun=
ishment for minting on chains other than the one that eventually wins, ever=
y minter without a significant fraction of the stake will be honest and not=
 attempt to mint on old blocks or support someone else's attempt to mint on=
 old blocks (until and if it becomes the heaviest chain). Because the attac=
ker would need probably >45% of the active stake (take a look at the reason=
ing here for a deeper analysis of that statement), I don't agree that punis=
hment is not a sufficient mitigation of the nothing at stake problem. To ex=
ploit the nothing at stake problem, you basically need to 51% attack, at wh=
ich point you've exceeded the operating conditions of the system, so of cou=
rse 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 desc=
ribed technique at any size of the stake and significantly so with just 5% =
of the stake. By significantly, I do not mean that the attacker is able to =
completely take control the network (in short term), but rather that the at=
tacker has significant advantage in the number of blocks she creates compar=
ed to what she "should be able to create". This means the attacker's stake =
increases significantly faster than of the honest nodes, which in long term=
 is very serious in PoS system. If you believe close to 50% is needed for t=
hat, you need to redo your math. So no, you are wrong stating that "to expl=
oit nothing at stake problem you basically need to 51% attack". It is rathe=
r the opposite - eventually, nothing at stake attack leads to ability to pe=
rform 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 wit=
h powerful DDOS in order to hurt liveness of such system
> > > > >
> > > > > Just like in bitcoin, associating keys with IP addresses isn't ge=
nerally an easy thing to do on the fly like that. If you know someone's IP =
address, you can target them. But if you only know their address or public =
key, the reverse isn't as easy. With a quorum-based PoS system, you can see=
 their public key and address, but finding out their IP to DOS would be a h=
uge challenge I think.
> > > > > I do not dispute that the problem is not trivial, but the problem=
 is not as hard as you think. The network graph analysis is a known techniq=
ue and it is not trivial, but not very hard either. Introducing a large num=
ber of nodes to the system to achieve very good success rate of analysis of=
 area of origin of blocks is doable and has been done in past. So again, I =
very much disagree with your conclusion that this is somehow secure. It is =
absolutely insecure.
> > > > > Note, tho, that quorum-based PoS generally also have punishments =
as part of the protocol. The introduction of punishments do indeed handily =
solve the nothing at stake problem. And you didn't mention a single problem=
 that the punishments introduce that weren't already there before punishmen=
ts. There are tradeoffs with introducing punishments (eg in some cases you =
might punish honest actors), but they are minor in comparison to solving th=
e nothing at stake problem.
> > > > > While I agree that introduction of punishment itself does not imp=
ly introducing a problem elsewhere (which I did not claim if you reread my =
previous message), it does introduce additional complexity which may introd=
uce problem, but more importantly, while it slightly improves resistance ag=
ainst the nothing at stake attack, it solves absolutely nothing. Your claim=
 is based on wrong claim of needed close to 50% stake, but that could not b=
e farther from the truth. It is not true even in optimal conditions when al=
l participants of the network stake or delegate their stake. These optimal =
conditions rarely, if ever, occur. And that's another thing that we have no=
t mention in our debate, so please allow me to introduce another problem to=
 PoS.
> > > > > Consider what is needed for such optimal conditions to occur - al=
l coins are always part of the stake, which means that they need to somehow=
 automatically part of the staking process even when they are moved. But in=
 many PoS systems you usually require some age (in terms of confirmations) =
of the coin before you allow it to be used for participation in staking pro=
cess and that is for a good reason - to prevent various grinding attacks. I=
n some systems the coin must be specifically registered before it can be st=
aked, in others, simply waiting for enough confirmations enables you to sta=
ke with the coin. I am not sure if there is a system which does not have th=
is cooling period for a coin that has been moved. Maybe it is possible thou=
gh, but AFAIK it is not common and not battle tested feature.
> > > > > Then if we admit that achieving the optimal condition is rather t=
heoretical. Then if we do not have the optimal condition, it means that a s=
taker with K% of the total available supply increases it's percentage over =
time to some amounts >K%. As long as the staker makes sure (which is not th=
at hard) that she does not miss a chance to create a block, her significanc=
e in the system will always increase in time. It will increase relative to =
all normal users who do not stake (if there are any) and relative to all ot=
her stakers who make mistakes or who are not wealthy enough to afford not s=
elling any position ever. But powerful attacker is exactly in such position=
 and thus she will gain significance in such a system. The technique I have=
 described, and that you mistakenly think is viable only with huge amounts =
of stake, only puts the attacker to even greater advantage. But even withou=
t the described attack (which exploits nothing at stake), the PoS system co=
nverges to a system more and more controlled by powerful entity, which we c=
an assume is the attacker.
> > > > > So I don't think it is at all misleading to claim that "nothing a=
t stake" is a solved problem. I do in fact mean that the solutions to that =
problem don't introduce any other problems with anywhere near the same leve=
l of significance.
> > > > > It still stands as truly misleading claim. I disagree that introd=
ucing DDOS opportunity with medium level of difficulty for the attacker to =
implement it, in case of "quorum-based PoS" is not a problem anywhere near =
the same level of significance. Such an attack vector allows you to turn of=
f 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 =
insecure until someone invents and demonstrates an actual way of solving th=
ese 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 heigh=
t
> > > > > >
> > > > > > > This sounds exploitable. It seems like an attacker could simp=
ly focus all their burns on a particular set of 6 blocks to double spend, m=
inimizing their cost of attack.
> > > > > >
> > > > > > could be right. the original idea was to have burns decay over =
time,
> > > > > > like ASIC's.
> > > > > > anyway the point was not that "i had a magic formula"
> > > > > > the point was that proof of burn is almost always better than p=
roof of
> > > > > > stake - simply because the "proof" is on-chain, not sitting on =
a node
> > > > > > somewhere waiting to be stolen.
> > > > > > On Mon, May 24, 2021 at 9:53 PM Billy Tetrud billy.tetrud@gmail=
.com wrote:
> > > > > >
> > > > > > > Is this the kind of proof of burn you're talking about?
> > > > > > >
> > > > > > > > if i have a choice between two chains, one longer and one s=
horter, i can only choose one... deterministically
> > > > > > >
> > > > > > > What prevents you from attempting to mine block 553 on both c=
hains?
> > > > > > >
> > > > > > > > miners have a very strong, long-term, investment in the sta=
bility of the chain.
> > > > > > >
> > > > > > > Yes, but the same can be said of any coin, even ones that do =
have the nothing at stake problem. This isn't sufficient tho because the ch=
ain is a common good, and the tragedy of the commons holds for it.
> > > > > > >
> > > > > > > > you burn them to be used at a future particular block heigh=
t
> > > > > > >
> > > > > > > This sounds exploitable. It seems like an attacker could simp=
ly focus all their burns on a particular set of 6 blocks to double spend, m=
inimizing their cost of attack.
> > > > > > >
> > > > > > > > i can imagine scenarios where large stakeholders can collud=
e to punish smaller stakeholders simply to drive them out of business, for =
example
> > > > > > >
> > > > > > > Are you talking about a 51% attack? This is possible in any d=
ecentralized cryptocurrency.
> > > > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik@q32.com w=
rote:
> > > > > > >
> > > > > > > > > > your burn investment is always "at stake", any redactio=
n can result in a loss-of-burn, because burns can be tied, precisely, to bl=
ock-heights
> > > > > > > > > > I'm fuzzy on how proof of burn works.
> > > > > > > >
> > > > > > > > when you burn coins, you burn them to be used at a future p=
articular
> > > > > > > > block height: so if i'm burning for block 553, i can only u=
se them to
> > > > > > > > mine block 553. if i have a choice between two chains, one =
longer
> > > > > > > > and one shorter, i can only choose one... deterministically=
, for that
> > > > > > > > burn: the chain with the height 553. if we fix the "lead ti=
me" for
> > > > > > > > burned coins to be weeks or even months in advance, miners =
have a very
> > > > > > > > strong, long-term, investment in the stability of the chain=
.
> > > > > > > > therefore there is no "nothing at stake" problem. it's
> > > > > > > > deterministic, so miners have no choice. they can only choo=
se the
> > > > > > > > transactions that go into the block. they cannot choose whi=
ch chain
> > > > > > > > to mine, and it's time-locked, so rollbacks and instability=
 always
> > > > > > > > hurt miners the most.
> > > > > > > > the "punishment" systems of PoS are "weird at best", certai=
nly
> > > > > > > > unproven. i can imagine scenarios where large stakeholders =
can
> > > > > > > > collude to punish smaller stakeholders simply to drive them=
 out of
> > > > > > > > business, for example. and then you have to put checks in p=
lace to
> > > > > > > > prevent that, and more checks for those prevention system..=
.
> > > > > > > > in PoB, there is no complexity. simpler systems like this a=
re
> > > > > > > > typically more secure.
> > > > > > > > PoB also solves problems caused by "energy dependence", whi=
ch could
> > > > > > > > lead to state monopolies on mining (like the new Bitcoin Mi=
ning
> > > > > > > > Council). these consortiums, if state sanctioned, could bec=
ome a
> > > > > > > > source of censorship, for example. Since PoB doesn't requir=
e you to
> > > > > > > > have a live, well-connected node, it's harder to censor & h=
arder to
> > > > > > > > trace.
> > > > > > > > Eliminating this weakness seems to be in the best interests=
 of
> > > > > > > > existing stakeholders
> > > > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud billy.tetrud@g=
mail.com wrote:
> > > > > > > >
> > > > > > > > > > proof of burn clearly solves this, since nothing is hel=
d online
> > > > > > > > >
> > > > > > > > > Well.. the coins to be burned need to be online when they=
're burned. But yes, only a small fraction of the total coins need to be on=
line.
> > > > > > > > >
> > > > > > > > > > your burn investment is always "at stake", any redactio=
n can result in a loss-of-burn, because burns can be tied, precisely, to bl=
ock-heights
> > > > > > > > >
> > > > > > > > > So you're saying that if say someone tries to mine a bloc=
k on a shorter chain, that requires them to send a transaction burning thei=
r coins, and that transaction could also be spent on the longest chain, whi=
ch means their coins are burned even if the chain they tried to mine on doe=
sn'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 s=
take" problem. You can simply punish people who mint on shorter chains (by =
rewarding people who publish proofs of this happening on the main chain). I=
n quorum-based PoS, you can punish people in the quorum that propose or sig=
n multiple blocks for the same height. The "nothing at stake" problem is a =
solved problem at this point for PoS.
> > > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik@q32.co=
m wrote:
> > > > > > > > >
> > > > > > > > > > > I don't see a way to get around the conflicting requi=
rement 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.
> > > > > > > > > >
> > > > > > > > > > proof of burn clearly solves this, since nothing is hel=
d online
> > > > > > > > > >
> > > > > > > > > > > how does proof of burn solve the "nothing at stake" p=
roblem in your view?
> > > > > > > > > >
> > > > > > > > > > definition of nothing at stake: in the event of a fork,=
 whether the
> > > > > > > > > > fork is accidental or a malicious, the optimal strategy=
 for any miner
> > > > > > > > > > is to mine on every chain, so that the miner gets their=
 reward no
> > > > > > > > > > matter which fork wins. indeed in proof-of-stake, the p=
roofs are
> > > > > > > > > > published on the very chains mines, so the incentive is=
 magnified.
> > > > > > > > > > in proof-of-burn, your burn investment is always "at st=
ake", any
> > > > > > > > > > redaction can result in a loss-of-burn, because burns c=
an be tied,
> > > > > > > > > > precisely, to block-heights
> > > > > > > > > > as a result, miners no longer have an incentive to mine=
 all chains
> > > > > > > > > > in this way proof of burn can be more secure than proof=
-of-stake, and
> > > > > > > > > > even more secure than proof of work
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitc=
oin-dev
> > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Billy,
> > > > > > > > > > > I was going to write a post which started by dismissi=
ng 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 se=
ttlement 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 pu=
t 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 t=
o run their own node, most don't, and that's perfectly acceptable.
> > > > > > > > > > > At no point do their personal decisions affect the un=
derlying consensus -- it only affects their personal security assurance (no=
t that of the system itself).
> > > > > > > > > > > In PoS systems this clean separation of responsibilit=
ies does not exist.
> > > > > > > > > > > I think that the more rigorously studied PoS protocol=
s 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 lead=
ing proof of stake protocols would have on Bitcoin:
> > > > > > > > > > >
> > > > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot)
> > > > > > > > > > >
> > > > > > > > > > > Cardano is a UTXO based PoS coin based on Ouroboros P=
raos3 with an inbuilt on-chain delegation system5.
> > > > > > > > > > > In these protocols, coin holders who do not want to r=
un their node with their hot keys in it delegate it to a "Stake Pool".
> > > > > > > > > > > I call the resulting system Proof-of-SquareSpace sinc=
e most will choose a pool by looking around for one with a nice website and=
 offering the largest share of the block reward.
> > > > > > > > > > > On the surface this might sound no different than som=
eone with an mining rig shopping around for a good mining pool but there ar=
e crucial differences:
> > > > > > > > > > >
> > > > > > > > > > > 1.  The person making the decision is forced into it =
just because they own the currency -- someone with a mining rig has purchas=
ed it with the intent to make profit by participating in consensus.
> > > > > > > > > > >
> > > > > > > > > > > 2.  When you join a mining pool your systems are very=
 much still online. You are just partaking in a pool to reduce your profit =
variance. You still see every block that you help create and you never help=
 create a block without seeing it first.
> > > > > > > > > > >
> > > > > > > > > > > 3.  If by SquareSpace sybil attack you gain a dishone=
st majority and start censoring transactions how are the users meant to red=
elegate their stake to honest pools?
> > > > > > > > > > >     I guess they can just send a transaction delegati=
ng 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 UTX=
O belongs to so the appropriate share of block rewards can be transferred t=
here.
> > > > > > > > > > > Being able to associate every UTXO to an account ruin=
s one of the main privacy advantages of the UTXO model.
> > > > > > > > > > > It also grows the size of the blockchain significantl=
y.
> > > > > > > > > > >
> > > > > > > > > > > ### "Pure" proof of stake (Algorand)
> > > > > > > > > > >
> > > > > > > > > > > Algorand's4 approach is to only allow online stake to=
 participate in the protocol.
> > > > > > > > > > > Theoretically, This means that keys holding funds hav=
e 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 "participati=
on keys"1 that will be used to create blocks on your coin holding key's beh=
alf.
> > > > > > > > > > > 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 retur=
n.
> > > > > > > > > > > Damn it's still Proof-of-SquareSpace!
> > > > > > > > > > > The minor advantage is that at least the participatio=
n keys expire after a certain amount of time so eventually the SquareSpace =
attacker will lose their hold on consensus.
> > > > > > > > > > > Importantly there is also less junk on the blockchain=
 because the participation keys are delegated off-chain and so are not maki=
ng as much of a mess.
> > > > > > > > > > >
> > > > > > > > > > > ### Conclusion
> > > > > > > > > > >
> > > > > > > > > > > I don't see a way to get around the conflicting requi=
rement 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.
> > > > > > > > > > > If we allow delegation then we open up a new social a=
ttack surface and it degenerates to Proof-of-SquareSpace.
> > > > > > > > > > > For a "digital gold" like system like Bitcoin we opti=
mize for simplicity and desperately want to avoid extraneous responsibiliti=
es for the holder of the coin.
> > > > > > > > > > > After all, gold is an inert element on the periodic t=
able that doesn't confer responsibilities on the holder to maintain the qua=
lity 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 tha=
t way and Proof-of-Stake makes everything a bit too exciting.
> > > > > > > > > > > I suppose in the end the market will decide what is r=
eal digital gold and whether these bad technical trade offs are worth being=
 able to say it uses less electricity. It goes without saying that making b=
ad technical decisions to appease the current political climate is an anath=
ema to Bitcoin.
> > > > > > > > > > > Would be interested to know if you or others think di=
fferently on these points.
> > > > > > > > > > > Cheers,
> > > > > > > > > > > LL
> > > > > > > > > > > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoi=
n-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > >
> > > > > > > > > > > > I think there is a lot of misinformation and bias a=
gainst Proof of Stake. Yes there have been lots of shady coins that use ins=
ecure 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 bet=
ween "proved to be impossible" and "have not achieved recognized success ye=
t". Most of the arguments levied against PoS are out of date or rely on unp=
roven assumptions or extrapolation from the analysis of a particular PoS sy=
stem. I certainly don't think we should experiment with bitcoin by switchin=
g 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 se=
curity (cost / capital required to execute an attack) while at the same tim=
e costing far less resources (which do translate to fees on the network) wi=
thout compromising any of the critical security properties bitcoin relies o=
n. I think the critical piece of this is the disagreements around hardcoded=
 checkpoints, which is a critical piece solving attacks that could be levie=
d on a PoS chain, and how that does (or doesn't) affect the security model.
> > > > > > > > > > > > @Eric Your proof of stake fallacy seems to be sayin=
g that PoS is worse when a 51% attack happens. While I agree, I think that =
line of thinking omits important facts:
> > > > > > > > > > > >
> > > > > > > > > > > > -   The capital required to 51% attack a PoS chain =
can be made substantially greater than on a PoS chain.
> > > > > > > > > > > > -   The capital the attacker stands to lose can be =
substantially greater as well if the attack is successful.
> > > > > > > > > > > > -   The effectiveness of paying miners to raise the=
 honest fraction of miners above 50% may be quite bad.
> > > > > > > > > > > > -   Allowing a 51% attack is already unacceptable. =
It should be considered whether what happens in the case of a 51% may not b=
e significantly different. The currency would likely be critically damaged =
in a 51% attack regardless of consensus mechanism.
> > > > > > > > > > > >
> > > > > > > > > > > > > Proof-of-stake tends towards oligopolistic contro=
l
> > > > > > > > > > > >
> > > > > > > > > > > > People repeat this often, but the facts support thi=
s. 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 bl=
ocks, 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 pre=
ssure - this is not disputed. Our goal in relation to that is to ensure tha=
t the centralization pressure remains insignifiant. Proof of work also clea=
rly 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 mo=
ment is I think quite warranted. However, the question is: can we do substa=
ntially better. I think if we can, we probably should... eventually.
> > > > > > > > > > > >
> > > > > > > > > > > > > Proof of Stake is only resilient to =E2=85=93 of =
the network demonstrating a Byzantine Fault, whilst Proof of Work is resili=
ent 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 threshol=
d of 1/3. I know that staking systems like Casper do in fact have that 1/3 =
requirement. However there are PoS designs that should exceed that up to ne=
arly 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 cur=
rently honest and have a collective 100 exahashes/s hashpower, an attacker =
does not need to obtain 100 exahashes/s, but actually only needs to accumul=
ate 50 exahashes/s. This is because as the attacker accumulates hashpower, =
it drives honest miners out of the market as the difficulty increases to be=
yond what is economically sustainable. Also, its been shown that the best p=
roof of work can do is require an attacker to obtain 33% of the hashpower b=
ecause 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 sec=
urity by a factor of about 83% (1 - 50%*33%).
> > > > > > > > > > > >
> > > > > > > > > > > > > Proof of Stake requires other trade-offs which ar=
e incompatible with Bitcoin's objective (to be a trustless digital cash) =
=E2=80=94 specifically the famous "security vs. liveness" guarantee
> > > > > > > > > > > >
> > > > > > > > > > > > Do you have a good source that talks about why you =
think proof of stake cannot be used for a trustless digital cash?
> > > > > > > > > > > >
> > > > > > > > > > > > > You cannot gain tokens without someone choosing t=
o give up those coins - a form of permission.
> > > > > > > > > > > >
> > > > > > > > > > > > This is not a practical constraint. Just like in mi=
ning, some nodes may reject you, but there will likely be more that will ac=
cept 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 mi=
llions of people in the market can be reasonably considered a "permissioned=
 currency".
> > > > > > > > > > > >
> > > > > > > > > > > > > 2.  Proof of stake must have a trusted means of t=
imestamping to regulate overproduction of blocks
> > > > > > > > > > > >
> > > > > > > > > > > > Both PoW and PoS could mine/mint blocks twice as fa=
st if everyone agreed to double their clock speeds. Both systems rely on an=
 honest majority sticking to standard time.
> > > > > > > > > > > > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky v=
ia bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Ah sorry, I didn't realize this was, in fact, a d=
ifferent thread! :)
> > > > > > > > > > > > > On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsk=
y 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 other threads going on these topics already where they would be =
relevant.
> > > > > > > > > > > > > > Also, it's important to distinguish between oPo=
W 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 interchangeabl=
e).
> > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > Mike
> > > > > > > > > > > > > > On Tue, May 18, 2021 at 4:55 PM Erik Aronesty v=
ia bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1.  i never suggested vdf's to replace pow.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2.  my suggestion was specifically in the con=
text of a working
> > > > > > > > > > > > > > >     proof-of-burn protocol
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   vdfs used only for timing (not block heig=
ht)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   blind-burned coins of a specific age used=
 to replace proof of work
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   the required "work" per block would simpl=
y be a competition to
> > > > > > > > > > > > > > >     acquire rewards, and so miners would have=
 to burn coins, well in
> > > > > > > > > > > > > > >     advance, and hope that their burned coins=
 got rewarded in some far
> > > > > > > > > > > > > > >     future
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   the point of burned coins is to mimic, in=
 every meaningful way, the
> > > > > > > > > > > > > > >     value gained from proof of work... withou=
t some of the security
> > > > > > > > > > > > > > >     drawbacks
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   the miner risks losing all of his burned =
coins (like all miners risk
> > > > > > > > > > > > > > >     losing their work in each block)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   new burns can't be used
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   old burns age out (like ASICs do)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   other requirements on burns might be need=
ed to properly mirror the
> > > > > > > > > > > > > > >     properties of PoW and the incentives Bitc=
oin uses to mine honestly.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3.  i do believe it is possible that a "burne=
d coin + vdf system"
> > > > > > > > > > > > > > >     might be more secure in the long run, and=
 that if the entire space
> > > > > > > > > > > > > > >     agreed that such an endeavor was worthwhi=
le, 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 Greenwoo=
d zachgrw@gmail.com wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi ZmnSCPxj,
> > > > > > > > > > > > > > > > Please note that I am not suggesting VDFs a=
s a means to save energy, but solely as a means to make the time between bl=
ocks more constant.
> > > > > > > > > > > > > > > > Zac
> > > > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj ZmnS=
CPxj@protonmail.com wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Good morning Zac,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > VDFs might enable more constant block t=
imes, 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-i=
s). As per the property of VDFs, miners are able show proof of work.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2.  Use current PoW mechanism with lowe=
r difficulty so finding a block takes 1 minute on average, again subject to=
 as-is difficulty adjustments.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > As a result, variation in block times w=
ill be greatly reduced.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As I understand it, another weakness of V=
DFs is that they are not inherently progress-free (their sequential nature =
prevents that; they are inherently progress-requiring).
> > > > > > > > > > > > > > > > > Thus, a miner which focuses on improving =
the amount of energy that it can pump into the VDF circuitry (by overclocki=
ng and freezing the circuitry), could potentially get into a winner-takes-a=
ll situation, possibly leading to even worse competition and even more ener=
gy consumption.
> > > > > > > > > > > > > > > > > After all, if you can start mining 0.1s f=
aster than the competition, that is a 0.1s advantage where only you can min=
e in the entire world.
> > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > ZmnSCPxj
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/lis=
tinfo/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/listinf=
o/bitcoin-dev
> > > > > > > > > > > >
> > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev
> > > > > > > > > > >
> > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev