path: root/20/bff8fc3ec67f024673c1161f9e16ee3ac0b6e1

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8824CC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Jun 2021 20:29:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 7A5BD607B7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Jun 2021 20:29:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level: 
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vPR---oV4VLz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Jun 2021 20:28:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com
 [IPv6:2607:f8b0:4864:20::52d])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 0AC5F60794
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Jun 2021 20:28:58 +0000 (UTC)
Received: by mail-pg1-x52d.google.com with SMTP id r1so308898pgk.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 01 Jun 2021 13:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=QkigGyJ4AJmu0YbcDv/zS8qkePsW9jyDRHBwtiQnflI=;
 b=wzKSHyOYaPUjk4QaqpSMvqyCD2rZgUY3Zimv0wBg3hfZYfAW69QL8RYTOm0RI9SX/m
 Vu0zBBK7MNhfyIMBci7Cv3fxu3iiozHrAjdQSXPWV2XPk5rbeGeYmt2mUbhD3dtvQAH6
 IOC5E0gC72MaliJtIZ3jUJE8qgfKA3hh7KB3WppqrhVSZk88VMPEmRGSDKt/UUIRy7qq
 shg8eDx9rM1IjBWUiS3YF4ACo+PR+Yp86Hj3btJQzFvUfGvrR9xQkfTKGKrBoWftly1k
 skhBZHHtv/Xp5IlvkuZxQ/lBvhJDGnLMoG9kXTZv10hbysJ6zz+g3FTO9ar4zazwdn6X
 qxXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=QkigGyJ4AJmu0YbcDv/zS8qkePsW9jyDRHBwtiQnflI=;
 b=F6CJCgYZRYw+U4q+W+fIh9hcUCHR5GDaVAKBqnf2tIxaXHxPMuaNrdq+soOxLqmd7g
 mCQRdDaDW3C1cD7FHq4Q3boII73WICSx6oS64mv1/ZwVmaKNPVDFgC0a7mtMmoACldn7
 KRpGTE0uVaH3FBBBho8ZeWJl5fwoZMuUes5CtXQampS9FtJ1HBdW2KY/N1ZpYcH/Z0Cz
 KZwQxSt85DWjM+SHe9280D/x/KIgDxx4XZjl+Mq5K+9MxAZZUHahcj1dWrnRd3edOzPc
 aE2G8Q5riRS3GGQidWfE2HDmDaMFRA9ORbmLU6/6A6CPxnVnpo2qwIZEfbHExab0GBkV
 IipA==
X-Gm-Message-State: AOAM531AMp2bZCGguuFTShspK+yWa5SvBn22ViwV2RXgUUjUDEj9qTzi
 W6G6mYIjgeB5sHXXHqcqNnF8NTDbMaQ7AweWQz15L28=
X-Google-Smtp-Source: ABdhPJwFVuRd+RtRyJHK9P+QI5lSF/h3s2xvTQSPLB5rNNSk2H1kb1wALac8++GoSlMQj3/1jdYn9kougo8ec/f04tk=
X-Received: by 2002:a63:f154:: with SMTP id o20mr4008381pgk.53.1622579336908; 
 Tue, 01 Jun 2021 13:28:56 -0700 (PDT)
MIME-Version: 1.0
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.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>
 <EdKK1tb2px2G--ianlCQpRjsn7vdXkSr60sV18NpVw-uVuKSA-ag9xXch_rYDkhtaJTH36zDMuVGZyYrKagMNNw_0OrLF8QsPiuo-YIxTaE=@protonmail.com>
 <CAJowKgK+i6WDXQcXnEEt+Y7Bq3vr64cTkSvPjraYiYhNRkBP1w@mail.gmail.com>
 <RgxuE0JLcjQQOuVPxCGdSy-GU4oZx3kmuErGtUCM27rhHKLc47kO7A4M0VQBxc8fj3Y026J7PC4wU0onWlm4tgKycTZTFAN_8PQX3-Tl0j4=@protonmail.com>
In-Reply-To: <RgxuE0JLcjQQOuVPxCGdSy-GU4oZx3kmuErGtUCM27rhHKLc47kO7A4M0VQBxc8fj3Y026J7PC4wU0onWlm4tgKycTZTFAN_8PQX3-Tl0j4=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 1 Jun 2021 16:28:45 -0400
Message-ID: <CAJowKgK7nCkog7+b4-b6mGrNzPye0ch2Y+o_mph2zeVN2MaxSQ@mail.gmail.com>
To: befreeandopen <befreeandopen@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 01 Jun 2021 22:05:19 +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 20:29:02 -0000

>  the classical debate with PoS supporters - I explain an attack and they =
"patch it", creating problem elsewhere

i agree.   my original post was:

"assume that we can accurately mimic the investment in ASIC's and the
expenditure of electricity with "burns" of coin representing that
investment"

only given that assumption can i state with confidence:

- proof of burn is better than proof of stake

and only because

- your stake is sitting on a node somewhere, able to be stolen

everything else is speculation about my original assumption.

overall a good PoB would have a

- large, up front buy-in event (buying the ASIC)
- delay function (timing)
- block-specific burn (electricity use... lost if burn is not selected)
- burns linked to specific buy-ins (can only burn the ASIC's i bought in)
- max-burn =3D=3D=3D max-buy-in (ASICs have capacity)
- max-burn decays over time (ASIC's become less valuable over time)

block-height =3D=3D=3D sum of block-specific burn

On Tue, Jun 1, 2021 at 3:26 PM befreeandopen
<befreeandopen@protonmail.com> wrote:
>
> Comments inline.
>
>
>
> > > Could you explain what am I missing here, because this actually does =
not seem better, but rather worse than some PoS schemes?
> >
> > Given your example, if !BTC is needed to burn, that's a $50k
> > investment in an ASIC needed to mine a block. That's not anywhere
> > near current levels. It's not even approaching the current PoW. A
> > $50k investment to be a large amount of hash power is ... well,
> > somewhere more than 10 years ago.
>
> This is +- true with todays prices, that was not my point. We all know th=
at today's total block revenue is nowhere near 1 BTC. If it is say 7 BTC, t=
hen we would expect that the miners spend roughly just about 7 BTC to produ=
ce the block - in long term, on average. Right? Today, this 7 BTC is suppos=
ed to be some average of investment into the mining rig, the building in wh=
ich the rig exists (or its rent) and then some electricity. So when I said =
1 BTC I meant that amount of BTC that is the sum of the block subsidy and f=
ees at the time of this imagined switch to PoB. Use 7 BTC if you want to ta=
lk today. And yes, that seems very weak. But can you explain why it is not =
the case after switching to PoB that the cost of producing the block should=
 roughly converge to to the revenue? Because I do not see why would miners =
spend more than what they can earn.
>
>
>
>
>
> > My original proof-of-burn concept was designed to mimic ASICs as much
> > as possible:
> >
> > 1.  large initial investment (burn to acquire power)
> > 2.  continued investment (burn to activate power in each block, lost if
> >     block is not found)
> >
> >     Ideally, the attacker would have to keep burning for each lottery
> >     ticket, which can only be used once. Committing that burn to a
> >     particular block for example.
> >
> >     Any attack you propose for a "assumed well designed PoB" can also a=
ttack PoW.
> >     Any attack you propose for a "assumed well designed PoB" can also a=
ttack PoS.
> >
> >     But there are some things PoB can do that PoS can't... which is rea=
lly
> >     my original point.
>
> This is the problem that I wanted to avoid. You refer to some "my origina=
l PoB", but I am strictly talking about the concept described in wiki becau=
se nothing else was provided to me. If we do not have a reference descripti=
on of what you are talking about the debate will quickly turn into the clas=
sical debate with PoS supporters - I explain an attack and they "patch it",=
 creating problem elsewhere. Then I explain an attack against that and they=
 patch it there. And this goes infinitely.
>
> So if there is some other version, better one than the one described in w=
iki, please let me know. If there is not, there is nothing to talk about re=
ally. You'd first need to define your model properly and describe very deta=
ils of how it should work and then we can analyze it. It does not make much=
 sense to me to analyze a ghost protocol that I always only see a tiny part=
 of.
>
> For example here above in the quoted text you mention some continual lost=
 (if block is not found). If that is not the exponential decay as described=
 in the wiki, then I have no idea what it is. I do not say that I can't ima=
gine for myself what it could be, but it is up to you to define it, so we c=
an be sure we are talking about the same thing.
>
> Same with those early unblinding of burns - nothing about that in the wik=
i, so that concept is alien to me and it can not be subject to a debate bef=
ore it is precisely described.
>
>
>
>
> >
> >
> > -   sunk costs/lost investment
> > -   "hashpower" is "offline", and cannot be seized.
> >
> >     On Tue, Jun 1, 2021 at 4:21 AM befreeandopen
> >     befreeandopen@protonmail.com wrote:
> >
> >
> > > 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 better over many proof of stake proposals. If there is more research o=
n PoB, please note I'm not commenting on that as I only read this wiki arti=
cle and my comments are purely related to this only.
> > > I hope we can agree that the idea with manual insertion of entropy ev=
ery week can be discarded, but at the same time I don't think it is a cruci=
al point 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 implementa=
tions with just small differences, which I try to summarize:
> > >
> > > -   in PoB, in order to use the coin for block production, you burn i=
t in the past and wait some time -- in the certain PoS I'm talking about, i=
n order to use the coin, you do not move the coin for some time - so in bot=
h there is the same idea - you somehow make the coin eligible for the block=
 creation process by first doing some action followed by some inaction for =
some time; the difference here is that if later you use such coin in PoS, t=
hen after waiting more time, you can use the coin again (for whatever purpo=
se), while in PoB the coin is gone forever (it is burned); this does not se=
em 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 historicall=
y was an era of so called CoinAge mechanism, which was somewhat inverse to =
this exponential decay, it was that the coin gets more power the older it i=
s untouched, some implementations were for linear increase in the power, so=
me exponential. Usually there was a certain limit - i.e. a maximum power th=
e coin may have reached. It turned out quite quickly that such property is =
making attacks easier. PoB reverses the idea, but I don't think that helps =
that much. In any case, there seems to be an optimal period of time for eac=
h used coin, in both PoS and PoB, where the coin is most suitable for block=
 production. I admit PoB version is better, but the crucial property here i=
s that some coins are more powerful than other.
> > >
> > > -   in both PoB and PoS it seems there is linear increase of the abil=
ity of the coin to produce blocks with the size of the coin (more BTC you b=
urn/stake, the better your chance)
> > >
> > >
> > > This characteristic of PoB does not suggest that it would have that m=
uch different properties than PoS. So it should suffer from same problems a=
s PoS. Namely, the problems I see now, with the given proposal from wiki, a=
re:
> > >
> > > -   there seems to be lack of definition of the heaviest chain and di=
fficulty adjustment - this seems crucial, but likely solvable, I'm just say=
ing it is importantly missing in the description
> > >
> > > -   there seems to be a problem with nothing at stake (nothing at bur=
n 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 fr=
ee checks 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 u=
se those burned coins to create arbitrary number of forks build on any pare=
nt blocks of your choice, not just the last block of the heaviest chain. I =
can't see at the moment how is this different from PoS nothing at stake pro=
blem. Maybe you can explain?
> > >
> > > -   it seems to me that there is a trivial attack against the scheme =
by a wealthy attacker. Suppose a common size of the burn is 1 BTC per block=
, suppose you define the heaviest chain rule somehow in relation to total n=
umber 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 2=
00 BTC on this attack, but you are in very strong position because after yo=
u wait the needed time, you should be able to do pretty nasty reorg. Suppos=
e that the 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 you have big UTXOs, your chances should be good, of course you can a=
lways try many times because you have a "lottery ticket" for every timestam=
pt t. So with this you should be able, with good chance, to find such B' an=
d then you have 19 UTXOs remaining to try to build on B' in the same way. I=
 can't see 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 (d=
ue to nothing 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 seem 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 Origi=
nal Message =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 qu=
ite strong to me and I'd like to read more.
> > > > > Forgive me if this has been mentioned recently, but is there a fu=
ll specification 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=
 proposal or technical documentation that would give me a precise informati=
on about what exactly it is that you are talking about.
> > > > > Sent with ProtonMail Secure Email.
> > > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 O=
riginal 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 w=
rote:
> > > > >
> > > > > > 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 a=
ttack. Let me make sure I understand it. You're saying it would go as follo=
ws?:
> > > > > > >
> > > > > > > 1.  The malicious actor comes across an opportunity to mint t=
he 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 future than minting on the top block. And instead lets the top block p=
roceed if it gives them more blocks in the future (also figuring in the 3 b=
locks 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 bloc=
ks will affect their future prospects of minting. Otherwise this would intr=
oduce the problem of stake grinding. This can be done using collaborative r=
andomness (where numbers from many parties are combined to create a random =
number that no individual party could predict). In fact, that's what the Ca=
sper protocol does to decide quorums. In a non quorum case, you can do some=
thing like record a hash of a number in the block header, and then have a s=
econd step to release that number later. Rewards can be given can be used t=
o ensure minters act honestly here by minting messages that release these n=
umbers and not releasing their secret numbers too early.
> > > > > > > Yes, you misunderstood it. First, let me say that the above t=
houghts of yours are incorrect, at least for non-quorum case. Since the tra=
nsition 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 next block, it follows that if a staker creates a new block locall=
y, she can decide whether the new state allows her to add another block on =
top. As you mentioned, this COULD introduce problem of staking, that you ar=
e incorrect in that it is a necessity. Usual prevention of the grinding pro=
blem in this case is that an "old enough" source of randomness applies for =
the current block production process. Of course this, as it is typical for =
PoS, introduces 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 com=
mon feature of PoS system (non-quorum), roughly speaking, is that if N is t=
he total 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 other 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 has 1 coin.
> > > > > > > What i was claiming is that using the technique I have descri=
bed, this linearity is violated. Why? Well, it works for honest stakers amo=
ng the competition of honest stakers - they really do have the chance of K =
to find the next block. However, the attacker, using nothing at stake, chec=
ks her ability to build block D (at some timestamp). If she is successful, =
she does not propagate D immediately, but instead she also checks whether s=
he can build on top of B and on top of A. Since with every new timestamp, u=
sually, there is a new chance to build the block, it is not uncommon that s=
he finds she is indeed able to build such block C' on top of B. Here it is =
likely t(C') > t(C) as the attacker has relatively low stake. Note that in =
order to produce such C', she not only could have tried the current timesta=
mp t(D), but also all previous timestamps up to t(B) (usually that's the co=
nsensus rule, but it may depend on a specific consensus). So her chance to =
produce such C' is greater than her previous chance of producing C (which c=
hance 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 continue=
s by trying to prolong this chain by finding D'. And again here, it is quit=
e likely that her chance to find such D' is greater than was her chance of =
finding D because again there are likely multiple timestamps she could try.=
 This all was possible just because nothing at stake allows you to just try=
 if you can produce a block in certain state of block chain or not. Now if =
she actually 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 produc=
ed 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 gained an extra block over the honest strategy which would only give he=
r block D.
> > > > > > > Fun fact tho: there is an attack called the "selfish mining a=
ttack" 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 researc=
h 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 as=
sociated with a bitcoin address is. However, the DOS risk can be solved mor=
e completely 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). On=
ly when someone does in fact mint a block do they reveal their hidden publi=
c key in order to prove they are allowed to mint the block.
> > > > > > > This is true, but you are mixing quorum and non-quorum system=
s. My objection here was towards such system where I specifically said that=
 the list of producers for next epoch is known up front and you confirmed t=
hat this is what you meant with "quorum" system. So in such system, I claim=
ed, the known 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 known. No need to dispute, again, something that was not claimed.
> > > > > > >
> > > > > > > > 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)
> > > > > > >
> > > > > > > I'm glad we agree there. Perhaps I misunderstood what you mea=
nt by "you should not omit to mention that by doing so, typically, you have=
 introduced another problem elsewhere."
> > > > > > > Perhaps you should quote the full sentence and not just a par=
t of it:
> > > > > > > "Of course you can always change the rules in a way that a ce=
rtain specific attack is not doable, but you should not omit to mention tha=
t 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 SOL=
VE IT COMPLETELY)
> > > > > > > In case of the punishment it was meant to be the not solve it=
 completely 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 cla=
ims that PoS is a reasonable alternative to PoW, let's stick to that.
> > > > > > >
> > > > > > > > As long as the staker makes sure (which is not that hard) t=
hat she does not miss a chance to create a block, her significance in the s=
ystem 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, s=
ure. But we don't live in that closed system. Minters will earn some ROI fr=
om minting just like any other financial activity. Others may find more suc=
cess spending their time doing things other than figuring out how to mint c=
oins. In that case, they'll be able to earn more coin that they could later=
 decide to use to mint blocks if they decide to.
> > > > > > > This only supports the point I was making. Since the optimal =
scenario with all existing coins participating is just theoretical, the att=
acker's position will ever so improve. It seems we are in agreement here, g=
reat.
> > > > > > >
> > > > > > > > Just because of the above we must reject PoS as being criti=
cally insecure
> > > > > > >
> > > > > > > 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 anyt=
hing you've brought up amounts to substantial evidence that all possible Po=
S protocols are insecure.
> > > > > > > I have not come up with anything. I'm afraid you've not reali=
zed the burden of proof is on your side if you vouch for a design that is n=
ot believed and trusted to be secure. It is up to you to show that you know=
 how to solve every problem that people throw at you. So far we have just d=
emonstrated that your claim that nothing at stake is solved was unjustified=
. You have not described a system that would solve it (and not introduce cr=
itical DDOS 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 nothing at stake, but it is good enough example that by itself preven=
ts its adoption in decentralized consensus. No need to go to other hard pro=
blems without 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 s=
he can prolong this chain or not and if so with what timestamp."
> > > > > > > > The scenario you describe would only be likely to happen at=
 all if the malicious actor has a very large fraction of the stake - probab=
ly quite close to 50%. At that point, you're talking about a 51% attack, no=
t 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 substanti=
al punishment for minting on chains other than the one that eventually wins=
, every minter without a significant fraction of the stake will be honest a=
nd not attempt to mint on old blocks or support someone else's attempt to m=
int 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=
 punishment is not a sufficient mitigation of the nothing at stake problem.=
 To exploit 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 th=
e described technique at any size of the stake and significantly so with ju=
st 5% of the stake. By significantly, I do not mean that the attacker is ab=
le to completely take control the network (in short term), but rather that =
the attacker has significant advantage in the number of blocks she creates =
compared to what she "should be able to create". This means the attacker's =
stake increases significantly faster than of the honest nodes, which in lon=
g 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 "t=
o exploit nothing at stake problem you basically need to 51% attack". It is=
 rather the opposite - eventually, nothing at stake attack leads to ability=
 to perform 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 poi=
nt with powerful DDOS in order to hurt liveness of such system
> > > > > > > >
> > > > > > > > Just like in bitcoin, associating keys with IP addresses is=
n't generally 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 p=
ublic key, the reverse isn't as easy. With a quorum-based PoS system, you c=
an see their 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 p=
roblem is not as hard as you think. The network graph analysis is a known t=
echnique and it is not trivial, but not very hard either. Introducing a lar=
ge number of nodes to the system to achieve very good success rate of analy=
sis of area of origin of blocks is doable and has been done in past. So aga=
in, 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 punish=
ments as part of the protocol. The introduction of punishments do indeed ha=
ndily solve the nothing at stake problem. And you didn't mention a single p=
roblem that the punishments introduce that weren't already there before pun=
ishments. There are tradeoffs with introducing punishments (eg in some case=
s you might punish honest actors), but they are minor in comparison to solv=
ing the nothing at stake problem.
> > > > > > > > While I agree that introduction of punishment itself does n=
ot imply introducing a problem elsewhere (which I did not claim if you rere=
ad my previous message), it does introduce additional complexity which may =
introduce problem, but more importantly, while it slightly improves resista=
nce against 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 farther from the truth. It is not true even in optimal conditions w=
hen all participants of the network stake or delegate their stake. These op=
timal conditions rarely, if ever, occur. And that's another thing that we h=
ave not mention in our debate, so please allow me to introduce another prob=
lem to PoS.
> > > > > > > > Consider what is needed for such optimal conditions to occu=
r - all coins are always part of the stake, which means that they need to s=
omehow automatically part of the staking process even when they are moved. =
But in many PoS systems you usually require some age (in terms of confirmat=
ions) of the coin before you allow it to be used for participation in staki=
ng process and that is for a good reason - to prevent various grinding atta=
cks. In some systems the coin must be specifically registered before it can=
 be staked, in others, simply waiting for enough confirmations enables you =
to stake with the coin. I am not sure if there is a system which does not h=
ave this cooling period for a coin that has been moved. Maybe it is possibl=
e though, but AFAIK it is not common and not battle tested feature.
> > > > > > > > Then if we admit that achieving the optimal condition is ra=
ther theoretical. Then if we do not have the optimal condition, it means th=
at a staker 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 hard) that she does not miss a chance to create a block, her signi=
ficance in the system will always increase in time. It will increase relati=
ve 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 selling any position ever. But powerful attacker is exactly in such po=
sition 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 am=
ounts of stake, only puts the attacker to even greater advantage. But even =
without the described attack (which exploits nothing at stake), the PoS sys=
tem converges to a system more and more controlled by powerful entity, whic=
h we can assume is the attacker.
> > > > > > > > So I don't think it is at all misleading to claim that "not=
hing at 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 sam=
e level of significance.
> > > > > > > > It still stands as truly misleading claim. I disagree that =
introducing DDOS opportunity with medium level of difficulty for the attack=
er 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 t=
urn off the network if you spend some time and money. That is hardly accept=
able.
> > > > > > > > Just because of the above we must reject PoS as being criti=
cally insecure until someone invents and demonstrates an actual way of solv=
ing 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 coul=
d simply focus all their burns on a particular set of 6 blocks to double sp=
end, minimizing 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 sitti=
ng on a node
> > > > > > > > > somewhere waiting to be stolen.
> > > > > > > > > On Mon, May 24, 2021 at 9:53 PM Billy Tetrud billy.tetrud=
@gmail.com wrote:
> > > > > > > > >
> > > > > > > > > > Is this the kind of proof of burn you're talking about?
> > > > > > > > > >
> > > > > > > > > > > if i have a choice between two chains, one longer and=
 one shorter, i can only choose one... deterministically
> > > > > > > > > >
> > > > > > > > > > What prevents you from attempting to mine block 553 on =
both chains?
> > > > > > > > > >
> > > > > > > > > > > miners have a very strong, long-term, investment in t=
he stability of the chain.
> > > > > > > > > >
> > > > > > > > > > Yes, but the same can be said of any coin, even ones th=
at 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 coul=
d simply focus all their burns on a particular set of 6 blocks to double sp=
end, minimizing 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 example
> > > > > > > > > >
> > > > > > > > > > Are you talking about a 51% attack? This is possible in=
 any decentralized cryptocurrency.
> > > > > > > > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty erik@q32=
.com wrote:
> > > > > > > > > >
> > > > > > > > > > > > > your burn investment is always "at stake", any re=
daction can result in a loss-of-burn, because burns can be tied, precisely,=
 to block-heights
> > > > > > > > > > > > > I'm fuzzy on how proof of burn works.
> > > > > > > > > > >
> > > > > > > > > > > when you burn coins, you burn them to be used at a fu=
ture particular
> > > > > > > > > > > block height: so if i'm burning for block 553, i can =
only use them to
> > > > > > > > > > > mine block 553. if i have a choice between two chains=
, one longer
> > > > > > > > > > > and one shorter, i can only choose one... determinist=
ically, for that
> > > > > > > > > > > burn: the chain with the height 553. if we fix the "l=
ead time" for
> > > > > > > > > > > burned coins to be weeks or even months in advance, m=
iners 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 onl=
y choose the
> > > > > > > > > > > transactions that go into the block. they cannot choo=
se which chain
> > > > > > > > > > > to mine, and it's time-locked, so rollbacks and insta=
bility always
> > > > > > > > > > > hurt miners the most.
> > > > > > > > > > > the "punishment" systems of PoS are "weird at best", =
certainly
> > > > > > > > > > > unproven. i can imagine scenarios where large stakeho=
lders can
> > > > > > > > > > > collude to punish smaller stakeholders simply to driv=
e them out of
> > > > > > > > > > > business, for example. and then you have to put check=
s in place to
> > > > > > > > > > > prevent that, and more checks for those prevention sy=
stem...
> > > > > > > > > > > in PoB, there is no complexity. simpler systems like =
this are
> > > > > > > > > > > typically more secure.
> > > > > > > > > > > PoB also solves problems caused by "energy dependence=
", which could
> > > > > > > > > > > lead to state monopolies on mining (like the new Bitc=
oin Mining
> > > > > > > > > > > Council). these consortiums, if state sanctioned, cou=
ld become a
> > > > > > > > > > > source of censorship, for example. Since PoB doesn't =
require you to
> > > > > > > > > > > have a live, well-connected node, it's harder to cens=
or & harder to
> > > > > > > > > > > trace.
> > > > > > > > > > > Eliminating this weakness seems to be in the best int=
erests of
> > > > > > > > > > > existing stakeholders
> > > > > > > > > > > On Mon, May 24, 2021 at 4:44 PM Billy Tetrud billy.te=
trud@gmail.com wrote:
> > > > > > > > > > >
> > > > > > > > > > > > > proof of burn clearly solves this, since nothing =
is held online
> > > > > > > > > > > >
> > > > > > > > > > > > Well.. the coins to be burned need to be online whe=
n 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 re=
daction can result in a loss-of-burn, because burns can be tied, precisely,=
 to block-heights
> > > > > > > > > > > >
> > > > > > > > > > > > So you're saying that if say someone tries to mine =
a block on a shorter chain, that requires them to send a transaction burnin=
g their coins, and that transaction could also be spent on the longest chai=
n, which means their coins are burned even if the chain they tried to mine =
on doesn't win? I'm fuzzy on how proof of burn works.
> > > > > > > > > > > >
> > > > > > > > > > > > > proof of burn can be more secure than proof-of-st=
ake
> > > > > > > > > > > >
> > > > > > > > > > > > FYI, proof of stake can be done without the "nothin=
g at stake" problem. You can simply punish people who mint on shorter chain=
s (by rewarding people who publish proofs of this happening on the main cha=
in). In quorum-based PoS, you can punish people in the quorum that propose =
or sign multiple blocks for the same height. The "nothing at stake" problem=
 is a solved problem at this point for PoS.
> > > > > > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik@=
q32.com wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > > I don't see a way to get around the conflicting=
 requirement that the keys for large amounts of coins should be kept offlin=
e but those are exactly the coins we need online to make the scheme secure.
> > > > > > > > > > > > >
> > > > > > > > > > > > > proof of burn clearly solves this, since nothing =
is held online
> > > > > > > > > > > > >
> > > > > > > > > > > > > > how does proof of burn solve the "nothing at st=
ake" problem in your view?
> > > > > > > > > > > > >
> > > > > > > > > > > > > definition of nothing at stake: in the event of a=
 fork, whether the
> > > > > > > > > > > > > fork is accidental or a malicious, the optimal st=
rategy for any miner
> > > > > > > > > > > > > is to mine on every chain, so that the miner gets=
 their reward no
> > > > > > > > > > > > > matter which fork wins. indeed in proof-of-stake,=
 the proofs are
> > > > > > > > > > > > > published on the very chains mines, so the incent=
ive is magnified.
> > > > > > > > > > > > > in proof-of-burn, your burn investment is always =
"at stake", any
> > > > > > > > > > > > > redaction can result in a loss-of-burn, because b=
urns can be tied,
> > > > > > > > > > > > > precisely, to block-heights
> > > > > > > > > > > > > as a result, miners no longer have an incentive t=
o 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 vi=
a bitcoin-dev
> > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Billy,
> > > > > > > > > > > > > > I was going to write a post which started by di=
smissing 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 glo=
bal settlement layer in a pure digital asset (i.e. "digital gold") which is=
 what Bitcoin is trying to be.
> > > > > > > > > > > > > > PoS necessarily gives responsibilities to the h=
olders of coins that they do not want and cannot handle.
> > > > > > > > > > > > > > In Bitcoin, large unsophisticated coin holders =
can put their coins in cold storage without a second thought given to the h=
ealth of the underlying ledger.
> > > > > > > > > > > > > > As much as hardcore Bitcoiners try to convince =
them to run their own node, most don't, and that's perfectly acceptable.
> > > > > > > > > > > > > > At no point do their personal decisions affect =
the underlying consensus -- it only affects their personal security assuran=
ce (not that of the system itself).
> > > > > > > > > > > > > > In PoS systems this clean separation of respons=
ibilities does not exist.
> > > > > > > > > > > > > > I think that the more rigorously studied PoS pr=
otocols will work fine within the security claims made in their papers.
> > > > > > > > > > > > > > People who believe that these protocols are des=
tined 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 th=
e leading proof of stake protocols would have on Bitcoin:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Cardano is a UTXO based PoS coin based on Ourob=
oros Praos3 with an inbuilt on-chain delegation system5.
> > > > > > > > > > > > > > In these protocols, coin holders who do not wan=
t to run their node with their hot keys in it delegate it to a "Stake Pool"=
.
> > > > > > > > > > > > > > I call the resulting system Proof-of-SquareSpac=
e since most will choose a pool by looking around for one with a nice websi=
te and offering the largest share of the block reward.
> > > > > > > > > > > > > > On the surface this might sound no different th=
an someone with an mining rig shopping around for a good mining pool but th=
ere are crucial differences:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1.  The person making the decision is forced in=
to it just because they own the currency -- someone with a mining rig has p=
urchased it with the intent to make profit by participating in consensus.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 2.  When you join a mining pool your systems ar=
e very much still online. You are just partaking in a pool to reduce your p=
rofit variance. You still see every block that you help create and you neve=
r help create a block without seeing it first.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 3.  If by SquareSpace sybil attack you gain a d=
ishonest majority and start censoring transactions how are the users meant =
to redelegate their stake to honest pools?
> > > > > > > > > > > > > >     I guess they can just send a transaction de=
legating to another pool...oh wait I guess that might be censored too! This=
 seems really really bad.
> > > > > > > > > > > > > >     In Bitcoin, miners can just join a differen=
t pool at a whim. There is nothing the attacker can do to stop them. A temp=
orary dishonest majority heals relatively well.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > There is another severe disadvantage to this on=
-chain delegation system: every UTXO must indicate which staking account th=
is UTXO belongs to so the appropriate share of block rewards can be transfe=
rred there.
> > > > > > > > > > > > > > Being able to associate every UTXO to an accoun=
t ruins one of the main privacy advantages of the UTXO model.
> > > > > > > > > > > > > > It also grows the size of the blockchain signif=
icantly.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ### "Pure" proof of stake (Algorand)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Algorand's4 approach is to only allow online st=
ake to participate in the protocol.
> > > > > > > > > > > > > > Theoretically, This means that keys holding fun=
ds have to be online in order for them to author blocks when they are chose=
n.
> > > > > > > > > > > > > > Of course in reality no one wants to keep their=
 coin holding keys online so in Alogorand you can authorize a set of "parti=
cipation keys"1 that will be used to create blocks on your coin holding key=
's behalf.
> > > > > > > > > > > > > > Hopefully you've spotted the problem.
> > > > > > > > > > > > > > You can send your participation keys to any mal=
icious party with a nice website (see random example 2) offering you a good=
 return.
> > > > > > > > > > > > > > Damn it's still Proof-of-SquareSpace!
> > > > > > > > > > > > > > The minor advantage is that at least the partic=
ipation keys expire after a certain amount of time so eventually the Square=
Space attacker will lose their hold on consensus.
> > > > > > > > > > > > > > Importantly there is also less junk on the bloc=
kchain because the participation keys are delegated off-chain and so are no=
t making as much of a mess.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ### Conclusion
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I don't see a way to get around the conflicting=
 requirement that the keys for large amounts of coins should be kept offlin=
e but those are exactly the coins we need online to make the scheme secure.
> > > > > > > > > > > > > > If we allow delegation then we open up a new so=
cial attack surface and it degenerates to Proof-of-SquareSpace.
> > > > > > > > > > > > > > For a "digital gold" like system like Bitcoin w=
e optimize for simplicity and desperately want to avoid extraneous responsi=
bilities for the holder of the coin.
> > > > > > > > > > > > > > After all, gold is an inert element on the peri=
odic table that doesn't confer responsibilities on the holder to maintain t=
he quality of all the other bars of gold out there.
> > > > > > > > > > > > > > Bitcoin feels like this too and in many ways is=
 more inert and beautifully boring than gold.
> > > > > > > > > > > > > > For Bitcoin to succeed I think we need to keep =
it that way and Proof-of-Stake makes everything a bit too exciting.
> > > > > > > > > > > > > > I suppose in the end the market will decide wha=
t is real digital gold and whether these bad technical trade offs are worth=
 being able to say it uses less electricity. It goes without saying that ma=
king bad technical decisions to appease the current political climate is an=
 anathema to Bitcoin.
> > > > > > > > > > > > > > Would be interested to know if you or others th=
ink differently on these points.
> > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > LL
> > > > > > > > > > > > > > On Fri, 21 May 2021 at 19:21, Billy Tetrud via =
bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think there is a lot of misinformation and =
bias against Proof of Stake. Yes there have been lots of shady coins that u=
se insecure PoS mechanisms. Yes there have been massive issues with distrib=
ution 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 differen=
ce between "proved to be impossible" and "have not achieved recognized succ=
ess yet". Most of the arguments levied against PoS are out of date or rely =
on unproven assumptions or extrapolation from the analysis of a particular =
PoS system. I certainly don't think we should experiment with bitcoin by sw=
itching 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 hig=
her security (cost / capital required to execute an attack) while at the sa=
me time costing far less resources (which do translate to fees on the netwo=
rk) without compromising any of the critical security properties bitcoin re=
lies on. I think the critical piece of this is the disagreements around har=
dcoded checkpoints, which is a critical piece solving attacks that could be=
 levied on a PoS chain, and how that does (or doesn't) affect the security =
model.
> > > > > > > > > > > > > > > @Eric Your proof of stake fallacy seems to be=
 saying that PoS is worse when a 51% attack happens. While I agree, I think=
 that 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 c=
an be substantially greater as well if the attack is successful.
> > > > > > > > > > > > > > > -   The effectiveness of paying miners to rai=
se the honest fraction of miners above 50% may be quite bad.
> > > > > > > > > > > > > > > -   Allowing a 51% attack is already unaccept=
able. It should be considered whether what happens in the case of a 51% may=
 not be significantly different. The currency would likely be critically da=
maged in a 51% attack regardless of consensus mechanism.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Proof-of-stake tends towards oligopolistic =
control
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > People repeat this often, but the facts suppo=
rt this. There is no centralization pressure in any proof of stake mechanis=
m that I'm aware of. IE if you have 10 times as much coin that you use to m=
int blocks, you should expect to earn 10x as much minting revenue - not mor=
e than 10x. By contrast, proof of work does in fact have clear centralizati=
on pressure - this is not disputed. Our goal in relation to that is to ensu=
re that the centralization pressure remains insignifiant. Proof of work als=
o clearly has a lot more barriers to entry than any proof of stake system d=
oes. Both of these mean the tendency towards oligopolistic control is worse=
 for PoW.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Energy usage, in-and-of-itself, is nothing =
to be ashamed of!!
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I certainly agree. Bitcoin's energy usage at =
the moment is I think quite warranted. However, the question is: can we do =
substantially better. I think if we can, we probably should... eventually.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Proof of Stake is only resilient to =E2=85=
=93 of the network 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 l=
inked to. I'm not aware of any proof that all PoS systems have a failure th=
reshold of 1/3. I know that staking systems like Casper do in fact have tha=
t 1/3 requirement. 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 a=
re currently honest and have a collective 100 exahashes/s hashpower, an att=
acker does not need to obtain 100 exahashes/s, but actually only needs to a=
ccumulate 50 exahashes/s. This is because as the attacker accumulates hashp=
ower, it drives 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 hashp=
ower because 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 security by a factor of about 83% (1 - 50%*33%).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Proof of Stake requires other trade-offs wh=
ich are incompatible with Bitcoin's objective (to be a trustless digital ca=
sh) =E2=80=94 specifically the famous "security vs. liveness" guarantee
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Do you have a good source that talks about wh=
y you think proof of stake cannot be used for a trustless digital cash?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > You cannot gain tokens without someone choo=
sing to give 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 w=
ill accept you, some sellers may reject you, but most would accept your mon=
ey as payment for bitcoins. I don't think requiring the "permission" of one=
 of millions of people in the market can be reasonably considered a "permis=
sioned currency".
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 2.  Proof of stake must have a trusted mean=
s of timestamping to regulate overproduction of blocks
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Both PoW and PoS could mine/mint blocks twice=
 as fast if everyone agreed to double their clock speeds. Both systems rely=
 on an honest majority sticking to standard time.
> > > > > > > > > > > > > > > On Wed, May 19, 2021 at 5:32 AM Michael Dubro=
vsky via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Ah sorry, I didn't realize this was, in fac=
t, a different thread! :)
> > > > > > > > > > > > > > > > On Wed, May 19, 2021 at 10:07 AM Michael Du=
brovsky mike@powx.org wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Folks, I suggest we keep the discussion t=
o 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 wou=
ld be relevant.
> > > > > > > > > > > > > > > > > Also, it's important to distinguish betwe=
en oPoW and these other "alternatives" to Hashcash. oPoW is a true Proof of=
 Work that doesn't alter the core game theory or security assumptions of Ha=
shcash and actually contains SHA (can be SHA3, SHA256, etc hash is intercha=
ngeable).
> > > > > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > > > > Mike
> > > > > > > > > > > > > > > > > On Tue, May 18, 2021 at 4:55 PM Erik Aron=
esty via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 1.  i never suggested vdf's to replace =
pow.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2.  my suggestion was specifically in t=
he context of a working
> > > > > > > > > > > > > > > > > >     proof-of-burn protocol
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -   vdfs used only for timing (not bloc=
k height)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -   blind-burned coins of a specific ag=
e used to replace proof of work
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -   the required "work" per block would=
 simply be a competition to
> > > > > > > > > > > > > > > > > >     acquire rewards, and so miners woul=
d 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 mim=
ic, in every meaningful way, the
> > > > > > > > > > > > > > > > > >     value gained from proof of work... =
without some of the security
> > > > > > > > > > > > > > > > > >     drawbacks
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > -   the miner risks losing all of his b=
urned 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 b=
e needed to properly mirror the
> > > > > > > > > > > > > > > > > >     properties of PoW and the incentive=
s Bitcoin uses to mine honestly.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 3.  i do believe it is possible that a =
"burned coin + vdf system"
> > > > > > > > > > > > > > > > > >     might be more secure in the long ru=
n, and that if the entire space
> > > > > > > > > > > > > > > > > >     agreed that such an endeavor was wo=
rthwhile, a test net could be spun
> > > > > > > > > > > > > > > > > >     up, and a hard-fork could be initia=
ted.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 4.  i would never suggest such a thing =
unless i believed it was
> > > > > > > > > > > > > > > > > >     possible that consensus was possibl=
e. so no, this is not an "alt
> > > > > > > > > > > > > > > > > >     coin"
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, May 18, 2021 at 10:02 AM Zac Gr=
eenwood zachgrw@gmail.com wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi ZmnSCPxj,
> > > > > > > > > > > > > > > > > > > Please note that I am not suggesting =
VDFs as a means to save energy, but solely as a means to make the time betw=
een blocks more constant.
> > > > > > > > > > > > > > > > > > > Zac
> > > > > > > > > > > > > > > > > > > On Tue, 18 May 2021 at 12:42, ZmnSCPx=
j ZmnSCPxj@protonmail.com wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Good morning Zac,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > VDFs might enable more constant b=
lock times, for instance by having a two-step PoW:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 1.  Use a VDF that takes say 9 mi=
nutes to resolve (VDF being subject to difficulty adjustments similar to th=
e as-is). As per the property of VDFs, miners are able show proof of work.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 2.  Use current PoW mechanism wit=
h lower difficulty so finding a block takes 1 minute on average, again subj=
ect to as-is difficulty adjustments.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > As a result, variation in block t=
imes will be greatly reduced.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > As I understand it, another weaknes=
s of VDFs is that they are not inherently progress-free (their sequential n=
ature prevents that; they are inherently progress-requiring).
> > > > > > > > > > > > > > > > > > > > Thus, a miner which focuses on impr=
oving the amount of energy that it can pump into the VDF circuitry (by over=
clocking and freezing the circuitry), could potentially get into a winner-t=
akes-all situation, possibly leading to even worse competition and even mor=
e energy consumption.
> > > > > > > > > > > > > > > > > > > > After all, if you can start mining =
0.1s faster than the competition, that is a 0.1s advantage where only you c=
an mine in the entire world.
> > > > > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > > > > ZmnSCPxj
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/l=
istinfo/bitcoin-dev
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/lis=
tinfo/bitcoin-dev
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev
>
>