path: root/db/fe4bb7a2ad445e2416cf91395e14dca551aea2

Return-Path: <tensiam@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D955DCD3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 10:10:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from EUR02-VE1-obe.outbound.protection.outlook.com
	(mail-oln040092069108.outbound.protection.outlook.com [40.92.69.108])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44A3071C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 10:10:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
	s=selector1;
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
	bh=9iw7I4G+kdQHv+Y3vNzKDMxc42AbfZs/YU1+nOooYaU=;
	b=kRygxrzRjoLC98UZ+5Nqr+tkhWnReW2aMcPyO0YIi31I9eFjWb4WnShqV2+f6CPsPycrQPYvLgeO591HksRdaZh+9sk95U1EC404/zchTtZv9weL9RXeitAhb7jZTjKx2wsrtu/Bp9j7ue0suakboGtgvwiP7/7uFSzbfrASNxCU8SuL1Fg9dh4QTK4XP7nKdjsC4UFiB63IuKI4ZLd5xJ9vCrjLtcbSV8p6k1wP40QmhLS6u28Q7NGRoNIzLIcGM1Pmb1XUkJrxTb63jqBeTOyMcsm5neIkcTghYs1SkOX0pkOob3UeErh6QW9TMnyfYN67TDNMMNSWEq4lWUaMEA==
Received: from VE1EUR02FT053.eop-EUR02.prod.protection.outlook.com
	(10.152.12.52) by VE1EUR02HT040.eop-EUR02.prod.protection.outlook.com
	(10.152.13.247) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.19;
	Wed, 17 Jul 2019 10:10:23 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.12.56) by
	VE1EUR02FT053.mail.protection.outlook.com (10.152.13.137) with
	Microsoft SMTP
	Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
	15.20.2052.19 via Frontend Transport; Wed, 17 Jul 2019 10:10:23 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
	([fe80::c5ee:488e:37fb:4be5]) by
	DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
	([fe80::c5ee:488e:37fb:4be5%4]) with mapi id 15.20.2073.012;
	Wed, 17 Jul 2019 10:10:23 +0000
From: "Kenshiro []" <tensiam@hotmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	ZmnSCPxj <ZmnSCPxj@protonmail.com>
Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabN5JoAgAC5YAg=
Date: Wed, 17 Jul 2019 10:10:23 +0000
Message-ID: <DB6PR10MB1832BAAB9D194B6AA61C2573A6C90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
In-Reply-To: <Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
Accept-Language: en-US, es-ES
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:7FC67997B5D5839612AEADEE9ED386AB9659C9ABBD6565BC2AC82C2A691F2F82;
	UpperCasedChecksum:61448249A0A2C5935749066CA2B4C4CBD126155A98FB828261926926897CE67F;
	SizeAsReceived:6991; Count:42
x-tmn: [9NjXFxtGgnuLl0Rhnzdcp8OfokP8i8jH]
x-ms-publictraffictype: Email
x-incomingheadercount: 42
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0;
	RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045);
	SRVR:VE1EUR02HT040; 
x-ms-traffictypediagnostic: VE1EUR02HT040:
x-microsoft-antispam-message-info: /o7UsI9hy3nEL4CDEivICGmHDlYSlk4odM16C1ZjC31HJLayDZrrZAWErvemF8vkXWjyaS/dAy0m7/naJ1Eh2EaBj9Vc3diwCdAVlNsnMWeo6/hZ/1gK+wn/YtwINfnOI0ytOy9UxAvSTzcnHCMF0WursHbPvCXllDVxmVx/m2/UFPW48F3h5lUiwqg1Ham6
Content-Type: multipart/alternative;
	boundary="_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0cb30bd7-1889-40fd-7a08-08d70a9efb9f
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 10:10:23.8358 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT040
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY,
	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: Wed, 17 Jul 2019 10:49:15 +0000
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
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: Wed, 17 Jul 2019 10:10:28 -0000

--_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

Hi ZmnSCPxj,

I'm based on the more evolved implementation of PoS that I know, which is P=
oS v3.0 and it's currently implemented in several coins:

http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-s=
take-version

As far as I know the grinding attack is and old issue that is fixed in PoS =
v3.0.

>>>At least the proposed `assumeutxo` requires the operator to explicitly e=
nable it, but I believe your "hardcoded checkpoints" cannot be disabled, mu=
ch less disabled-by-default.

We don't trust the developers, the source code is public and anyone can che=
ck it. With the hardcoded checkpoints is exactly the same, they are in the =
source code repository and everyone can check them. The checkpoints are the=
 easiest part to check. A user doesn't have any reason to remove the checkp=
oints, but as with anything in the source code, they could modify it to avo=
id the checkpoints (and become vulnerable to Long Range attacks doing it)

>>>Under the trust-minimization requirement of Bitcoin this is simply not a=
cceptable.
As there is no way to trust-minimally heal from a network split (and every =
time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus=
 algorithm.

The block explorer or other additional source of trust like a friend would =
only be required in the extreme situation that the network is under a 51% a=
ttack, and only by the nodes that are updating blocks in that moment. Updat=
ed nodes are fully protected, and under normal circumstances new nodes can =
just follow the longest chain as always. The other extreme situation that c=
ould cause a hard fork is that the network is splitted more than N blocks, =
which should require some social consensus to fix it. So N should be long e=
nough, like a few hours of blocks or even 1 day.

>>> History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily censor=
 on the creation of new blocks.

I don't agree, history rewrite attacks are much worse than censorship becau=
se they can be used to steal funds from people. In PoS staking addresses ar=
e public, so maybe it should be possible to detect if some transaction in t=
he mempool is repeatedly being ignored and what staking deposit is repeated=
ly ignoring transactions. After some time, a hard fork could burn the funds=
 of the evil validator.

>>> Worse, under proof-of-stake it is often the case that stakers are award=
ed even more coin with which they can stake.

Sure, but in PoW the miners with more hash power earn more coins that can b=
e used to purchase more miners. There is always the privilege of the rich g=
uy, no matter if its PoW or PoS. The point is to design a protocol that don=
't allow the rich to destroy the network.


Let me put it in this way: NXT is a PoS coin that uses moving checkpoints w=
ith a market cap of 21 million dollars. If the current PoS protocols are so=
 flawed, how can you explain that a coin with this market cap is not being =
attacked?

https://www.coingecko.com/en/coins/nxt

Another thing is that Ethereum itself is going to PoS next year, but with a=
 different implementation that I'm proposing here.

Regards,

________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Wednesday, July 17, 2019 1:00
To: Kenshiro \[\]; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

Good morning Kenshiro,


Sent with ProtonMail Secure Email.

=1B$B!>!>!>!>!>!>!>=1B(B Original Message =1B$B!>!>!>!>!>!>!>=1B(B
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:

> Hi,
>
> After studying several Proof of Stake implementations I think it's not on=
ly an eco-friendly (and more ethical) alternative to Proof of Work, but cor=
rectly implemented could be 100% secure against all 51% history rewrite att=
acks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvemen=
ts are required:

Under the trust-minimization and uncensorability requirements that Bitcoin =
has, nothing is more efficient than proof-of-work.
The very idea of proof-of-stake labors under the assumption that unencumber=
ed free-market payment for the consumption of energy is somehow not market-=
efficient despite the well-known phenomenon of the invisible hand, and beli=
eves that it is possible to get something for nothing.

Please re-examine your assumptions.

> - Hardcoded checkpoints:each Bitcoin Core release (each few months) shoul=
d include a hardcoded checkpoint with the hash of the current block height =
in that moment. This simple measure protects the blockchain up to the last =
checkpoint, and prevents any Long-Range attack.

While this is a developer list and made up of developers who would be quite=
 incentivized to agree to such a setup, note that this effectively trusts t=
he developers.
At least the proposed `assumeutxo` requires the operator to explicitly enab=
le it, but I believe your "hardcoded checkpoints" cannot be disabled, much =
less disabled-by-default.

> This extra rule could be connecting to a block explorer to download the h=
ash of the current block height, or ask some trusted source like a friend a=
nd enter the hash manually. After being fully updated, the user can always =
check that he is in the correct chain checking with a block explorer.

Under the trust-minimization requirement of Bitcoin this is simply not acce=
ptable.
As there is no way to trust-minimally heal from a network split (and every =
time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus=
 algorithm.

>
> Someone could have 99% of the coins and still would be unable to use the =
coins to do any history rewrite attack. The attacker could only slow down t=
he network not creating his blocks, or censor transactions in his blocks.

History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily censor=
 on the creation of new blocks.

Censorship attacks cannot be prevented except by ensuring that no single en=
tity can claim 51% control of new block creation.
By ensuring this, we can ensure that at least some other entities are unlik=
ely to keep a transaction out of the blockchain, and in particular that no =
entity can make a short-ranged history rewrite if a censored transaction *d=
oes* get into the blockchain from the efforts of another block producer.

This is trivial under proof-of-work, and is the cost we accept in order to =
achieve uncensorability, since it is non-trivial to acquire energy.
Under proof-of-stake it is difficult to impossible to determine if some sin=
gle entity controls >51% of stakeable coins, and thus has no way to protect=
 against censorship attack.
Worse, under proof-of-stake it is often the case that stakers are awarded e=
ven more coin with which they can stake.

Depending on the PoS implementation, stake-grinding may allow a 49% staker =
to achieve 51% and thereby the ability to censor transactions.


Regards,
ZmnSCPxj

--_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-=
jp">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span>Hi ZmnSCPxj,<br>
</span>
<div><br>
</div>
<div>I'm based on the more evolved implementation of PoS that I know, which=
 is PoS v3.0 and it's currently implemented in several coins:<br>
</div>
<div><br>
</div>
<div>http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof=
-of-stake-version<br>
</div>
<div><br>
</div>
<div>As far as I know the grinding attack is and old issue that is fixed in=
 PoS v3.0.<br>
</div>
<div><br>
</div>
<div>&gt;&gt;&gt;At least the proposed `assumeutxo` requires the operator t=
o explicitly enable it, but I believe your &quot;hardcoded checkpoints&quot=
; cannot be disabled, much less disabled-by-default.<br>
</div>
<div><br>
</div>
<div>We don't trust the developers, the source code is public and anyone ca=
n check it. With the hardcoded checkpoints is exactly the same, they are in=
 the source code repository and everyone can check them. The checkpoints ar=
e the easiest part to check. A user
 doesn't have any reason to remove the checkpoints, but as with anything in=
 the source code, they could modify it to avoid the checkpoints (and become=
 vulnerable to Long Range attacks doing it)<br>
</div>
<div><br>
</div>
<div>&gt;&gt;&gt;Under the trust-minimization requirement of Bitcoin this i=
s simply not acceptable.<br>
</div>
<div>As there is no way to trust-minimally heal from a network split (and e=
very time a node is shut down, that is indistinguishable from a network spl=
it that isolates that particular node), this is not a trust-minimizing cons=
ensus algorithm.<br>
</div>
<div><br>
</div>
<div>The block explorer or other additional source of trust like a friend w=
ould only be required in the extreme situation that the network is under a =
51% attack, and only by the nodes that are updating blocks in that moment. =
Updated nodes are fully protected,
 and under normal circumstances new nodes can just follow the longest chain=
 as always. The other extreme situation that could cause a hard fork is tha=
t the network is splitted more than N blocks, which should require some soc=
ial consensus to fix it. So N should
 be long enough, like a few hours of blocks or even 1 day.<br>
</div>
<div><br>
</div>
<div>&gt;&gt;&gt; History rewrites are not the only attack possible.<br>
</div>
<div>The worst attack is a censorship attack, and a 99% staker can easily c=
ensor on the creation of new blocks.<br>
</div>
<div><br>
</div>
<div>I don't agree, history rewrite attacks are much worse than censorship =
because they can be used to steal funds from people. In PoS staking address=
es are public, so maybe it should be possible to detect if some transaction=
 in the mempool is repeatedly&nbsp;being
 ignored and what staking deposit is repeatedly ignoring transactions. Afte=
r some time, a hard fork could burn the funds of the evil validator.<br>
</div>
<div><br>
</div>
<div>&gt;&gt;&gt; Worse, under proof-of-stake it is often the case that sta=
kers are awarded even more coin with which they can stake.<br>
</div>
<div><br>
</div>
<div>Sure, but in PoW the miners with more hash power earn more coins that =
can be used to purchase more miners. There is always the privilege of the r=
ich guy, no matter if its PoW or PoS. The point is to design a protocol tha=
t don't allow the rich to destroy
 the network.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Let me put it in this way: NXT is a PoS coin that uses moving checkpoi=
nts with a market cap of 21 million dollars. If the current PoS protocols a=
re so flawed, how can you explain that a coin with this market cap is not b=
eing attacked?<br>
</div>
<div><br>
</div>
<div>https://www.coingecko.com/en/coins/nxt<br>
</div>
<div><br>
</div>
<div>Another thing is that Ethereum itself is going to PoS next year, but w=
ith a different implementation that I'm proposing here.<br>
</div>
<div><br>
</div>
<span>Regards,</span><br>
</div>
<div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> ZmnSCPxj &lt;ZmnSCPxj=
@protonmail.com&gt;<br>
<b>Sent:</b> Wednesday, July 17, 2019 1:00<br>
<b>To:</b> Kenshiro \[\]; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Secure Proof Of Stake implementation on B=
itcoin</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">Good morning Kenshiro,<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
=1B$B!>!>!>!>!>!>!>=1B(B Original Message =1B$B!>!>!>!>!>!>!>=1B(B<br>
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev &lt;bitcoi=
n-dev@lists.linuxfoundation.org&gt; wrote:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; After studying several Proof of Stake implementations I think it's not=
 only an eco-friendly (and more ethical) alternative to Proof of Work, but =
correctly implemented could be 100% secure against all 51% history rewrite =
attacks. Over a &quot;standard&quot; PoS protocol
 like PoS v3.0, only 2 extra improvements are required:<br>
<br>
Under the trust-minimization and uncensorability requirements that Bitcoin =
has, nothing is more efficient than proof-of-work.<br>
The very idea of proof-of-stake labors under the assumption that unencumber=
ed free-market payment for the consumption of energy is somehow not market-=
efficient despite the well-known phenomenon of the invisible hand, and beli=
eves that it is possible to get
 something for nothing.<br>
<br>
Please re-examine your assumptions.<br>
<br>
&gt; - Hardcoded checkpoints:each Bitcoin Core release (each few months) sh=
ould include a hardcoded checkpoint with the hash of the current block heig=
ht in that moment. This simple measure protects the blockchain up to the la=
st checkpoint, and prevents any Long-Range
 attack.<br>
<br>
While this is a developer list and made up of developers who would be quite=
 incentivized to agree to such a setup, note that this effectively trusts t=
he developers.<br>
At least the proposed `assumeutxo` requires the operator to explicitly enab=
le it, but I believe your &quot;hardcoded checkpoints&quot; cannot be disab=
led, much less disabled-by-default.<br>
<br>
&gt; This extra rule could be connecting to a block explorer to download th=
e hash of the current block height, or ask some trusted source like a frien=
d and enter the hash manually. After being fully updated, the user can alwa=
ys check that he is in the correct
 chain checking with a block explorer.<br>
<br>
Under the trust-minimization requirement of Bitcoin this is simply not acce=
ptable.<br>
As there is no way to trust-minimally heal from a network split (and every =
time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus=
 algorithm.<br>
<br>
&gt;<br>
&gt; Someone could have 99% of the coins and still would be unable to use t=
he coins to do any history rewrite attack. The attacker could only slow dow=
n the network not creating his blocks, or censor transactions in his blocks=
.<br>
<br>
History rewrites are not the only attack possible.<br>
The worst attack is a censorship attack, and a 99% staker can easily censor=
 on the creation of new blocks.<br>
<br>
Censorship attacks cannot be prevented except by ensuring that no single en=
tity can claim 51% control of new block creation.<br>
By ensuring this, we can ensure that at least some other entities are unlik=
ely to keep a transaction out of the blockchain, and in particular that no =
entity can make a short-ranged history rewrite if a censored transaction *d=
oes* get into the blockchain from
 the efforts of another block producer.<br>
<br>
This is trivial under proof-of-work, and is the cost we accept in order to =
achieve uncensorability, since it is non-trivial to acquire energy.<br>
Under proof-of-stake it is difficult to impossible to determine if some sin=
gle entity controls &gt;51% of stakeable coins, and thus has no way to prot=
ect against censorship attack.<br>
Worse, under proof-of-stake it is often the case that stakers are awarded e=
ven more coin with which they can stake.<br>
<br>
Depending on the PoS implementation, stake-grinding may allow a 49% staker =
to achieve 51% and thereby the ability to censor transactions.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</div>
</span></font></div>
</div>
</body>
</html>

--_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_--