path: root/a4/6041abfa6e2079e584fb36dcfebec53fce1c95

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3E931C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 21:40:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0E57184195
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 21:40:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id IaeaV-yy3xdb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 21:40:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [IPv6:2a00:1450:4864:20::531])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 66FE583DC4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 21:40:40 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id o5so6421660edc.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 May 2021 14:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=J2tgwZIm3OsUo3yCqOEsOac/SHhKANIJkXsDi14Zul0=;
 b=Zc2EZLrxbS8HRHsLuxFOfgGmei9PXhrp08bFJzmfmfZ4dBL9yD8gA0d55MUM3vygVY
 tqcw6zOD92zis3NzUYpLh8QtBnpsmd3I4SJwzKjDlstd188Dxz2sQz7LkUENlMvKl93B
 hfIIDp+8UKQQhsxXIzMHIVMxMbFxer+f537ioUcvxAXGn1kGRjYVnIBYcdANAkHc8ywy
 toWzCygsxk0VKMWBb/RCvTJA4g/A+DmYKyq0IDMNE9IC2P6UTf+lVAAAhzZYc4jHS23z
 ZFpebspr77CEWQLZtZ6u0pt6Ca54pU8esLqzdtzzWwkZ613LexaWEz/GWifIPPU8/THa
 afTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=J2tgwZIm3OsUo3yCqOEsOac/SHhKANIJkXsDi14Zul0=;
 b=JOi4CQ0MXqpXNI3dorhIABbP8GgARsXfef4/4ZAWsb7aYce5LPnt0L+fy0Z+Nt7ZH+
 r/J+WIHxRtGcUBzeKZEzzXg6TcmgOhvDae8xXMiQzBbeBwwhifpGmH23efU+4VK9DCUa
 0/f8SElGn7CMLKhYD3eGPoRMHJGQmKDOMwytEE/EXiBZHM3MZmBoIobVIWjiDQsE/5Ie
 3pzN+Y5dxTd7EyyZyp7FDpy35HuRy9aK35X7NrF5Nxz3upwXLcvhKZ8zzyrbNcJjZr1/
 +Qzeiu52KP5pjfsxmXmkLChq2KB+xVNexPKH6j5dG9fFIvxiDlv6gZbQjCB5A5YX3pov
 AXcg==
X-Gm-Message-State: AOAM531YT5EYySnhlIF6j75nI2eN3P8+4yF8H8Elu2t5q3j0/ly+eyYd
 IUTdB56M2Gr0b3A3WvROSK109O6cLkfCPoQPsD4=
X-Google-Smtp-Source: ABdhPJzxbrRFiR05xjVARWm2IzN+kzZR3SlUSZXvH0cahp4Mb9fl2vhhaI/D/4AeIeQApj6Qv2nD18NDvIqFg2y/iK8=
X-Received: by 2002:a50:fb17:: with SMTP id d23mr11994894edq.338.1622238038187; 
 Fri, 28 May 2021 14:40:38 -0700 (PDT)
MIME-Version: 1.0
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com>
 <CAJowKgJYUkxJ4htPvCLtARRr0Db13+BKzWtG40DEv6uEOh5yXw@mail.gmail.com>
 <CAGpPWDY4KgNVEoMDAJkWReX4zUUjDuB5SwB0Ap6OU98fuK4DxA@mail.gmail.com>
 <CAJowKgJWZ++6NkbYk15NBtA7x37of0n3_qF1UjCbV0Ui7XG8zA@mail.gmail.com>
 <CAGpPWDZs5Y10Fjbt8OPx3jEqjgNdQLODNdTW4iRyXTrpuNGFQQ@mail.gmail.com>
 <3TVoontwJmoMv0tp1S5MU_U8icxcQZfajtbNEXqOjuvO7GpfUQdh9pEGSIbLEYJndrDa_dJQqa0sSwY-BmuCmyHMRWqa9lEaUjZJSP5Vbyw=@protonmail.com>
 <CAGpPWDbqZLzMog4s9SPVm5xstbJbsHwND6x3qWHR-dh6naCnNQ@mail.gmail.com>
 <L1IhpSfDNx5OPXYnHfcFDiOzJa8jihbR8YE4MBRaYjuQt2GQsrNd0UnJaJg_mCgHNOcG6QE1Wrwp6zZ-YxOgDNu_aBE67HJkbemHz5Nz9c4=@protonmail.com>
 <CAJowKgKgGynQ9NYe_7xEai0tcBW4b=tQnNpv9vndx1hLCowfWg@mail.gmail.com>
 <J3_n3ygIuQf54KXVl8jlbyahX5WJIzffVeDD3yt0RkRbPRyD56OPj3DT05wGJoEfI6XfLOq2DiaN-vdnXSdi7Q23NWrZ-Tg9jzM9jtx8-hg=@protonmail.com>
 <CAJowKgJTEHLeHpKUOavAY9hHZ_3hChkJnMX13K-pSUhch7JwdQ@mail.gmail.com>
In-Reply-To: <CAJowKgJTEHLeHpKUOavAY9hHZ_3hChkJnMX13K-pSUhch7JwdQ@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 28 May 2021 11:40:19 -1000
Message-ID: <CAGpPWDbT-epwo5puaDdJG87Y-9fmKwFnxJTU8qEUAP9J39=itQ@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary="00000000000001e03205c36aba22"
X-Mailman-Approved-At: Sat, 29 May 2021 13:23:40 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 SatoshiSingh <SatoshiSingh@protonmail.com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 21:40:46 -0000

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

@befreeandopen   "If you want to make some arbitrary very narrow
definitions of what nothing at stake is so that you can claim your false
statement that it is a solved problem"

Wow, you are really unnecessarily hostile. This isn't r/bitcoin my friend.
Please assume some good faith. I simply pointed out my misunderstanding.
But it sounds like you're not willing to explain yourself clearly nor
actually have a reasoned discussion and prefer to insult me. So I think our
conversation is indeed over.

On Fri, May 28, 2021 at 10:06 AM Erik Aronesty <erik@q32.com> wrote:

> best writeup i know of is here:
>
> https://en.bitcoin.it/wiki/Proof_of_burn
>
> no formal proposals or proofs that i know of.
>
> On Fri, May 28, 2021 at 10:40 AM befreeandopen
> <befreeandopen@protonmail.com> wrote:
> >
> > Erik, I am sorry, I have little knowledge about proof-of-burn, I never
> found it interesting up until now. Some of your recent claims seem quite
> strong to me and I'd like to read more.
> >
> > Forgive me if this has been mentioned recently, but is there a full
> 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 detaile=
d
> proposal or technical documentation that would give me a precise
> information about what exactly it is that you are talking about.
> >
> >
> > Sent with ProtonMail Secure Email.
> >
> > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina=
l Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> > On Wednesday, May 26, 2021 11:07 PM, Erik Aronesty <erik@q32.com> wrote=
:
> >
> > > note: the "nothing at stake" problem you propose is not broken for
> > > proof-of-burn, because the attacker
> > >
> > > a) has no idea which past transactions are burns
> > > b) has no way to use his mining power, even 5%, to maliciously improv=
e
> > > his odds of being selected
> > >
> > > On Wed, May 26, 2021 at 9:12 AM befreeandopen
> > > befreeandopen@protonmail.com wrote:
> > >
> > > > @befreeandopen I guess I misunderstood your selfish minting attack.
> Let me make sure I understand it. You're saying it would go as follows?:
> > > >
> > > > 1.  The malicious actor comes across an opportunity to mint the nex=
t
> 3 blocks. But they hold off and don't release their blocks just yet.
> > > > 2.  They receive a new block minted by someone else.
> > > > 3.  The malicious actor then chooses to release their other 2 block=
s
> on on the second from the top block if it gives them more blocks in the
> future than minting on the top block. And instead lets the top block
> proceed if it gives them more blocks in the future (also figuring in the =
3
> blocks they're missing out on minting).
> > > > 4.  Profit!
> > > >
> > > > The problem with this attack is that any self respecting PoS system
> wouldn't have the information available for minters to know how blocks wi=
ll
> affect 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 rand=
om
> number that no individual party could predict). In fact, that's what the
> Casper protocol 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 ha=
ve
> a second step to release that number later. Rewards can be given can be
> used to ensure minters act honestly here by minting messages that release
> these numbers and not releasing their secret numbers too early.
> > > > Yes, you misunderstood it. First, let me say that the above thought=
s
> of yours are incorrect, at least for non-quorum case. Since the transitio=
n
> in the blockchain system from S1 to S2 is only by adding new block, and
> since stakers always need to be able to decide whether or not they can ad=
d
> the next block, it follows that if a staker creates a new block locally,
> she can decide whether the new state allows her to add another block on
> top. As you mentioned, this COULD introduce problem of staking, that you
> are incorrect in that it is a necessity. Usual prevention of the grinding
> problem in this case is that an "old enough" source of randomness applies
> for the current block production process. Of course this, as it is typica=
l
> 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 common
> feature of PoS system (non-quorum), roughly speaking, is that if N is the
> total amount of coins that participate in the staking process to create a
> new 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 syst=
em
> - 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 competition of honest stakers - they really do have the chance of K t=
o
> find the next block. However, the attacker, using nothing at stake, check=
s
> her ability to build block D (at some timestamp). If she is successful, s=
he
> does not propagate D immediately, but instead she also checks whether she
> can build on top of B and on top of A. Since with every new timestamp,
> usually, there is a new chance to build the block, it is not uncommon tha=
t
> she finds she is indeed able to build such block C' on top of B. Here it =
is
> likely t(C') > t(C) as the attacker has relatively low stake. Note that i=
n
> order to produce such C', she not only could have tried the current
> timestamp t(D), but also all previous timestamps up to t(B) (usually that=
's
> the consensus rule, but it may depend on a specific consensus). So her
> chance to produce such C' is greater than her previous chance of producin=
g
> 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 trying to prolong this chain by finding D'. And
> again here, it is quite likely that her chance to find such D' is greater
> than was her chance of finding D because again there are likely multiple
> timestamps she could try. This 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 produced two different forks. She can not be punishe=
d
> 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 with a bitcoin address is. However, the DOS risk can be solved
> more 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). Only when someone does in fact mint a block do they reveal
> their hidden public key in order to prove they are allowed to mint the
> block.
> > > > This is true, but you are mixing quorum and non-quorum systems. My
> 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 that
> this is what you meant with "quorum" system. So in such system, I claimed=
,
> the known producer is the only target at any given point of time. This of
> 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 imply
> 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 meant 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 part of i=
t:
> > > > "Of course you can always change the rules in a way that a certain
> specific attack is not doable, but you should not omit to mention that by
> doing so, typically, you have introduced another problem elsewhere, or yo=
u
> have not solved it completely."
> > > > You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT
> COMPLETELY)
> > > > In case of the punishment it was meant to be the not solve it
> 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 claims
> that PoS is a reasonable alternative to PoW, let's stick to that.
> > > >
> > > > > As long as the staker makes sure (which is not that hard) that sh=
e
> does not miss a chance to create a block, her significance in the system
> will always increase in time. It will increase relative to all normal use=
rs
> who do not stake
> > > >
> > > > Well, if you're in the closed system of the cryptocurrency, sure.
> But we don't live in that closed system. Minters will earn some ROI from
> minting just like any other financial activity. Others may find more
> success spending their time doing things other than figuring out how to
> mint coins. In that case, they'll be able to earn more coin that they cou=
ld
> later decide to use to mint blocks if they decide to.
> > > > This only supports the point I was making. Since the optimal
> scenario with all existing coins participating is just theoretical, the
> attacker's position will ever so improve. It seems we are in agreement
> here, great.
> > > >
> > > > > Just because of the above we must reject PoS as being critically
> 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 anythin=
g
> you've brought up amounts to substantial evidence that all possible PoS
> protocols are insecure.
> > > > I have not come up with anything. I'm afraid you've not realized th=
e
> burden of proof is on your side if you vouch for a design that is not
> 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
> demonstrated that your claim that nothing at stake is solved was
> unjustified. You have not described a system that would solve it (and not
> introduce critical DDOS attack vector as it is in quorum based systems -
> per the prior 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 prevents i=
ts
> adoption in decentralized consensus. No need to go to other hard problems
> without solving nothing at stake.
> > > > On Tue, May 25, 2021 at 11:10 AM befreeandopen
> befreeandopen@protonmail.com wrote:
> > > >
> > > > > @befreeandopen " An attacker can calculate whether or not she can
> prolong this chain or not and if so with what timestamp."
> > > > > The scenario you describe would only be likely to happen at all i=
f
> the malicious actor has a very large fraction of the stake - probably qui=
te
> close to 50%. At that point, you're talking about a 51% attack, not the
> nothing at stake problem. The nothing at stake problem is the problem whe=
re
> anyone will mint on any chain. Its clear that if there's a substantial
> 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 mi=
nt
> 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 th=
at
> 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 wit=
h
> PoW.
> > > > > This is not at all the case. The attacker benefits using the
> 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 abl=
e
> to completely take control the network (in short term), but rather that t=
he
> 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
> 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 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 point wit=
h
> powerful DDOS in order to hurt liveness of such system
> > > > >
> > > > > Just like in bitcoin, associating keys with IP addresses isn'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
> public key, the reverse isn't as easy. With a quorum-based PoS system, yo=
u
> can see their public key and address, but finding out their IP to DOS wou=
ld
> 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 and 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 area of origin of blocks is doable and has been done in past.
> So again, I very much disagree with your conclusion that this is somehow
> secure. It is absolutely insecure.
> > > > > Note, tho, that quorum-based PoS generally also have punishments
> as part of the protocol. The introduction of punishments do indeed handil=
y
> solve the nothing at stake problem. And you didn't mention a single probl=
em
> that the punishments introduce that weren't already there before
> punishments. There are tradeoffs with introducing punishments (eg in some
> cases you might punish honest actors), but they are minor in comparison t=
o
> solving the nothing at stake problem.
> > > > > While I agree that introduction of punishment itself does not
> imply introducing a problem elsewhere (which I did not claim if you rerea=
d
> my previous message), it does introduce additional complexity which may
> introduce problem, but more importantly, while it slightly improves
> resistance 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 when all participants of the network stake or delegate
> their stake. These optimal conditions rarely, if ever, occur. And that's
> another thing that we have not mention in our debate, so please allow me =
to
> introduce another problem to PoS.
> > > > > Consider what is needed for such optimal conditions to occur - al=
l
> coins are always part of the stake, which means that they need to somehow
> automatically part of the staking process even when they are moved. But i=
n
> many PoS systems you usually require some age (in terms of confirmations)
> of the coin before you allow it to be used for participation in staking
> process and that is for a good reason - to prevent various grinding
> attacks. In some systems the coin must be specifically registered before =
it
> can be 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 have this cooling period for a coin that has been moved. Maybe it is
> possible though, but AFAIK it is not common and not battle tested feature=
.
> > > > > Then if we admit that achieving the optimal condition is rather
> theoretical. Then if we do not have the optimal condition, it means that =
a
> staker with K% of the total available supply increases it's percentage ov=
er
> 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
> 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 selling any position ever. But powerful attacker is
> exactly in such position and thus she will gain significance in such a
> system. The technique I have described, and that you mistakenly think is
> viable only with huge amounts of stake, only puts the attacker to even
> greater advantage. But even without the described attack (which exploits
> nothing at stake), the PoS system converges to a system more and more
> controlled by powerful entity, which we can assume is the attacker.
> > > > > So I don't think it is at all misleading to claim that "nothing a=
t
> stake" is a solved problem. I do in fact mean that the solutions to that
> problem don't introduce any other problems with anywhere near the same
> level of significance.
> > > > > It still stands as truly misleading claim. I disagree that
> introducing DDOS opportunity with medium level of difficulty for the
> attacker to implement it, in case of "quorum-based PoS" is not a problem
> anywhere near the same level of significance. Such an attack vector allow=
s
> you to turn off the network if you spend some time and money. That is
> hardly acceptable.
> > > > > Just because of the above we must reject PoS as being critically
> insecure 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 heigh=
t
> > > > > >
> > > > > > > This sounds exploitable. It seems like an attacker could
> simply focus all their burns on a particular set of 6 blocks to double
> spend, 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 sitting on =
a
> node
> > > > > > somewhere waiting to be stolen.
> > > > > > On Mon, May 24, 2021 at 9:53 PM Billy Tetrud
> billy.tetrud@gmail.com wrote:
> > > > > >
> > > > > > > Is this the kind of proof of burn you're talking about?
> > > > > > >
> > > > > > > > if i have a choice between two chains, one longer and one
> 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 the
> stability 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 heigh=
t
> > > > > > >
> > > > > > > This sounds exploitable. It seems like an attacker could
> simply focus all their burns on a particular set of 6 blocks to double
> spend, minimizing their cost of attack.
> > > > > > >
> > > > > > > > i can imagine scenarios where large stakeholders can collud=
e
> to punish smaller stakeholders simply to drive them out of business, for
> example
> > > > > > >
> > > > > > > Are you talking about a 51% attack? This is possible in any
> 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 redactio=
n
> 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 future
> 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... deterministically=
,
> for that
> > > > > > > > burn: the chain with the height 553. if we fix the "lead
> time" for
> > > > > > > > burned coins to be weeks or even months in advance, miners
> 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 the
> > > > > > > > transactions that go into the block. they cannot choose
> which chain
> > > > > > > > to mine, and it's time-locked, so rollbacks and instability
> always
> > > > > > > > hurt miners the most.
> > > > > > > > the "punishment" systems of PoS are "weird at best",
> 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 a=
re
> > > > > > > > typically more secure.
> > > > > > > > PoB also solves problems caused by "energy dependence",
> which could
> > > > > > > > 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 requir=
e
> you to
> > > > > > > > have a live, well-connected node, it's harder to censor &
> harder 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 hel=
d
> online
> > > > > > > > >
> > > > > > > > > Well.. the coins to be burned need to be online when
> they're burned. But yes, only a small fraction of the total coins need to
> be online.
> > > > > > > > >
> > > > > > > > > > your burn investment is always "at stake", any redactio=
n
> 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 bloc=
k
> on a shorter chain, that requires them to send a transaction burning thei=
r
> coins, and that transaction could also be spent on the longest chain, whi=
ch
> means their coins are burned even if the chain they tried to mine on
> 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
> rewarding people who publish proofs of this happening on the main chain).
> In quorum-based PoS, you can punish people in the quorum that propose or
> sign multiple blocks for the same height. The "nothing at stake" problem =
is
> a solved problem at this point for PoS.
> > > > > > > > > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty erik@q32.co=
m
> wrote:
> > > > > > > > >
> > > > > > > > > > > I don't see a way to get around the conflicting
> requirement that the keys for large amounts of coins should be kept offli=
ne
> but those are exactly the coins we need online to make the scheme secure.
> > > > > > > > > >
> > > > > > > > > > proof of burn clearly solves this, since nothing is hel=
d
> online
> > > > > > > > > >
> > > > > > > > > > > how does proof of burn solve the "nothing at stake"
> 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 strategy
> for any miner
> > > > > > > > > > is to mine on every chain, so that the miner gets their
> reward no
> > > > > > > > > > matter which fork wins. indeed in proof-of-stake, the
> proofs are
> > > > > > > > > > published on the very chains mines, so the incentive is
> magnified.
> > > > > > > > > > in proof-of-burn, your burn investment is always "at
> stake", any
> > > > > > > > > > redaction can result in a loss-of-burn, because burns
> can be tied,
> > > > > > > > > > precisely, to block-heights
> > > > > > > > > > as a result, miners no longer have an incentive to mine
> 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 many of the weak arguments that are made against PoS made in
> this thread and elsewhere.
> > > > > > > > > > > Although I don't agree with all your points you have
> done a decent job here so I'll focus on the second part: why I think
> Proof-of-Stake is inappropriate for a Bitcoin-like system.
> > > > > > > > > > > Proof of stake is not fit for purpose for a global
> settlement layer in a pure digital asset (i.e. "digital gold") which is
> what Bitcoin is trying to be.
> > > > > > > > > > > PoS necessarily gives responsibilities to the holders
> of coins that they do not want and cannot handle.
> > > > > > > > > > > In Bitcoin, large unsophisticated coin holders can pu=
t
> their coins in cold storage without a second thought given to the health =
of
> the underlying ledger.
> > > > > > > > > > > As much as hardcore Bitcoiners try to convince them t=
o
> run their own node, most don't, and that's perfectly acceptable.
> > > > > > > > > > > At no point do their personal decisions affect the
> underlying consensus -- it only affects their personal security assurance
> (not that of the system itself).
> > > > > > > > > > > In PoS systems this clean separation of
> responsibilities does not exist.
> > > > > > > > > > > I think that the more rigorously studied PoS protocol=
s
> will work fine within the security claims made in their papers.
> > > > > > > > > > > People who believe that these protocols are destined
> for catastrophic consensus failure are certainly in for a surprise.
> > > > > > > > > > > But the devil is in the detail.
> > > > > > > > > > > Let's look at what the implications of using the
> leading proof of stake protocols would have on Bitcoin:
> > > > > > > > > > >
> > > > > > > > > > > ### Proof of SquareSpace (Cardano, Polkdadot)
> > > > > > > > > > >
> > > > > > > > > > > Cardano is a UTXO based PoS coin based on Ouroboros
> Praos3 with an inbuilt on-chain delegation system5.
> > > > > > > > > > > In these protocols, coin holders who do not want to
> run their node with their hot keys in it delegate it to a "Stake Pool".
> > > > > > > > > > > I call the resulting system Proof-of-SquareSpace sinc=
e
> most will choose a pool by looking around for one with a nice website and
> offering the largest share of the block reward.
> > > > > > > > > > > On the surface this might sound no different than
> someone with an mining rig shopping around for a good mining pool but the=
re
> are crucial differences:
> > > > > > > > > > >
> > > > > > > > > > > 1.  The person making the decision is forced into it
> just because they own the currency -- someone with a mining rig has
> purchased it with the intent to make profit by participating in consensus=
.
> > > > > > > > > > >
> > > > > > > > > > > 2.  When you join a mining pool your systems are very
> much still online. You are just partaking in a pool to reduce your profit
> variance. You still see every block that you help create and you never he=
lp
> create a block without seeing it first.
> > > > > > > > > > >
> > > > > > > > > > > 3.  If by SquareSpace sybil attack you gain a
> dishonest majority and start censoring transactions how are the users mea=
nt
> to redelegate their stake to honest pools?
> > > > > > > > > > >     I guess they can just send a transaction
> delegating to another pool...oh wait I guess that might be censored too!
> This seems really really bad.
> > > > > > > > > > >     In Bitcoin, miners can just join a different pool
> at a whim. There is nothing the attacker can do to stop them. A temporary
> dishonest majority heals relatively well.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > There is another severe disadvantage to this on-chain
> delegation system: every UTXO must indicate which staking account this UT=
XO
> belongs to so the appropriate share of block rewards can be transferred
> there.
> > > > > > > > > > > Being able to associate every UTXO to an account ruin=
s
> one of the main privacy advantages of the UTXO model.
> > > > > > > > > > > It also grows the size of the blockchain significantl=
y.
> > > > > > > > > > >
> > > > > > > > > > > ### "Pure" proof of stake (Algorand)
> > > > > > > > > > >
> > > > > > > > > > > Algorand's4 approach is to only allow online stake to
> participate in the protocol.
> > > > > > > > > > > Theoretically, This means that keys holding funds hav=
e
> to be online in order for them to author blocks when they are chosen.
> > > > > > > > > > > Of course in reality no one wants to keep their coin
> holding keys online so in Alogorand you can authorize a set of
> "participation keys"1 that will be used to create blocks on your coin
> holding key's behalf.
> > > > > > > > > > > Hopefully you've spotted the problem.
> > > > > > > > > > > You can send your participation keys to any malicious
> party with a nice website (see random example 2) offering you a good retu=
rn.
> > > > > > > > > > > Damn it's still Proof-of-SquareSpace!
> > > > > > > > > > > The minor advantage is that at least the participatio=
n
> keys expire after a certain amount of time so eventually the SquareSpace
> attacker will lose their hold on consensus.
> > > > > > > > > > > Importantly there is also less junk on the blockchain
> because the participation keys are delegated off-chain and so are not
> 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 offli=
ne
> but those are exactly the coins we need online to make the scheme secure.
> > > > > > > > > > > If we allow delegation then we open up a new social
> attack surface and 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 for the holder of the coin.
> > > > > > > > > > > After all, gold is an inert element on the periodic
> table that doesn't confer responsibilities on the holder to maintain the
> quality of all the other bars of gold out there.
> > > > > > > > > > > Bitcoin feels like this too and in many ways is more
> inert and beautifully boring than gold.
> > > > > > > > > > > For Bitcoin to succeed I think we need to keep it tha=
t
> way and Proof-of-Stake makes everything a bit too exciting.
> > > > > > > > > > > I suppose in the end the market will decide what is
> real digital gold and whether these bad technical trade offs are worth
> being able to say it uses less electricity. It goes without saying that
> making bad technical decisions to appease the current political climate i=
s
> an anathema to Bitcoin.
> > > > > > > > > > > Would be interested to know if you or others think
> 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 use
> insecure PoS mechanisms. Yes there have been massive issues with
> distribution of PoS coins (of course there have also been massive issues
> with PoW coins as well). However, I want to remind everyone that there is=
 a
> difference between "proved to be impossible" and "have not achieved
> recognized success yet". Most of the arguments levied against PoS are out
> of date or rely on unproven assumptions or extrapolation from the analysi=
s
> of a particular PoS system. I certainly don't think we should experiment
> with bitcoin by switching to PoS, but from my research, it seems very
> likely that there is a proof of stake consensus protocol we could build
> that has substantially higher security (cost / capital required to execut=
e
> an attack) while at the same time costing far less resources (which do
> translate to fees on the network) without compromising any of the critica=
l
> security properties bitcoin relies on. I think the critical piece of this
> is the disagreements around hardcoded checkpoints, which is a critical
> piece solving attacks that could be levied on a PoS chain, and how that
> does (or doesn't) affect the security model.
> > > > > > > > > > > > @Eric Your proof of stake fallacy seems to be sayin=
g
> that PoS is worse when a 51% attack happens. While I agree, I think that
> line of thinking omits important facts:
> > > > > > > > > > > >
> > > > > > > > > > > > -   The capital required to 51% attack a PoS chain
> can be made substantially greater than on a PoS chain.
> > > > > > > > > > > > -   The capital the attacker stands to lose can be
> substantially greater as well if the attack is successful.
> > > > > > > > > > > > -   The effectiveness of paying miners to raise the
> honest fraction of miners above 50% may be quite bad.
> > > > > > > > > > > > -   Allowing a 51% attack is already unacceptable.
> It should be considered whether what happens in the case of a 51% may not
> be significantly different. The currency would likely be critically damag=
ed
> in a 51% attack regardless of consensus mechanism.
> > > > > > > > > > > >
> > > > > > > > > > > > > Proof-of-stake tends towards oligopolistic contro=
l
> > > > > > > > > > > >
> > > > > > > > > > > > People repeat this often, but the facts support
> this. There is no centralization pressure in any proof of stake mechanism
> that I'm aware of. IE if you have 10 times as much coin that you use to
> mint blocks, you should expect to earn 10x as much minting revenue - not
> more than 10x. By contrast, proof of work does in fact have clear
> centralization pressure - this is not disputed. Our goal in relation to
> that is to ensure that the centralization pressure remains insignifiant.
> Proof of work also clearly has a lot more barriers to entry than any proo=
f
> of stake system does. Both of these mean the tendency towards oligopolist=
ic
> 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 resilien=
t
> up to the =C2=BD threshold
> > > > > > > > > > > >
> > > > > > > > > > > > I see no mention of this in the pos.pdf you linked
> to. I'm not aware of any proof that all PoS systems have a failure
> threshold of 1/3. I know that staking systems like Casper do in fact have
> that 1/3 requirement. However there are PoS designs that should exceed th=
at
> 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 currently 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 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 hashpower 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 which ar=
e
> incompatible with Bitcoin's objective (to be a trustless digital cash) =
=E2=80=94
> specifically the famous "security vs. liveness" guarantee
> > > > > > > > > > > >
> > > > > > > > > > > > Do you have a good source that talks about why you
> think proof of stake cannot be used for a trustless digital cash?
> > > > > > > > > > > >
> > > > > > > > > > > > > You cannot gain tokens without someone choosing t=
o
> give up those coins - a form of permission.
> > > > > > > > > > > >
> > > > > > > > > > > > This is not a practical constraint. Just like in
> mining, some nodes may reject you, but there will likely be more that wil=
l
> accept you, some sellers may reject you, but most would accept your money
> as payment for bitcoins. I don't think requiring the "permission" of one =
of
> millions of people in the market can be reasonably considered a
> "permissioned currency".
> > > > > > > > > > > >
> > > > > > > > > > > > > 2.  Proof of stake must have a trusted means of
> timestamping to regulate overproduction of blocks
> > > > > > > > > > > >
> > > > > > > > > > > > Both PoW and PoS could mine/mint blocks twice as
> fast if everyone agreed to double their clock speeds. Both systems rely o=
n
> an honest majority sticking to standard time.
> > > > > > > > > > > > On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky
> via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Ah sorry, I didn't realize this was, in fact, a
> different thread! :)
> > > > > > > > > > > > > On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsk=
y
> mike@powx.org wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Folks, I suggest we keep the discussion to PoW,
> oPoW, and the BIP itself. PoS, VDFs, and so on are interesting but I gues=
s
> there are other threads going on these topics already where they would be
> relevant.
> > > > > > > > > > > > > > Also, it's important to distinguish between oPo=
W
> and these other "alternatives" to Hashcash. oPoW is a true Proof of Work
> that doesn't alter the core game theory or security assumptions of Hashca=
sh
> and actually contains SHA (can be SHA3, SHA256, etc hash is
> interchangeable).
> > > > > > > > > > > > > > Cheers,
> > > > > > > > > > > > > > Mike
> > > > > > > > > > > > > > On Tue, May 18, 2021 at 4:55 PM Erik Aronesty
> via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1.  i never suggested vdf's to replace pow.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2.  my suggestion was specifically in the
> context of a working
> > > > > > > > > > > > > > >     proof-of-burn protocol
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   vdfs used only for timing (not block
> height)
> > > > > > > > > > > > > > > -   blind-burned coins of a specific age used
> to replace proof of work
> > > > > > > > > > > > > > > -   the required "work" per block would simpl=
y
> be a competition to
> > > > > > > > > > > > > > >     acquire rewards, and so miners would have
> to burn coins, well in
> > > > > > > > > > > > > > >     advance, and hope that their burned coins
> got rewarded in some far
> > > > > > > > > > > > > > >     future
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   the point of burned coins is to mimic, in
> every meaningful way, the
> > > > > > > > > > > > > > >     value gained from proof of work... withou=
t
> some of the security
> > > > > > > > > > > > > > >     drawbacks
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   the miner risks losing all of his burned
> coins (like all miners risk
> > > > > > > > > > > > > > >     losing their work in each block)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -   new burns can't be used
> > > > > > > > > > > > > > > -   old burns age out (like ASICs do)
> > > > > > > > > > > > > > > -   other requirements on burns might be
> needed to properly mirror the
> > > > > > > > > > > > > > >     properties of PoW and the incentives
> Bitcoin uses to mine honestly.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 3.  i do believe it is possible that a "burne=
d
> coin + vdf system"
> > > > > > > > > > > > > > >     might be more secure in the long run, and
> that if the entire space
> > > > > > > > > > > > > > >     agreed that such an endeavor was
> worthwhile, a test net could be spun
> > > > > > > > > > > > > > >     up, and a hard-fork could be initiated.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 4.  i would never suggest such a thing unless
> i believed it was
> > > > > > > > > > > > > > >     possible that consensus was possible. so
> no, this is not an "alt
> > > > > > > > > > > > > > >     coin"
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, May 18, 2021 at 10:02 AM Zac Greenwoo=
d
> zachgrw@gmail.com wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi ZmnSCPxj,
> > > > > > > > > > > > > > > > Please note that I am not suggesting VDFs a=
s
> a means to save energy, but solely as a means to make the time between
> 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 resolve (VDF being subject to difficulty adjustments similar to the
> as-is). As per the property of VDFs, miners are able show proof of work.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2.  Use current PoW mechanism with lowe=
r
> difficulty so finding a block takes 1 minute on average, again subject to
> as-is difficulty adjustments.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > As a result, variation in block times
> will be greatly reduced.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > As I understand it, another weakness of
> VDFs is that they are not inherently progress-free (their sequential natu=
re
> prevents that; they are inherently progress-requiring).
> > > > > > > > > > > > > > > > > Thus, a miner which focuses on improving
> the amount of energy that it can pump into the VDF circuitry (by
> overclocking and freezing the circuitry), could potentially get into a
> winner-takes-all situation, possibly leading to even worse competition an=
d
> even more energy consumption.
> > > > > > > > > > > > > > > > > After all, if you can start mining 0.1s
> faster than the competition, that is a 0.1s advantage where only you can
> mine in the entire world.
> > > > > > > > > > > > > > > > > Regards,
> > > > > > > > > > > > > > > > > ZmnSCPxj
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > > > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Michael Dubrovsky
> > > > > > > > > > > > > Founder; PoWx
> > > > > > > > > > > > > www.PoWx.org
> > > > > > > > > > > > >
> > > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > > >
> > > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > > > > > > > > >
> > > > > > > > > > > bitcoin-dev mailing list
> > > > > > > > > > > bitcoin-dev@lists.linuxfoundation.org
> > > > > > > > > > >
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>

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

<div dir=3D"ltr">@befreeandopen=C2=A0 =C2=A0&quot;If you want to make some =
arbitrary very narrow definitions of what nothing at stake is so that you c=
an claim your false statement that it is a solved problem&quot;<div><div><b=
r></div><div>Wow, you are really unnecessarily hostile. This isn&#39;t r/bi=
tcoin my friend. Please assume some good faith. I simply pointed out my mis=
understanding. But it sounds like you&#39;re not willing to explain yoursel=
f clearly nor actually have a reasoned discussion and prefer to insult me. =
So I think our conversation is indeed over.=C2=A0</div></div></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 28=
, 2021 at 10:06 AM Erik Aronesty &lt;<a href=3D"mailto:erik@q32.com">erik@q=
32.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">best writeup i know of is here:<br>
<br>
<a href=3D"https://en.bitcoin.it/wiki/Proof_of_burn" rel=3D"noreferrer" tar=
get=3D"_blank">https://en.bitcoin.it/wiki/Proof_of_burn</a><br>
<br>
no formal proposals or proofs that i know of.<br>
<br>
On Fri, May 28, 2021 at 10:40 AM befreeandopen<br>
&lt;<a href=3D"mailto:befreeandopen@protonmail.com" target=3D"_blank">befre=
eandopen@protonmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Erik, I am sorry, I have little knowledge about proof-of-burn, I never=
 found it interesting up until now. Some of your recent claims seem quite s=
trong to me and I&#39;d like to read more.<br>
&gt;<br>
&gt; Forgive me if this has been mentioned recently, but is there a full sp=
ecification of the concept you are referring to? I don&#39;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 informatio=
n about what exactly it is that you are talking about.<br>
&gt;<br>
&gt;<br>
&gt; Sent with ProtonMail Secure Email.<br>
&gt;<br>
&gt; =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origin=
al Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<=
br>
&gt; On Wednesday, May 26, 2021 11:07 PM, Erik Aronesty &lt;<a href=3D"mail=
to:erik@q32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; note: the &quot;nothing at stake&quot; problem you propose is not=
 broken for<br>
&gt; &gt; proof-of-burn, because the attacker<br>
&gt; &gt;<br>
&gt; &gt; a) has no idea which past transactions are burns<br>
&gt; &gt; b) has no way to use his mining power, even 5%, to maliciously im=
prove<br>
&gt; &gt; his odds of being selected<br>
&gt; &gt;<br>
&gt; &gt; On Wed, May 26, 2021 at 9:12 AM befreeandopen<br>
&gt; &gt; <a href=3D"mailto:befreeandopen@protonmail.com" target=3D"_blank"=
>befreeandopen@protonmail.com</a> wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; @befreeandopen I guess I misunderstood your selfish minting =
attack. Let me make sure I understand it. You&#39;re saying it would go as =
follows?:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1.=C2=A0 The malicious actor comes across an opportunity to =
mint the next 3 blocks. But they hold off and don&#39;t release their block=
s just yet.<br>
&gt; &gt; &gt; 2.=C2=A0 They receive a new block minted by someone else.<br=
>
&gt; &gt; &gt; 3.=C2=A0 The malicious actor then chooses to release their o=
ther 2 blocks on on the second from the top block if it gives them more blo=
cks in the future than minting on the top block. And instead lets the top b=
lock proceed if it gives them more blocks in the future (also figuring in t=
he 3 blocks they&#39;re missing out on minting).<br>
&gt; &gt; &gt; 4.=C2=A0 Profit!<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The problem with this attack is that any self respecting PoS=
 system wouldn&#39;t have the information available for minters to know how=
 blocks will affect their future prospects of minting. Otherwise this would=
 introduce the problem of stake grinding. This can be done using collaborat=
ive randomness (where numbers from many parties are combined to create a ra=
ndom number that no individual party could predict). In fact, that&#39;s wh=
at the Casper protocol does to decide quorums. In a non quorum case, you ca=
n 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 minters act honestly here by minting messages that releas=
e these numbers and not releasing their secret numbers too early.<br>
&gt; &gt; &gt; Yes, you misunderstood it. First, let me say that the above =
thoughts of yours are incorrect, at least for non-quorum case. Since the tr=
ansition 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 ca=
n add the next block, it follows that if a staker creates a new block local=
ly, 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 a=
re incorrect in that it is a necessity. Usual prevention of the grinding pr=
oblem in this case is that an &quot;old enough&quot; source of randomness a=
pplies for the current block production process. Of course this, as it is t=
ypical for PoS, introduces other problems, but let&#39;s discard those.<br>
&gt; &gt; &gt; I will try to explain in detail what you misunderstood befor=
e. You start with a chain ending with blocks A-B-C, C being the top, the co=
mmon feature of PoS system (non-quorum), roughly speaking, is that if N is =
the total amount of coins that participate in the staking process to create=
 a new block on top of C (let&#39;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 st=
ake. In other words, the power of stakers is supposed to be linear in the s=
ystem - you own 10 coins gives you 10x the chance of finding block over som=
eone who has 1 coin.<br>
&gt; &gt; &gt; What i was claiming is that using the technique I have descr=
ibed, this linearity is violated. Why? Well, it works for honest stakers am=
ong 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, che=
cks 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 =
she can build on top of B and on top of A. Since with every new timestamp, =
usually, there is a new chance to build the block, it is not uncommon that =
she finds she is indeed able to build such block C&#39; on top of B. Here i=
t is likely t(C&#39;) &gt; t(C) as the attacker has relatively low stake. N=
ote that in order to produce such C&#39;, she not only could have tried the=
 current timestamp t(D), but also all previous timestamps up to t(B) (usual=
ly that&#39;s the consensus rule, but it may depend on a specific consensus=
). So her chance to produce such C&#39; is greater than her previous chance=
 of producing C (which chance was limited by other stakers in the system an=
d the discovery of block C by one of them). Now suppose that she found such=
 C&#39; and now she continues by trying to prolong this chain by finding D&=
#39;. And again here, it is quite likely that her chance to find such D&#39=
; is greater than was her chance of finding D because again there are likel=
y multiple timestamps she could try. This all was possible just because not=
hing 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&#39;, s=
he discards D and only publishes chain A-B-C&#39;-D&#39;, which can not be =
punished despite the fact that she indeed produced two different forks. She=
 can not be punished because this production was local and only the final r=
esult of A-B-C&#39;-D&#39; was published, in which case she gained an extra=
 block over the honest strategy which would only give her block D.<br>
&gt; &gt; &gt; Fun fact tho: there is an attack called the &quot;selfish mi=
ning attack&quot; for proof of work, and it reduces the security of PoW by =
at least 1/3rd.<br>
&gt; &gt; &gt; How is that relevant to our discussion? This is known resear=
ch that has nothing to do with PoS except that it is often worse on PoS.<br=
>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; the problem is not as hard as you think<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I don&#39;t claim to know just how hard finding the IP addre=
ss associated with a bitcoin address is. However, the DOS risk can be solve=
d more completely by only allowing the owner of coins themselves to know wh=
ether they can mint a block. Eg by determining whether someone can mint a b=
lock based on their public key hidden behind hashes (as normal in addresses=
). Only when someone does in fact mint a block do they reveal their hidden =
public key in order to prove they are allowed to mint the block.<br>
&gt; &gt; &gt; This is true, but you are mixing quorum and non-quorum syste=
ms. My objection here was towards such system where I specifically said tha=
t the list of producers for next epoch is known up front and you confirmed =
that this is what you meant with &quot;quorum&quot; system. So in such syst=
em, I claimed, 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 futur=
e producers are not known. No need to dispute, again, something that was no=
t claimed.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I agree that introduction of punishment itself does not=
 imply introducing a problem elsewhere (which I did not claim if you reread=
 my previous message)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;m glad we agree there. Perhaps I misunderstood what yo=
u meant by &quot;you should not omit to mention that by doing so, typically=
, you have introduced another problem elsewhere.&quot;<br>
&gt; &gt; &gt; Perhaps you should quote the full sentence and not just a pa=
rt of it:<br>
&gt; &gt; &gt; &quot;Of course you can always change the rules in a way tha=
t a certain specific attack is not doable, but you should not omit to menti=
on that by doing so, typically, you have introduced another problem elsewhe=
re, or you have not solved it completely.&quot;<br>
&gt; &gt; &gt; You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SO=
LVE IT COMPLETELY)<br>
&gt; &gt; &gt; In case of the punishment it was meant to be the not solve i=
t completely part.<br>
&gt; &gt; &gt; Also &quot;typically&quot; does not imply always.<br>
&gt; &gt; &gt; But this parsing of English sentences for you seems very off=
 topic here. My point is, in context of Bitcoin, reject such unsupported cl=
aims that PoS is a reasonable alternative to PoW, let&#39;s stick to that.<=
br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; As long as the staker makes sure (which is not that har=
d) that she does not miss a chance to create a block, her significance in t=
he system will always increase in time. It will increase relative to all no=
rmal users who do not stake<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Well, if you&#39;re in the closed system of the cryptocurren=
cy, sure. But we don&#39;t live in that closed system. Minters will earn so=
me ROI from minting just like any other financial activity. Others may find=
 more success spending their time doing things other than figuring out how =
to mint coins. In that case, they&#39;ll be able to earn more coin that the=
y could later decide to use to mint blocks if they decide to.<br>
&gt; &gt; &gt; This only supports the point I was making. Since the optimal=
 scenario with all existing coins participating is just theoretical, the at=
tacker&#39;s position will ever so improve. It seems we are in agreement he=
re, great.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Just because of the above we must reject PoS as being c=
ritically insecure<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 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&#39;t see how=
 anything you&#39;ve brought up amounts to substantial evidence that all po=
ssible PoS protocols are insecure.<br>
&gt; &gt; &gt; I have not come up with anything. I&#39;m afraid you&#39;ve =
not realized the burden of proof is on your side if you vouch for a design =
that is not 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 ha=
ve just demonstrated that your claim that nothing at stake is solved was un=
justified. You have not described a system that would solve it (and not int=
roduce critical DDOS attack vector as it is in quorum based systems - per t=
he prior definition of such systems).<br>
&gt; &gt; &gt; Of course the list of problems of PoS systems do not end wit=
h just nothing at stake, but it is good enough example that by itself preve=
nts its adoption in decentralized consensus. No need to go to other hard pr=
oblems without solving nothing at stake.<br>
&gt; &gt; &gt; On Tue, May 25, 2021 at 11:10 AM befreeandopen <a href=3D"ma=
ilto:befreeandopen@protonmail.com" target=3D"_blank">befreeandopen@protonma=
il.com</a> wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; @befreeandopen &quot; An attacker can calculate whether=
 or not she can prolong this chain or not and if so with what timestamp.&qu=
ot;<br>
&gt; &gt; &gt; &gt; The scenario you describe would only be likely to happe=
n at all if the malicious actor has a very large fraction of the stake - pr=
obably quite close to 50%. At that point, you&#39;re talking about a 51% at=
tack, not the nothing at stake problem. The nothing at stake problem is the=
 problem where anyone will mint on any chain. Its clear that if there&#39;s=
 a substantial punishment for minting on chains other than the one that eve=
ntually wins, every minter without a significant fraction of the stake will=
 be honest and not attempt to mint on old blocks or support someone else&#3=
9;s attempt to mint on old blocks (until and if it becomes the heaviest cha=
in). Because the attacker would need probably &gt;45% of the active stake (=
take a look at the reasoning here for a deeper analysis of that statement),=
 I don&#39;t agree that punishment is not a sufficient mitigation of the no=
thing at stake problem. To exploit the nothing at stake problem, you basica=
lly need to 51% attack, at which point you&#39;ve exceeded the operating co=
nditions of the system, so of course its gonna have problems, just like a 5=
1% attack would cause with PoW.<br>
&gt; &gt; &gt; &gt; This is not at all the case. The attacker benefits usin=
g the described technique at any size of the stake and significantly so wit=
h just 5% of the stake. By significantly, I do not mean that the attacker i=
s able to completely take control the network (in short term), but rather t=
hat the attacker has significant advantage in the number of blocks she crea=
tes compared to what she &quot;should be able to create&quot;. This means t=
he attacker&#39;s stake increases significantly faster than of the honest n=
odes, which in long term is very serious in PoS system. If you believe clos=
e to 50% is needed for that, you need to redo your math. So no, you are wro=
ng stating that &quot;to exploit nothing at stake problem you basically nee=
d to 51% attack&quot;. It is rather the opposite - eventually, nothing at s=
take attack leads to ability to perform 51% attack.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; I am not sure if this is what you call quorum-base=
d PoS<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Yes, pre-selected minters is exactly what I mean by tha=
t.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; it allows the attacker to know who to attack at wh=
ich point with powerful DDOS in order to hurt liveness of such system<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Just like in bitcoin, associating keys with IP addresse=
s isn&#39;t generally an easy thing to do on the fly like that. If you know=
 someone&#39;s IP address, you can target them. But if you only know their =
address or public key, the reverse isn&#39;t as easy. With a quorum-based P=
oS system, you can see their public key and address, but finding out their =
IP to DOS would be a huge challenge I think.<br>
&gt; &gt; &gt; &gt; I do not dispute that the problem is not trivial, but t=
he problem is not as hard as you think. The network graph analysis is a kno=
wn technique and 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 a=
nalysis of area of origin of blocks is doable and has been done in past. So=
 again, I very much disagree with your conclusion that this is somehow secu=
re. It is absolutely insecure.<br>
&gt; &gt; &gt; &gt; Note, tho, that quorum-based PoS generally also have pu=
nishments as part of the protocol. The introduction of punishments do indee=
d handily solve the nothing at stake problem. And you didn&#39;t mention a =
single problem that the punishments introduce that weren&#39;t already ther=
e before punishments. There are tradeoffs with introducing punishments (eg =
in some cases you might punish honest actors), but they are minor in compar=
ison to solving the nothing at stake problem.<br>
&gt; &gt; &gt; &gt; While I agree that introduction of punishment itself do=
es not imply introducing a problem elsewhere (which I did not claim if you =
reread my previous message), it does introduce additional complexity which =
may introduce problem, but more importantly, while it slightly improves res=
istance 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 c=
ould not be farther from the truth. It is not true even in optimal conditio=
ns when all participants of the network stake or delegate their stake. Thes=
e optimal conditions rarely, if ever, occur. And that&#39;s another thing t=
hat we have not mention in our debate, so please allow me to introduce anot=
her problem to PoS.<br>
&gt; &gt; &gt; &gt; Consider what is needed for such optimal conditions to =
occur - all coins are always part of the stake, which means that they need =
to somehow automatically part of the staking process even when they are mov=
ed. But in many PoS systems you usually require some age (in terms of confi=
rmations) of the coin before you allow it to be used for participation in s=
taking process and that is for a good reason - to prevent various grinding =
attacks. In some systems the coin must be specifically registered before it=
 can be 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 n=
ot have this cooling period for a coin that has been moved. Maybe it is pos=
sible though, but AFAIK it is not common and not battle tested feature.<br>
&gt; &gt; &gt; &gt; Then if we admit that achieving the optimal condition i=
s rather theoretical. Then if we do not have the optimal condition, it mean=
s that a staker with K% of the total available supply increases it&#39;s pe=
rcentage over time to some amounts &gt;K%. As long as the staker makes sure=
 (which is not that hard) that she does not miss a chance to create a block=
, her significance in the system will always increase in time. It will incr=
ease relative to all normal users who do not stake (if there are any) and r=
elative to all other stakers who make mistakes or who are not wealthy enoug=
h to afford not selling any position ever. But powerful attacker is exactly=
 in such position and thus she will gain significance in such a system. The=
 technique I have described, and that you mistakenly think is viable only w=
ith huge amounts of stake, only puts the attacker to even greater advantage=
. But even without the described attack (which exploits nothing at stake), =
the PoS system converges to a system more and more controlled by powerful e=
ntity, which we can assume is the attacker.<br>
&gt; &gt; &gt; &gt; So I don&#39;t think it is at all misleading to claim t=
hat &quot;nothing at stake&quot; is a solved problem. I do in fact mean tha=
t the solutions to that problem don&#39;t introduce any other problems with=
 anywhere near the same level of significance.<br>
&gt; &gt; &gt; &gt; It still stands as truly misleading claim. I disagree t=
hat introducing DDOS opportunity with medium level of difficulty for the at=
tacker to implement it, in case of &quot;quorum-based PoS&quot; is not a pr=
oblem anywhere near the same level of significance. Such an attack vector a=
llows you to turn off the network if you spend some time and money. That is=
 hardly acceptable.<br>
&gt; &gt; &gt; &gt; Just because of the above we must reject PoS as being c=
ritically insecure until someone invents and demonstrates an actual way of =
solving these issues.<br>
&gt; &gt; &gt; &gt; On Tue, May 25, 2021 at 3:00 AM Erik Aronesty <a href=
=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a> wrote:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; you burn them to be used at a future par=
ticular block height<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; This sounds exploitable. It seems like an att=
acker could simply focus all their burns on a particular set of 6 blocks to=
 double spend, minimizing their cost of attack.<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; could be right. the original idea was to have burn=
s decay over time,<br>
&gt; &gt; &gt; &gt; &gt; like ASIC&#39;s.<br>
&gt; &gt; &gt; &gt; &gt; anyway the point was not that &quot;i had a magic =
formula&quot;<br>
&gt; &gt; &gt; &gt; &gt; the point was that proof of burn is almost always =
better than proof of<br>
&gt; &gt; &gt; &gt; &gt; stake - simply because the &quot;proof&quot; is on=
-chain, not sitting on a node<br>
&gt; &gt; &gt; &gt; &gt; somewhere waiting to be stolen.<br>
&gt; &gt; &gt; &gt; &gt; On Mon, May 24, 2021 at 9:53 PM Billy Tetrud <a hr=
ef=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.c=
om</a> wrote:<br>
&gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; Is this the kind of proof of burn you&#39;re =
talking about?<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; if i have a choice between two chains, o=
ne longer and one shorter, i can only choose one... deterministically<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; What prevents you from attempting to mine blo=
ck 553 on both chains?<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; miners have a very strong, long-term, in=
vestment in the stability of the chain.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; Yes, but the same can be said of any coin, ev=
en ones that do have the nothing at stake problem. This isn&#39;t sufficien=
t tho because the chain is a common good, and the tragedy of the commons ho=
lds for it.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; you burn them to be used at a future par=
ticular block height<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; This sounds exploitable. It seems like an att=
acker could simply focus all their burns on a particular set of 6 blocks to=
 double spend, minimizing their cost of attack.<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; i can imagine scenarios where large stak=
eholders can collude to punish smaller stakeholders simply to drive them ou=
t of business, for example<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; Are you talking about a 51% attack? This is p=
ossible in any decentralized cryptocurrency.<br>
&gt; &gt; &gt; &gt; &gt; &gt; On Mon, May 24, 2021 at 11:49 AM Erik Aronest=
y <a href=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a> wrote:=
<br>
&gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; your burn investment is always=
 &quot;at stake&quot;, any redaction can result in a loss-of-burn, because =
burns can be tied, precisely, to block-heights<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I&#39;m fuzzy on how proof of =
burn works.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; when you burn coins, you burn them to be=
 used at a future particular<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; block height: so if i&#39;m burning for =
block 553, i can only use them to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; mine block 553. if i have a choice betwe=
en two chains, one longer<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; and one shorter, i can only choose one..=
. deterministically, for that<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; burn: the chain with the height 553. if =
we fix the &quot;lead time&quot; for<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; burned coins to be weeks or even months =
in advance, miners have a very<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; strong, long-term, investment in the sta=
bility of the chain.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; therefore there is no &quot;nothing at s=
take&quot; problem. it&#39;s<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; deterministic, so miners have no choice.=
 they can only choose the<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; transactions that go into the block. the=
y cannot choose which chain<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; to mine, and it&#39;s time-locked, so ro=
llbacks and instability always<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; hurt miners the most.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; the &quot;punishment&quot; systems of Po=
S are &quot;weird at best&quot;, certainly<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; unproven. i can imagine scenarios where =
large stakeholders can<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; collude to punish smaller stakeholders s=
imply to drive them out of<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; business, for example. and then you have=
 to put checks in place to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; prevent that, and more checks for those =
prevention system...<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; in PoB, there is no complexity. simpler =
systems like this are<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; typically more secure.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; PoB also solves problems caused by &quot=
;energy dependence&quot;, which could<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; lead to state monopolies on mining (like=
 the new Bitcoin Mining<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Council). these consortiums, if state sa=
nctioned, could become a<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; source of censorship, for example. Since=
 PoB doesn&#39;t require you to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; have a live, well-connected node, it&#39=
;s harder to censor &amp; harder to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; trace.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; Eliminating this weakness seems to be in=
 the best interests of<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; existing stakeholders<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; On Mon, May 24, 2021 at 4:44 PM Billy Te=
trud <a href=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">billy.tetr=
ud@gmail.com</a> wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; proof of burn clearly solves t=
his, since nothing is held online<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Well.. the coins to be burned need =
to be online when they&#39;re burned. But yes, only a small fraction of the=
 total coins need to be online.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; your burn investment is always=
 &quot;at stake&quot;, any redaction can result in a loss-of-burn, because =
burns can be tied, precisely, to block-heights<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; So you&#39;re saying that if say so=
meone tries to mine a block on a shorter chain, that requires them to send =
a transaction burning their coins, and that transaction could also be spent=
 on the longest chain, which means their coins are burned even if the chain=
 they tried to mine on doesn&#39;t win? I&#39;m fuzzy on how proof of burn =
works.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; proof of burn can be more secu=
re than proof-of-stake<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; FYI, proof of stake can be done wit=
hout the &quot;nothing at stake&quot; problem. You can simply punish people=
 who mint on shorter chains (by rewarding people who publish proofs of this=
 happening on the main chain). In quorum-based PoS, you can punish people i=
n the quorum that propose or sign multiple blocks for the same height. The =
&quot;nothing at stake&quot; problem is a solved problem at this point for =
PoS.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Mon, May 24, 2021 at 3:47 AM Eri=
k Aronesty <a href=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</=
a> wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I don&#39;t see a way to =
get around the conflicting requirement that the keys for large amounts of c=
oins should be kept offline but those are exactly the coins we need online =
to make the scheme secure.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; proof of burn clearly solves t=
his, since nothing is held online<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; how does proof of burn so=
lve the &quot;nothing at stake&quot; problem in your view?<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; definition of nothing at stake=
: in the event of a fork, whether the<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; fork is accidental or a malici=
ous, the optimal strategy for any miner<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; is to mine on every chain, so =
that the miner gets their reward no<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; matter which fork wins. indeed=
 in proof-of-stake, the proofs are<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; published on the very chains m=
ines, so the incentive is magnified.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; in proof-of-burn, your burn in=
vestment is always &quot;at stake&quot;, any<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; redaction can result in a loss=
-of-burn, because burns can be tied,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; precisely, to block-heights<br=
>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; as a result, miners no longer =
have an incentive to mine all chains<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; in this way proof of burn can =
be more secure than proof-of-stake, and<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; even more secure than proof of=
 work<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Sun, May 23, 2021 at 3:52 A=
M Lloyd Fournier via bitcoin-dev<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a> wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Hi Billy,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I was going to write a po=
st which started by dismissing many of the weak arguments that are made aga=
inst PoS made in this thread and elsewhere.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Although I don&#39;t agre=
e with all your points you have done a decent job here so I&#39;ll focus on=
 the second part: why I think Proof-of-Stake is inappropriate for a Bitcoin=
-like system.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Proof of stake is not fit=
 for purpose for a global settlement layer in a pure digital asset (i.e. &q=
uot;digital gold&quot;) which is what Bitcoin is trying to be.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; PoS necessarily gives res=
ponsibilities to the holders of coins that they do not want and cannot hand=
le.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; In Bitcoin, large unsophi=
sticated coin holders can put their coins in cold storage without a second =
thought given to the health of the underlying ledger.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; As much as hardcore Bitco=
iners try to convince them to run their own node, most don&#39;t, and that&=
#39;s perfectly acceptable.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; At no point do their pers=
onal decisions affect the underlying consensus -- it only affects their per=
sonal security assurance (not that of the system itself).<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; In PoS systems this clean=
 separation of responsibilities does not exist.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I think that the more rig=
orously studied PoS protocols will work fine within the security claims mad=
e in their papers.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; People who believe that t=
hese protocols are destined for catastrophic consensus failure are certainl=
y in for a surprise.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; But the devil is in the d=
etail.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Let&#39;s look at what th=
e implications of using the leading proof of stake protocols would have on =
Bitcoin:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; ### Proof of SquareSpace =
(Cardano, Polkdadot)<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cardano is a UTXO based P=
oS coin based on Ouroboros Praos3 with an inbuilt on-chain delegation syste=
m5.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; In these protocols, coin =
holders who do not want to run their node with their hot keys in it delegat=
e it to a &quot;Stake Pool&quot;.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I call the resulting syst=
em Proof-of-SquareSpace since most will choose a pool by looking around for=
 one with a nice website and offering the largest share of the block reward=
.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On the surface this might=
 sound no different than someone with an mining rig shopping around for a g=
ood mining pool but there are crucial differences:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; 1.=C2=A0 The person makin=
g the decision is forced into it just because they own the currency -- some=
one with a mining rig has purchased it with the intent to make profit by pa=
rticipating in consensus.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; 2.=C2=A0 When you join a =
mining pool your systems are very much still online. You are just partaking=
 in a pool to reduce your profit variance. You still see every block that y=
ou help create and you never help create a block without seeing it first.<b=
r>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; 3.=C2=A0 If by SquareSpac=
e sybil attack you gain a dishonest majority and start censoring transactio=
ns how are the users meant to redelegate their stake to honest pools?<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0I gues=
s they can just send a transaction delegating to another pool...oh wait I g=
uess that might be censored too! This seems really really bad.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0 =C2=A0 =C2=A0In Bit=
coin, miners can just join a different pool at a whim. There is nothing the=
 attacker can do to stop them. A temporary dishonest majority heals relativ=
ely well.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; There is another severe d=
isadvantage to this on-chain delegation system: every UTXO must indicate wh=
ich staking account this UTXO belongs to so the appropriate share of block =
rewards can be transferred there.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Being able to associate e=
very UTXO to an account ruins one of the main privacy advantages of the UTX=
O model.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; It also grows the size of=
 the blockchain significantly.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; ### &quot;Pure&quot; proo=
f of stake (Algorand)<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Algorand&#39;s4 approach =
is to only allow online stake to participate in the protocol.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Theoretically, This means=
 that keys holding funds have to be online in order for them to author bloc=
ks when they are chosen.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Of course in reality no o=
ne wants to keep their coin holding keys online so in Alogorand you can aut=
horize a set of &quot;participation keys&quot;1 that will be used to create=
 blocks on your coin holding key&#39;s behalf.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Hopefully you&#39;ve spot=
ted the problem.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; You can send your partici=
pation keys to any malicious party with a nice website (see random example =
2) offering you a good return.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Damn it&#39;s still Proof=
-of-SquareSpace!<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; The minor advantage is th=
at at least the participation keys expire after a certain amount of time so=
 eventually the SquareSpace attacker will lose their hold on consensus.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Importantly there is also=
 less junk on the blockchain because the participation keys are delegated o=
ff-chain and so are not making as much of a mess.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; ### Conclusion<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I don&#39;t see a way to =
get around the conflicting requirement that the keys for large amounts of c=
oins should be kept offline but those are exactly the coins we need online =
to make the scheme secure.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; If we allow delegation th=
en we open up a new social attack surface and it degenerates to Proof-of-Sq=
uareSpace.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; For a &quot;digital gold&=
quot; like system like Bitcoin we optimize for simplicity and desperately w=
ant to avoid extraneous responsibilities for the holder of the coin.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; After all, gold is an ine=
rt element on the periodic table that doesn&#39;t confer responsibilities o=
n the holder to maintain the quality of all the other bars of gold out ther=
e.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Bitcoin feels like this t=
oo and in many ways is more inert and beautifully boring than gold.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; For Bitcoin to succeed I =
think we need to keep it that way and Proof-of-Stake makes everything a bit=
 too exciting.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I suppose in the end the =
market will decide what is real digital gold and whether these bad technica=
l trade offs are worth being able to say it uses less electricity. It goes =
without saying that making bad technical decisions to appease the current p=
olitical climate is an anathema to Bitcoin.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Would be interested to kn=
ow if you or others think differently on these points.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cheers,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; LL<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Fri, 21 May 2021 at 19=
:21, Billy Tetrud via bitcoin-dev <a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
 wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I think there is a l=
ot of misinformation and bias against Proof of Stake. Yes there have been l=
ots of shady coins that use insecure PoS mechanisms. Yes there have been ma=
ssive issues with distribution of PoS coins (of course there have also been=
 massive issues with PoW coins as well). However, I want to remind everyone=
 that there is a difference between &quot;proved to be impossible&quot; and=
 &quot;have not achieved recognized success yet&quot;. Most of the argument=
s levied against PoS are out of date or rely on unproven assumptions or ext=
rapolation from the analysis of a particular PoS system. I certainly don&#3=
9;t think we should experiment with bitcoin by switching to PoS, but from m=
y research, it seems very likely that there is a proof of stake consensus p=
rotocol we could build that has substantially higher security (cost / capit=
al required to execute an attack) while at the same time costing far less r=
esources (which do translate to fees on the network) without compromising a=
ny of the critical security properties bitcoin relies on. I think the criti=
cal piece of this is the disagreements around hardcoded checkpoints, which =
is a critical piece solving attacks that could be levied on a PoS chain, an=
d how that does (or doesn&#39;t) affect the security model.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; @Eric Your proof of =
stake fallacy seems to be saying that PoS is worse when a 51% attack happen=
s. While I agree, I think that line of thinking omits important facts:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=A0 =C2=A0The ca=
pital required to 51% attack a PoS chain can be made substantially greater =
than on a PoS chain.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=A0 =C2=A0The ca=
pital the attacker stands to lose can be substantially greater as well if t=
he attack is successful.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=A0 =C2=A0The ef=
fectiveness of paying miners to raise the honest fraction of miners above 5=
0% may be quite bad.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=A0 =C2=A0Allowi=
ng a 51% attack is already unacceptable. It should be considered whether wh=
at happens in the case of a 51% may not be significantly different. The cur=
rency would likely be critically damaged in a 51% attack regardless of cons=
ensus mechanism.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Proof-of-stake =
tends towards oligopolistic control<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; People repeat this o=
ften, but the facts support this. There is no centralization pressure in an=
y proof of stake mechanism that I&#39;m aware of. IE if you have 10 times a=
s much coin that you use to mint blocks, you should expect to earn 10x as m=
uch minting revenue - not more than 10x. By contrast, proof of work does in=
 fact have clear centralization pressure - this is not disputed. Our goal i=
n relation to that is to ensure that the centralization pressure remains in=
signifiant. Proof of work also clearly has a lot more barriers to entry tha=
n any proof of stake system does. Both of these mean the tendency towards o=
ligopolistic control is worse for PoW.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Energy usage, i=
n-and-of-itself, is nothing to be ashamed of!!<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I certainly agree. B=
itcoin&#39;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 pr=
obably should... eventually.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Proof of Stake =
is only resilient to =E2=85=93 of the network demonstrating a Byzantine Fau=
lt, whilst Proof of Work is resilient up to the =C2=BD threshold<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; I see no mention of =
this in the pos.pdf you linked to. I&#39;m not aware of any proof that all =
PoS systems have a failure threshold of 1/3. I know that staking systems li=
ke Casper do in fact have that 1/3 requirement. However there are PoS desig=
ns that should exceed that up to nearly 50% as far as I&#39;m aware. Proof =
of work is not in fact resilient up to the 1/2 threshold in the way you wou=
ld think. IE, if 100% of miners are currently honest and have a collective =
100 exahashes/s hashpower, an attacker does not need to obtain 100 exahashe=
s/s, but actually only needs to accumulate 50 exahashes/s. This is because =
as the attacker accumulates hashpower, it drives honest miners out of the m=
arket as the difficulty increases to beyond what is economically sustainabl=
e. Also, its been shown that the best proof of work can do is require an at=
tacker to obtain 33% of the hashpower because of the selfish mining attack =
discussed in depth in this paper: <a href=3D"https://arxiv.org/abs/1311.024=
3" rel=3D"noreferrer" target=3D"_blank">https://arxiv.org/abs/1311.0243</a>=
. Together, both of these things reduce PoW&#39;s security by a factor of a=
bout 83% (1 - 50%*33%).<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Proof of Stake =
requires other trade-offs which are incompatible with Bitcoin&#39;s objecti=
ve (to be a trustless digital cash) =E2=80=94 specifically the famous &quot=
;security vs. liveness&quot; guarantee<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Do you have a good s=
ource that talks about why you think proof of stake cannot be used for a tr=
ustless digital cash?<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; You cannot gain=
 tokens without someone choosing to give up those coins - a form of permiss=
ion.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; This is not a practi=
cal constraint. Just like in mining, some nodes may reject you, but there w=
ill likely be more that will accept you, some sellers may reject you, but m=
ost would accept your money as payment for bitcoins. I don&#39;t think requ=
iring the &quot;permission&quot; of one of millions of people in the market=
 can be reasonably considered a &quot;permissioned currency&quot;.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; 2.=C2=A0 Proof =
of stake must have a trusted means of timestamping to regulate overproducti=
on of blocks<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Both PoW and PoS cou=
ld 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.<=
br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Wed, May 19, 2021=
 at 5:32 AM Michael Dubrovsky via bitcoin-dev <a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a> wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Ah sorry, I did=
n&#39;t realize this was, in fact, a different thread! :)<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Wed, May 19,=
 2021 at 10:07 AM Michael Dubrovsky <a href=3D"mailto:mike@powx.org" target=
=3D"_blank">mike@powx.org</a> wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Folks, I s=
uggest we keep the discussion to PoW, oPoW, and the BIP itself. PoS, VDFs, =
and so on are interesting but I guess there are other threads going on thes=
e topics already where they would be relevant.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Also, it&#=
39;s important to distinguish between oPoW and these other &quot;alternativ=
es&quot; to Hashcash. oPoW is a true Proof of Work that doesn&#39;t alter t=
he core game theory or security assumptions of Hashcash and actually contai=
ns SHA (can be SHA3, SHA256, etc hash is interchangeable).<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Cheers,<br=
>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Mike<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Tue, Ma=
y 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a> wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; 1.=C2=
=A0 i never suggested vdf&#39;s to replace pow.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; 2.=C2=
=A0 my suggestion was specifically in the context of a working<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0proof-of-burn protocol<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=
=A0 =C2=A0vdfs used only for timing (not block height)<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=
=A0 =C2=A0blind-burned coins of a specific age used to replace proof of wor=
k<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=
=A0 =C2=A0the required &quot;work&quot; per block would simply be a competi=
tion to<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0acquire rewards, and so miners would have to burn coins, well=
 in<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0advance, and hope that their burned coins got rewarded in som=
e far<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0future<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=
=A0 =C2=A0the point of burned coins is to mimic, in every meaningful way, t=
he<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0value gained from proof of work... without some of the securi=
ty<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0drawbacks<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=
=A0 =C2=A0the miner risks losing all of his burned coins (like all miners r=
isk<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0losing their work in each block)<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=
=A0 =C2=A0new burns can&#39;t be used<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=
=A0 =C2=A0old burns age out (like ASICs do)<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; -=C2=
=A0 =C2=A0other requirements on burns might be needed to properly mirror th=
e<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0properties of PoW and the incentives Bitcoin uses to mine hon=
estly.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; 3.=C2=
=A0 i do believe it is possible that a &quot;burned coin + vdf system&quot;=
<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0might be more secure in the long run, and that if the entire =
space<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0agreed that such an endeavor was worthwhile, a test net could=
 be spun<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0up, and a hard-fork could be initiated.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; 4.=C2=
=A0 i would never suggest such a thing unless i believed it was<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0possible that consensus was possible. so no, this is not an &=
quot;alt<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;=C2=A0=
 =C2=A0 =C2=A0coin&quot;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; On Tu=
e, May 18, 2021 at 10:02 AM Zac Greenwood <a href=3D"mailto:zachgrw@gmail.c=
om" target=3D"_blank">zachgrw@gmail.com</a> wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
Hi ZmnSCPxj,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
Please note that I am not suggesting VDFs as a means to save energy, but so=
lely as a means to make the time between blocks more constant.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
Zac<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
On Tue, 18 May 2021 at 12:42, ZmnSCPxj <a href=3D"mailto:ZmnSCPxj@protonmai=
l.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a> wrote:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<=
br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; Good morning Zac,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; &gt; VDFs might enable more constant block times, for instance by havi=
ng a two-step PoW:<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; &gt; 1.=C2=A0 Use a VDF that takes say 9 minutes to resolve (VDF being=
 subject to difficulty adjustments similar to the as-is). As per the proper=
ty of VDFs, miners are able show proof of work.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; &gt; 2.=C2=A0 Use current PoW mechanism with lower difficulty so findi=
ng a block takes 1 minute on average, again subject to as-is difficulty adj=
ustments.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; &gt; As a result, variation in block times will be greatly reduced.<br=
>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; As I understand it, another weakness of VDFs is that they are not inhe=
rently progress-free (their sequential nature prevents that; they are inher=
ently progress-requiring).<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; Thus, a miner which focuses on improving the amount of energy that it =
can pump into the VDF circuitry (by overclocking and freezing the circuitry=
), could potentially get into a winner-takes-all situation, possibly leadin=
g to even worse competition and even more energy consumption.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; After all, if you can start mining 0.1s faster than the competition, t=
hat is a 0.1s advantage where only you can mine in the entire world.<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; Regards,<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; =
&gt; ZmnSCPxj<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; bitco=
in-dev mailing list<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a hr=
ef=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=
=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailman=
/listinfo/bitcoin-dev</a><br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; --<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Michael Du=
brovsky<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Founder; P=
oWx<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D=
"http://www.PoWx.org" rel=3D"noreferrer" target=3D"_blank">www.PoWx.org</a>=
<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; --<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Michael Dubrovs=
ky<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; Founder; PoWx<b=
r>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D"http=
://www.PoWx.org" rel=3D"noreferrer" target=3D"_blank">www.PoWx.org</a><br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; bitcoin-dev mai=
ling list<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a><br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D"http=
s://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferr=
er" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev</a><br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; bitcoin-dev mailing =
list<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D"https://l=
ists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer" t=
arget=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin=
-dev</a><br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; bitcoin-dev mailing list<=
br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo=
undation.org</a><br>
&gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; &gt; <a href=3D"https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=
=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br>
&gt;<br>
&gt;<br>
</blockquote></div>

--00000000000001e03205c36aba22--