diff options
| author | Tao Effect <contact@taoeffect.com> | 2017-11-02 16:55:55 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-11-02 23:55:57 +0000 |
| commit | 5b6a73c9f9cd94917e0cc9f8b54cec4efa1e0ed8 (patch) | |
| tree | b14b962e06706e6d4eb01f0d3e01298987f84bb2 /9c | |
| parent | 112d2dccdc3cf422694feb0b439bea3eedf8f9b7 (diff) | |
| download | pi-bitcoindev-5b6a73c9f9cd94917e0cc9f8b54cec4efa1e0ed8.tar.gz pi-bitcoindev-5b6a73c9f9cd94917e0cc9f8b54cec4efa1e0ed8.zip | |
Re: [bitcoin-dev] Introducing a POW through a soft-fork
Diffstat (limited to '9c')
| -rw-r--r-- | 9c/1cf38efff35aff6e67ac7343c7b8fd67cc9a3d | 443 |
1 files changed, 443 insertions, 0 deletions
diff --git a/9c/1cf38efff35aff6e67ac7343c7b8fd67cc9a3d b/9c/1cf38efff35aff6e67ac7343c7b8fd67cc9a3d new file mode 100644 index 000000000..b47e9d24d --- /dev/null +++ b/9c/1cf38efff35aff6e67ac7343c7b8fd67cc9a3d @@ -0,0 +1,443 @@ +Return-Path: <contact@taoeffect.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 6D642C19 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 2 Nov 2017 23:55:57 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from homiemail-a5.g.dreamhost.com (homie.mail.dreamhost.com + [208.97.132.208]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83E92DF + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 2 Nov 2017 23:55:56 +0000 (UTC) +Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) + by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id DFF6E70407D; + Thu, 2 Nov 2017 16:55:55 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=from + :content-type:mime-version:subject:message-id:date:references:to + :in-reply-to; s=taoeffect.com; bh=iXqkmUepY6zZ56XqHgk9Ts0t9og=; + b=UMlfSgscNYj/tLOzMz6q3Op4lg1E0JbPD5XdDnAOD8LZDCzUfuC7hm0gMQrgk + BIaM93d/u+eR1rGzuFIUk401de/x3hBqDUilfzp4sxgiWgGVoYal2HVTe7ux07wb + fuMbfIQO2qNxhviRQLttC7wWpM5GXthr4A33wFoFu3f7uc= +Received: from [192.168.42.66] (184-23-254-163.fiber.dynamic.sonic.net + [184.23.254.163]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + (Authenticated sender: contact@taoeffect.com) + by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPSA id 86E42704078; + Thu, 2 Nov 2017 16:55:55 -0700 (PDT) +From: Tao Effect <contact@taoeffect.com> +Content-Type: multipart/signed; + boundary="Apple-Mail=_934A4CDF-DA4A-4164-9803-6BB7C19E50A3"; + protocol="application/pgp-signature"; micalg=pgp-sha512 +X-Mao-Original-Outgoing-Id: 531359754.946768-8b0393adb31fa394c0f357e3e8786091 +Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) +Message-Id: <D075DBB7-1C8A-4F83-9C0E-CC2321A8C5A7@taoeffect.com> +Date: Thu, 2 Nov 2017 16:55:55 -0700 +References: <CAB0O3SVjhG19R61B78hFCPwfwWemTXj=tOsvgAgoNbjFYXXAtg@mail.gmail.com> +To: Devrandom <c1.bitcoin@niftybox.net>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <CAB0O3SVjhG19R61B78hFCPwfwWemTXj=tOsvgAgoNbjFYXXAtg@mail.gmail.com> +X-Mailer: Apple Mail (2.3273) +X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, + DKIM_VALID_AU, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE autolearn=disabled 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, 03 Nov 2017 00:01:22 +0000 +Subject: Re: [bitcoin-dev] Introducing a POW through a soft-fork +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, 02 Nov 2017 23:55:57 -0000 + + +--Apple-Mail=_934A4CDF-DA4A-4164-9803-6BB7C19E50A3 +Content-Type: multipart/alternative; + boundary="Apple-Mail=_7FB1C43F-2CD8-4630-A50B-99FFB29C12DE" + + +--Apple-Mail=_7FB1C43F-2CD8-4630-A50B-99FFB29C12DE +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=us-ascii + +Just going to throw in my support for a POW change, not any particular = +implementation, but the idea. + +Bitcoin is technically owned by China now. That's not acceptable. + +- Greg + +-- +Please do not email me anything that you are not comfortable also = +sharing with the NSA. + +> On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev = +<bitcoin-dev@lists.linuxfoundation.org = +<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: +>=20 +> Hi all, +>=20 +> Feedback is welcome on the draft below. In particular, I want to see = +if there is interest in further development of the idea and also = +interested in any attack vectors or undesirable dynamics. +>=20 +> (Formatted version available here: = +https://github.com/devrandom/btc-papers/blob/master/aux-pow.md = +<https://github.com/devrandom/btc-papers/blob/master/aux-pow.md> ) +>=20 +> # Soft-fork Introduction of a New POW +>=20 +> ## Motivation: +>=20 +> - Mitigate mining centralization pressures by introducing a POW that = +does not have economies of scale +> - Introduce an intermediary confirmation point, reducing the impact of = +mining power fluctuations +>=20 +> Note however that choice of a suitable POW will require deep analysis. = + Some pitfalls include: botnet mining, POWs that seem ASIC resistant but = +are not, unexpected/covert optimization. +>=20 +> In particular, unexpected/covert optimizations, such as ASCIBOOST, = +present a potential centralizing and destabilizing force. +>=20 +> ## Design +>=20 +> ### Aux POW intermediate block +>=20 +> Auxiliary POW blocks are introduced between normal blocks - i.e. the = +chain alternates between the two POWs. +> Each aux-POW block points to the previous normal block and contains = +transactions just like a normal block. +> Each normal block points to the previous aux-POW block and must = +contain all transactions from the aux-POW block. +> Block space is not increased. +>=20 +> The new intermediate block and the pointers are introduced via a = +soft-fork restriction. +>=20 +> ### Reward for aux POW miners +>=20 +> The reward for the aux POW smoothly increases from zero to a target = +value (e.g. 1/2 of the total reward) over time. +> The reward is transferred via a soft-fork restriction requiring a = +coinbase output to an address published in the +> aux-POW block. +>=20 +> ### Aux POW difficulty adjustment +>=20 +> Difficulty adjustments remain independent for the two POWs. +>=20 +> The difficulty of the aux POW is adjusted based on the average time = +between normal block found +> to aux block found. +>=20 +> Further details are dependent on the specific POW. +>=20 +> ### Heaviest chain rule change +>=20 +> This is a semi-hard change, because non-upgraded nodes can get on the = +wrong chain in case of attack. However, +> it might be possible to construct an alert system that notifies = +non-upgraded nodes of an upcoming rule change. +> All blocks are still valid, so this is not a hardforking change. +>=20 +> The heaviest chain definition changes from sum of `difficulty` to sum = +of: +>=20 +> mainDifficulty ^ x * auxDifficulty ^ y +>=20 +> where we start at: +>=20 +> x =3D 1; y =3D 0 +>=20 +> and end at values of x and y that are related to the target relative = +rewards. For example, if the target rewards +> are equally distributed, we will want ot end up at: +>=20 +> x =3D 1/2; y =3D 1/2 +>=20 +> so that both POWs have equal weight. If the aux POW is to become = +dominant, x should end small relative to y. +>=20 +>=20 +> ## Questions and Answers +>=20 +> - What should be the parameters if we want the aux POW to have equal = +weight? A: 1/2 of the reward should be transferred +> to aux miners and x =3D 1/2, y =3D 1/2. +>=20 +> - What should be the parameters if we want to deprecate the main POW? = +A: most of the reward should be transferred to +> aux miners and x =3D 0, y =3D 1. The main difficulty will tend to = +zero, and aux miners will just trivially generate the +> main block immediately after finding an aux block, with identical = +content. +>=20 +> - Wasted bandwidth to transfer transactions twice? A: this can be = +optimized by skipping transactions already +> transferred. +>=20 +> - Why would miners agree to soft-fork away some of their reward? A: = +they would agree if they believe that +> the coins will increase in value due to improved security properties. +>=20 +> ## Open Questions +>=20 +> - After a block of one type is found, we can naively assume that POW = +will become idle while a block of the other type is being mined. In = +practice, the spare capacity can be used to find alternative = +("attacking") blocks or mine other coins. Is that a problem? +> - Is selfish mining amplified by this scheme for miners that have both = +types of hardware? +>=20 +> ## POW candidates +>=20 +> - SHA256 (i.e. use same POW, but introduce an intermediate block for = +faster confirmation) +> - Proof of Space and Time (Bram Cohen) +> - Equihash +> - Ethash +>=20 +> ## Next Steps +>=20 +> - evaluate POW candidates +> - evaluate difficulty adjustment rules +> - simulate miner behavior to identify if there are incentives for = +detrimental behavior patterns (e.g. block withholding / selfish mining) +> - Protocol details +>=20 +> ## Credits +>=20 +> Bram Cohen came up with a similar idea back in March: +> = +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.= +html = +<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744= +.html>_______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org = +<mailto:bitcoin-dev@lists.linuxfoundation.org> +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + +--Apple-Mail=_7FB1C43F-2CD8-4630-A50B-99FFB29C12DE +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=us-ascii + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dus-ascii"><meta http-equiv=3D"Content-Type" content=3D"text/html= + charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = +-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = +class=3D"">Just going to throw in my support for a POW change, not any = +particular implementation, but the idea.<div class=3D""><br = +class=3D""></div><div class=3D"">Bitcoin is technically owned by China = +now. That's not acceptable.</div><div class=3D""><br class=3D""></div><div= + class=3D"">- Greg<br class=3D""><div class=3D""> +<span style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: = +14px; font-style: normal; font-variant-caps: normal; font-weight: = +normal; letter-spacing: normal; text-align: start; text-indent: 0px; = +text-transform: none; white-space: normal; word-spacing: 0px; = +-webkit-text-stroke-width: 0px; font-variant-ligatures: normal; = +font-variant-position: normal; font-variant-numeric: normal; = +font-variant-alternates: normal; font-variant-east-asian: normal; = +line-height: normal; orphans: 2; widows: 2;" class=3D""><br = +class=3D"Apple-interchange-newline">--</span><br style=3D"color: rgb(0, = +0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; = +font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = +text-align: start; text-indent: 0px; text-transform: none; white-space: = +normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = +font-variant-ligatures: normal; font-variant-position: normal; = +font-variant-numeric: normal; font-variant-alternates: normal; = +font-variant-east-asian: normal; line-height: normal; orphans: 2; = +widows: 2;" class=3D""><span style=3D"color: rgb(0, 0, 0); font-family: = +Helvetica; font-size: 14px; font-style: normal; font-variant-caps: = +normal; font-weight: normal; letter-spacing: normal; text-align: start; = +text-indent: 0px; text-transform: none; white-space: normal; = +word-spacing: 0px; -webkit-text-stroke-width: 0px; = +font-variant-ligatures: normal; font-variant-position: normal; = +font-variant-numeric: normal; font-variant-alternates: normal; = +font-variant-east-asian: normal; line-height: normal; orphans: 2; = +widows: 2;" class=3D"">Please do not email me anything that you are not = +comfortable also sharing</span><span style=3D"color: rgb(0, 0, 0); = +font-family: Helvetica; font-size: 14px; font-style: normal; = +font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = +text-align: start; text-indent: 0px; text-transform: none; white-space: = +normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = +font-variant-ligatures: normal; font-variant-position: normal; = +font-variant-numeric: normal; font-variant-alternates: normal; = +font-variant-east-asian: normal; line-height: normal; orphans: 2; = +widows: 2;" class=3D""> with the NSA.</span> +</div> +<br class=3D""><div><blockquote type=3D"cite" class=3D""><div = +class=3D"">On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev = +<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = +class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:</div><br = +class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = +class=3D""><span style=3D"color:rgb(33,33,33);font-size:13px" = +class=3D"">Hi all,</span><div style=3D"color:rgb(33,33,33);font-size:13px"= + class=3D""><br class=3D""></div><div = +style=3D"color:rgb(33,33,33);font-size:13px" class=3D"">Feedback is = +welcome on the draft below. In particular, I want to see if there = +is interest in further development of the idea and also interested in = +any attack vectors or undesirable dynamics.</div><div = +style=3D"color:rgb(33,33,33);font-size:13px" class=3D""><br = +class=3D""></div><div style=3D"color:rgb(33,33,33);font-size:13px" = +class=3D"">(Formatted version available here: <a = +href=3D"https://github.com/devrandom/btc-papers/blob/master/aux-pow.md" = +class=3D"">https://github.com/devrandom/btc-papers/blob/master/aux-pow.md<= +/a> )</div><div style=3D"color:rgb(33,33,33);font-size:13px" = +class=3D""><br class=3D""></div><div = +style=3D"color:rgb(33,33,33);font-size:13px" class=3D""><div class=3D""># = +Soft-fork Introduction of a New POW</div><div class=3D""><br = +class=3D""></div><div class=3D"">## Motivation:<br class=3D""></div><div = +class=3D""><br class=3D""></div><div class=3D"">- Mitigate mining = +centralization pressures by introducing a POW that does not have = +economies of scale</div><div class=3D"">- Introduce an intermediary = +confirmation point, reducing the impact of mining power = +fluctuations</div><div class=3D""><br class=3D""></div><div = +class=3D"">Note however that choice of a suitable POW will require deep = +analysis. Some pitfalls include: botnet mining, POWs that seem = +ASIC resistant but are not, unexpected/covert optimization.</div><div = +class=3D""><br class=3D""></div><div class=3D"">In particular, = +unexpected/covert optimizations, such as ASCIBOOST, present a potential = +centralizing and destabilizing force.</div><div class=3D""><br = +class=3D""></div><div class=3D"">## Design</div><div class=3D""><br = +class=3D""></div><div class=3D"">### Aux POW intermediate = +block</div><div class=3D""><br class=3D""></div><div class=3D"">Auxiliary = +POW blocks are introduced between normal blocks - i.e. the chain = +alternates between the two POWs.</div><div class=3D"">Each aux-POW block = +points to the previous normal block and contains transactions just like = +a normal block.</div><div class=3D"">Each normal block points to the = +previous aux-POW block and must contain all transactions from the = +aux-POW block.</div><div class=3D"">Block space is not = +increased.</div><div class=3D""><br class=3D""></div><div class=3D"">The = +new intermediate block and the pointers are introduced via a soft-fork = +restriction.</div><div class=3D""><br class=3D""></div><div class=3D"">###= + Reward for aux POW miners</div><div class=3D""><br class=3D""></div><div = +class=3D"">The reward for the aux POW smoothly increases from zero to a = +target value (e.g. 1/2 of the total reward) over time.</div><div = +class=3D"">The reward is transferred via a soft-fork restriction = +requiring a coinbase output to an address published in the</div><div = +class=3D"">aux-POW block.</div><div class=3D""><br class=3D""></div><div = +class=3D"">### Aux POW difficulty adjustment</div><div class=3D""><br = +class=3D""></div><div class=3D"">Difficulty adjustments remain = +independent for the two POWs.</div><div class=3D""><br = +class=3D""></div><div class=3D"">The difficulty of the aux POW is = +adjusted based on the average time between normal block found</div><div = +class=3D"">to aux block found.</div><div class=3D""><br = +class=3D""></div><div class=3D"">Further details are dependent on the = +specific POW.</div><div class=3D""><br class=3D""></div><div = +class=3D"">### Heaviest chain rule change</div><div class=3D""><br = +class=3D""></div><div class=3D"">This is a semi-hard change, because = +non-upgraded nodes can get on the wrong chain in case of attack. = +However,</div><div class=3D"">it might be possible to construct an alert = +system that notifies non-upgraded nodes of an upcoming rule = +change.</div><div class=3D"">All blocks are still valid, so this is not = +a hardforking change.</div><div class=3D""><br class=3D""></div><div = +class=3D"">The heaviest chain definition changes from sum of = +`difficulty` to sum of:</div><div class=3D""><br class=3D""></div><div = +class=3D""> mainDifficulty ^ x * auxDifficulty ^ = +y</div><div class=3D""><br class=3D""></div><div class=3D"">where we = +start at:</div><div class=3D""><br class=3D""></div><div class=3D""> = + x =3D 1; y =3D 0</div><div class=3D""><br class=3D""></div><div = +class=3D"">and end at values of x and y that are related to the target = +relative rewards. For example, if the target rewards</div><div = +class=3D"">are equally distributed, we will want ot end up at:</div><div = +class=3D""><br class=3D""></div><div class=3D""> x =3D 1/2; = +y =3D 1/2</div><div class=3D""><br class=3D""></div><div class=3D"">so = +that both POWs have equal weight. If the aux POW is to become = +dominant, x should end small relative to y.</div><div class=3D""><br = +class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">## = +Questions and Answers</div><div class=3D""><br class=3D""></div><div = +class=3D"">- What should be the parameters if we want the aux POW to = +have equal weight? A: 1/2 of the reward should be transferred</div><div = +class=3D"">to aux miners and x =3D 1/2, y =3D 1/2.</div><div = +class=3D""><br class=3D""></div><div class=3D"">- What should be the = +parameters if we want to deprecate the main POW? A: most of the = +reward should be transferred to</div><div class=3D"">aux miners and x =3D = +0, y =3D 1. The main difficulty will tend to zero, and aux miners = +will just trivially generate the</div><div class=3D"">main block = +immediately after finding an aux block, with identical = +content.</div><div class=3D""><br class=3D""></div><div class=3D"">- = +Wasted bandwidth to transfer transactions twice? A: this can be = +optimized by skipping transactions already</div><div = +class=3D"">transferred.</div><div class=3D""><br class=3D""></div><div = +class=3D"">- Why would miners agree to soft-fork away some of their = +reward? A: they would agree if they believe that</div><div = +class=3D"">the coins will increase in value due to improved security = +properties.</div><div class=3D""><br class=3D""></div><div class=3D"">## = +Open Questions</div><div class=3D""><br class=3D""></div><div class=3D"">-= + After a block of one type is found, we can naively assume that POW will = +become idle while a block of the other type is being mined. In = +practice, the spare capacity can be used to find alternative = +("attacking") blocks or mine other coins. Is that a = +problem?</div><div class=3D"">- Is selfish mining amplified by this = +scheme for miners that have both types of hardware?</div><div = +class=3D""><br class=3D""></div><div class=3D"">## POW = +candidates</div><div class=3D""><br class=3D""></div><div class=3D"">- = +SHA256 (i.e. use same POW, but introduce an intermediate block for = +faster confirmation)</div><div class=3D"">- Proof of Space and Time = +(Bram Cohen)</div><div class=3D"">- Equihash</div><div class=3D"">- = +Ethash</div><div class=3D""><br class=3D""></div><div class=3D"">## Next = +Steps</div><div class=3D""><br class=3D""></div><div class=3D"">- = +evaluate POW candidates</div><div class=3D"">- evaluate difficulty = +adjustment rules</div><div class=3D"">- simulate miner behavior to = +identify if there are incentives for detrimental behavior patterns (e.g. = +block withholding / selfish mining)</div><div class=3D"">- Protocol = +details</div><div class=3D""><br class=3D""></div><div class=3D"">## = +Credits</div><div class=3D""><br class=3D""></div><div class=3D"">Bram = +Cohen came up with a similar idea back in March:</div><div class=3D""><a = +href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March= +/013744.html" target=3D"_blank" = +class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ma= +rch/013744.html</a></div></div></div> +_______________________________________________<br class=3D"">bitcoin-dev = +mailing list<br class=3D""><a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = +class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a = +href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= +/a><br class=3D""></div></blockquote></div><br = +class=3D""></div></body></html>= + +--Apple-Mail=_7FB1C43F-2CD8-4630-A50B-99FFB29C12DE-- + +--Apple-Mail=_934A4CDF-DA4A-4164-9803-6BB7C19E50A3 +Content-Transfer-Encoding: 7bit +Content-Disposition: attachment; + filename=signature.asc +Content-Type: application/pgp-signature; + name=signature.asc +Content-Description: Message signed with OpenPGP + +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEEgYtgnomHliYDCUth7GcgK+kJUkcFAln7sIoACgkQ7GcgK+kJ +UkfNRhAA14St486JMZDiNkymAysHXvCj0JnEQp73Ch8AX0UkjJnGe8T8O8NgDLNW +XIrRp5ZSC8pz9rTbr3i1lgwTcWVgqTmYeT73yWv2bi5IgDNjomRWolJRMRdr+srw +L2BRdQZ7uYA+FP0YppwACZ6Lb7OSgrkneCiIBG8rcC4nqDDc/zfehjP62c0pPq2V +3ylFOVWOt6ipLuMKJZJS/AdwrkKzp3pFnny7L1rJNRB3kbnbSBh448aQzUHOQjJR +o/VucHgOsV7vFydntO19NSIvv2+ZKGss0Tka/GyEsAQcFiof6JZXpfAk01cLXs6S +vjeGZrQkiUjhyXOFKXg2zYk1dQGsnF+e/Ov6fN8YWnxXLCaXhIUYY91JLUqpHEoo +DBcJKerkiryd+BJrX6aAB935D3Tb+Ii5ydjdKeRXe1AgzcRkTSeWyaFz65sEHeq0 +l3hFjDB2bSc60zyPVeZ8+bICo3yQpQ2g6L5WrvctyKX4STikkhmTUNySGl8KZNri +OhJ8Xjn+ljdNI5xi9LlJZT/3FVDm//uo6TubG7rCbPJBfoAySTz34bXZ5dKKHot/ +jdEm5vNxmlH7gCrtHnUvk3aLXOf2hjpEv5g66Vitg9ZNOILIdDRChnvndJJS6HTt +WUn3Q4zfTeNbCNtv9dPuZN2ybZPGeQ8AdsmX7eXCRFeku8A31RI= +=TOtZ +-----END PGP SIGNATURE----- + +--Apple-Mail=_934A4CDF-DA4A-4164-9803-6BB7C19E50A3-- + |