path: root/5c/e7a6e7b5568bc9c5a9a655939dfda340a20166

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 AA418C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 14:40:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id A5E3C4040E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 14:40:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001,
 RCVD_IN_MSPIKE_WL=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 McryF3y2GA4M
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 14:40:53 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
 [185.70.40.141])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 8957E406AE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 14:40:52 +0000 (UTC)
Date: Fri, 28 May 2021 14:40:45 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1622212847;
 bh=yCs4q3Ii1UmVKGiwG9rT6pJg+pQou3fGeDWdDJBjqz0=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=TUmN4aBV6H/8Ung+Yris5LxGiPmK8pTpkE8IAGgI6wAeud69FQeBik/hBZjnhfmvr
 oFP/tfqlwHVJToIMjR8Yq4xMDia+d+1e/W72jJLfUu+lDItzZjfmYMGYwhJZrALOf2
 6ViXU1FVLHlrTQ9wgGa8naMNUGv/4XDCkQ/l3UqI=
To: Erik Aronesty <erik@q32.com>
From: befreeandopen <befreeandopen@protonmail.com>
Reply-To: befreeandopen <befreeandopen@protonmail.com>
Message-ID: <J3_n3ygIuQf54KXVl8jlbyahX5WJIzffVeDD3yt0RkRbPRyD56OPj3DT05wGJoEfI6XfLOq2DiaN-vdnXSdi7Q23NWrZ-Tg9jzM9jtx8-hg=@protonmail.com>
In-Reply-To: <CAJowKgKgGynQ9NYe_7xEai0tcBW4b=tQnNpv9vndx1hLCowfWg@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 28 May 2021 15:12:31 +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 14:40:55 -0000

Erik, I am sorry, I have little knowledge about proof-of-burn, I never foun=
d it interesting up until now. Some of your recent claims seem quite strong=
 to me and I'd like to read more.

Forgive me if this has been mentioned recently, but is there a full specifi=
cation of the concept you are referring to? I don't mean just the basic ide=
a description (that much is clear to me), I mean a fully detailed proposal =
or technical documentation that would give me a precise information about w=
hat 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 Me=
ssage =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. 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 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 futur=
e 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 wou=
ldn't have the information available for minters to know how blocks will af=
fect their future prospects of minting. Otherwise this would introduce the =
problem of stake grinding. This can be done using collaborative randomness =
(where numbers from many parties are combined to create a random number tha=
t no individual party could predict). In fact, that's what the Casper proto=
col 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 ensure m=
inters 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 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 since=
 stakers always need to be able to decide whether or not they can add the n=
ext 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. As yo=
u mentioned, this COULD introduce problem of staking, that you are incorrec=
t in that it is a necessity. Usual prevention of the grinding problem in th=
is case is that an "old enough" source of randomness applies for the curren=
t block production process. Of course this, as it is typical for PoS, intro=
duces other problems, but let's discard those.
> > I will try to explain in detail what you misunderstood before. You star=
t with a chain ending with blocks A-B-C, C being the top, the common featur=
e of PoS system (non-quorum), roughly speaking, is that if N is the total a=
mount of coins that participate in the staking process to create a new bloc=
k 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 other w=
ords, 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 has 1 =
coin.
> > What i was claiming is that using the technique I have described, this =
linearity is violated. Why? Well, it works for honest stakers among the com=
petition of honest stakers - they really do have the chance of K to find th=
e next block. However, the attacker, using nothing at stake, checks her abi=
lity to build block D (at some timestamp). If she is successful, she does n=
ot propagate D immediately, but instead she also checks whether she can bui=
ld on top of B and on top of A. Since with every new timestamp, usually, th=
ere is a new chance to build the block, it is not uncommon that she finds s=
he 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 p=
roduce such C', she not only could have tried the current timestamp t(D), b=
ut also all previous timestamps up to t(B) (usually that's the consensus ru=
le, but it may depend on a specific consensus). So her chance to produce su=
ch 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 tryin=
g to prolong this chain by finding D'. And again here, it is quite likely t=
hat 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 all =
was possible just because nothing at stake allows you to just try if you ca=
n produce a block in certain state of block chain or not. Now if she actual=
ly 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 dif=
ferent 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 gained=
 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" 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 associated w=
ith a bitcoin address is. However, the DOS risk can be solved more complete=
ly 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 t=
heir public key hidden behind hashes (as normal in addresses). Only when so=
meone does in fact mint a block do they reveal their hidden public key in o=
rder to prove they are allowed to mint the block.
> > This is true, but you are mixing quorum and non-quorum systems. My obje=
ction here was towards such system where I specifically said that the list =
of producers for next epoch is known up front and you confirmed that this i=
s what you meant with "quorum" system. So in such system, I claimed, the kn=
own producer is the only target at any given point of time. This of course =
does not apply to any other type of system where future producers are not k=
nown. No need to dispute, again, something that was not claimed.
> >
> > > I agree that introduction of punishment itself does not imply introdu=
cing a problem elsewhere (which I did not claim if you reread my previous m=
essage)
> >
> > 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 introduce=
d 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 spec=
ific attack is not doable, but you should not omit to mention that by doing=
 so, typically, you have introduced another problem elsewhere, or you have =
not solved it completely."
> > You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT COMP=
LETELY)
> > In case of the punishment it was meant to be the not solve it completel=
y 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 that P=
oS 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 do=
es 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. But w=
e don't live in that closed system. Minters will earn some ROI from minting=
 just like any other financial activity. Others may find more success spend=
ing their time doing things other than figuring out how to mint coins. In t=
hat 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 w=
ith all existing coins participating is just theoretical, the attacker's po=
sition will ever so improve. It seems we are in agreement here, great.
> >
> > > Just because of the above we must reject PoS as being critically inse=
cure
> >
> > I think the only thing we can conclude from this is that you have come =
up with an insecure proof of stake protocol. I don't see how anything you'v=
e brought up amounts to substantial evidence that all possible PoS protocol=
s are insecure.
> > I have not come up with anything. I'm afraid you've not realized the bu=
rden of proof is on your side if you vouch for a design that is not believe=
d and trusted to be secure. It is up to you to show that you know how to so=
lve every problem that people throw at you. So far we have just demonstrate=
d 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 DDO=
S attack vector as it is in quorum based systems - per the prior definition=
 of such systems).
> > Of course the list of problems of PoS systems do not end with just noth=
ing at stake, but it is good enough example that by itself prevents its ado=
ption in decentralized consensus. No need to go to other hard problems with=
out solving nothing at stake.
> > On Tue, May 25, 2021 at 11:10 AM befreeandopen befreeandopen@protonmail=
.com wrote:
> >
> > > @befreeandopen " An attacker can calculate whether or not she can pro=
long this chain or not and if so with what timestamp."
> > > The scenario you describe would only be likely to happen at all if th=
e malicious actor has a very large fraction of the stake - probably quite c=
lose to 50%. At that point, you're talking about a 51% attack, not the noth=
ing at stake problem. The nothing at stake problem is the problem where any=
one will mint on any chain. Its clear that if there's a substantial punishm=
ent for minting on chains other than the one that eventually wins, every mi=
nter without a significant fraction of the stake will be honest and not att=
empt 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 attacker =
would need probably >45% of the active stake (take a look at the reasoning =
here for a deeper analysis of that statement), I don't agree that punishmen=
t is not a sufficient mitigation of the nothing at stake problem. To exploi=
t the nothing at stake problem, you basically need to 51% attack, at which =
point you've exceeded the operating conditions of the system, so of course =
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 describe=
d technique at any size of the stake and significantly so with just 5% of t=
he stake. By significantly, I do not mean that the attacker is able to comp=
letely take control the network (in short term), but rather that the attack=
er has significant advantage in the number of blocks she creates compared t=
o what she "should be able to create". This means the attacker's stake incr=
eases 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 that,=
 you need to redo your math. So no, you are wrong stating that "to exploit =
nothing at stake problem you basically need to 51% attack". It is rather th=
e opposite - eventually, nothing at stake attack leads to ability to perfor=
m 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 po=
werful DDOS in order to hurt liveness of such system
> > >
> > > Just like in bitcoin, associating keys with IP addresses isn't genera=
lly an easy thing to do on the fly like that. If you know someone's IP addr=
ess, 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 the=
ir public key and address, but finding out their IP to DOS would be a huge =
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 technique a=
nd it is not trivial, but not very hard either. Introducing a large number =
of nodes to the system to achieve very good success rate of analysis of are=
a 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 abso=
lutely insecure.
> > > Note, tho, that quorum-based PoS generally also have punishments as p=
art of the protocol. The introduction of punishments do indeed handily solv=
e the nothing at stake problem. And you didn't mention a single problem tha=
t the punishments introduce that weren't already there before punishments. =
There are tradeoffs with introducing punishments (eg in some cases you migh=
t punish honest actors), but they are minor in comparison to solving the no=
thing at stake problem.
> > > While I agree that introduction of punishment itself does not imply i=
ntroducing a problem elsewhere (which I did not claim if you reread my prev=
ious message), it does introduce additional complexity which may introduce =
problem, but more importantly, while it slightly improves resistance agains=
t 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 be fa=
rther from the truth. It is not true even in optimal conditions when all pa=
rticipants of the network stake or delegate their stake. These optimal cond=
itions rarely, if ever, occur. And that's another thing that we have not me=
ntion in our debate, so please allow me to introduce another problem to PoS=
.
> > > Consider what is needed for such optimal conditions to occur - all co=
ins are always part of the stake, which means that they need to somehow aut=
omatically part of the staking process even when they are moved. But in man=
y PoS systems you usually require some age (in terms of confirmations) of t=
he coin before you allow it to be used for participation in staking process=
 and that is for a good reason - to prevent various grinding attacks. In so=
me systems the coin must be specifically registered before it can be staked=
, in others, simply waiting for enough confirmations enables you to stake w=
ith the coin. I am not sure if there is a system which does not have this c=
ooling 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 theor=
etical. Then if we do not have the optimal condition, it means that a stake=
r 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 that h=
ard) 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 all =
normal users who do not stake (if there are any) and relative to all other =
stakers who make mistakes or who are not wealthy enough to afford not selli=
ng 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 des=
cribed, and that you mistakenly think is viable only with huge amounts of s=
take, only puts the attacker to even greater advantage. But even without th=
e described attack (which exploits nothing at stake), the PoS system conver=
ges to a system more and more controlled by powerful entity, which we can a=
ssume is the attacker.
> > > So I don't think it is at all misleading to claim that "nothing at st=
ake" is a solved problem. I do in fact mean that the solutions to that prob=
lem don't introduce any other problems with anywhere near the same level of=
 significance.
> > > It still stands as truly misleading claim. I disagree that introducin=
g DDOS opportunity with medium level of difficulty for the attacker to impl=
ement 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 off th=
e network if you spend some time and money. That is hardly acceptable.
> > > Just because of the above we must reject PoS as being critically inse=
cure until someone invents and demonstrates an actual way of solving these =
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 f=
ocus all their burns on a particular set of 6 blocks to double spend, minim=
izing 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 proof=
 of
> > > > stake - simply because the "proof" is on-chain, not sitting on a no=
de
> > > > 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 short=
er, i can only choose one... deterministically
> > > > >
> > > > > What prevents you from attempting to mine block 553 on both chain=
s?
> > > > >
> > > > > > miners have a very strong, long-term, investment in the stabili=
ty 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 chain =
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 f=
ocus all their burns on a particular set of 6 blocks to double spend, minim=
izing 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 exam=
ple
> > > > >
> > > > > Are you talking about a 51% attack? This is possible in any decen=
tralized cryptocurrency.
> > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik@q32.com wrote=
:
> > > > >
> > > > > > > > your burn investment is always "at stake", any redaction ca=
n result in a loss-of-burn, because burns can be tied, precisely, to block-=
heights
> > > > > > > > I'm fuzzy on how proof of burn works.
> > > > > >
> > > > > > when you burn coins, you burn them to be used at a future parti=
cular
> > > > > > block height: so if i'm burning for block 553, i can only use t=
hem to
> > > > > > mine block 553. if i have a choice between two chains, one long=
er
> > > > > > and one shorter, i can only choose one... deterministically, fo=
r that
> > > > > > burn: the chain with the height 553. if we fix the "lead time" =
for
> > > > > > burned coins to be weeks or even months in advance, miners have=
 a very
> > > > > > strong, long-term, investment in the stability of the chain.
> > > > > > therefore there is no "nothing at stake" problem. it's
> > > > > > deterministic, so miners have no choice. they can only choose t=
he
> > > > > > transactions that go into the block. they cannot choose which c=
hain
> > > > > > to mine, and it's time-locked, so rollbacks and instability alw=
ays
> > > > > > hurt miners the most.
> > > > > > the "punishment" systems of PoS are "weird at best", certainly
> > > > > > unproven. i can imagine scenarios where large stakeholders can
> > > > > > collude to punish smaller stakeholders simply to drive them out=
 of
> > > > > > business, for example. and then you have to put checks in place=
 to
> > > > > > prevent that, and more checks for those prevention system...
> > > > > > in PoB, there is no complexity. simpler systems like this are
> > > > > > typically more secure.
> > > > > > PoB also solves problems caused by "energy dependence", which c=
ould
> > > > > > lead to state monopolies on mining (like the new Bitcoin Mining
> > > > > > Council). these consortiums, if state sanctioned, could become =
a
> > > > > > source of censorship, for example. Since PoB doesn't require yo=
u to
> > > > > > have a live, well-connected node, it's harder to censor & harde=
r to
> > > > > > trace.
> > > > > > Eliminating this weakness seems to be in the best interests of
> > > > > > existing stakeholders
> > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud billy.tetrud@gmail=
.com wrote:
> > > > > >
> > > > > > > > proof of burn clearly solves this, since nothing is held on=
line
> > > > > > >
> > > > > > > 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 online=
.
> > > > > > >
> > > > > > > > your burn investment is always "at stake", any redaction ca=
n result in a loss-of-burn, because burns can be tied, precisely, to block-=
heights
> > > > > > >
> > > > > > > So you're saying that if say someone tries to mine a block on=
 a shorter chain, that requires them to send a transaction burning their co=
ins, and that transaction could also be spent on the longest chain, which m=
eans 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 stake=
" problem. You can simply punish people who mint on shorter chains (by rewa=
rding people who publish proofs of this happening on the main chain). In qu=
orum-based PoS, you can punish people in the quorum that propose or sign mu=
ltiple blocks for the same height. The "nothing at stake" problem is a solv=
ed problem at this point for PoS.
> > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik@q32.com wr=
ote:
> > > > > > >
> > > > > > > > > I don't see a way to get around the conflicting requireme=
nt that the keys for large amounts of coins should be kept offline but thos=
e are exactly the coins we need online to make the scheme secure.
> > > > > > > >
> > > > > > > > proof of burn clearly solves this, since nothing is held on=
line
> > > > > > > >
> > > > > > > > > how does proof of burn solve the "nothing at stake" probl=
em in your view?
> > > > > > > >
> > > > > > > > definition of nothing at stake: in the event of a fork, whe=
ther 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 rew=
ard no
> > > > > > > > matter which fork wins. indeed in proof-of-stake, the proof=
s are
> > > > > > > > published on the very chains mines, so the incentive is mag=
nified.
> > > > > > > > in proof-of-burn, your burn investment is always "at stake"=
, any
> > > > > > > > redaction can result in a loss-of-burn, because burns can b=
e tied,
> > > > > > > > precisely, to block-heights
> > > > > > > > as a result, miners no longer have an incentive to mine all=
 chains
> > > > > > > > in this way proof of burn can be more secure than proof-of-=
stake, and
> > > > > > > > even more secure than proof of work
> > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-=
dev
> > > > > > > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > >
> > > > > > > > > Hi Billy,
> > > > > > > > > I was going to write a post which started by dismissing m=
any 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-S=
take is inappropriate for a Bitcoin-like system.
> > > > > > > > > Proof of stake is not fit for purpose for a global settle=
ment layer in a pure digital asset (i.e. "digital gold") which is what Bitc=
oin is trying to be.
> > > > > > > > > PoS necessarily gives responsibilities to the holders of =
coins that they do not want and cannot handle.
> > > > > > > > > In Bitcoin, large unsophisticated coin holders can put th=
eir coins in cold storage without a second thought given to the health of t=
he underlying ledger.
> > > > > > > > > As much as hardcore Bitcoiners try to convince them to ru=
n their own node, most don't, and that's perfectly acceptable.
> > > > > > > > > At no point do their personal decisions affect the underl=
ying consensus -- it only affects their personal security assurance (not th=
at of the system itself).
> > > > > > > > > In PoS systems this clean separation of responsibilities =
does not exist.
> > > > > > > > > I think that the more rigorously studied PoS protocols wi=
ll work fine within the security claims made in their papers.
> > > > > > > > > People who believe that these protocols are destined for =
catastrophic consensus failure are certainly in for a surprise.
> > > > > > > > > But the devil is in the detail.
> > > > > > > > > Let's look at what the implications of using the leading =
proof of stake protocols would have on Bitcoin:
> > > > > > > > >
> > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot)
> > > > > > > > >
> > > > > > > > > Cardano is a UTXO based PoS coin based on Ouroboros Praos=
3 with an inbuilt on-chain delegation system5.
> > > > > > > > > In these protocols, coin holders who do not want to run t=
heir node with their hot keys in it delegate it to a "Stake Pool".
> > > > > > > > > I call the resulting system Proof-of-SquareSpace since mo=
st will choose a pool by looking around for one with a nice website and off=
ering the largest share of the block reward.
> > > > > > > > > On the surface this might sound no different than someone=
 with an mining rig shopping around for a good mining pool but there are cr=
ucial differences:
> > > > > > > > >
> > > > > > > > > 1.  The person making the decision is forced into it just=
 because they own the currency -- someone with a mining rig has purchased i=
t with the intent to make profit by participating in consensus.
> > > > > > > > >
> > > > > > > > > 2.  When you join a mining pool your systems are very muc=
h still online. You are just partaking in a pool to reduce your profit vari=
ance. You still see every block that you help create and you never help cre=
ate a block without seeing it first.
> > > > > > > > >
> > > > > > > > > 3.  If by SquareSpace sybil attack you gain a dishonest m=
ajority and start censoring transactions how are the users meant to redeleg=
ate their stake to honest pools?
> > > > > > > > >     I guess they can just send a transaction delegating t=
o another pool...oh wait I guess that might be censored too! This seems rea=
lly 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 dish=
onest majority heals relatively well.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > There is another severe disadvantage to this on-chain del=
egation system: every UTXO must indicate which staking account this UTXO be=
longs to so the appropriate share of block rewards can be transferred there=
.
> > > > > > > > > Being able to associate every UTXO to an account ruins on=
e 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 par=
ticipate 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 hold=
ing keys online so in Alogorand you can authorize a set of "participation k=
eys"1 that will be used to create blocks on your coin holding key's behalf.
> > > > > > > > > Hopefully you've spotted the problem.
> > > > > > > > > You can send your participation keys to any malicious par=
ty 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 ke=
ys expire after a certain amount of time so eventually the SquareSpace atta=
cker will lose their hold on consensus.
> > > > > > > > > Importantly there is also less junk on the blockchain bec=
ause the participation keys are delegated off-chain and so are not making a=
s much of a mess.
> > > > > > > > >
> > > > > > > > > ### Conclusion
> > > > > > > > >
> > > > > > > > > I don't see a way to get around the conflicting requireme=
nt that the keys for large amounts of coins should be kept offline but thos=
e are exactly the coins we need online to make the scheme secure.
> > > > > > > > > If we allow delegation then we open up a new social attac=
k surface and it degenerates to Proof-of-SquareSpace.
> > > > > > > > > For a "digital gold" like system like Bitcoin we optimize=
 for simplicity and desperately want to avoid extraneous responsibilities f=
or the holder of the coin.
> > > > > > > > > After all, gold is an inert element on the periodic table=
 that doesn't confer responsibilities on the holder to maintain the quality=
 of all the other bars of gold out there.
> > > > > > > > > Bitcoin feels like this too and in many ways is more iner=
t and beautifully boring than gold.
> > > > > > > > > For Bitcoin to succeed I think we need to keep it that wa=
y and Proof-of-Stake makes everything a bit too exciting.
> > > > > > > > > I suppose in the end the market will decide what is real =
digital gold and whether these bad technical trade offs are worth being abl=
e to say it uses less electricity. It goes without saying that making bad t=
echnical decisions to appease the current political climate is an anathema =
to Bitcoin.
> > > > > > > > > Would be interested to know if you or others think differ=
ently on these points.
> > > > > > > > > Cheers,
> > > > > > > > > LL
> > > > > > > > > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-de=
v bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > >
> > > > > > > > > > I think there is a lot of misinformation and bias again=
st Proof of Stake. Yes there have been lots of shady coins that use insecur=
e PoS mechanisms. Yes there have been massive issues with distribution of P=
oS coins (of course there have also been massive issues with PoW coins as w=
ell). However, I want to remind everyone that there is a difference between=
 "proved to be impossible" and "have not achieved recognized success yet". =
Most of the arguments levied against PoS are out of date or rely on unprove=
n assumptions or extrapolation from the analysis of a particular PoS system=
. I certainly don't think we should experiment with bitcoin by switching to=
 PoS, but from my research, it seems very likely that there is a proof of s=
take consensus protocol we could build that has substantially higher securi=
ty (cost / capital required to execute an attack) while at the same time co=
sting far less resources (which do translate to fees on the network) withou=
t compromising any of the critical security properties bitcoin relies on. I=
 think the critical piece of this is the disagreements around hardcoded che=
ckpoints, 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 th=
at 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 subs=
tantially greater as well if the attack is successful.
> > > > > > > > > > -   The effectiveness of paying miners to raise the hon=
est fraction of miners above 50% may be quite bad.
> > > > > > > > > > -   Allowing a 51% attack is already unacceptable. It s=
hould be considered whether what happens in the case of a 51% may not be si=
gnificantly 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. T=
here is no centralization pressure in any proof of stake mechanism that I'm=
 aware of. IE if you have 10 times as much coin that you use to mint blocks=
, you should expect to earn 10x as much minting revenue - not more than 10x=
. By contrast, proof of work does in fact have clear centralization pressur=
e - this is not disputed. Our goal in relation to that is to ensure that th=
e centralization pressure remains insignifiant. Proof of work also clearly =
has a lot more barriers to entry than any proof of stake system does. Both =
of these mean the tendency towards oligopolistic control is worse for PoW.
> > > > > > > > > >
> > > > > > > > > > > Energy usage, in-and-of-itself, is nothing to be asha=
med of!!
> > > > > > > > > >
> > > > > > > > > > I certainly agree. Bitcoin's energy usage at the moment=
 is I think quite warranted. However, the question is: can we do substantia=
lly 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 resilient =
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 requ=
irement. However there are PoS designs that should exceed that up to nearly=
 50% as far as I'm aware. Proof of work is not in fact resilient up to the =
1/2 threshold in the way you would think. IE, if 100% of miners are current=
ly honest and have a collective 100 exahashes/s hashpower, an attacker does=
 not need to obtain 100 exahashes/s, but actually only needs to accumulate =
50 exahashes/s. This is because as the attacker accumulates hashpower, it d=
rives honest miners out of the market as the difficulty increases to beyond=
 what is economically sustainable. Also, its been shown that the best proof=
 of work can do is require an attacker to obtain 33% of the hashpower becau=
se of the selfish mining attack discussed in depth in this paper: https://a=
rxiv.org/abs/1311.0243. Together, both of these things reduce PoW's securit=
y by a factor of about 83% (1 - 50%*33%).
> > > > > > > > > >
> > > > > > > > > > > Proof of Stake requires other trade-offs which are in=
compatible 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 thin=
k proof of stake cannot be used for a trustless digital cash?
> > > > > > > > > >
> > > > > > > > > > > You cannot gain tokens without someone choosing to gi=
ve up those coins - a form of permission.
> > > > > > > > > >
> > > > > > > > > > This is not a practical constraint. Just like in mining=
, some nodes may reject you, but there will likely be more that will accept=
 you, some sellers may reject you, but most would accept your money as paym=
ent for bitcoins. I don't think requiring the "permission" of one of millio=
ns of people in the market can be reasonably considered a "permissioned cur=
rency".
> > > > > > > > > >
> > > > > > > > > > > 2.  Proof of stake must have a trusted means of times=
tamping to regulate overproduction of blocks
> > > > > > > > > >
> > > > > > > > > > Both PoW and PoS could mine/mint blocks twice as fast i=
f everyone agreed to double their clock speeds. Both systems rely on an hon=
est majority sticking to standard time.
> > > > > > > > > > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via b=
itcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > >
> > > > > > > > > > > Ah sorry, I didn't realize this was, in fact, a diffe=
rent thread! :)
> > > > > > > > > > > On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky mi=
ke@powx.org wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Folks, I suggest we keep the discussion to PoW, oPo=
W, and the BIP itself. PoS, VDFs, and so on are interesting but I guess the=
re are other threads going on these topics already where they would be rele=
vant.
> > > > > > > > > > > > Also, it's important to distinguish between oPoW an=
d these other "alternatives" to Hashcash. oPoW is a true Proof of Work that=
 doesn't alter the core game theory or security assumptions of Hashcash and=
 actually contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
> > > > > > > > > > > > Cheers,
> > > > > > > > > > > > Mike
> > > > > > > > > > > > On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via b=
itcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > 1.  i never suggested vdf's to replace pow.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 2.  my suggestion was specifically in the context=
 of a working
> > > > > > > > > > > > >     proof-of-burn protocol
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > -   vdfs used only for timing (not block height)
> > > > > > > > > > > > > -   blind-burned coins of a specific age used to =
replace proof of work
> > > > > > > > > > > > > -   the required "work" per block would simply be=
 a competition to
> > > > > > > > > > > > >     acquire rewards, and so miners would have to =
burn coins, well in
> > > > > > > > > > > > >     advance, and hope that their burned coins got=
 rewarded in some far
> > > > > > > > > > > > >     future
> > > > > > > > > > > > >
> > > > > > > > > > > > > -   the point of burned coins is to mimic, in eve=
ry meaningful way, the
> > > > > > > > > > > > >     value gained from proof of work... without so=
me of the security
> > > > > > > > > > > > >     drawbacks
> > > > > > > > > > > > >
> > > > > > > > > > > > > -   the miner risks losing all of his burned coin=
s (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 t=
o properly mirror the
> > > > > > > > > > > > >     properties of PoW and the incentives Bitcoin =
uses to mine honestly.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 3.  i do believe it is possible that a "burned co=
in + vdf system"
> > > > > > > > > > > > >     might be more secure in the long run, and tha=
t 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 b=
elieved 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 za=
chgrw@gmail.com wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi ZmnSCPxj,
> > > > > > > > > > > > > > Please note that I am not suggesting VDFs as a =
means to save energy, but solely as a means to make the time between blocks=
 more constant.
> > > > > > > > > > > > > > Zac
> > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPxj ZmnSCPxj=
@protonmail.com wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Good morning Zac,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > VDFs might enable more constant block times=
, for instance by having a two-step PoW:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1.  Use a VDF that takes say 9 minutes to r=
esolve (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 di=
fficulty so finding a block takes 1 minute on average, again subject to as-=
is difficulty adjustments.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > As a result, variation in block times will =
be greatly reduced.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > As I understand it, another weakness of VDFs =
is that they are not inherently progress-free (their sequential nature prev=
ents that; they are inherently progress-requiring).
> > > > > > > > > > > > > > > Thus, a miner which focuses on improving the =
amount of energy that it can pump into the VDF circuitry (by overclocking a=
nd freezing the circuitry), could potentially get into a winner-takes-all s=
ituation, possibly leading to even worse competition and even more energy c=
onsumption.
> > > > > > > > > > > > > > > After all, if you can start mining 0.1s faste=
r 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/listinf=
o/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/bi=
tcoin-dev
> > > > > > > > > >
> > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev
> > > > > > > > >
> > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev