From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4CBBCB76 for ; Wed, 7 Jun 2017 01:51:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a38.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35C681A6 for ; Wed, 7 Jun 2017 01:51:42 +0000 (UTC) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 10CD510AFB5; Tue, 6 Jun 2017 18:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=taoeffect.com; bh=sJZOlwuDApNEIP1l+ 616VmktWfI=; b=hig1Wxh2OOSM/wRonB6MMKg7/r1k3u4Goq6Wn51nVjd2tIm/f L64Dw27T3qP+DKMHPaVOLvXGiqea8jLaR/uiYNnkfjvsnxrVuzbp6c2g2+HxRATw AaTKi0qBwvQ7qFsj5AdruSvRNZyJztwwhGFgZ+mM+LBQfNzsWvX1k5zfro= Received: from [192.168.42.64] (184-23-255-227.fiber.dynamic.sonic.net [184.23.255.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: contact@taoeffect.com) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id 9754A10AFB0; Tue, 6 Jun 2017 18:51:40 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1AEAF7EF-89BF-4AFD-9132-3878FF956856"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Tao Effect In-Reply-To: Date: Tue, 6 Jun 2017 18:51:39 -0700 X-Mao-Original-Outgoing-Id: 518493099.591898-91cde3662e5a687f3597ce14d0158180 Message-Id: References: To: James Hilliard X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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: Wed, 07 Jun 2017 01:58:30 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] User Activated Soft Fork Split Protection X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 01:51:44 -0000 --Apple-Mail=_1AEAF7EF-89BF-4AFD-9132-3878FF956856 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDEDC1C0-6CDC-4A87-8D22-F9CF4FBC69A8" --Apple-Mail=_CDEDC1C0-6CDC-4A87-8D22-F9CF4FBC69A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What is the probability that a 65% threshold is too low and can allow a = "surprise miner attack", whereby miners are kept offline before the = deadline, and brought online immediately after, creating potential = havoc? (Nit: "simple majority" usually refers to >50%, I think, might cause = confusion.) -Greg Slepak -- Please do not email me anything that you are not comfortable also = sharing with the NSA. > On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev = > wrote: >=20 > Due to the proposed calendar(https://segwit2x.github.io/ = ) for the > SegWit2x agreement being too slow to activate SegWit mandatory > signalling ahead of BIP148 using BIP91 I would like to propose another > option that miners can use to prevent a chain split ahead of the Aug > 1st BIP148 activation date. >=20 > The splitprotection soft fork is essentially BIP91 but using BIP8 > instead of BIP9 with a lower activation threshold and immediate > mandatory signalling lock-in. This allows for a majority of miners to > activate mandatory SegWit signalling and prevent a potential chain > split ahead of BIP148 activation. >=20 > This BIP allows for miners to respond to market forces quickly ahead > of BIP148 activation by signalling for splitprotection. Any miners > already running BIP148 should be encouraged to use splitprotection. >=20 > 
>  BIP: splitprotection
>  Layer: Consensus (soft fork)
>  Title: User Activated Soft Fork Split Protection
>  Author: James Hilliard >
>  Comments-Summary: No comments yet.
>  Comments-URI:
>  Status: Draft
>  Type: Standards Track
>  Created: 2017-05-22
>  License: BSD-3-Clause
>           CC0-1.0
>
>=20 > =3D=3DAbstract=3D=3D >=20 > This document specifies a coordination mechanism for a simple majority > of miners to prevent a chain split ahead of BIP148 activation. >=20 > =3D=3DDefinitions=3D=3D >=20 > "existing segwit deployment" refer to the BIP9 "segwit" deployment > using bit 1, between November 15th 2016 and November 15th 2017 to > activate BIP141, BIP143 and BIP147. >=20 > =3D=3DMotivation=3D=3D >=20 > The biggest risk of BIP148 is an extended chain split, this BIP > provides a way for a simple majority of miners to eliminate that risk. >=20 > This BIP provides a way for a simple majority of miners to coordinate > activation of the existing segwit deployment with less than 95% > hashpower before BIP148 activation. Due to time constraints unless > immediately deployed BIP91 will likely not be able to enforce > mandatory signalling of segwit before the Aug 1st activation of > BIP148. This BIP provides a method for rapid miner activation of > SegWit mandatory signalling ahead of the BIP148 activation date. Since > the primary goal of this BIP is to reduce the chance of an extended > chain split as much as possible we activate using a simple miner > majority of 65% over a 504 block interval rather than a higher > percentage. This BIP also allows miners to signal their intention to > run BIP148 in order to prevent a chain split. >=20 > =3D=3DSpecification=3D=3D >=20 > While this BIP is active, all blocks must set the nVersion header top > 3 bits to 001 together with bit field (1<<1) (according to the > existing segwit deployment). Blocks that do not signal as required > will be rejected. >=20 > =3D=3DDeployment=3D=3D >=20 > This BIP will be deployed by "version bits" with a 65%(this can be > adjusted if desired) activation threshold BIP9 with the name > "splitprotecion" and using bit 2. >=20 > This BIP starts immediately and is a BIP8 style soft fork since > mandatory signalling will start on midnight August 1st 2017 (epoch > time 1501545600) regardless of whether or not this BIP has reached its > own signalling threshold. This BIP will cease to be active when segwit > is locked-in. >=20 > =3D=3D=3D Reference implementation =3D=3D=3D >=20 > 
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
>    LOCK(cs_main);
>    return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) =3D=3D
> THRESHOLD_LOCKED_IN);
> }
>=20
> // SPLITPROTECTION mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) =3D=3D
> THRESHOLD_LOCKED_IN &&
>     !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
>     !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> and is not active.
> {
>    bool fVersionBits =3D (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D=

> VERSIONBITS_TOP_BITS;
>    bool fSegbit =3D (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
>    if (!(fVersionBits && fSegbit)) {
>        return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>    }
> }
>=20
> // BIP148 mandatory segwit signalling.
> int64_t nMedianTimePast =3D pindex->GetMedianTimePast();
> if ( (nMedianTimePast >=3D 1501545600) &&  // Tue 01 Aug 2017 00:00:00 =
UTC
>     (nMedianTimePast <=3D 1510704000) &&  // Wed 15 Nov 2017 00:00:00 =
UTC
>     (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
>      !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
> // and is not active.
> {
>    bool fVersionBits =3D (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D=

> VERSIONBITS_TOP_BITS;
>    bool fSegbit =3D (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
>    if (!(fVersionBits && fSegbit)) {
>        return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>    }
> }
>
>=20 > = https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:splitprote= ction-v0.14.1 = >=20 > =3D=3DBackwards Compatibility=3D=3D >=20 > This deployment is compatible with the existing "segwit" bit 1 > deployment scheduled between midnight November 15th, 2016 and midnight > November 15th, 2017. This deployment is also compatible with the > existing BIP148 deployment. This BIP is compatible with BIP91 only if > BIP91 activates before it and before BIP148. Miners will need to > upgrade their nodes to support splitprotection otherwise they may > build on top of an invalid block. While this bip is active users > should either upgrade to splitprotection or wait for additional > confirmations when accepting payments. >=20 > =3D=3DRationale=3D=3D >=20 > Historically we have used IsSuperMajority() to activate soft forks > such as BIP66 which has a mandatory signalling requirement for miners > once activated, this ensures that miners are aware of new rules being > enforced. This technique can be leveraged to lower the signalling > threshold of a soft fork while it is in the process of being deployed > in a backwards compatible way. We also use a BIP8 style timeout to > ensure that this BIP is compatible with BIP148 and that BIP148 > compatible mandatory signalling activates regardless of miner > signalling levels. >=20 > By orphaning non-signalling blocks during the BIP9 bit 1 "segwit" > deployment, this BIP can cause the existing "segwit" deployment to > activate without needing to release a new deployment. As we approach > BIP148 activation it may be desirable for a majority of miners to have > a method that will ensure that there is no chain split. >=20 > =3D=3DReferences=3D=3D >=20 > = *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/01371= 4.html = > Mailing list discussion] > = *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 = > P2SH flag day activation] > *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]] > *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]] > *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]] > *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]] > *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for > Version 0 Witness Program]] > *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element = malleability]] > *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit = deployment]] > *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]] > *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit = benefits = ] >=20 > =3D=3DCopyright=3D=3D >=20 > This document is dual licensed as BSD 3-clause, and Creative Commons > CC0 1.0 Universal. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = --Apple-Mail=_CDEDC1C0-6CDC-4A87-8D22-F9CF4FBC69A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii What is the probability that a 65% = threshold is too low and can allow a "surprise miner attack", whereby = miners are kept offline before the deadline, and brought online = immediately after, creating potential havoc?

(Nit: "simple majority" usually refers = to >50%, I think, might cause confusion.)

-Greg = Slepak

--
Please do not email me anything that you are not = comfortable also sharing with the NSA.

On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:

Due = to the proposed calendar(https://segwit2x.github.io/) for the
SegWit2x= agreement being too slow to activate SegWit mandatory
signalling ahead of BIP148 using BIP91 I would like to = propose another
option that miners can use to prevent a = chain split ahead of the Aug
1st BIP148 activation = date.

The splitprotection soft fork is = essentially BIP91 but using BIP8
instead of BIP9 with a = lower activation threshold and immediate
mandatory = signalling lock-in. This allows for a majority of miners to
activate mandatory SegWit signalling and prevent a potential = chain
split ahead of BIP148 activation.

This BIP allows for miners to respond to market forces = quickly ahead
of BIP148 activation by signalling for = splitprotection. Any miners
already running BIP148 should = be encouraged to use splitprotection.

<pre>
 BIP: splitprotection
 Layer: Consensus (soft fork)
=  Title: User Activated Soft Fork Split Protection
=  Author: James Hilliard <james.hilliard1@gmail.com>
=  Comments-Summary: No comments yet.
=  Comments-URI:
 Status: Draft
=  Type: Standards Track
 Created: 2017-05-22
 License: BSD-3-Clause
=           CC0-1.0
</pre>

=3D=3DAbstract=3D=3D<= br class=3D"">
This document specifies a coordination = mechanism for a simple majority
of miners to prevent a = chain split ahead of BIP148 activation.

=3D=3DDefinitions=3D=3D

"existing = segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th = 2017 to
activate BIP141, BIP143 and BIP147.

=3D=3DMotivation=3D=3D

The biggest risk of BIP148 is an extended chain split, this = BIP
provides a way for a simple majority of miners to = eliminate that risk.

This BIP provides a = way for a simple majority of miners to coordinate
activation= of the existing segwit deployment with less than 95%
hashpower before BIP148 activation. Due to time constraints = unless
immediately deployed BIP91 will likely not be able = to enforce
mandatory signalling of segwit before the Aug = 1st activation of
BIP148. This BIP provides a method for = rapid miner activation of
SegWit mandatory signalling = ahead of the BIP148 activation date. Since
the primary = goal of this BIP is to reduce the chance of an extended
chain split as much as possible we activate using a simple = miner
majority of 65% over a 504 block interval rather = than a higher
percentage. This BIP also allows miners to = signal their intention to
run BIP148 in order to prevent a = chain split.

=3D=3DSpecification=3D=3D

While this BIP is active, all blocks must set = the nVersion header top
3 bits to 001 together with bit = field (1<<1) (according to the
existing segwit = deployment). Blocks that do not signal as required
will be = rejected.

=3D=3DDeployment=3D=3D

This BIP will be deployed by "version bits" = with a 65%(this can be
adjusted if desired) activation = threshold BIP9 with the name
"splitprotecion" and using = bit 2.

This BIP starts immediately and is a = BIP8 style soft fork since
mandatory signalling will start = on midnight August 1st 2017 (epoch
time 1501545600) = regardless of whether or not this BIP has reached its
own = signalling threshold. This BIP will cease to be active when segwit
is locked-in.

=3D=3D=3D = Reference implementation =3D=3D=3D

<pre>
// Check if Segregated Witness is = Locked In
bool IsWitnessLockedIn(const CBlockIndex* = pindexPrev, const
Consensus::Params& params)
{
   LOCK(cs_main);
   return (VersionBitsState(pindexPrev, = params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) = =3D=3D
THRESHOLD_LOCKED_IN);
}

// SPLITPROTECTION mandatory segwit = signalling.
if ( VersionBitsState(pindex->pprev, = chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) = =3D=3D
THRESHOLD_LOCKED_IN &&
=     !IsWitnessLockedIn(pindex->pprev, = chainparams.GetConsensus()) &&
// Segwit is not = locked in
=     !IsWitnessEnabled(pindex->pprev, = chainparams.GetConsensus()) ) //
and is not active.
{
   bool fVersionBits =3D = (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D
VERSIONBITS_TOP_BITS;
   bool = fSegbit =3D (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
=    if (!(fVersionBits && fSegbit)) {
=        return state.DoS(0, = error("ConnectBlock(): relayed block must
signal for = segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
=    }
}

// = BIP148 mandatory segwit signalling.
int64_t = nMedianTimePast =3D pindex->GetMedianTimePast();
if ( = (nMedianTimePast >=3D 1501545600) &&  // Tue 01 Aug 2017 = 00:00:00 UTC
    (nMedianTimePast = <=3D 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC
=     (!IsWitnessLockedIn(pindex->pprev, = chainparams.GetConsensus()) &&
// Segwit is not = locked in
=      !IsWitnessEnabled(pindex->pprev, = chainparams.GetConsensus())) )
// and is not active.
{
   bool fVersionBits =3D = (pindex->nVersion & VERSIONBITS_TOP_MASK) =3D=3D
VERSIONBITS_TOP_BITS;
   bool = fSegbit =3D (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) !=3D 0;
=    if (!(fVersionBits && fSegbit)) {
=        return state.DoS(0, = error("ConnectBlock(): relayed block must
signal for = segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
=    }
}
</pre>

https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard= :splitprotection-v0.14.1

=3D=3DBackwards = Compatibility=3D=3D

This deployment is = compatible with the existing "segwit" bit 1
deployment = scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. This deployment is also compatible with = the
existing BIP148 deployment. This BIP is compatible = with BIP91 only if
BIP91 activates before it and before = BIP148. Miners will need to
upgrade their nodes to support = splitprotection otherwise they may
build on top of an = invalid block. While this bip is active users
should = either upgrade to splitprotection or wait for additional
confirmations when accepting payments.

=3D=3DRationale=3D=3D

Historically= we have used IsSuperMajority() to activate soft forks
such = as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new = rules being
enforced. This technique can be leveraged to = lower the signalling
threshold of a soft fork while it is = in the process of being deployed
in a backwards compatible = way. We also use a BIP8 style timeout to
ensure that this = BIP is compatible with BIP148 and that BIP148
compatible = mandatory signalling activates regardless of miner
signalling levels.

By orphaning = non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" = deployment to
activate without needing to release a new = deployment. As we approach
BIP148 activation it may be = desirable for a majority of miners to have
a method that = will ensure that there is no chain split.

=3D=3DReferences=3D=3D

*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ma= rch/013714.html
Mailing list discussion]
*[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L12= 81-L1283
P2SH flag day activation]
*[[bip-0009.mediawiki|BIP9 Version bits with timeout and = delay]]
*[[bip-0016.mediawiki|BIP16 Pay to Script = Hash]]
*[[bip-0091.mediawiki|BIP91 Reduced threshold = Segwit MASF]]
*[[bip-0141.mediawiki|BIP141 Segregated = Witness (Consensus layer)]]
*[[bip-0143.mediawiki|BIP143 = Transaction Signature Verification for
Version 0 Witness = Program]]
*[[bip-0147.mediawiki|BIP147 Dealing with dummy = stack element malleability]]
*[[bip-0148.mediawiki|BIP148 = Mandatory activation of segwit deployment]]
*[[bip-0149.mediawiki|BIP149 Segregated Witness (second = deployment)]]
*[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit = benefits]

=3D=3DCopyright=3D=3D

This document is dual licensed as BSD = 3-clause, and Creative Commons
CC0 1.0 Universal.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>

= --Apple-Mail=_CDEDC1C0-6CDC-4A87-8D22-F9CF4FBC69A8-- --Apple-Mail=_1AEAF7EF-89BF-4AFD-9132-3878FF956856 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----- iQIcBAEBCgAGBQJZN1wrAAoJEOxnICvpCVJHbqYP/iD7mVhWTvbKqOkRLxxocLg7 g+vOpsRNKDhUzEIVTH2eYW8S/fgQmfwgXIVQ6dtJATp2VHbRqxknVlu9YtBMoLwB CGj2sykfoZRTw//F7pT9wRU5LaMUnicFBgE4Eq7ZgVlATLFigxd2tI0lTJrDjzKX nz1lGuKW6sAe25pcC1KpWIR3w4YqhBoX3WVCU5lA5A6OtvvYSRmZEYsq6z7RDRA7 mdU9X+CZIAbQJKVZm1tjwFhy30PDXfWP03FlYtzJLykrl81Lt+T70jj/IQaGzpVn 7pOM8AHZs4niSQ+JHazdH+mMO+adUmaxGPLupTSYZ6R0ZxFP86E53neGWydkppSr qsY1g7/p1Gj7ATrLCd4Y9ZD+GCVEx6rvorX8APOHfj2CJhS9JZs4oWqenUW57qRb fmlW3xpNHQRH7JZASHjBohPfxh6hOPYZVbOZIL2P14ws6P3XYYzbSM6TtNNq6/dj EgRSFUUnBz/uR4Xf8V5FPLcifGJykXS+JJdgieKC/kGm4Xol6z5kX5D/PB+IPtTT eagPKvBXUTobSzhr7povNPfjz2LSvVdqhGwK5b/+YLfhvjYItl6wC/h0kLdKc1EL m9EOxaqVV3dsxWMyRQB5VR/iUcEVL+g9Sp7JrOXHQLJuE6v3uidar8Au7wLeuueo BrpC8it2ZAgimGKLExiG =LTLt -----END PGP SIGNATURE----- --Apple-Mail=_1AEAF7EF-89BF-4AFD-9132-3878FF956856--