path: root/e2/9a05f43a5bc9da596afbae607782e7d0c990f1

Return-Path: <stanga@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BF7A610AB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Dec 2015 11:15:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com
	[209.85.215.41])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0045A5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Dec 2015 11:15:48 +0000 (UTC)
Received: by mail-lf0-f41.google.com with SMTP id y184so172335161lfc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Dec 2015 03:15:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc:content-type;
	bh=wBRJ5BDSToKFfJF8MQ6XZqEyVW/pWqgCRLvJEbWjPfA=;
	b=gSDwiNvuFj9LlmVsxD9etN65gkdFM3ZMRq4geTiPg0XkIiB8XpBiPIgA6CCf6jqpqv
	dYacrccm0Mo5su2DBe8yLIJw6BGsdqoVTpoLZEvQGO+7AVz0g77gCM2pQ0rChvaST8tg
	x+5FHl8o8drTXEC3447wA+zFK/Qs93NZGqZd3tMalrT5rUOfjG5LBN1uYPrmmkWa+DP3
	2omTF+LsQ6xzihxnzu5XdBbjCAdgMsdJjkt325143tFu7XDE0cZb9dd0mDPXaDJ7oOKQ
	XWN2/m4LSlkRkSYtb8wv5xzulRSmZuHlxe1QdC52/y5b9zJQoAGswubJYWSlJkHTCM8i
	4XXQ==
X-Received: by 10.25.37.198 with SMTP id l189mr14281788lfl.111.1451042147099; 
	Fri, 25 Dec 2015 03:15:47 -0800 (PST)
MIME-Version: 1.0
Sender: stanga@gmail.com
Received: by 10.25.84.139 with HTTP; Fri, 25 Dec 2015 03:15:27 -0800 (PST)
In-Reply-To: <CABeL=0jgv3G8qx6wM+ZfwN154qhQY-GJdXnABc-iWL=YDNmhag@mail.gmail.com>
References: <20151219184240.GB12893@muck>
	<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
	<219f125cee6ca68fd27016642e38fdf1@xbt.hk>
	<CAAcC9ys_t7X0WpQ8W3577M8GLiA5sPV2F1BJ9qZbnMkE-1j3+Q@mail.gmail.com>
	<aff8da46a69bdd7ef92ca87725866a5c@xbt.hk>
	<CAPkFh0vNECi1OmBwki+8NNAQbe6EG2FEE4RR5z=kYVLLDFHUXg@mail.gmail.com>
	<20151220132842.GA25481@muck>
	<CAPkFh0t-+WhZYVLyT_auLa87zAATNOH=CpU4S5H=n6S1wmZ-oQ@mail.gmail.com>
	<CABeL=0jgv3G8qx6wM+ZfwN154qhQY-GJdXnABc-iWL=YDNmhag@mail.gmail.com>
From: Ittay <ittay.eyal@cornell.edu>
Date: Fri, 25 Dec 2015 13:15:27 +0200
X-Google-Sender-Auth: 3Z1EfqOkTFvKCA6_FFnHszdQVKM
Message-ID: <CABT1wW=r5DPG1e6XFe7NMHrquo1FzygPCdjEJ2QQnmGbqVMH2Q@mail.gmail.com>
To: Jannes Faber <jannes.faber@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f16d4bb6a0e0527b7131f
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 25 Dec 2015 11:34:43 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 25 Dec 2015 11:15:50 -0000

--001a113f16d4bb6a0e0527b7131f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Treating the pool block withholding attack as a weapon has bad
connotations, and I don't think anyone directly condones such an attack.
Nevertheless, the mere possibility of the attack could drive miners away
from those overly-large open pools.

As for masquerading as multiple small pools -- that's a very good point,
with a surprising answer: it doesn't really matter. An attacker attacks all
parts of the open pool proportionally to their size, and the result is
basically identical to that of attacking a single large pool.

All that being said -- it's not great to rely on the potential of attacks
and on threats against the honest large pools out there (including GHash,
which, afaik, did nothing more wrong than being successful).

Best,
Ittay


On Mon, Dec 21, 2015 at 1:39 PM, Jannes Faber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If you're saying a block withholding attack is a nice weapon to have to
> dissuade large pools, isn't that easily defeated by large pools simply
> masquerading as multiple small pools? As, for all we know, ghash may have
> done?
>
> If you don't know who to attack there's no point in having the weapon.
> While that weapon is still dangerous in the hands of others that are
> indiscriminate, like the solo miners example of Peter Todd.
>
> Sorry if i misunderstood your point.
>
> --
> Jannes
>
> On 20 December 2015 at 18:00, Emin G=C3=BCn Sirer <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete@petertodd.org> wrote:
>>
>>> There are a number of techniques that can be used to detect block
>>> withholding attacks that you are not aware of. These techniques usually
>>> have the characteristic that if known they can be avoided, so obviously
>>> those who know about them are highly reluctant to reveal what exactly
>>> they are. I personally know about some of them and have been asked to
>>> keep that information secret, which I will.
>>>
>>
>> Indeed, there are lots of weak measures that one could employ against
>> an uninformed attacker. As I mentioned before, these are unlikely to be
>> effective against a savvy attacker, and this is a good thing.
>>
>>
>>> In the context of KYC, this techniques would likely hold up in court,
>>> which means that if this stuff becomes a more serious problem it's
>>> perfectly viable for large, well-resourced, pools to prevent block
>>> withholding attacks, in part by removing anonymity of hashing power.
>>> This would not be a positive development for the ecosystem.
>>>
>>
>> KYC has a particular financial-regulation connotation in Bitcoin circles=
,
>> of which I'm sure you're aware, and which you're using as a spectre.
>> You don't mean government-regulated-KYC a la FINCEN and Bitcoin
>> exchanges like Coinbase, you are just referring to a pool operator
>> demanding to know that its customer is not coming from its competitors'
>> data centers.
>>
>> And your prediction doesn't seem well-motivated or properly justified.
>> There are tons of conditionals in your prediction, starting with the
>> premise
>> that every single open pool would implement some notion of identity
>> checking. I don't believe that will happen. Instead, we will have the
>> bigger
>> pools become more suspicious of signing up new hash power, which is a
>> good thing. And we will have small groups of people who have some reason
>> for trusting each other (e.g. they know each other from IRC, conferences=
,
>> etc) band together into small pools. These are fantastic outcomes for
>> decentralization.
>>
>> Secondly, DRM tech can also easily be used to prevent block withholding
>>> attacks by attesting to the honest of the hashing power. This is being
>>> discussed in the industry, and again, this isn't a positive development
>>> for the ecosystem.
>>>
>>
>> DRM is a terrible application. Once again, I see that you're trying to
>> use those
>> three letters as a spectre as well, knowing that most people hate DRM,
>> but
>> keep in mind that DRM is just an application -- it's like pointing to
>> Adobe Flash
>> to taint all browser plugins.
>>
>> The tech behind DRM is called "attestation," and it provides a technical
>> capability not possible by any other means. In essence, attestation can
>> ensure that
>> a remote node is indeed running the code that it purports to be running.
>> Since
>> most problems in computer security and distributed systems stem from not
>> knowing what protocol the attacker is going to follow, attestation is th=
e
>> only
>> technology we have that lets us step around this limitation.
>>
>> It can ensure, for instance,
>>   - that a node purporting to be Bitcoin Core (vLatest) is indeed runnin=
g
>> an
>> unadulterated, latest version of Bitcoin Core
>>   - that a node claiming that it does not harvest IP addresses from SPV
>> clients indeed does not harvest IP addresses.
>>   - that a cloud hashing outfit that rented out X terahashes to a user
>> did
>> indeed rent out X terahashes to that particular user,
>>   - that a miner operating on behalf of some pool P will not misbehave a=
nd
>> discard perfectly good blocks
>> and so forth. All of these would be great for the ecosystem. Just gettin=
g
>> rid
>> of the cloudhashing scams would put an end to a lot of heartache.
>>
>> > Keep in mind that when an open pool gets big, like GHash did and
>>> > two other pools did before them, the only thing at our disposal used
>>> > to be to yell at people about centralization until they left the big
>>> > pools and reformed into smaller groups. Not only was such yelling
>>> > kind of desperate looking, it wasn't incredibly effective, either.
>>> > We had no protocol mechanisms that put pressure on big pools to
>>> > stop signing up people. Ittay's discovery changed that: pools that
>>> > get to be very big by indiscriminately signing up miners are likely t=
o
>>> > be infiltrated and their profitability will drop. And Peter's post is
>>> > evidence that this is, indeed, happening as predicted. This is a
>>> > good outcome, it puts pressure on the big pools to not grow.
>>>
>>> GHash.io was not a pure pool - they owned and operated a significant
>>> amount of physical hashing power, and it's not at all clear that their =
%
>>> of the network actually went down following that 51% debacle.
>>>
>>
>> Right, it's not clear at all that yelling at people has much effect. As
>> much
>> fun as I had going to that meeting with GHash in London to ask them to
>> back down off of the 51% boundary, I am pretty sure that yelling at larg=
e
>> open pools will not scale. We needed better mechanisms for keeping pools
>> in check.
>>
>> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
>> time when we should count our blessings, not work actively to render
>> them inoperable.
>>
>> Currently a significant % of the hashing power - possibly a majority -
>>> is in the form of large hashing installations whose owners individually=
,
>>> and definitely in trusting groups, have enough hashing power to solo
>>> mine. Eyal's results indicate those miners have incentives to attack
>>> pools, and additionally they have the incentive of killing off pools to
>>> make it difficult for new competition to get established, yet they
>>> themselves are not vulnerable to that attack.
>>>
>>
>> There are indeed solo miners out there who can attack the big open
>> pools. The loss of the biggest open pools would not be a bad outcome.
>> Pools >25% pose a danger, and the home miner doesn't need a pool
>> >25% for protection against variance.
>>
>> > Peter, you allude to a specific suggestion from Luke-Jr. Can you
>>> > please describe what it is?
>>>
>>> Basically you have the pool pick a secret k for each share, and commit
>>> to H(k) in the share. Additionally the share commits to a target divide=
r
>>> D. The PoW validity rule is then changed from H(block header) < T, to b=
e
>>> H(block header) < T * D && H(H(block header) + k) < max_int / D
>>>
>>
>> Thanks, this requires a change to the Bitcoin PoW. Good luck with that!
>>
>> Once again, this suggestion would make the GHash-at-51% situation
>> possible again. Working extra hard to re-enable those painful days
>> sounds like a terrible idea.
>>
>> - egs
>>
>>
>> _______________________________________________
>> 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
>
>

--001a113f16d4bb6a0e0527b7131f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Treating the pool block withholding attack as a weapon has=
 bad connotations, and I don&#39;t think anyone directly condones such an a=
ttack. Nevertheless, the mere possibility of the attack could drive miners =
away from those overly-large open pools.=C2=A0<div><br><div><div>As for=C2=
=A0<span style=3D"font-size:12.8px">masquerading as multiple small pools --=
 that&#39;s a very good point, with a surprising answer: it doesn&#39;t rea=
lly matter. An attacker attacks all parts of the open pool proportionally t=
o their size, and the result is basically identical to that of attacking a =
single large pool.=C2=A0</span><div><br></div></div><div>All that being sai=
d -- it&#39;s not great to rely on the potential of attacks and on threats =
against the honest large pools out there (including GHash, which, afaik, di=
d nothing more wrong than being successful).=C2=A0</div><div><br></div><div=
>Best,=C2=A0</div><div>Ittay=C2=A0</div><div><br></div></div></div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Dec 21, 201=
5 at 1:39 PM, Jannes Faber via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><p dir=3D"ltr">If you&#39;re saying a block withh=
olding attack is a nice=20
weapon to have to dissuade large pools, isn&#39;t that easily defeated by=
=20
large pools simply masquerading as multiple small pools? As, for all we=20
know, ghash may have done?</p>
<p dir=3D"ltr">If you don&#39;t know who to attack there&#39;s no point in =
having=20
the weapon. While that weapon is still dangerous in the hands of others=20
that are indiscriminate, like the solo miners example of Peter Todd.</p>
<p dir=3D"ltr">Sorry if i misunderstood your point.</p></div><div class=3D"=
gmail_extra"><br clear=3D"all"><div><div>--<br>Jannes</div></div>
<br><div class=3D"gmail_quote"><div><div class=3D"h5">On 20 December 2015 a=
t 18:00, Emin G=C3=BCn Sirer <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><span>On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_bla=
nk">pete@petertodd.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">There are a number of techniques that can be used to detect block<br>
withholding attacks that you are not aware of. These techniques usually<br>
have the characteristic that if known they can be avoided, so obviously<br>
those who know about them are highly reluctant to reveal what exactly<br>
they are. I personally know about some of them and have been asked to<br>
keep that information secret, which I will.<br></blockquote><div><br></div>=
</span><div>Indeed, there are lots of weak measures that one could employ a=
gainst=C2=A0</div><div>an uninformed attacker. As I mentioned before, these=
 are unlikely to be</div><div>effective against a savvy attacker, and this =
is a good thing.</div><span><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
In the context of KYC, this techniques would likely hold up in court,<br>
which means that if this stuff becomes a more serious problem it&#39;s<br>
perfectly viable for large, well-resourced, pools to prevent block<br>
withholding attacks, in part by removing anonymity of hashing power.<br>
This would not be a positive development for the ecosystem.<br></blockquote=
><div><br></div></span><div>KYC has a particular financial-regulation conno=
tation in Bitcoin circles,=C2=A0</div><div>of which I&#39;m sure you&#39;re=
 aware, and which you&#39;re using as a spectre.=C2=A0</div><div>You don&#3=
9;t mean government-regulated-KYC a la FINCEN and Bitcoin</div><div>exchang=
es like Coinbase, you are just referring to a pool operator</div><div>deman=
ding to know that its customer is not coming from its competitors&#39;</div=
><div>data centers.</div><div><br></div><div>And your prediction doesn&#39;=
t seem well-motivated or properly justified.=C2=A0</div><div>There are tons=
 of conditionals in your prediction, starting with the premise<br></div><di=
v>that every single open pool would implement some notion of identity=C2=A0=
</div><div>checking. I don&#39;t believe that will happen. Instead, we will=
 have the bigger</div><div>pools become more suspicious of signing up new h=
ash power, which is a</div><div>good thing. And we will have small groups o=
f people who have some reason</div><div>for trusting each other (e.g. they =
know each other from IRC, conferences,=C2=A0</div><div>etc) band together i=
nto small pools. These are fantastic outcomes for</div><div>decentralizatio=
n.</div><span><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Secondly, DRM t=
ech can also easily be used to prevent block withholding<br>
attacks by attesting to the honest of the hashing power. This is being<br>
discussed in the industry, and again, this isn&#39;t a positive development=
<br>
for the ecosystem.<br></blockquote><div><br></div></span><div>DRM is a terr=
ible application. Once again, I see that you&#39;re trying to use those</di=
v><div>three letters as a spectre as well, knowing that most people hate DR=
M, but=C2=A0</div><div>keep in mind that DRM is just an application -- it&#=
39;s like pointing to Adobe Flash</div><div>to taint all browser plugins.</=
div><div><br></div><div>The tech behind DRM is called &quot;attestation,&qu=
ot; and it provides a technical=C2=A0</div><div>capability not possible by =
any other means. In essence, attestation can ensure that</div><div>a remote=
 node is indeed running the code that it purports to be running. Since=C2=
=A0</div><div>most problems in computer security and distributed systems st=
em from not</div><div>knowing what protocol the attacker is going to follow=
, attestation is the only=C2=A0</div><div>technology we have that lets us s=
tep around this limitation.=C2=A0</div><div><br></div><div>It can ensure, f=
or instance,=C2=A0</div><div>=C2=A0 - that a node purporting to be Bitcoin =
Core (vLatest) is indeed running an</div><div>unadulterated, latest version=
 of Bitcoin Core=C2=A0</div><div>=C2=A0 - that a node claiming that it does=
 not harvest IP addresses from SPV=C2=A0</div><div>clients indeed does not =
harvest IP addresses.</div><div>=C2=A0 - that a cloud hashing outfit that r=
ented out X terahashes to a user did=C2=A0<br></div><div>indeed rent out X =
terahashes to that particular user,=C2=A0</div><div>=C2=A0 - that a miner o=
perating on behalf of some pool P will not misbehave and</div><div>discard =
perfectly good blocks</div><div>and so forth. All of these would be great f=
or the ecosystem. Just getting rid</div><div>of the cloudhashing scams woul=
d put an end to a lot of heartache.</div><span><div><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><span>
&gt; Keep in mind that when an open pool gets big, like GHash did and<br>
&gt; two other pools did before them, the only thing at our disposal used<b=
r>
&gt; to be to yell at people about centralization until they left the big<b=
r>
&gt; pools and reformed into smaller groups. Not only was such yelling<br>
&gt; kind of desperate looking, it wasn&#39;t incredibly effective, either.=
<br>
&gt; We had no protocol mechanisms that put pressure on big pools to<br>
&gt; stop signing up people. Ittay&#39;s discovery changed that: pools that=
<br>
&gt; get to be very big by indiscriminately signing up miners are likely to=
<br>
&gt; be infiltrated and their profitability will drop. And Peter&#39;s post=
 is<br>
&gt; evidence that this is, indeed, happening as predicted. This is a<br>
&gt; good outcome, it puts pressure on the big pools to not grow.<br>
<br>
</span>GHash.io was not a pure pool - they owned and operated a significant=
<br>
amount of physical hashing power, and it&#39;s not at all clear that their =
%<br>
of the network actually went down following that 51% debacle.<br></blockquo=
te><div><br></div></span><div>Right, it&#39;s not clear at all that yelling=
 at people has much effect. As much</div><div>fun as I had going to that me=
eting with GHash in London to ask them to</div><div>back down off of the 51=
% boundary, I am pretty sure that yelling at large</div><div>open pools wil=
l not scale. We needed better mechanisms for keeping pools</div><div>in che=
ck.</div><div><br></div><div>And Miner&#39;s Dilemma (MD) attacks are clear=
ly quite effective. This is a</div><div>time when we should count our bless=
ings, not work actively to render</div><div>them inoperable.</div><span><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
Currently a significant % of the hashing power - possibly a majority -<br>
is in the form of large hashing installations whose owners individually,<br=
>
and definitely in trusting groups, have enough hashing power to solo<br>
mine. Eyal&#39;s results indicate those miners have incentives to attack<br=
>
pools, and additionally they have the incentive of killing off pools to<br>
make it difficult for new competition to get established, yet they<br>
themselves are not vulnerable to that attack.<br></blockquote><div><br></di=
v></span><div>There are indeed solo miners out there who can attack the big=
 open</div><div>pools. The loss of the biggest open pools would not be a ba=
d outcome.</div><div>Pools &gt;25% pose a danger, and the home miner doesn&=
#39;t need a pool=C2=A0</div><div>&gt;25% for protection against variance.=
=C2=A0</div><span><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
&gt; Peter, you allude to a specific suggestion from Luke-Jr. Can you<br>
&gt; please describe what it is?<br>
<br>
</span>Basically you have the pool pick a secret k for each share, and comm=
it<br>
to H(k) in the share. Additionally the share commits to a target divider<br=
>
D. The PoW validity rule is then changed from H(block header) &lt; T, to be=
<br>
H(block header) &lt; T * D &amp;&amp; H(H(block header) + k) &lt; max_int /=
 D<br></blockquote><div><br></div></span><div>Thanks, this requires a chang=
e to the Bitcoin PoW. Good luck with that!=C2=A0</div><div><br></div><div>O=
nce again, this suggestion would make the GHash-at-51% situation=C2=A0</div=
><div>possible again. Working extra hard to re-enable those painful days=C2=
=A0</div><div>sounds like a terrible idea.=C2=A0</div><div><br></div><div>-=
 egs</div><div><br></div></div></div></div>
<br></div></div><span class=3D"">__________________________________________=
_____<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--001a113f16d4bb6a0e0527b7131f--