path: root/2d/87448a616af563da238baf2953821adb8f9d39

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@monetize.io>) id 1Um5dc-0003W9-SO
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Jun 2013 17:12:12 +0000
Received: from mail-oa0-f51.google.com ([209.85.219.51])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Um5da-000241-R7
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Jun 2013 17:12:12 +0000
Received: by mail-oa0-f51.google.com with SMTP id i4so2148676oah.38
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 10 Jun 2013 10:12:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:organization:user-agent:mime-version:to
	:subject:references:in-reply-to:x-enigmail-version:content-type
	:x-gm-message-state;
	bh=6rYvOezqJ2R78hdD8VRruycEYZ5ibRfHXyJ0n1KOdW4=;
	b=BLNOZctJB6pNLK7PkoMdgkSWHr4thcaiMY4vuGPCQl5bDgLjDBTpzMxsC7RYhwXQtv
	GpPI7ZcIOHrrdFfl3YlO5H4Jwf7ooyeVJNfrubYiZMYJ8lM+2Tn2aCdrD3VVH0gTkArY
	HRXXrf45nIzr4mRhanVWcUeHZWV+AHYyGKFJ4ycGay/S24Pgww0pSDNv8oMQ3YshSBbC
	ipAAhgO7CuEKnTP+iuaSEOB/9kwyLOSdzW4XZOBmpn2OHQoptdhCEtRWno6J2BqqvY8E
	M8PsjIk9iFXGi9Hcm4EnBOWAgLbulbgHQfPXWEzbEcoB22kG78kiTqYKNOP2vxjIg9kF
	q81w==
X-Received: by 10.182.158.36 with SMTP id wr4mr8660333obb.60.1370882778940;
	Mon, 10 Jun 2013 09:46:18 -0700 (PDT)
Received: from [192.168.1.118] (adsl-71-131-176-210.dsl.sntc01.pacbell.net.
	[71.131.176.210])
	by mx.google.com with ESMTPSA id b1sm23308532oeo.8.2013.06.10.09.46.16
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 10 Jun 2013 09:46:17 -0700 (PDT)
Message-ID: <51B602D8.5030706@monetize.io>
Date: Mon, 10 Jun 2013 09:46:16 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
	rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: John Dillon <john.dillon892@googlemail.com>, 
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>
In-Reply-To: <CAPaL=UWcKmnChw0zYGVduzHHdQ-AgG7uqbCLvjjuW6Q67zmS0g@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
	boundary="------------030200010002050405050902"
X-Gm-Message-State: ALoCoQmfA1XKpEcA6seojbghDQSqfGDCdC8MtjCSVqA84hqgccmuVkLAqvtyL0JBXz+QGwJaxn+y
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Um5da-000241-R7
Subject: Re: [Bitcoin-development] Proposal: Vote on the blocksize limit
 with proof-of-stake voting
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 10 Jun 2013 17:12:13 -0000

This is a multi-part message in MIME format.
--------------030200010002050405050902
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

What you are recommending is a drastic change that the conservative
bitcoin developers probably wouldn't get behind (but let's see). However
proof-of-stake voting on protocol soft-forks has vast implications even
beyond the block size limit. Within Freicoin, we have looked at is as a
possibility for determining how to distribute the demurrage, a proposal
we are calling 'Republicoin' due to the fact that with proxy voting we
expect a system to emerge similar to the government budgeting in
parliamentary republics. Distributed, non-coersive government by
protocol, if you will.

So anyway, even if you get shot down, please continue to pursue this
proposal. It very likely has uses that you haven't thought of yet.

Cheers,
Mark

On 6/9/13 9:09 PM, John Dillon wrote:
> It has been suggested that we leave the decision of what the blocksize to be
> entirely up to miners. However this leaves a parameter that affects every
> Bitcoin participant in the control of a small minority. Of course we
can not
> force miners to increase the blocksize if they choose to decrease it,
because
> the contents of the blocks they make are their decision and their decision
> only. However proposals to leave the maximum size unlimited to allow
miners to
> force us to accept arbitrarily large blocks even if the will of the
majority of
> Bitcoin participants is that they wish to remain able to validate the
> blockchain.
>
> What we need is a way to balance this asymetrical power relationship.
>
> Proof-of-stake voting gives us a way of achieving that balance.
Essentially for
> a miner to prove that the majority will of the poeple is to accept a
larger
> blocksize they must prove that the majority has in fact voted for that
> increase. The upper limit on the blocksize is then determined by the
median of
> all votes, where each txout in the UTXO set is one vote, weighted by txout
> value. A txout without a corresponding vote is considered to be a vote
for the
> status quo. To allow the voting process to continue even if coins are
"lost"
> votes, including default votes, are weighted inversely according to
their age
> in years after 1 year. IE a vote with weight 1BTC that is 1.5 years
old will be
> recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1
day old
> and 6 months old UTXO are treated equivalently. The 1 year minimum is
simply to
> make voting required no more than once per year. (of course, a real
> implementation should do all of these figures by block height, IE
after 52,560
> blocks instead of after 1 year)
>
> A vote will consist of a txout with a scriptPubKey of the following form:
>
>     OP_RETURN magic vote_id txid vout vote scriptSig
>
> Where scriptSig is a valid signature for a transaction with nLockTime
> 500,000,000-1 spending txid:vout to scriptPubKey:
>
>     OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL
>
> vote_id is the ID of the specific vote being made, and magic is
included to
> allow UTXO proof implementations a as yet unspecified way of
identifying votes
> and including the weighted median as part of the UTXO tree sums. (it also
> allows SPV clients to verify the vote if the UTXO set is a Patricia
tree of
> scriptPubKeys) vote is just the numerical vote itself. The vote must
compute
> the median, rather than the mean, so as to not allow someone to skew
the vote
> by simply setting their value extremely high. Someone who still
remembers their
> statistics classes should chime in on the right way to compute a
median in a
> merkle-sum-tree.
>
> The slightly unusual construction of votes makes implementation by wallet
> software as simple as possible within existing code-paths. Votes could
still be
> constructed even in wallets lacking specific voting capability
provided the
> wallet software does have the ability to set nLockTime.
>
> Of course in the future the voting mechanism can be used for
additional votes
> with an additional vote_id. For instance the Bitcoin community could
vote to
> increase the inflation subsidy, another example of a situation where
the wishes
> of miners may conflict with the wishes of the broader community.
>
> Users may of course actually create these specially encoded txouts
themselves
> and get them into the blockchain.  However doing so is not needed as a
given
> vote is only required to actually be in the chain by a miner wishing to
> increase the blocksize. Thus we should extend the P2P protocol with a
mechanism
> by which votes can be broadcast independently of transactions. To
prevent DoS
> attacks only votes with known vote_id's will be accepted, and only for
> txid:vout's already in the blockchain, and a record of txouts for whom
votes
> have already broadcast will be kept. (this record need not be
authoritative as
> its purpose is only to prevent DoS attacks) Miners wishing to increase the
> blocksize can record these votes and include them in the blocks they
mine as
> required. To reduce the cost of including votes in blocks 5% of every
block
> should be assigned to voting only. (this can be implemented by a
soft-fork)
>
> For any given block actual limit in effect is then the rolling median
of the
> blocks in the last year. At the beginning of every year the value
considered to
> be the status quo resets to the mean of the limit at the beginning and
end of
> the interval.  (again, by "year" we really mean 52,560 blocks) The rolling
> median and periodic reset process ensures that the limit changes
gradually and
> is not influenced by temporary events such as hacks to large exchanges or
> malicious wallet software.  The rolling median also ensures that for a
miner
> the act of including a vote is never wasted due to the txout later
being spent.
>
> Implementing the voting system can happen prior to an actual hard-fork
allowing
> for an increase and can be an important part of determining if the
hard-fork is
> required at all.
>
> Coercion and vote buying is of course possible in this system. A miner
could
> say that they will only accept transactions accompanied by a vote for
a given
> limit. However in a decentralized system completely preventing vote
buying is
> of course impossble, and the design of Bitcoin itself has a fundemental
> assumption that a majority of miners will behave in a specific kind of
"honest"
> way.
>
> A voting process ensures that any increase to the blocksize genuinely
> represents the desires of the Bitcoin community, and the process described
> above ensures that any changes happen at a rate that gives all
participants
> time to react. The process also gives a mechanism for the community to
vote to
> decrease the limit if it turns out that the new one was in fact too
high. (note
> how the way the status quo is set ensures the default action is for
the limit
> to gradually decrease even if everyone stops voting)
>
> As many of you know I have been quite vocal that the 1MB limit should
stay. But
> I would be happy to support the outcome of a vote done properly,
whatever that
> outcome may be.
>
>
------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> .
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRtgLYAAoJEAdzVfsmodw4vWEQAIWxuEXMZb80qTMFyvWiR0Tt
Cn/yx8iG2tPa4xGUq0ypwBU3doFEzYBj3bMyQuluGRP7BBhGat4qhrmI/qGVwYXW
RSQdbdgnp4DXhaOD2QzYh/5zDbN/1jCkuxyUvx/QNAeNEpmN1BoDKhDlM/ywCKdj
qfFZWj30pTzADJiY7P5upCu3TiYuQtTWTHlap2c4fToNsLxAMiLZJTOE1Ytdc31Q
O8iwkV7eFlueawtfFLh/dNz5zVKXSOoNz1sFmgjkO3QQaSqSzinBE1z3vR9QYL+A
R7X1v0sQXDpE0XiPymWE8adjGIai3CBUVZcvnJrPtUznydmpe+OvLf3UZE+QfCuJ
tLP9u42e+gjOb6r9qp4tLZBGlTR2moY/IPtVs8KiMDWt9Nq1fO94IBGyJgFYOxRn
Zq6/funKTO6SO8d+ppQ158s2faVmN3OKMrn6BNnfddWD3/EBhGzEDzuNuNAvfKqQ
nrqEusWrfOZOh66pIs6qvROSamaC42FXMUwBU0wA3W3MEuQhXrGM1S2huKykgZ9W
WsOpC6ng6j5H5dSIs4tvnsDY9hUa9zWIB1+i368pXDv8biOs7ULKEP3mdC1q+4YD
tM/MkC0xKax2zG4wbbez8FpwTpUOOznpYPMZqXkLOkGCAdiAyg2UnLPduudaAkQz
adXXe284XHjjOcZUDvGw
=trsn
-----END PGP SIGNATURE-----


--------------030200010002050405050902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    -----BEGIN PGP SIGNED MESSAGE-----<br>
    Hash: SHA1<br>
    <br>
    John,<br>
    <br>
    What you are recommending is a drastic change that the conservative
    bitcoin developers probably wouldn't get behind (but let's see).
    However proof-of-stake voting on protocol soft-forks has vast
    implications even beyond the block size limit. Within Freicoin, we
    have looked at is as a possibility for determining how to distribute
    the demurrage, a proposal we are calling 'Republicoin' due to the
    fact that with proxy voting we expect a system to emerge similar to
    the government budgeting in parliamentary republics. Distributed,
    non-coersive government by protocol, if you will.<br>
    <br>
    So anyway, even if you get shot down, please continue to pursue this
    proposal. It very likely has uses that you haven't thought of yet.<br>
    <br>
    Cheers,<br>
    Mark<br>
    <br>
    On 6/9/13 9:09 PM, John Dillon wrote:<br>
    <span style="white-space: pre;">&gt; It has been suggested that we
      leave the decision of what the blocksize to be<br>
      &gt; entirely up to miners. However this leaves a parameter that
      affects every<br>
      &gt; Bitcoin participant in the control of a small minority. Of
      course we can not<br>
      &gt; force miners to increase the blocksize if they choose to
      decrease it, because<br>
      &gt; the contents of the blocks they make are their decision and
      their decision<br>
      &gt; only. However proposals to leave the maximum size unlimited
      to allow miners to<br>
      &gt; force us to accept arbitrarily large blocks even if the will
      of the majority of<br>
      &gt; Bitcoin participants is that they wish to remain able to
      validate the<br>
      &gt; blockchain.<br>
      &gt;<br>
      &gt; What we need is a way to balance this asymetrical power
      relationship.<br>
      &gt;<br>
      &gt; Proof-of-stake voting gives us a way of achieving that
      balance. Essentially for<br>
      &gt; a miner to prove that the majority will of the poeple is to
      accept a larger<br>
      &gt; blocksize they must prove that the majority has in fact voted
      for that<br>
      &gt; increase. The upper limit on the blocksize is then determined
      by the median of<br>
      &gt; all votes, where each txout in the UTXO set is one vote,
      weighted by txout<br>
      &gt; value. A txout without a corresponding vote is considered to
      be a vote for the<br>
      &gt; status quo. To allow the voting process to continue even if
      coins are "lost"<br>
      &gt; votes, including default votes, are weighted inversely
      according to their age<br>
      &gt; in years after 1 year. IE a vote with weight 1BTC that is 1.5
      years old will be<br>
      &gt; recorded the same as a &lt;1 year old vote weighted as
      0.67BTC, and a 1 day old<br>
      &gt; and 6 months old UTXO are treated equivalently. The 1 year
      minimum is simply to<br>
      &gt; make voting required no more than once per year. (of course,
      a real<br>
      &gt; implementation should do all of these figures by block
      height, IE after 52,560<br>
      &gt; blocks instead of after 1 year)<br>
      &gt;<br>
      &gt; A vote will consist of a txout with a scriptPubKey of the
      following form:<br>
      &gt;<br>
      &gt;&nbsp;&nbsp;&nbsp;&nbsp; OP_RETURN magic vote_id txid vout vote scriptSig<br>
      &gt;<br>
      &gt; Where scriptSig is a valid signature for a transaction with
      nLockTime<br>
      &gt; 500,000,000-1 spending txid:vout to scriptPubKey:<br>
      &gt;<br>
      &gt;&nbsp;&nbsp;&nbsp;&nbsp; OP_HASH160 H(OP_RETURN magic vote_id txid vout vote)
      OP_EQUAL<br>
      &gt;<br>
      &gt; vote_id is the ID of the specific vote being made, and magic
      is included to<br>
      &gt; allow UTXO proof implementations a as yet unspecified way of
      identifying votes<br>
      &gt; and including the weighted median as part of the UTXO tree
      sums. (it also<br>
      &gt; allows SPV clients to verify the vote if the UTXO set is a
      Patricia tree of<br>
      &gt; scriptPubKeys) vote is just the numerical vote itself. The
      vote must compute<br>
      &gt; the median, rather than the mean, so as to not allow someone
      to skew the vote<br>
      &gt; by simply setting their value extremely high. Someone who
      still remembers their<br>
      &gt; statistics classes should chime in on the right way to
      compute a median in a<br>
      &gt; merkle-sum-tree.<br>
      &gt;<br>
      &gt; The slightly unusual construction of votes makes
      implementation by wallet<br>
      &gt; software as simple as possible within existing code-paths.
      Votes could still be<br>
      &gt; constructed even in wallets lacking specific voting
      capability provided the<br>
      &gt; wallet software does have the ability to set nLockTime.<br>
      &gt;<br>
      &gt; Of course in the future the voting mechanism can be used for
      additional votes<br>
      &gt; with an additional vote_id. For instance the Bitcoin
      community could vote to<br>
      &gt; increase the inflation subsidy, another example of a
      situation where the wishes<br>
      &gt; of miners may conflict with the wishes of the broader
      community.<br>
      &gt;<br>
      &gt; Users may of course actually create these specially encoded
      txouts themselves<br>
      &gt; and get them into the blockchain.&nbsp; However doing so is not
      needed as a given<br>
      &gt; vote is only required to actually be in the chain by a miner
      wishing to<br>
      &gt; increase the blocksize. Thus we should extend the P2P
      protocol with a mechanism<br>
      &gt; by which votes can be broadcast independently of
      transactions. To prevent DoS<br>
      &gt; attacks only votes with known vote_id's will be accepted, and
      only for<br>
      &gt; txid:vout's already in the blockchain, and a record of txouts
      for whom votes<br>
      &gt; have already broadcast will be kept. (this record need not be
      authoritative as<br>
      &gt; its purpose is only to prevent DoS attacks) Miners wishing to
      increase the<br>
      &gt; blocksize can record these votes and include them in the
      blocks they mine as<br>
      &gt; required. To reduce the cost of including votes in blocks 5%
      of every block<br>
      &gt; should be assigned to voting only. (this can be implemented
      by a soft-fork)<br>
      &gt;<br>
      &gt; For any given block actual limit in effect is then the
      rolling median of the<br>
      &gt; blocks in the last year. At the beginning of every year the
      value considered to<br>
      &gt; be the status quo resets to the mean of the limit at the
      beginning and end of<br>
      &gt; the interval.&nbsp; (again, by "year" we really mean 52,560
      blocks) The rolling<br>
      &gt; median and periodic reset process ensures that the limit
      changes gradually and<br>
      &gt; is not influenced by temporary events such as hacks to large
      exchanges or<br>
      &gt; malicious wallet software.&nbsp; The rolling median also ensures
      that for a miner<br>
      &gt; the act of including a vote is never wasted due to the txout
      later being spent.<br>
      &gt;<br>
      &gt; Implementing the voting system can happen prior to an actual
      hard-fork allowing<br>
      &gt; for an increase and can be an important part of determining
      if the hard-fork is<br>
      &gt; required at all.<br>
      &gt;<br>
      &gt; Coercion and vote buying is of course possible in this
      system. A miner could<br>
      &gt; say that they will only accept transactions accompanied by a
      vote for a given<br>
      &gt; limit. However in a decentralized system completely
      preventing vote buying is<br>
      &gt; of course impossble, and the design of Bitcoin itself has a
      fundemental<br>
      &gt; assumption that a majority of miners will behave in a
      specific kind of "honest"<br>
      &gt; way.<br>
      &gt;<br>
      &gt; A voting process ensures that any increase to the blocksize
      genuinely<br>
      &gt; represents the desires of the Bitcoin community, and the
      process described<br>
      &gt; above ensures that any changes happen at a rate that gives
      all participants<br>
      &gt; time to react. The process also gives a mechanism for the
      community to vote to<br>
      &gt; decrease the limit if it turns out that the new one was in
      fact too high. (note<br>
      &gt; how the way the status quo is set ensures the default action
      is for the limit<br>
      &gt; to gradually decrease even if everyone stops voting)<br>
      &gt;<br>
      &gt; As many of you know I have been quite vocal that the 1MB
      limit should stay. But<br>
      &gt; I would be happy to support the outcome of a vote done
      properly, whatever that<br>
      &gt; outcome may be.<br>
      &gt;<br>
      &gt;
------------------------------------------------------------------------------<br>
      &gt; How ServiceNow helps IT people transform IT departments:<br>
      &gt; 1. A cloud service to automate IT design, transition and
      operations<br>
      &gt; 2. Dashboards that offer high-level views of enterprise
      services<br>
      &gt; 3. A single system of record for all IT processes<br>
      &gt; <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/servicenow-d2d-j">http://p.sf.net/sfu/servicenow-d2d-j</a><br>
      &gt; _______________________________________________<br>
      &gt; Bitcoin-development mailing list<br>
      &gt; <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
      &gt;
      <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
      &gt; .<br>
      &gt;</span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----<br>
    Version: GnuPG/MacGPG2 v2.0.19 (Darwin)<br>
    Comment: GPGTools - <a class="moz-txt-link-freetext" href="http://gpgtools.org">http://gpgtools.org</a><br>
    Comment: Using GnuPG with Thunderbird - <a class="moz-txt-link-freetext" href="http://www.enigmail.net/">http://www.enigmail.net/</a><br>
    <br>
    iQIcBAEBAgAGBQJRtgLYAAoJEAdzVfsmodw4vWEQAIWxuEXMZb80qTMFyvWiR0Tt<br>
    Cn/yx8iG2tPa4xGUq0ypwBU3doFEzYBj3bMyQuluGRP7BBhGat4qhrmI/qGVwYXW<br>
    RSQdbdgnp4DXhaOD2QzYh/5zDbN/1jCkuxyUvx/QNAeNEpmN1BoDKhDlM/ywCKdj<br>
    qfFZWj30pTzADJiY7P5upCu3TiYuQtTWTHlap2c4fToNsLxAMiLZJTOE1Ytdc31Q<br>
    O8iwkV7eFlueawtfFLh/dNz5zVKXSOoNz1sFmgjkO3QQaSqSzinBE1z3vR9QYL+A<br>
    R7X1v0sQXDpE0XiPymWE8adjGIai3CBUVZcvnJrPtUznydmpe+OvLf3UZE+QfCuJ<br>
    tLP9u42e+gjOb6r9qp4tLZBGlTR2moY/IPtVs8KiMDWt9Nq1fO94IBGyJgFYOxRn<br>
    Zq6/funKTO6SO8d+ppQ158s2faVmN3OKMrn6BNnfddWD3/EBhGzEDzuNuNAvfKqQ<br>
    nrqEusWrfOZOh66pIs6qvROSamaC42FXMUwBU0wA3W3MEuQhXrGM1S2huKykgZ9W<br>
    WsOpC6ng6j5H5dSIs4tvnsDY9hUa9zWIB1+i368pXDv8biOs7ULKEP3mdC1q+4YD<br>
    tM/MkC0xKax2zG4wbbez8FpwTpUOOznpYPMZqXkLOkGCAdiAyg2UnLPduudaAkQz<br>
    adXXe284XHjjOcZUDvGw<br>
    =trsn<br>
    -----END PGP SIGNATURE-----<br>
    <br>
  </body>
</html>

--------------030200010002050405050902--