path: root/6a/8eea6e8372aee3c491333e37fb15e5f192f7ec

Return-Path: <eric@voskuil.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C7A3EC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 08:55:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id B5F9040137
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 08:55:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=voskuil-org.20150623.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id qcBlQ2bzu8o2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 08:55:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com
 [IPv6:2607:f8b0:4864:20::62c])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3E1A6402E3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 08:55:48 +0000 (UTC)
Received: by mail-pl1-x62c.google.com with SMTP id z4so1071859plg.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 01:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20150623.gappssmtp.com; s=20150623;
 h=from:to:cc:references:in-reply-to:subject:date:message-id
 :mime-version:thread-index:content-language;
 bh=2Xtfy5GqrUdbqxW0mbGyXnKsULjlR7fDR43OVxiEI4U=;
 b=UBCp7d9wSr/Osgi1ArA3g0RmQW+B3GsTPkQtZigBoxNaie+wnsK3ZbsKyLgL4E9+BY
 KQ6TBDyL2p/ECskt7VEq0V7xgfE9vZaSQL0pFdTJdTPWavVUHZp2bioUhYg6FW9dghc1
 JdRdPnBNeZ8+gnxQ9b/JQ+Fb8yEAlUamG/ONiwI3+H+P+FN38ByO9fyYeC52xF5bFGbX
 zmQHSwBeJ8PqtsM+NLR84VaZ27DOKc+eZK7Hv1rbIC6JzDLZlDbkvAtXupv8drwsevT9
 R5WCP12te7wV3oQPePCsHGeWtQIpUtsDz36pGtKycdEaxuQgvD5i2Yd+7i89WlU6ImXS
 Aa8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date
 :message-id:mime-version:thread-index:content-language;
 bh=2Xtfy5GqrUdbqxW0mbGyXnKsULjlR7fDR43OVxiEI4U=;
 b=RV6WH/0+xA0nXLSnTik/5sphmkAPivAnDofTqa2cyOIpqd01oRpaBcFa6JTf+pXpvr
 +ZVyIredoBy34Fndwto9T8AyBLgBJFup1q3Y4QQvnTFfSTVnnMDJLuszLBibhELCFwfv
 zqbn2RLh9z5EE8TQ2O9AcLDao0ZFcXTp2pHMS0OWZR9bT1YoWYAVxFu9sQsjAlZ5TleR
 zNniIuvA3boeDxcCdDIGRkaaRphaZTBZjoMQyQVsXp+AlBL9ofj1QM5StFQejB5/VS/J
 DtHjWWuVxDDsyxvJOaubucaskJ9EJriRZQFLXyWY3Dr+fo0tzrPITaLRKn9WaYmKg29w
 +hTA==
X-Gm-Message-State: AOAM531JRsZWgbS2inIUSj++ZZgI+16D+8qwUwdeZqfGCPb16jekRRMW
 DZ6SC0ZR6Q/B1uyzfmL3+rTm/Q==
X-Google-Smtp-Source: ABdhPJzLMJZs4Whij513I3restW3i/S3b51HX+3QdQBW0Ork8m9IlVByLH0nyC4FfZ1yXw2hTKQk6Q==
X-Received: by 2002:a17:90a:df10:: with SMTP id
 gp16mr3433056pjb.164.1625043347614; 
 Wed, 30 Jun 2021 01:55:47 -0700 (PDT)
Received: from ERICDESKTOP ([2601:600:9c00:1d0::9d25])
 by smtp.gmail.com with ESMTPSA id z26sm17131623pfk.112.2021.06.30.01.55.46
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 30 Jun 2021 01:55:47 -0700 (PDT)
From: <eric@voskuil.org>
To: "'Billy Tetrud'" <billy.tetrud@gmail.com>
References: <CABm2gDot=YnMB8isbouLV_g=P=OAeN7H966juqbBexXyK9jw8A@mail.gmail.com>
 <2368396E-6964-4F12-B50F-2BE477D0C7D8@voskuil.org>
 <CAGpPWDZVak_8pbfOE7SXNWy31_5LmabY4xj8pseUzR7XMJX5ug@mail.gmail.com>
In-Reply-To: <CAGpPWDZVak_8pbfOE7SXNWy31_5LmabY4xj8pseUzR7XMJX5ug@mail.gmail.com>
Date: Wed, 30 Jun 2021 01:55:47 -0700
Message-ID: <020101d76d8d$b86397f0$292ac7d0$@voskuil.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----=_NextPart_000_0202_01D76D53.0C05F870"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGzRHqRlNUnlmfFxKP28gVDQPjFFgHW7TzYAa1DJcarWGSOAA==
Content-Language: en-us
Cc: 'Bitcoin Protocol Discussion' <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork upgrades
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, 30 Jun 2021 08:55:49 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0202_01D76D53.0C05F870
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All good questions.

=20

> Is the goal here to do what the economic majority wants, or some other =
group? If so, do you think we have an accurate way of measuring what the =
economic majority wants?

=20

It=E2=80=99s important that people understand that =
=E2=80=9Ceconomic=E2=80=9D does not refer to people interested in, =
HODLing, coding, or selling Bitcoin. It is only those who are *presently =
accepting* it. We refer to these as =E2=80=9Ceconomic nodes=E2=80=9D. =
Those are the people with the economic power to reject coin that they =
consider invalid. Only their validation is of any economic consequence =
in the event of a split. I see no reason to assume that the economy is =
any less centralized than mining is pooled. Today the support of the =
economy would be best measured by meeting with exchange operators. If =
they did not go along, any unenforced soft fork (split) would isolate =
everyone who thought they could continue to trade their coin on =
exchanges.

=20

I=E2=80=99d also question the use of the term =
=E2=80=9Cmajority=E2=80=9D. It applies to hash power, by design, but not =
to the economy. A split of any size is possible, requiring no majority. =
All it requires is other people to trade with.

=20

Exchanges are highly regulated and compliant institutions. Mining =
operations are heavily pooled. Neither of these is inherently better =
than the other. Everyone can have a say by being a miner or being a =
merchant. Subeconomies can split, majority hash power can censor (which =
is the exact mechanism of soft fork enforcement). These ideas are =
straightforward and hardly worthy of debate. The interesting question is =
how one gets others to go along with his new coin. Make no mistake, any =
rule change (soft or hard) is a new coin. If hash power doesn=E2=80=99t =
enforce the new rules of a soft fork, the chain is split just as if it =
was a hard fork.

=20

I=E2=80=99m sure people will continue to try and devise ways to figure =
out who wants to come along, to try and convince people (including =
exchanges and miners) to do so, to reassure them that everyone else will =
=E2=80=9Chave to=E2=80=9D, and to mislead them about the actual behavior =
and risks. We=E2=80=99ve seen permanent splits, and we=E2=80=99ve seen =
hash power enforced soft forks. We=E2=80=99re likely to see more of =
both. But as core devs we have a responsibility to inform people, =
honestly, and let them decide. My only beef with this whole process has =
been that a widespread belief had formed, supported by far too many core =
devs (and even embedded in the text of deployed BIPs), that soft forks =
are inherently =E2=80=9Cbackward compatible=E2=80=9D. This is =
unequivocally not true. The only such compatibility is majority hash =
power enforcement of a soft fork. This is not a matter of opinion, =
it=E2=80=99s the core innovation of Bitcoin. Proof of Work settles the =
question of who has authority to order transactions. Majority hash power =
has that authority. Merchants can split again and again, but their =
miners will still have that authority. If one wants a say, one can mine.

=20

e

=20

From: Billy Tetrud <billy.tetrud@gmail.com>=20
Sent: Tuesday, June 29, 2021 7:03 PM
To: Eric Voskuil <eric@voskuil.org>
Cc: Jorge Tim=C3=B3n <jtimon@jtimon.cc>; Luke Dashjr <luke@dashjr.org>; =
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Trinary Version Signaling for softfork =
upgrades

=20

@Jorge

=20

>I don't think we should avoid splits at all costs.

=20

I absolutely agree that we shouldn't avoid splits at all costs. There =
are some costs too high to pay to avoid a split. If an economic majority =
started wanting to increase bitcoin's blocksize to 1 GB next year, we =
should absolutely hard fork away from that mess with a minority chain.=20

=20

>  I don't think we should avoid splits when possible,=20

=20

I want to see why exactly we disagree about avoiding chain splits "when =
possible". Are you really saying that we should just hard fork every =
time instead of soft fork? Should we even bother to get widespread buy =
in at all, or should we just release the software, hardfork away, and =
let anyone that wants to follow us follow us later? Are you not at all =
worried about the costs associated with an increased orphan rate and =
reorg rate? Are you not worried that an update might happen too fast and =
that a significant fraction of people that could have come along with us =
to the new update might be left behind because they didn't have time to =
evaluate the changed rules?

=20

Do you agree that, in a conversation about rule changes, some people =
want it their way no matter what and will hardfork to get the rules they =
want, and some people want it their way, but only if enough other people =
agree to follow those rules too? Some people might want a rule change, =
but aren't willing to follow, say, a 20% minority fork. Perhaps their =
personal cut-off is 40% or 50% or 75% or 90%. Do you agree those people =
exist?=20

=20

If you do, then I don't understand why you disagree that we should avoid =
chain splits even "when possible". Maybe you could elaborate as to what =
you mean there.=20

=20

@Luke

=20

Are you in agreement with Jorge here that we should not even attempt to =
avoid chain splits?=20

=20

> The only alternative to a split in the problematic scenarios are 1) =
concede centralised miner control over the network, and 2) have =
inconsistent enforcement of rules by users who don't agree on what the =
correct rules are, again leading to centralised miner control over the =
network.

=20

There is not simply a binary "do or do not". There is also timing. =
Non-contentious changes can happen fast. Contentious changes need more =
time for discussion, preparation, or coordination, even if the eventual =
outcome is the same. Do you disagree that timing issues can be =
important, that delays can be useful and help to avoid chain splits? Do =
you agree that miners have a (large) incentive to follow the economic =
majority? Is the goal here to do what the economic majority wants, or =
some other group? If so, do you think we have an accurate way of =
measuring what the economic majority wants? Will that mechanism continue =
to be accurate into the future?=20

=20

I'm asking these questions to try and figure out why we disagree here.


------=_NextPart_000_0202_01D76D53.0C05F870
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta =
name=3DGenerator content=3D"Microsoft Word 15 (filtered =
medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple style=3D'word-wrap:break-word'><div =
class=3DWordSection1><p class=3DMsoNormal>All good =
questions.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>&gt; Is the goal here to&nbsp;do what the economic =
majority wants,&nbsp;or some other group? If so, do you think we have an =
accurate way of measuring what the economic majority =
wants?<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>It=E2=80=99s important that people understand that =
=E2=80=9Ceconomic=E2=80=9D does not refer to people interested in, =
HODLing, coding, or selling Bitcoin. It is only those who are =
*<b>presently accepting</b>* it. We refer to these as =E2=80=9Ceconomic =
nodes=E2=80=9D. Those are the people with the economic power to reject =
coin that they consider invalid. Only their validation is of any =
economic consequence in the event of a split. I see no reason to assume =
that the economy is any less centralized than mining is pooled. Today =
the support of the economy would be best measured by meeting with =
exchange operators. If they did not go along, any unenforced soft fork =
(split) would isolate everyone who thought they could continue to trade =
their coin on exchanges.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I=E2=80=99d =
also question the use of the term =E2=80=9Cmajority=E2=80=9D. It applies =
to hash power, by design, but not to the economy. A split of any size is =
possible, requiring no majority. All it requires is other people to =
trade with.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Exchanges are highly regulated and compliant =
institutions. Mining operations are heavily pooled. Neither of these is =
inherently better than the other. Everyone can have a say by being a =
miner or being a merchant. Subeconomies can split, majority hash power =
can censor (which is the exact mechanism of soft fork enforcement). =
These ideas are straightforward and hardly worthy of debate. The =
interesting question is how one gets others to go along with his new =
coin. Make no mistake, any rule change (soft or hard) is a new coin. If =
hash power doesn=E2=80=99t enforce the new rules of a soft fork, the =
chain is split just as if it was a hard fork.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I=E2=80=99m =
sure people will continue to try and devise ways to figure out who wants =
to come along, to try and convince people (including exchanges and =
miners) to do so, to reassure them that everyone else will =E2=80=9Chave =
to=E2=80=9D, and to mislead them about the actual behavior and risks. =
We=E2=80=99ve seen permanent splits, and we=E2=80=99ve seen hash power =
enforced soft forks. We=E2=80=99re likely to see more of both. But as =
core devs we have a responsibility to inform people, honestly, and let =
them decide. My only beef with this whole process has been that a =
widespread belief had formed, supported by far too many core devs (and =
even embedded in the text of deployed BIPs), that soft forks are =
inherently =E2=80=9Cbackward compatible=E2=80=9D. This is unequivocally =
not true. The only such compatibility is majority hash power enforcement =
of a soft fork. This is not a matter of opinion, it=E2=80=99s the core =
innovation of Bitcoin. Proof of Work settles the question of who has =
authority to order transactions. Majority hash power has that authority. =
Merchants can split again and again, but their miners will still have =
that authority. If one wants a say, one can mine.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>e<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div =
style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in'><p class=3DMsoNormal><b>From:</b> Billy Tetrud =
&lt;billy.tetrud@gmail.com&gt; <br><b>Sent:</b> Tuesday, June 29, 2021 =
7:03 PM<br><b>To:</b> Eric Voskuil =
&lt;eric@voskuil.org&gt;<br><b>Cc:</b> Jorge Tim=C3=B3n =
&lt;jtimon@jtimon.cc&gt;; Luke Dashjr &lt;luke@dashjr.org&gt;; Bitcoin =
Protocol Discussion =
&lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br><b>Subject:</b> Re: =
[bitcoin-dev] Trinary Version Signaling for softfork =
upgrades<o:p></o:p></p></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><div><p =
class=3DMsoNormal>@Jorge<o:p></o:p></p><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>&gt;I don't think we should avoid splits at all =
costs.<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I =
absolutely agree that we shouldn't avoid splits at all costs. There are =
some costs too high to pay to avoid a split. If an economic majority =
started wanting to increase bitcoin's blocksize&nbsp;to 1 GB next year, =
we should absolutely hard fork away from that mess with a minority =
chain.&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>&gt;&nbsp; I don't think we should avoid splits when =
possible,&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=3DMsoNormal>I =
want to see why exactly we disagree about avoiding chain splits =
&quot;when possible&quot;. Are you really saying that we should just =
hard fork every time instead of soft fork? Should we even bother to get =
widespread buy in at all, or should we just release the software, =
hardfork away, and let anyone that wants to follow us follow us later? =
Are you not at all worried about the costs associated with an increased =
orphan rate and reorg rate? Are you not worried that an update might =
happen too fast and that a significant fraction of people that could =
have come along with us to the new update might be left behind because =
they didn't have time to evaluate the =
changed&nbsp;rules?<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Do you agree that, in a conversation about rule =
changes, some people want it their way no matter what and will hardfork =
to get the rules they want, and some people want it their way, but only =
if enough other people agree to follow those rules too? Some people =
might want a rule change, but aren't willing to follow, say, a 20% =
minority fork. Perhaps their personal cut-off is 40% or 50% or 75% or =
90%. Do you agree those people exist?&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>If you do, then I don't understand why you disagree =
that we should avoid chain splits even &quot;when possible&quot;. Maybe =
you could elaborate as to what you mean =
there.&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>@Luke<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>Are you in agreement with Jorge here that we should =
not even attempt to avoid chain =
splits?&nbsp;<o:p></o:p></p></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>&gt; The only alternative to a split in the =
problematic scenarios are 1) concede centralised miner control over the =
network, and 2) have inconsistent enforcement of rules by users who =
don't agree on what the correct rules are, again leading to centralised =
miner control over the network.<o:p></o:p></p></div><div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>There is not simply a binary &quot;do or do not&quot;. =
There is also timing. Non-contentious changes can happen fast. =
Contentious changes need more time for discussion,&nbsp;preparation, or =
coordination,&nbsp;even if the eventual outcome is the same. Do you =
disagree that&nbsp;timing issues can be important,&nbsp;that&nbsp;delays =
can be useful and help to avoid chain&nbsp;splits? Do you agree that =
miners have a (large) incentive to follow the economic majority? Is the =
goal here to&nbsp;do what the economic majority wants,&nbsp;or some =
other group? If so, do you think we have an accurate way of measuring =
what the economic majority wants? Will that mechanism continue to be =
accurate into the future?&nbsp;<o:p></o:p></p></div></div><div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p></div><div><p =
class=3DMsoNormal>I'm asking these questions to try and figure out why =
we disagree here.<o:p></o:p></p></div></div></div></body></html>
------=_NextPart_000_0202_01D76D53.0C05F870--