path: root/34/433accfce8d1533200df35dc90fa7ab2152cc3

Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 15648899
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 17:37:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f68.google.com (mail-it0-f68.google.com
	[209.85.214.68])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7ACEB293
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 17:37:26 +0000 (UTC)
Received: by mail-it0-f68.google.com with SMTP id z70so1375471itb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Mar 2017 10:37:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=S3H+xdYUYrp9LNofVUX/9xC6yZBGuPTD9OLXACJuy50=;
	b=KX1uUjNk+3PbteskewjSU41Orb8KhIG2KeM16BcYCP81j4e1WcwD/dvEB/MXwI8K3V
	CAu/IWB7KuK6EbVH+pVhjNpr10G/jnRkN5TX9HG7TFyIhEkeNdYoCN2JrZ9xHJc78lz2
	suqS2r2xYo6ekAiEwYT6d+YP/06t4n5h9wbXYmzH5n//Wxf02nXrZnlrPP+8gge+O+Bs
	8/GCgk70JAzKmpRevqrKQu+aqwptqRAMrD0wQj4MKxT8di+HnVyi7Y4WvhKBidSoCurB
	G0QejwC8+W7cL7VRNKBJwB928itqK1xGTTdqLUP/aNhCB0GgPhpjmm8+dNNq8g+Z+nzb
	Vc5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=S3H+xdYUYrp9LNofVUX/9xC6yZBGuPTD9OLXACJuy50=;
	b=cgvHPtLhrDgX9S6cRVeSOwf8R9Ul8IVHXcAQyoIeY5f3yzYc/m+LkpKFNxU+ps03OO
	rVcLlIxTktqZyxnc/QHmE20lZTW8mpCDcx2lKfCY//0xyGmyXq1f1Y73d/tc63Vf74JM
	EhFSmH+u2cduRbeRb5eC4xeITPhBrIJaVSJ7QjaKEYRvb54TeEuZvpZwPFa+RMPTK0tP
	Fo6D2Mh6nn0YteP4RIcgWRIgk6ayLxZ6izsT8hvUysV3gMUTzXqYh15VgOUDYITSyyAf
	bc2UbUL4UduJUvz+R/BC/GFf2lb6h4EGUut34663fH6BUooKjzXSzS25Po9nLE6IoepZ
	0AeA==
X-Gm-Message-State: AFeK/H3DZYOPqrhQU2wk18+n8RiM9kn2P3CLA37FoAqnxgwI9xDNUEZ77IiITzLsJt9PydK9+BkpxZFG1E0kzg==
X-Received: by 10.107.17.199 with SMTP id 68mr9548866ior.127.1490377045783;
	Fri, 24 Mar 2017 10:37:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.135.146 with HTTP; Fri, 24 Mar 2017 10:37:25 -0700 (PDT)
In-Reply-To: <CANN4kmcoffWnwE3jCSSNE8xFp4JAUTJim9TsBVtx0QuBbN03FQ@mail.gmail.com>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
	<CANN4kmcoffWnwE3jCSSNE8xFp4JAUTJim9TsBVtx0QuBbN03FQ@mail.gmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Fri, 24 Mar 2017 18:37:25 +0100
Message-ID: <CAFMkqK-Yqc79J9rGmUkf+0xtjFyvaMe31E01ourew=1zPhuf3g@mail.gmail.com>
To: Nick ODell <nickodell@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113ed7cc655218054b7d7202
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	HTML_OBFUSCATE_10_20, 
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no 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, 24 Mar 2017 18:10:01 +0000
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
 malicious miner takeover?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 24 Mar 2017 17:37:33 -0000

--001a113ed7cc655218054b7d7202
Content-Type: text/plain; charset=UTF-8

> For example would be something like this:
> If block = (empty OR  <%75 of mempool) THEN discard
> This threshold just an example

I don't think this is a good idea, mempool is different from node to node
and is not a part of the consensus.

Hampus

2017-03-24 18:29 GMT+01:00 Nick ODell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> Two concerns:
>
> 1) This makes block validity depend on things that aren't in the
> blockchain. If you and I have different minrelaytxfee's, we will have
> different mempool sizes. Your node will discard a block, but my node will
> think it is valid, and our nodes will not come to consensus.
>
> 2) This is trivially bypassed. A miner can take some coins they own
> already, and create a zero-value transaction that has a scriptPubKey of
> OP_1. (i.e. anyone-can-spend.) Then, they create another transaction
> spending the first transaction, with an empty scriptSig, and the same
> scriptPubKey. They do this over and over until they fill up the block.
>
> The last OP_1 output can be left for the next miner. Since the above
> algorithm is deterministic, a merkle tree containing every transaction
> except the coinbase can be precomputed. The 'malicious' miners do not need
> to store this fake block.
>
> On Fri, Mar 24, 2017 at 10:03 AM, CANNON via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> When the original white paper was written the idea was that nodes
>> would be miners at same time. That the distribution of mining power
>> being mostly on par with the distribution of nodes if I understand
>> correctly. The problem we face now I fear, is the mining power
>> becoming centralized. Even if every bitcoin node invested a $1000
>> into mining power and mined at a loss, it still would not even
>> make a dent in hash distribution. Currently there are around 6000
>> known nodes. If each node invested $1000 for say 10 ths of hashing
>> power. At current hashrate of around 3,674,473,142 GH/s this would
>> only make up %16 of hash power. This is out of balance as while
>> nodes are distributed mining power is becoming very centralized
>> due to the creation of monopolization of ASICs. The problem we
>> are facing is a small group of a couple people whom control a
>> large amount and growing of hash power. At time of this writing
>> it has quickly risen to 39% and at current rate will soon become
>> 50% of hashing power that is controlled by a small group of a few
>> people. Their intentions are too hijack the bitcoin network to a
>> cryptocurrency that suits their dangerous agenda. Dangerous because
>> their plan would centralize power of consensus as I understand it,
>> to themselves the miners. Dangerous also because the code base of
>> the attempting subverters is buggy, insecure, and reckless from a
>> technological standpoint. Even though they only have very minute
>> amount of nodes compared to legitimate bitcion nodes, the danger
>> is that they are very quickly taking over in mining power. While
>> it is true that nodes will not accept invalid blocks that would be
>> attempted to be pushed by the conspirators, they are threatening to
>> attack the valid (or in their words, "minority chain") by dedicating
>> some mining power soley to attacking the valid chain by mining empty
>> blocks and orphaning the valid chain. So even though the majority
>> of nodes would be enforcing what blocks are valid and as a result
>> block the non-compliant longer chain, the conspiring miner can simply
>> (as they are currently threatening to) make the valid chain unuseable
>> by mining empty blocks.
>>
>> If a malicious miner with half or majority control passes invalid
>> blocks, the worst case scenario is a hardfork coin split in which
>> the non-compliant chain becomes an alt. However the problem is that
>> this malicious miner is very recently threatening to not just simply
>> fork, but to kill the valid chain to force economic activity to the
>> adversary controlled chain. If we can simply defend against attacks
>> to the valid chain, we can prevent the valid chain from dying.
>>
>> While empty or near empty blocks would generally be protected by
>> the incentive of miners to make money. The threat is there if the
>> malicious miner with majority control is willing to lose out on
>> these transaction fees and block reward if their intention is to
>> suppress it to force the majority onto their chain.
>>
>> Proposal for potential solution Update nodes to ignore empty blocks,
>> so this way mined empty blocks cannot be used to DOS attack the
>> blockchain. But what about defense from say, blocks that are
>> not empty but intentionally only have a couple transactions
>> in it? Possible to have nodes not only ignore empty blocks,
>> but also blocks that are abnormally small compared to number of
>> valid transactions in mempool?
>>
>> For example would be something like this:
>> If block = (empty OR  <%75 of mempool) THEN discard
>> This threshold just an example.
>>
>> What would be any potentials risks
>> and attacks resulting from both having such new rulesets and not
>> doing anything?
>>
>> Lets assume that the first problem of blocking empty or near empty
>> blocks has been mitigated with the above proposed solution. How
>> likely and possible would it be for a malicious miner with lots of
>> mining power to orphan the chain after so many blocks even with
>> non empty blocks? Is there a need to mitigate this?
>> If so is it possible?
>>
>> Time is running short I fear. There needs to be discussion on various
>> attacks and how they can be guarded against along with various
>> other contingency plans.
>>
>> - --
>> Cannon
>> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> Email: cannon@cannon-ciota.info
>>
>> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> If this matters to you, use PGP.
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
>> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
>> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
>> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
>> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
>> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
>> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
>> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
>> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
>> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
>> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
>> Gu3oWoE1ld+BC6At28AD
>> =SSuj
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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
>
>

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

<div dir=3D"ltr"><div><div>&gt; For example would be something like this:<b=
r>
&gt; If block =3D (empty OR=C2=A0 &lt;%75 of mempool) THEN discard<br>
&gt; This threshold just an example<br><br></div>I don&#39;t think this is =
a good idea, mempool is different from node to node and is not a part of th=
e consensus.<br><br></div>Hampus<br></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">2017-03-24 18:29 GMT+01:00 Nick ODell via bitcoin-=
dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</sp=
an>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Two concerns:<div><=
br></div><div>1) This makes block validity depend on things that aren&#39;t=
 in the blockchain. If you and I have different minrelaytxfee&#39;s, we wil=
l have different mempool sizes. Your node will discard a block, but my node=
 will think it is valid, and our nodes will not come to consensus.</div><di=
v><br></div><div>2) This is trivially bypassed. A miner can take some coins=
 they own already, and create a zero-value transaction that has a scriptPub=
Key of OP_1. (i.e. anyone-can-spend.) Then, they create another transaction=
 spending the first transaction, with an empty scriptSig, and the same scri=
ptPubKey. They do this over and over until they fill up the block.</div><di=
v><br></div><div>The last OP_1 output can be left for the next miner. Since=
 the above algorithm is deterministic, a merkle tree containing every trans=
action except the coinbase can be precomputed. The &#39;malicious&#39; mine=
rs do not need to store this fake block.</div></div><div class=3D"HOEnZb"><=
div class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Mar 24, 2017 at 10:03 AM, CANNON via bitcoin-dev <span dir=3D"ltr">=
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
When the original white paper was written the idea was that nodes<br>
would be miners at same time. That the distribution of mining power<br>
being mostly on par with the distribution of nodes if I understand<br>
correctly. The problem we face now I fear, is the mining power<br>
becoming centralized. Even if every bitcoin node invested a $1000<br>
into mining power and mined at a loss, it still would not even<br>
make a dent in hash distribution. Currently there are around 6000<br>
known nodes. If each node invested $1000 for say 10 ths of hashing<br>
power. At current hashrate of around 3,674,473,142 GH/s this would<br>
only make up %16 of hash power. This is out of balance as while<br>
nodes are distributed mining power is becoming very centralized<br>
due to the creation of monopolization of ASICs. The problem we<br>
are facing is a small group of a couple people whom control a<br>
large amount and growing of hash power. At time of this writing<br>
it has quickly risen to 39% and at current rate will soon become<br>
50% of hashing power that is controlled by a small group of a few<br>
people. Their intentions are too hijack the bitcoin network to a<br>
cryptocurrency that suits their dangerous agenda. Dangerous because<br>
their plan would centralize power of consensus as I understand it,<br>
to themselves the miners. Dangerous also because the code base of<br>
the attempting subverters is buggy, insecure, and reckless from a<br>
technological standpoint. Even though they only have very minute<br>
amount of nodes compared to legitimate bitcion nodes, the danger<br>
is that they are very quickly taking over in mining power. While<br>
it is true that nodes will not accept invalid blocks that would be<br>
attempted to be pushed by the conspirators, they are threatening to<br>
attack the valid (or in their words, &quot;minority chain&quot;) by dedicat=
ing<br>
some mining power soley to attacking the valid chain by mining empty<br>
blocks and orphaning the valid chain. So even though the majority<br>
of nodes would be enforcing what blocks are valid and as a result<br>
block the non-compliant longer chain, the conspiring miner can simply<br>
(as they are currently threatening to) make the valid chain unuseable<br>
by mining empty blocks.<br>
<br>
If a malicious miner with half or majority control passes invalid<br>
blocks, the worst case scenario is a hardfork coin split in which<br>
the non-compliant chain becomes an alt. However the problem is that<br>
this malicious miner is very recently threatening to not just simply<br>
fork, but to kill the valid chain to force economic activity to the<br>
adversary controlled chain. If we can simply defend against attacks<br>
to the valid chain, we can prevent the valid chain from dying.<br>
<br>
While empty or near empty blocks would generally be protected by<br>
the incentive of miners to make money. The threat is there if the<br>
malicious miner with majority control is willing to lose out on<br>
these transaction fees and block reward if their intention is to<br>
suppress it to force the majority onto their chain.<br>
<br>
Proposal for potential solution Update nodes to ignore empty blocks,<br>
so this way mined empty blocks cannot be used to DOS attack the<br>
blockchain. But what about defense from say, blocks that are<br>
not empty but intentionally only have a couple transactions<br>
in it? Possible to have nodes not only ignore empty blocks,<br>
but also blocks that are abnormally small compared to number of<br>
valid transactions in mempool?<br>
<br>
For example would be something like this:<br>
If block =3D (empty OR=C2=A0 &lt;%75 of mempool) THEN discard<br>
This threshold just an example.<br>
<br>
What would be any potentials risks<br>
and attacks resulting from both having such new rulesets and not<br>
doing anything?<br>
<br>
Lets assume that the first problem of blocking empty or near empty<br>
blocks has been mitigated with the above proposed solution. How<br>
likely and possible would it be for a malicious miner with lots of<br>
mining power to orphan the chain after so many blocks even with<br>
non empty blocks? Is there a need to mitigate this?<br>
If so is it possible?<br>
<br>
Time is running short I fear. There needs to be discussion on various<br>
attacks and how they can be guarded against along with various<br>
other contingency plans.<br>
<br>
- --<br>
Cannon<br>
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832<br>
Email: <a href=3D"mailto:cannon@cannon-ciota.info" target=3D"_blank">cannon=
@cannon-ciota.info</a><br>
<br>
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD<br>
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.<br>
If this matters to you, use PGP.<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQIcBAEBCgAGBQJY1UH/AAoJEAYDai<wbr>9lH2mw2QYQALDLBxjdO5WTG7VXfuAE<wbr>476p<=
br>
D3o1MMGw23tb+DFUO5WV6aFqfy3VSx<wbr>bVXz6UuWbj6kHgp3ys6qxg5TX0Dy8t<wbr>KSZM<=
br>
V28kovuS/pfen4gTxw1FCNff7YVW1R<wbr>8QX+cSYxSD5EoEaTbpIPgi8zMusDxU<wbr>VZk2<=
br>
WG3ItoyvkLvoNIYGDcU3gR3UkjDS5l<wbr>OPiHu5BKSj1dEiibOXhr8JEBCznfUS<wbr>yxCG<=
br>
TjVRJaUPlwCU06nad8jAZiDrsW3l86<wbr>6iNkBKaMzMavYuMLvCGIdRkbf54B2Z<wbr>lIT/<=
br>
S/owusxqeIdQpydi/3ydnrqyeWo3zn<wbr>Mnn+oOvdvfYEHKLts6gar3Zv8cZ40y<wbr>YSIE<=
br>
z7C7GQFIo5TYDUNOk+2VE7NNtdX39W<wbr>j3gJql/305miaIt0qMsf1D30ODjePw<wbr>yxUQ<=
br>
LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/t<wbr>Fm3kx0PunptJaZT8d9EgMeHREjCF4d<wbr>i04A<=
br>
6Dp3Qeug41X/zdIc2AM387QnPwmGB1<wbr>TpfrY9qgvcrIe26T6An2V5LHwVmslC<wbr>X3ui<=
br>
DYAl0o5ODQqnnakF1FIrr1blMVqm7F<wbr>qDPQc1I5TfzQuxX2+x+5zdrciPC2HU<wbr>MCMQ<=
br>
jMujge5IdGL3kjEwjt+M6kqLu0/T0f<wbr>hdUetb2DWrRJUcEVoIaiUL7qLJC+<wbr>4KMR3d<=
br>
Gu3oWoE1ld+BC6At28AD<br>
=3DSSuj<br>
-----END PGP SIGNATURE-----<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a113ed7cc655218054b7d7202--