path: root/b9/0dcc6b537ce6bf56a7907c921386a5852d2270

Return-Path: <erik.lite@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D55DD9AF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Jun 2017 14:18:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
	[209.85.223.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9315B1DB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Jun 2017 14:18:41 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id c201so23837391ioe.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Jun 2017 07:18:41 -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
	:cc; bh=0gWdM20NZ9n8xqju7zYnys6LZ8pykg/CkPL/yxPC6Vc=;
	b=GqT50klNISi1SoDE7fmzbInMtM1HbL3s5IBOFSHiyvwcZHVqEee8FBXKXNcjdhQYIp
	ZLt27gB4UhrwSwCZVN1MTkXYoV9F8vn+Ug+ly70kthZSRzEVy9Yu1N+c1CXLKGGxUYnq
	eSVVPQ1tWFJjv4Fxa59Iz1quUgBaafxCIjDcIY5srqOabLJfVb2BNLsbZ0Ceq3JhsKvr
	IO9EExYadLRYscAHdymeIo/7oQnYXplZVe5lJF2HG4fvgpjflWIuagwQiSU5TcYi9j6n
	/9Uz48vIrrjrtD6wmo9T1AojBp4U8m2mA9TXaLFkoHTXnoPmdpIlrj4v+ztgEO5HUwp+
	NaEQ==
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:cc;
	bh=0gWdM20NZ9n8xqju7zYnys6LZ8pykg/CkPL/yxPC6Vc=;
	b=gVwIAWqZtbM/eMuSRvrIyoLaXAHjsPL58tBEJZuih0F1EocsvJikaMuKg840t5Z2A1
	lDoDN6rA+5a389+wPmdyrYcItFwa+o9JXNcOrzo3hNw4+kqiXbrvAqSua74JNe28YDp5
	zclr8vfhfzsor2ZPNSrlnpCMtDe0TeMLcb1Tjl2+92PS7s7k8f8a40g32fUqI8kYp6DL
	9cy5fWBBWxO4mxuQfdQZP7pk6VJ1N5tdr59MiR+W3eNPjW48ZkLAnKHjRB90RJ3+0wV4
	N5xJiV+4JoRjclvJE5BNiw1Ksq2qcpiwdkqlBLnbTgrY+snmzWiIAvlI6ohn1YbMmiXz
	ny1Q==
X-Gm-Message-State: AKS2vOz+VI1WhiZOeooKPtZqOzYp5zoZYkUqgTXyIl56g8w3ahQ6ZhYk
	BkhGfib16nOaWJpvIA0W2tlsDJLBhlIIy6Y=
X-Received: by 10.107.130.150 with SMTP id m22mr2682414ioi.140.1498141120798; 
	Thu, 22 Jun 2017 07:18:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.33.80 with HTTP; Thu, 22 Jun 2017 07:18:40 -0700 (PDT)
In-Reply-To: <BLUPR0301MB2002AAC764B140C4DE74768DEEDB0@BLUPR0301MB2002.namprd03.prod.outlook.com>
References: <CA+Yhp0Uv3zrg28G7QcgXPSv4Md9j2U-=SROJqWAOqvW_tCu=bQ@mail.gmail.com>
	<BLUPR0301MB2002AAC764B140C4DE74768DEEDB0@BLUPR0301MB2002.namprd03.prod.outlook.com>
From: Ilya Eriklintsev <erik.lite@gmail.com>
Date: Thu, 22 Jun 2017 17:18:40 +0300
Message-ID: <CA+Yhp0VmAA4ixRURTubttOyW0D_e+YAd=70QC+8FGShA5=JVCw@mail.gmail.com>
To: John Hardy <john@seebitcoin.com>
Content-Type: multipart/alternative; boundary="001a113fb6805438ae05528d29e0"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Thu, 22 Jun 2017 14:22:20 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized
	proof-of-work
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: Thu, 22 Jun 2017 14:18:43 -0000

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

Thanks a lot for the reply, let me think it over and come up with a proper
response. You and Conrad may be right about the proposal being irrelevant
to DDoS, so I'll try to come up with the more solid argument supporting my
point of view, otherwise, I will refute the proposal myself). At the moment
I feel like I need to specify game theoretical model and consider all costs
and incentives in more details. Sincerely yours, Ilya Eriklintsev.

On 22 June 2017 at 16:47, John Hardy <john@seebitcoin.com> wrote:

> Hi Ilya,
>
>
> This proposal wouldn't work because bad actors can perform PoW just as
> cheaply as any other participant.
>
>
> The transaction fee already acts as a mechanism to prevent spam. It is not
> a problem to have a lot of low value transactions in the mempool as
> thresholds can easily be set for them to be disregarded/expire - a 300MB
>  maxmempool size by default eliminates any real 'DDOS' risk. Spam only
> really becomes an issue when it enters the blockchain. If a spammer is
> willing to pay the tx fee to spam, they'd be willing to pay the PoW.
>
>
> The only actors who can spam the blockchain at zero cost are the miners
> themselves (beyond the opportunity cost of including genuine fee paying
> transactions). They can even do it without their transactions ever hitting
> the mempool or including a fee, though this behaviour would be easy to spot.
>
>
> If miners are colluding to spam the mempool or blocks in order to increase
> the average transaction cost overall there is little that can be done as
> the network relies on 51% of hashpower being honest. A miner creating spam
> transactions that enter the mempool has the risk that another miner would
> include it in a block and they would incur an economic cost if this
> happened.
>
>
> I had an idea for a dynamic blocksize that required miners to pay a
> percentage of the transaction fees to the next mined block. Here is a
> link: https://lists.linuxfoundation.org/pipermail/
> bitcoin-discuss/2017-January/000123.html
>
>
> If it was established that miners spamming blocks with transactions was an
> issue, this could be used as a disincentive as it means the cost for doing
> so becomes non-zero.
>
>
> Regards,
>
> John Hardy
> john@seebitcoin.com
>
> ------------------------------
> *From:* bitcoin-dev-bounces@lists.linuxfoundation.org <
> bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Ilya
> Eriklintsev via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> *Sent:* Wednesday, June 21, 2017 9:55 AM
> *To:* bitcoin-dev@lists.linuxfoundation.org
> *Subject:* [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized
> proof-of-work
>
> Hello everyone,
>
> recently I have got an idea that in my opinion will improve bitcoin
> network, making it better store-of-value for growing cyberspace and
> cryptoeconomy. Sorry for longread below and thank you for your time.
>
> *Decentralized proof-of-work and DDoS resistance for Bitcoin*
>
> *Abstract*
>
> By introducing some new block validation rules it is possible to make
> Bitcoin network more secure, decentralized and DDoS resistant. The idea is
> to modify simple proof-of-work puzzle in such a way that user transactions
> could be hardened with the same proof-of-work algorithm thus incentivising
> all the miners to include that particular transaction. Such mechanism will
> effectively give a handicap to every miner who includes "mined" transaction
> into next block, increasing probability of him getting block reward.
>
> *Problems and motivation*
>
> This document will address the issue of a continuous DDoS attack targeting
> the Bitcoin network, e.g. full nodes mempools constantly being overflowed
> with transactions carrying small value reduce system primary ability to
> transfer value (and hence making it perfect store of value). Valid
> transactions are cheap to create (in the sense of computational effort
> required) and no adequate mechanism exist to make transaction total value
> increase probably of its confirmation by the network.
>
> Currently, miners decide which transactions to include in blocks because
> it's them who are securing Bitcoin network providing proof-of-work
> certificates stored inside every block header. Miners have to store the
> whole blockchain at all times, so one of the costs is storage which grows
> linearly with the transaction size (blockchain size as well). Another cost
> is network bandwidth which depends directly on the size of data to be
> communicated over.
>
> The only incentive a person who wants to transfer his bitcoins is allowed
> to use is setting of transaction fee, that is going directly to the miner.
> This solution probably was intended to utilize free market (as implied by
> Satoshi introducing sequence numbers) to determine appropriate fees, but
> that is obviously not the case, in the current bitcoin network operating in
> full block capacity mode. This fee market deviates significantly from a
> free market premise (also attempts being made to make it closer, e.g. in
> BIP125 where Replace-By-Fee signaling is supposed to help in replacing
> "stuck" transactions with noncompetitive fee).
>
> Currently, bitcoin network is susceptible to the DDoS attack of a kind.
> Adversary creating and translating into the network a lot of transactions
> carrying small value (e.g. only miners fee), will be able to impair the
> ability to transfer value for everyone in the world, should he has enough
> money to pay the fees. Miners would continue to work providing security for
> the network and new blocks will consist of transaction transferring
> negligible value. It's a major drawback because the cost of such attack
> doesn't grow asymmetrically with the cost of BTC asset.
>
> *Proposed solution*
>
> So how do we incentivize all miners to include our transaction carrying a
> lot of value in the next block? The only thing a miner supposed to do to
> get a reward is to produce Hashcash proof-of-work, thus providing
> cryptographic security guarantees for the whole Bitcoin blockchain. What if
> including our transaction in a block would reduce effort requirements for
> the miner produce valid block?
>
> We could do so by extending the concept of proof-of-work, in such a way
> that we do not sacrifice security at all. Here are both descriptions
> proof-of-work as-is and to-be:
>
> Standart proof-of-work: hash(previous block hash + current block target +
> current block metadata + current block transactions) < target
>
> Decentralized proof-of-work: hash(previous block hash + current block
> target + current block metadata + current block transactions) - sum( FFFF -
> hash( previous block hash + raw_tx ) ) < target
>
> It is possible to imagine completely mining agnostic proof-of-work, for
> example, the following PoW would do:
>
> Distributed (mining-agnostic) proof-of-work: sum( FFFF - hash( previous
> block hash + current block target + current block metadata + signed_tx ) )
> < target
>
> Described protocol change could be implemented as user activated soft-fork
> (described in BIP148), introducing new blocks with the modified
> proof-of-work concept.
>
> * Economic reasoning*
>
> An adversary whose goal is to prevent the network from transferring value
> will have to compete with good users hash rate using same equipment good
> miners will use. And it's far more complicated than competing with others
> using the money to pay transaction fees.
>
> In order to investigate probable consequences of protocol upgrade and
> stability of implied economical equilibrium, we need an adequate game
> theoretical model. Such model and numerical simulation results should be
> obtained and studied before any protocol change could be considered by the
> community.
>
> To me it seems like a win-win solution for everyone owning BTC:
>
> Miners benefit: as the result DDoS attack will be stopped, Bitcoin becomes
> perfect store-of-value finally. Political decentralization of hash rate
> will be incentivized as mining equipment becomes relevant to every user.
> Users benefit: miners will have direct incentives to include transactions
> deemed important by their sender and supported by some amount of
> proof-of-work.
>
> Sincerely yours, Ilya Eriklintsev.
>

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

<div dir=3D"ltr">Thanks a lot for the reply, let me think it over and come =
up with a proper response. You and Conrad may be right about the proposal b=
eing irrelevant to DDoS, so I&#39;ll try to come up with the more solid arg=
ument supporting my point of view, otherwise, I will refute the proposal my=
self). At the moment I feel like I need to specify game theoretical model a=
nd consider all costs and incentives in more details. Sincerely yours, Ilya=
 Eriklintsev.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On 22 June 2017 at 16:47, John Hardy <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:john@seebitcoin.com" target=3D"_blank">john@seebitcoin.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">




<div dir=3D"ltr">
<div id=3D"m_1143854536130231162divtagdefaultwrapper" style=3D"font-size:12=
pt;color:#000000;font-family:Calibri,Helvetica,sans-serif" dir=3D"ltr">
<p>Hi Ilya,</p>
<p><br>
</p>
<p>This proposal wouldn&#39;t work because bad actors can perform PoW just =
as cheaply as any other participant.</p>
<p><br>
</p>
<p>The transaction fee already acts as a mechanism to prevent spam. It is n=
ot a problem to have a lot of low value transactions in the mempool as thre=
sholds can easily be set for them to be disregarded/expire - a 300MB =C2=A0=
maxmempool size by default eliminates
 any real &#39;DDOS&#39; risk. Spam only really becomes an issue when it en=
ters the blockchain. If a spammer is willing to pay the tx fee to spam, the=
y&#39;d be willing to pay the PoW.</p>
<p><br>
</p>
<p>The only actors who can spam the blockchain at zero cost are the miners =
themselves (beyond the opportunity cost of including genuine fee paying tra=
nsactions). They can even do it without their transactions ever hitting the=
 mempool or including a fee, though
 this behaviour would be easy to spot.</p>
<p><br>
</p>
<p>If miners are colluding to spam the mempool or blocks in order to increa=
se the average transaction cost overall there is little that can be done as=
 the network relies on 51% of hashpower being honest. A miner creating spam=
 transactions that enter the mempool
 has the risk that another miner would include it in a block and they would=
 incur an economic cost if this happened.</p>
<p><br>
</p>
<p>I had an idea for a dynamic blocksize that required miners to pay a perc=
entage of the transaction fees to the next mined block.
<span style=3D"font-family:Calibri,Helvetica,sans-serif,EmojiFont,&quot;App=
le Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe =
UI Symbol&quot;,&quot;Android Emoji&quot;,EmojiSymbols;font-size:16px">
Here is a link:=C2=A0</span><a href=3D"https://lists.linuxfoundation.org/pi=
permail/bitcoin-discuss/2017-January/000123.html" class=3D"m_11438545361302=
31162OWAAutoLink" id=3D"m_1143854536130231162LPlnk778968" style=3D"font-fam=
ily:Calibri,Helvetica,sans-serif,EmojiFont,&quot;Apple Color Emoji&quot;,&q=
uot;Segoe UI Emoji&quot;,NotoColorEmoji,&quot;Segoe UI Symbol&quot;,&quot;A=
ndroid Emoji&quot;,EmojiSymbols;font-size:16px" target=3D"_blank">https://l=
ists.<wbr>linuxfoundation.org/pipermail/<wbr>bitcoin-discuss/2017-January/<=
wbr>000123.html</a></p>
<p><br>
</p>
<p>If it was established that miners spamming blocks with transactions was =
an issue, this could be used as a disincentive as it means the cost for doi=
ng so becomes non-zero.</p>
<p><br>
</p>
Regards,
<div><br>
</div>
<div>John Hardy</div>
<div><a href=3D"mailto:john@seebitcoin.com" target=3D"_blank">john@seebitco=
in.com</a></div>
<div><br>
<div style=3D"color:rgb(0,0,0)">
<hr style=3D"display:inline-block;width:98%">
<div id=3D"m_1143854536130231162divRplyFwdMsg" dir=3D"ltr"><font face=3D"Ca=
libri, sans-serif" color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> =
<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev-bounces@lists.<wbr>linuxfoundation.org</a> &lt;<a href=
=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev-bounces@lists.<wbr>linuxfoundation.org</a>&gt; on behalf of Il=
ya Eriklintsev via bitcoin-dev
 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;<br>
<b>Sent:</b> Wednesday, June 21, 2017 9:55 AM<br>
<b>To:</b> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<b>Subject:</b> [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized =
proof-of-work</font>
<div>=C2=A0</div>
</div><div><div class=3D"h5">
<div>
<div dir=3D"ltr"><span style=3D"font-size:12.8px">Hello everyone,</span>
<div style=3D"font-size:12.8px"><br>
<div>recently I have got an idea that in my opinion will improve bitcoin ne=
twork, making it better store-of-value for growing cyberspace and cryptoeco=
nomy. Sorry for longread=C2=A0below and thank you for your time.
<div><br>
</div>
<b>Decentralized proof-of-work and DDoS resistance for Bitcoin</b><br>
<br>
<b>Abstract</b><br>
<br>
By introducing some new block validation rules it is possible to make Bitco=
in network more secure, decentralized and DDoS resistant. The idea is to mo=
dify simple proof-of-work puzzle in such a way that user transactions could=
 be hardened with the same proof-of-work
 algorithm thus incentivising all the miners to include that particular tra=
nsaction. Such mechanism will effectively give a handicap to every miner wh=
o includes &quot;mined&quot; transaction into next block, increasing probab=
ility of him getting block reward.<br>
<br>
<b>Problems and motivation</b><br>
<br>
This document will address the issue of a continuous DDoS attack targeting =
the Bitcoin network, e.g. full nodes mempools constantly being overflowed w=
ith transactions carrying small value reduce system primary ability to tran=
sfer value (and hence making it
 perfect store of value). Valid transactions are cheap to create (in the se=
nse of computational effort required) and no adequate mechanism exist to ma=
ke transaction total value increase probably of its confirmation by the net=
work.<br>
<br>
Currently, miners decide which transactions to include in blocks because it=
&#39;s them who are securing Bitcoin network providing proof-of-work certif=
icates stored inside every block header. Miners have to store the whole blo=
ckchain at all times, so one of the
 costs is storage which grows linearly with the transaction size (blockchai=
n size as well). Another cost is network bandwidth which depends directly o=
n the size of data to be communicated over.<br>
<br>
The only incentive a person who wants to transfer his bitcoins is allowed t=
o use is setting of transaction fee, that is going directly to the miner. T=
his solution probably was intended to utilize free market (as implied by Sa=
toshi introducing sequence numbers)
 to determine appropriate fees, but that is obviously not the case, in the =
current bitcoin network operating in full block capacity mode. This fee mar=
ket deviates significantly from a free market premise (also attempts being =
made to make it closer, e.g. in
 BIP125 where Replace-By-Fee signaling is supposed to help in replacing &qu=
ot;stuck&quot; transactions with noncompetitive fee).<br>
<br>
Currently, bitcoin network is susceptible to the DDoS attack of a kind. Adv=
ersary creating and translating into the network a lot of transactions carr=
ying small value (e.g. only miners fee), will be able to impair the ability=
 to transfer value for everyone
 in the world, should he has enough money to pay the fees. Miners would con=
tinue to work providing security for the network and new blocks will consis=
t of transaction transferring negligible value. It&#39;s a major drawback b=
ecause the cost of such attack doesn&#39;t
 grow asymmetrically with the cost of BTC asset.<br>
<br>
<b>Proposed solution</b><br>
<br>
So how do we incentivize all miners to include our transaction carrying a l=
ot of value in the next block? The only thing a miner supposed to do to get=
 a reward is to produce Hashcash proof-of-work, thus providing cryptographi=
c security guarantees for the whole
 Bitcoin blockchain. What if including our transaction in a block would red=
uce effort requirements for the miner produce valid block?<br>
<br>
We could do so by extending the concept of proof-of-work, in such a way tha=
t we do not sacrifice security at all. Here are both descriptions proof-of-=
work as-is and to-be:<br>
<br>
Standart proof-of-work: hash(previous block hash + current block target + c=
urrent block metadata + current block transactions) &lt; target<br>
<br>
Decentralized proof-of-work: hash(previous block hash + current block targe=
t + current block metadata + current block transactions) - sum( FFFF - hash=
( previous block hash + raw_tx ) ) &lt; target<br>
<br>
It is possible to imagine completely mining agnostic proof-of-work, for exa=
mple, the following PoW would do:<br>
<br>
Distributed (mining-agnostic) proof-of-work: sum( FFFF - hash( previous blo=
ck hash + current block target + current block metadata + signed_tx ) ) &lt=
; target<br>
<br>
Described protocol change could be implemented as user activated soft-fork =
(described in BIP148), introducing new blocks with the modified proof-of-wo=
rk concept.<br>
<b><br>
Economic reasoning</b><br>
<br>
An adversary whose goal is to prevent the network from transferring value w=
ill have to compete with good users hash rate using same equipment good min=
ers will use. And it&#39;s far more complicated than competing with others =
using the money to pay transaction fees.<br>
<br>
In order to investigate probable consequences of protocol upgrade and stabi=
lity of implied economical equilibrium, we need an adequate game theoretica=
l model. Such model and numerical simulation results should be obtained and=
 studied before any protocol change
 could be considered by the community.<br>
<br>
To me it seems like a win-win solution for everyone owning BTC:<br>
<br>
Miners benefit: as the result DDoS attack will be stopped, Bitcoin becomes =
perfect store-of-value finally. Political decentralization of hash rate wil=
l be incentivized as mining equipment becomes relevant to every user.<br>
Users benefit: miners will have direct incentives to include transactions d=
eemed important by their sender and supported by some amount of proof-of-wo=
rk.</div>
<div><br>
</div>
<div>Sincerely yours, Ilya Eriklintsev.</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>
</div>

</blockquote></div><br></div>

--001a113fb6805438ae05528d29e0--