path: root/44/11e51bfb9886f33669524473abb3471f0596c8

Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5E7C9C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 May 2021 22:07:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 2F53D6074F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 May 2021 22:07:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level: 
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fz4AhlkmoFR8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 May 2021 22:07:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [IPv6:2a00:1450:4864:20::12b])
 by smtp3.osuosl.org (Postfix) with ESMTPS id D727160733
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 May 2021 22:07:18 +0000 (UTC)
Received: by mail-lf1-x12b.google.com with SMTP id x38so2825002lfa.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 May 2021 15:07:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=D8xLM+I+QvLKwy39DUz55FzhmuYj6Y7TqeFlR4oLP6Q=;
 b=oJyNmnOK0RDx88TTb0HRoBDERseJeZy9iJz5JmvmcoHeCNeqB4jyYrWpcEFOAi3FKS
 9HmfFlEMHAzdYbtAqjIpg4j02+PbTkuunLKSjZUBas26RFT8dIXj8hAVqbkUoy4MwLmN
 VKvSjH/DY1hLK0X2NaaE389QyKn8/3TebzjkDRmzifZo6jpH0DSObsZoIUHonTkkAHO7
 V3obVaBzsIZAj1ve+4+J9AJHt/Bz/d7KF2m7s5DM1wGyFFNblneYN0bFLmmaVzQSp90o
 T37a0NQA+CG6y96XbaG8ru8y1zOVutk84lVWI7gWcnQrNWOsoRuiBO2dmnHDfiEz0JQE
 54sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=D8xLM+I+QvLKwy39DUz55FzhmuYj6Y7TqeFlR4oLP6Q=;
 b=nXTQEZBv9Z9swGKsKPpPTKRPYUjPv29n1XdWwGZaTCbSRZomFzI/z+rpbaeMCD/xyz
 fERaUdzsGB+eScjXdUZWoPt4KLU64Pl6YwVl5FaefJ9rLOyyHnfzvw6s6PoJ4fSsWcWe
 wRIvD5mLTAf1MzqoD7em/hnZzdIt6BE70saDGJy+qTm9IbwX1wB8/tRKpVRM6OoIirQs
 F6LmrjkXek5+S/adA38RMzpoIM0ue7UiA8ph4dwCDPCZstvJ43nOTareaDHC08xPO8Pv
 9M+ePu+HxSARKD7vMpVtrp5d67IumKzz4KlspPYh//B09lxujtsQZZuhjLUd8Jl5tGxa
 SUzw==
X-Gm-Message-State: AOAM532dGIYySOYRBMNVTeFvy2oDpfYcc2x1K4Zl+k3to0OBqC+7Z+Nh
 qVs/6MPGNsAca1DuUYvDMYXO26rS5Pb/4v+68Mp5Rio=
X-Google-Smtp-Source: ABdhPJwkCHM8O6bat3sFHSFdG/Wn256EPzDSloedTjCOCIabix3+as+/n+kn9BuucsQlF7IMVvbRo713zVskIJkyG1Q=
X-Received: by 2002:a05:6512:228f:: with SMTP id
 f15mr163664lfu.537.1622066835529; 
 Wed, 26 May 2021 15:07:15 -0700 (PDT)
MIME-Version: 1.0
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com>
 <CAJowKgJOZwb0PgW93Y+Jy+yi1kv09Gu7-gjWvt7eUqWfJ_zJuw@mail.gmail.com>
 <CAGpPWDbWvBQd3xh8fx+Le8br2LmsqC_Tds5R=wvw1EmiLk42Xw@mail.gmail.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>
In-Reply-To: <L1IhpSfDNx5OPXYnHfcFDiOzJa8jihbR8YE4MBRaYjuQt2GQsrNd0UnJaJg_mCgHNOcG6QE1Wrwp6zZ-YxOgDNu_aBE67HJkbemHz5Nz9c4=@protonmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 26 May 2021 18:07:02 -0400
Message-ID: <CAJowKgKgGynQ9NYe_7xEai0tcBW4b=tQnNpv9vndx1hLCowfWg@mail.gmail.com>
To: befreeandopen <befreeandopen@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 26 May 2021 22:14:48 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 SatoshiSingh <SatoshiSingh@protonmail.com>,
 Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2021 22:07:22 -0000

note: the "nothing at stake" problem you propose is not broken for
proof-of-burn, because the attacker

a) has no idea which past transactions are burns
b) has no way to use his mining power, even 5%, to maliciously improve
his odds of being selected

On Wed, May 26, 2021 at 9:12 AM befreeandopen
<befreeandopen@protonmail.com> wrote:
>
>
>
> @befreeandopen I guess I misunderstood your selfish minting attack. Let m=
e make sure I understand it. You're saying it would go as follows?:
>
> 1. The malicious actor comes across an opportunity to mint the next 3 blo=
cks. But they hold off and don't release their blocks just yet.
> 2. They receive a new block minted by someone else.
> 3. The malicious actor then chooses to release their other 2 blocks on on=
 the second from the top block if it gives them more blocks in the future t=
han 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 would=
n't have the information available for minters to know how blocks will affe=
ct their future prospects of minting. Otherwise this would introduce the pr=
oblem of stake grinding. This can be done using collaborative randomness (w=
here numbers from many parties are combined to create a random number that =
no individual party could predict). In fact, that's what the Casper protoco=
l does to decide quorums. In a non quorum case, you can do something like r=
ecord a hash of a number in the block header, and then have a second step t=
o release that number later. Rewards can be given can be used to ensure min=
ters act honestly here by minting messages that release these numbers and n=
ot releasing their secret numbers too early.
>
>
> Yes, you misunderstood it. First, let me say that the above thoughts of y=
ours are incorrect, at least for non-quorum case. Since the transition in t=
he blockchain system from S1 to S2 is only by adding new block, and since s=
takers always need to be able to decide whether or not they can add the nex=
t block, it follows that if a staker creates a new block locally, she can d=
ecide 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 typical for PoS, introdu=
ces 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 amo=
unt 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 st=
ake has chance K to be the one who will create the next stake. In other wor=
ds, the power of stakers is supposed to be linear in the system - you own 1=
0 coins gives you 10x the chance of finding block over someone who has 1 co=
in.
>
> What i was claiming is that using the technique I have described, this li=
nearity is violated. Why? Well, it works for honest stakers among the compe=
tition of honest stakers - they really do have the chance of K to find the =
next block. However, the attacker, using nothing at stake, checks her abili=
ty 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, ther=
e is a new chance to build the block, it is not uncommon that she finds she=
 is indeed able to build such block C' on top of B. Here it is likely t(C')=
 > t(C) as the attacker has relatively low stake. Note that in order to pro=
duce such C', she not only could have tried the current timestamp t(D), but=
 also all previous timestamps up to t(B) (usually that's the consensus rule=
, but it may depend on a specific consensus). So her chance to produce such=
 C' is greater than her previous chance of producing C (which chance was li=
mited 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 tha=
t her chance to find such D' is greater than was her chance of finding D be=
cause again there are likely multiple timestamps she could try. This all wa=
s 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', wh=
ich can not be punished despite the fact that she indeed produced two diffe=
rent forks. She can not be punished because this production was local and o=
nly the final result of A-B-C'-D' was published, in which case she gained a=
n 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 p=
roof 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 n=
othing 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 wit=
h 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 mi=
nt a block. Eg by determining whether someone can mint a block based on the=
ir public key hidden behind hashes (as normal in addresses). Only when some=
one does in fact mint a block do they reveal their hidden public key in ord=
er to prove they are allowed to mint the block.
>
>
> This is true, but you are mixing quorum and non-quorum systems. My object=
ion 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 know=
n producer is the only target at any given point of time. This of course do=
es not apply to any other type of system where future producers are not kno=
wn. No need to dispute, again, something that was not claimed.
>
>
>
>
> > I agree that introduction of punishment itself does not imply introduci=
ng a problem elsewhere (which I did not claim if you reread my previous mes=
sage)
>
> I'm glad we agree there. Perhaps I misunderstood what you meant by "you s=
hould 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 it:
>
> "Of course you can always change the rules in a way that a certain specif=
ic attack is not doable, but you should not omit to mention that by doing s=
o, typically, you have introduced another problem elsewhere, or you have no=
t solved it completely."
>
> You can parse this as: (CREATE PROBLEM ELSEWHERE) OR (NOT SOLVE IT COMPLE=
TELY)
> 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 she does=
 not miss a chance to create a block, her significance in the system will a=
lways increase in time. It will increase relative to all normal users who d=
o 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 j=
ust like any other financial activity. Others may find more success spendin=
g their time doing things other than figuring out how to mint coins. In tha=
t case, they'll be able to earn more coin that they could later decide to u=
se to mint blocks if they decide to.
>
>
> This only supports the point I was making. Since the optimal scenario wit=
h all existing coins participating is just theoretical, the attacker's posi=
tion will ever so improve. It seems we are in agreement here, great.
>
>
>
>
> > Just because of the above we must reject PoS as being critically insecu=
re
>
> I think the only thing we can conclude from this is that you have come up=
 with an insecure proof of stake protocol. I don't see how anything you'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 the burd=
en 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 solv=
e 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 n=
ot 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 o=
f such systems).
>
> Of course the list of problems of PoS systems do not end with just nothin=
g at stake, but it is good enough example that by itself prevents its adopt=
ion in decentralized consensus. No need to go to other hard problems withou=
t 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 prolon=
g this chain or not and if so with what timestamp."
>>
>> The scenario you describe would only be likely to happen at all if the m=
alicious actor has a very large fraction of the stake - probably quite clos=
e to 50%. At that point, you're talking about a 51% attack, not the nothing=
 at stake problem. The nothing at stake problem is the problem where anyone=
 will mint on any chain. Its clear that if there's a substantial punishment=
 for minting on chains other than the one that eventually wins, every minte=
r without a significant fraction of the stake will be honest and not attemp=
t to mint on old blocks or support someone else's attempt to mint on old bl=
ocks (until and if it becomes the heaviest chain). Because the attacker wou=
ld need probably >45% of the active stake (take a look at the reasoning her=
e for a deeper analysis of that statement), I don't agree that punishment i=
s not a sufficient mitigation of the nothing at stake problem. To exploit t=
he nothing at stake problem, you basically need to 51% attack, at which poi=
nt you've exceeded the operating conditions of the system, so of course its=
 gonna have problems, just like a 51% attack would cause with PoW.
>>
>>
>> This is not at all the case. The attacker benefits using the described t=
echnique at any size of the stake and significantly so with just 5% of the =
stake. By significantly, I do not mean that the attacker is able to complet=
ely take control the network (in short term), but rather that the attacker =
has significant advantage in the number of blocks she creates compared to w=
hat she "should be able to create". This means the attacker's stake increas=
es significantly faster than of the honest nodes, which in long term is ver=
y serious in PoS system. If you believe close to 50% is needed for that, yo=
u need to redo your math. So no, you are wrong stating that "to exploit not=
hing at stake problem you basically need to 51% attack". It is rather the o=
pposite - eventually, nothing at stake attack leads to ability to perform 5=
1% attack.
>>
>>
>>
>> > I am not sure if this is what you call quorum-based PoS
>>
>> Yes, pre-selected minters is exactly what I mean by that.
>>
>> > it allows the attacker to know who to attack at which point with power=
ful 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, th=
e reverse isn't as easy. With a quorum-based PoS system, you can see their =
public key and address, but finding out their IP to DOS would be a huge cha=
llenge 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 o=
f origin of blocks is doable and has been done in past. So again, I very mu=
ch disagree with your conclusion that this is somehow secure. It is absolut=
ely insecure.
>>
>>
>>
>> Note, tho, that quorum-based PoS generally also have punishments as part=
 of the protocol. The introduction of punishments do indeed handily solve t=
he nothing at stake problem. And you didn't mention a single problem that t=
he punishments introduce that weren't already there before punishments. The=
re are tradeoffs with introducing punishments (eg in some cases you might p=
unish honest actors), but they are minor in comparison to solving the nothi=
ng at stake problem.
>>
>>
>> While I agree that introduction of punishment itself does not imply intr=
oducing a problem elsewhere (which I did not claim if you reread my previou=
s message), it does introduce additional complexity which may introduce pro=
blem, but more importantly, while it slightly improves resistance against t=
he nothing at stake attack, it solves absolutely nothing. Your claim is bas=
ed on wrong claim of needed close to 50% stake, but that could not be farth=
er from the truth. It is not true even in optimal conditions when all parti=
cipants of the network stake or delegate their stake. These optimal conditi=
ons rarely, if ever, occur. And that's another thing that we have not menti=
on in our debate, so please allow me to introduce another problem to PoS.
>>
>> 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 automa=
tically part of the staking process even when they are moved. But in many P=
oS 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 an=
d 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, i=
n 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 cool=
ing 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 theoreti=
cal. Then if we do not have the optimal condition, it means that a staker w=
ith K% of the total available supply increases it's percentage over time to=
 some amounts >K%. As long as the staker makes sure (which is not that hard=
) that she does not miss a chance to create a block, her significance in th=
e system will always increase in time. It will increase relative to all nor=
mal users who do not stake (if there are any) and relative to all other sta=
kers 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 th=
us she will gain significance in such a system. The technique I have descri=
bed, and that you mistakenly think is viable only with huge amounts of stak=
e, only puts the attacker to even greater advantage. But even without the d=
escribed attack (which exploits nothing at stake), the PoS system converges=
 to a system more and more controlled by powerful entity, which we can assu=
me is the attacker.
>>
>>
>> So I don't think it is at all misleading to claim that "nothing at stake=
" is a solved problem. I do in fact mean that the solutions to that problem=
 don't introduce any other problems with anywhere near the same level of si=
gnificance.
>>
>>
>> It still stands as truly misleading claim. I disagree that introducing D=
DOS opportunity with medium level of difficulty for the attacker to impleme=
nt it, in case of "quorum-based PoS" is not a problem anywhere near the sam=
e level of significance. Such an attack vector allows you to turn off the n=
etwork if you spend some time and money. That is hardly acceptable.
>>
>> Just because of the above we must reject PoS as being critically insecur=
e until someone invents and demonstrates an actual way of solving these iss=
ues.
>>
>>
>>
>> On Tue, May 25, 2021 at 3:00 AM Erik Aronesty <erik@q32.com> wrote:
>>>
>>> > > you burn them to be used at a future particular block height
>>>
>>> > This sounds exploitable. It seems like an attacker could simply focus=
 all their burns on a particular set of 6 blocks to double spend, minimizin=
g 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> w=
rote:
>>> >
>>> > 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 o=
f the chain.
>>> >
>>> > Yes, but the same can be said of any coin, even ones that do have the=
 nothing at stake problem. This isn't sufficient tho because the chain is a=
 common good, and the tragedy of the commons holds for it.
>>> >
>>> > > you burn them to be used at a future particular block height
>>> >
>>> > This sounds exploitable. It seems like an attacker could simply focus=
 all their burns on a particular set of 6 blocks to double spend, minimizin=
g their cost of attack.
>>> >
>>> > > i can imagine scenarios where large stakeholders can collude to pun=
ish smaller stakeholders simply to drive them out of business, for example
>>> >
>>> > Are you talking about a 51% attack? This is possible in any decentral=
ized cryptocurrency.
>>> >
>>> >
>>> > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty <erik@q32.com> wrote:
>>> >>
>>> >> > > your burn investment is always "at stake", any redaction can res=
ult in a loss-of-burn, because burns can be tied, precisely, to block-heigh=
ts
>>> >> > 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 t=
o
>>> >> mine block 553.   if i have a choice between two chains, one longer
>>> >> and one shorter, i can only choose one... deterministically, for tha=
t
>>> >> 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 ve=
ry
>>> >> 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 are
>>> >> 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 require you t=
o
>>> >> 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 held online
>>> >> >
>>> >> > Well.. the coins to be burned need to be online when they're burne=
d. But yes, only a small fraction of the total coins need to be online.
>>> >> >
>>> >> > > your burn investment is always "at stake", any redaction can res=
ult in a loss-of-burn, because burns can be tied, precisely, to block-heigh=
ts
>>> >> >
>>> >> > So you're saying that if say someone tries to mine a block on a sh=
orter chain, that requires them to send a transaction burning their coins, =
and that transaction could also be spent on the longest chain, which means =
their coins are burned even if the chain they tried to mine on doesn't win?=
 I'm fuzzy on how proof of burn works.
>>> >> >
>>> >> > > proof of burn can be more secure than proof-of-stake
>>> >> >
>>> >> > FYI, proof of stake can be done without the "nothing at stake" pro=
blem. 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 multipl=
e blocks for the same height. The "nothing at stake" problem is a solved pr=
oblem at this point for PoS.
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty <erik@q32.com> wrote=
:
>>> >> >>
>>> >> >> > I don't see a way to get around the conflicting requirement tha=
t the keys for large amounts of coins should be kept offline but those are =
exactly the coins we need online to make the scheme secure.
>>> >> >>
>>> >> >> proof of burn clearly solves this, since nothing is held 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 t=
he
>>> >> >> fork is accidental or a malicious, the optimal strategy for any m=
iner
>>> >> >> 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 ar=
e
>>> >> >> 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 chain=
s
>>> >> >>
>>> >> >> 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 elsew=
here.
>>> >> >> > Although I don't agree with all your points you have done a dec=
ent job here so I'll focus on the second part: why I think Proof-of-Stake i=
s inappropriate for a Bitcoin-like system.
>>> >> >> >
>>> >> >> > Proof of stake is not fit for purpose for a global settlement l=
ayer 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 put their co=
ins in cold storage without a second thought given to the health of the und=
erlying ledger.
>>> >> >> > As much as hardcore Bitcoiners try to convince them to run thei=
r own node, most don't, and that's perfectly acceptable.
>>> >> >> > At no point do their personal decisions affect the underlying c=
onsensus -- it only affects their personal security assurance (not that of =
the system itself).
>>> >> >> > In PoS systems this clean separation of responsibilities does n=
ot exist.
>>> >> >> >
>>> >> >> > I think that the more rigorously studied PoS protocols will wor=
k fine within the security claims made in their papers.
>>> >> >> > People who believe that these protocols are destined for catast=
rophic consensus failure are certainly in for a surprise.
>>> >> >> > But the devil is in the detail.
>>> >> >> > Let's look at what the implications of using the leading proof =
of stake protocols would have on Bitcoin:
>>> >> >> >
>>> >> >> > ### Proof of SquareSpace (Cardano, Polkdadot)
>>> >> >> >
>>> >> >> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] wi=
th an inbuilt on-chain delegation system[5].
>>> >> >> > In these protocols, coin holders who do not want to run their n=
ode with their hot keys in it delegate it to a "Stake Pool".
>>> >> >> > I call the resulting system Proof-of-SquareSpace since most wil=
l 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 there are crucial =
differences:
>>> >> >> >
>>> >> >> > 1. The person making the decision is forced into it just becaus=
e 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. Y=
ou still see every block that you help create and *you never help create a =
block without seeing it first*.
>>> >> >> >
>>> >> >> > 3. If by SquareSpace sybil attack you gain a dishonest majority=
 and start censoring transactions how are the users meant to redelegate the=
ir 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. Th=
ere is nothing the attacker can do to stop them. A temporary dishonest majo=
rity heals relatively well.
>>> >> >> >
>>> >> >> > There is another severe disadvantage to this on-chain delegatio=
n system: every UTXO must indicate which staking account this UTXO belongs =
to so the appropriate share of block rewards can be transferred there.
>>> >> >> > Being able to associate every UTXO to an account ruins one of t=
he main privacy advantages of the UTXO model.
>>> >> >> > It also grows the size of the blockchain significantly.
>>> >> >> >
>>> >> >> > ### "Pure" proof of stake (Algorand)
>>> >> >> >
>>> >> >> > Algorand's[4] approach is to only allow online stake to partici=
pate in the protocol.
>>> >> >> > Theoretically, This means that keys holding funds have to be on=
line in order for them to author blocks when they are chosen.
>>> >> >> > Of course in reality no one wants to keep their coin holding ke=
ys 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 wit=
h a nice website (see random example [2]) offering you a good return.
>>> >> >> > Damn it's still Proof-of-SquareSpace!
>>> >> >> > The minor advantage is that at least the participation keys exp=
ire after a certain amount of time so eventually the SquareSpace attacker w=
ill lose their hold on consensus.
>>> >> >> > Importantly there is also less junk on the blockchain because t=
he 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 tha=
t the keys for large amounts of coins should be kept offline but those are =
exactly the coins we need online to make the scheme secure.
>>> >> >> > If we allow delegation then we open up a new social attack surf=
ace and it degenerates to Proof-of-SquareSpace.
>>> >> >> >
>>> >> >> > For a "digital gold" like system like Bitcoin we optimize for s=
implicity 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 al=
l the other bars of gold out there.
>>> >> >> > Bitcoin feels like this too and in many ways is more inert and =
beautifully boring than gold.
>>> >> >> > For Bitcoin to succeed I think we need to keep it that way and =
Proof-of-Stake makes everything a bit too exciting.
>>> >> >> >
>>> >> >> > I suppose in the end the market will decide what is real digita=
l gold and whether these bad technical trade offs are worth being able to s=
ay it uses less electricity. It goes without saying that making bad technic=
al decisions to appease the current political climate is an anathema to Bit=
coin.
>>> >> >> >
>>> >> >> > Would be interested to know if you or others think differently =
on these points.
>>> >> >> >
>>> >> >> > [1]: https://developer.algorand.org/docs/run-a-node/participate=
/generate_keys/
>>> >> >> > [2]: https://staking.staked.us/algorand-staking
>>> >> >> > [3]: https://eprint.iacr.org/2017/573.pdf
>>> >> >> > [4]: https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-=
75b3-44de-bc7f-805f0e53a8d9_theoretical.pdf
>>> >> >> > [5]: https://hydra.iohk.io/build/790053/download/1/delegation_d=
esign_spec.pdf
>>> >> >> >
>>> >> >> > Cheers,
>>> >> >> >
>>> >> >> > LL
>>> >> >> >
>>> >> >> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <bit=
coin-dev@lists.linuxfoundation.org> wrote:
>>> >> >> >>
>>> >> >> >> I think there is a lot of misinformation and bias against Proo=
f of Stake. Yes there have been lots of shady coins that use insecure PoS m=
echanisms. Yes there have been massive issues with distribution of PoS coin=
s (of course there have also been massive issues with PoW coins as well). H=
owever, I want to remind everyone that there is a difference between "prove=
d 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 assum=
ptions or extrapolation from the analysis of a particular PoS system. I cer=
tainly don't think we should experiment with bitcoin by switching to PoS, b=
ut from my research, it seems very likely that there is a proof of stake co=
nsensus protocol we could build that has substantially higher security (cos=
t / capital required to execute an attack) while at the same time costing f=
ar less resources (which do translate to fees on the network) *without* com=
promising any of the critical security properties bitcoin relies on. I thin=
k the critical piece of this is the disagreements around hardcoded checkpoi=
nts, which is a critical piece solving attacks that could be levied on a Po=
S chain, and how that does (or doesn't) affect the security model.
>>> >> >> >>
>>> >> >> >> @Eric Your proof of stake fallacy seems to be saying that PoS =
is worse when a 51% attack happens. While I agree, I think that line of thi=
nking omits important facts:
>>> >> >> >> * The capital required to 51% attack a PoS chain can be made s=
ubstantially 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 fract=
ion 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 significant=
ly different. The currency would likely be critically damaged in a 51% atta=
ck regardless of consensus mechanism.
>>> >> >> >>
>>> >> >> >> > Proof-of-stake tends towards oligopolistic control
>>> >> >> >>
>>> >> >> >> People repeat this often, but the facts support this. There is=
 no centralization pressure in any proof of stake mechanism that I'm aware =
of. IE if you have 10 times as much coin that you use to mint blocks, you s=
hould expect to earn 10x as much minting revenue - not more than 10x. By co=
ntrast, proof of work does in fact have clear centralization pressure - thi=
s is not disputed. Our goal in relation to that is to ensure that the centr=
alization pressure remains insignifiant. Proof of work also clearly has a l=
ot more barriers to entry than any proof of stake system does. Both of thes=
e mean the tendency towards oligopolistic control is worse for PoW.
>>> >> >> >>
>>> >> >> >> > Energy usage, in-and-of-itself, is nothing to be ashamed of!=
!
>>> >> >> >>
>>> >> >> >> I certainly agree. Bitcoin's energy usage at the moment is I t=
hink quite warranted. However, the question is: can we do substantially bet=
ter. I think if we can, we probably should... eventually.
>>> >> >> >>
>>> >> >> >> > Proof of Stake is only resilient to =E2=85=93 of the network=
 demonstrating a Byzantine Fault, whilst Proof of Work is resilient up to t=
he =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 that up to nearly 50% as=
 far as I'm aware. Proof of work is not in fact resilient up to the 1/2 thr=
eshold in the way you would think. IE, if 100% of miners are currently hone=
st and have a collective 100 exahashes/s hashpower, an attacker does not ne=
ed to obtain 100 exahashes/s, but actually only needs to accumulate 50 exah=
ashes/s. This is because as the attacker accumulates hashpower, it drives h=
onest miners out of the market as the difficulty increases to beyond what i=
s economically sustainable. Also, its been shown that the best proof of wor=
k can do is require an attacker to obtain 33% of the hashpower because of t=
he selfish mining attack discussed in depth in this paper: https://arxiv.or=
g/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 are incompat=
ible with Bitcoin's objective (to be a trustless digital cash) =E2=80=94 sp=
ecifically 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 to give up t=
hose coins - a form of permission.
>>> >> >> >>
>>> >> >> >> This is not a practical constraint. Just like in mining, some =
nodes may reject you, but there will likely be more that will accept you, s=
ome 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 p=
eople 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 every=
one agreed to double their clock speeds. Both systems rely on an honest maj=
ority 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 thr=
ead! :)
>>> >> >> >>>
>>> >> >> >>> On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike@powx=
.org> wrote:
>>> >> >> >>>>
>>> >> >> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and th=
e BIP itself. PoS, VDFs, and so on are interesting but I guess there are ot=
her threads going on these topics already where they would be relevant.
>>> >> >> >>>>
>>> >> >> >>>> Also, it's important to distinguish between oPoW and these o=
ther "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't =
alter the core game theory or security assumptions of Hashcash and actually=
 contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>>> >> >> >>>>
>>> >> >> >>>> Cheers,
>>> >> >> >>>> Mike
>>> >> >> >>>>
>>> >> >> >>>> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-de=
v <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 wor=
king
>>> >> >> >>>>> proof-of-burn protocol
>>> >> >> >>>>>
>>> >> >> >>>>> - vdfs used only for timing (not block height)
>>> >> >> >>>>> - blind-burned coins of a specific age used to replace proo=
f of work
>>> >> >> >>>>> - the required "work" per block would simply be a competiti=
on to
>>> >> >> >>>>> acquire rewards, and so miners would have to burn coins, we=
ll in
>>> >> >> >>>>> advance, and hope that their burned coins got rewarded in s=
ome far
>>> >> >> >>>>> future
>>> >> >> >>>>> - the point of burned coins is to mimic, in every meaningfu=
l way, the
>>> >> >> >>>>> value gained from proof of work... without some of the secu=
rity
>>> >> >> >>>>> 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 m=
irror the
>>> >> >> >>>>> properties of PoW and the incentives Bitcoin uses to mine h=
onestly.
>>> >> >> >>>>>
>>> >> >> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf =
system"
>>> >> >> >>>>> might be more secure in the long run, and that if the entir=
e space
>>> >> >> >>>>> agreed that such an endeavor was worthwhile, a test net cou=
ld 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 a=
n "alt
>>> >> >> >>>>> coin"
>>> >> >> >>>>>
>>> >> >> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw@gma=
il.com> wrote:
>>> >> >> >>>>> >
>>> >> >> >>>>> > Hi ZmnSCPxj,
>>> >> >> >>>>> >
>>> >> >> >>>>> > Please note that I am not suggesting VDFs as a means to s=
ave energy, but solely as a means to make the time between blocks more cons=
tant.
>>> >> >> >>>>> >
>>> >> >> >>>>> > Zac
>>> >> >> >>>>> >
>>> >> >> >>>>> >
>>> >> >> >>>>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj@protonma=
il.com> wrote:
>>> >> >> >>>>> >>
>>> >> >> >>>>> >> Good morning Zac,
>>> >> >> >>>>> >>
>>> >> >> >>>>> >> > VDFs might enable more constant block times, for insta=
nce 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 p=
roperty of VDFs, miners are able show proof of work.
>>> >> >> >>>>> >> >
>>> >> >> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so =
finding a block takes 1 minute on average, again subject to as-is difficult=
y adjustments.
>>> >> >> >>>>> >> >
>>> >> >> >>>>> >> > As a result, variation in block times will be greatly =
reduced.
>>> >> >> >>>>> >>
>>> >> >> >>>>> >> As I understand it, another weakness of VDFs is that the=
y are not inherently progress-free (their sequential nature prevents that; =
they are inherently progress-requiring).
>>> >> >> >>>>> >>
>>> >> >> >>>>> >> Thus, a miner which focuses on improving the amount of e=
nergy that it can pump into the VDF circuitry (by overclocking and freezing=
 the circuitry), could potentially get into a winner-takes-all situation, p=
ossibly leading to even *worse* competition and even *more* energy consumpt=
ion.
>>> >> >> >>>>> >> 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 ent=
ire 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-de=
v
>>> >> >> >>
>>> >> >> >> _______________________________________________
>>> >> >> >> 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
>>
>>
>