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 9903171F for ; Wed, 20 Dec 2017 08:49:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADE6087 for ; Wed, 20 Dec 2017 08:49:13 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A1A5120BFE; Wed, 20 Dec 2017 03:49:12 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 20 Dec 2017 03:49:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=mIDsB9NmnZ6Tgt/WdXgXJCteDH8+ykMu6MepVXEWzbE=; b=KOLPcUbs bRi7Cs2nmdEZeLfMkrAJjqahlyAF9wgnZqzJM0jJQSc6zD6HYm8jZlgtPlpG3HKo 1WVdXEEr6sB6I6MnNP5bvTRexLDLOieUzJ70HLGra6RVuakOR8eLuXIoiuyIZFea HDj1zRtwdh0pg8y1VPYWjT84zrjlBCoa3yhpoGijv/wiv8FpjWay1w9ImGKtdUrJ WSsEi16RI7RNuj93wEiT91ALnBbPUxWv7ntEqujdbYVvYYIx4wgEMokeTjlyXw25 Ia415MmamR7fheSTtI9Z7opUr81n4I+FkeguH0nKucrXtQ3slK+8nMSUDDjecbZY BMNmMGSYwcaBvg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mIDsB9NmnZ6Tgt/WdXgXJCteDH8+y kMu6MepVXEWzbE=; b=X6fWKJTakS2sWOz8xaWFOaR2gTy4765fYjiMPe4lzWz3o tysHfQM5RRO1DlRnvie8tjRzyVvqcZ2fOK8GC0yzgUAquft+I3lu4gmjNoyp10BR Ng/mBkgc4fL9IRcklPpVDbIANDZ0isphiANQybyhpREdKFOJevkj/UaN9yDAETFx N+aGw1VqApRCb/UdcqgI2XbZTqV2Uowf0ifwZSCVE/5Kz6c54Mjd9/q5dt74D1uC CrSp9rXqBuFqKeBHSPfjgwQdWxFxvFGITzdFLS7CQbiXQAwWJ66wkzpi0k7Jen+7 Ajg04oqdQa+oSIv//+PzzedcRA6Gka+UwDvihBzcA== X-ME-Sender: Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl [84.105.61.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B4BE8240F6; Wed, 20 Dec 2017 03:49:11 -0500 (EST) From: Sjors Provoost Content-Type: multipart/signed; boundary="Apple-Mail=_9AD3BDD0-7B31-4573-883B-24A7583359AD"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 20 Dec 2017 09:49:09 +0100 References: To: Nicolas Dorier , Bitcoin Dev In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW, TVD_PH_BODY_ACCOUNTS_PRE 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, 20 Dec 2017 15:17:16 +0000 Subject: Re: [bitcoin-dev] BIP Proposal: Crypto Open Exchange Protocol (COX) 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, 20 Dec 2017 08:49:15 -0000 --Apple-Mail=_9AD3BDD0-7B31-4573-883B-24A7583359AD Content-Type: multipart/alternative; boundary="Apple-Mail=_49C21D35-A3AB-4732-BCCD-A8A62DE2F8F8" --Apple-Mail=_49C21D35-A3AB-4732-BCCD-A8A62DE2F8F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think this could be quite useful, although I don=E2=80=99t know if it = will get adopted. If any such small local exchanges want to weigh in on = this proposal, that would help. Same goes for shopping cart integrators, = e.g. the folks writing WooCommerce and Shopify plugins. Consider adding some requirements around the use of SSL and certificate = pinning. Can you refer to the kind of best practices Stripe and PayPal = recommend? Should some additional shared-secret or cookie / macaroon = based authentication be added? Can you clarify if this integration can run in a browser, or due to = security / privacy constraints must be server-to-server? Though it=E2=80=99s important to remain future-proof by being flexible, = leaving the above details to individual implementers is probably going = to result in bad things. What are your thoughts on rate limiting vs. privacy? Should a payment = source never return the same address even if nothing is paid to it? = Otherwise someone could just crawl webshops to create an inventory of = payment addresses. A new address every page reload could be a DDOS = vector. It also wouldn't be compatible with BIP44 because of its gap = limit, although I don=E2=80=99t think that=E2=80=99s a huge problem for = exchanges. Can this be combined with an invoice mechanism similar to Lightning, = e.g. where the exchange sends a pre-image to the users wallet (relayed = via and retained by the web shop) upon receipt of the funds, which they = can then present to the merchant in case something went wrong. Exchanges = might be happy to support this protocol, but they don=E2=80=99t want the = burden of dealing with user support requests, so having signed invoices = could help with that. I would consider a more specific name like Delegated UTXO or something. = =E2=80=9CExchange=E2=80=9D suggests is more like 0X or Bisq. Speaking of Bisq, it would be neat if merchants can rely on random peer = to peer counterparties to convert to fiat, so their customer information = and revenue figures aren=E2=80=99t in the hands of a single counter = party. Obviously that=E2=80=99s a can of worms today, but it would be = nice if the protocol was able to support that if one day someone figures = out the fraud, compliance and bookkeeping stuff. Finally, why only exchanges? It could make sense fo shopping cart = software to talk to a Bitcoin wallet that=E2=80=99s hosted somewhere = else for similar reasons. Right now the best these plugins can do is = hold on to an XPUB, and I=E2=80=99ve even seen solutions that just send = the customers coins to their own backend wallet and then forward it. Sjors > Op 20 dec. 2017, om 07:28 heeft Nicolas Dorier via bitcoin-dev = het volgende geschreven: >=20 > Hi everyone, >=20 > As some of you know, I am working on a complete open source = replacement of Bitpay for allowing merchant to accept cryptocurrency = payments while having a way to sell automatically. >=20 > A crucial, missing part, is fiat conversion. And I figured out a = simple protocol that exchanges (or adapters) can implement to allow any = merchant to cash out BTC in fiat while giving them the freedom to choose = their own payment processor solution. >=20 > This also have positive impact on scalability: Before, a merchant = would receive the bitcoin from the customer then would send to the = exchange, resulting in two transactions. > With this specification, it would be one transaction. >=20 > Special thanks to anditto and kallewoof for reviewing. I am waiting = for your feedback: >=20 > Github link: = https://github.com/NicolasDorier/bips/blob/master/bip-xxx.mediawiki = >=20 > 
>   BIP: XXX
>   Layer: Applications
>   Title: Crypto Open Exchange Protocol (COX)
>   Author: Nicolas Dorier >
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX =

>   Status: Draft
>   Type: Standards Track
>   Created: 2017-12-20
>   License: BSD-3-Clause
>            CC0-1.0
>
>=20 > =3D=3DAbstract=3D=3D >=20 > A simple protocol for decoupling payment processor solutions from = exchanges. >=20 > =3D=3DMotivation=3D=3D >=20 > Cryptocurrency merchant adoption is mainly driven by availability, = ease of use and means of acceptance. > We call such solutions `Payment Processors`. >=20 > Until now, payment processing solutions fall into one of the two = following categories: >=20 > # Self-hosted with the customer paying in cryptocurrency and the = merchant receiving it directly. > # Centralized, coupled with an exchange feature, with the customer = paying in cryptocurrency to the merchant, and receiving fiat or = cryptocurrency on his exchange account. >=20 > The self-hosted solution has two issues: >=20 > # The merchant becomes vulnerable to the wild volatility of = cryptocurrencies. > # It is wasteful of blockchain space, if the merchant does not pay = suppliers in crypto, as they need a second transaction to change to his = exchange, >=20 > The centralized solution has two issues: >=20 > # It locks-in the merchant to a particular payment processor whose = intentions might not be aligned (e.g. Bitpay who tried to redefine = Bitcoin as being a different chain, without merchant approval) > # It has to deal with local regulations (e.g. Bitpay does not provide = fiat CAD to canadian merchants) >=20 > The goal of this BIP is to specify a simple protocol which makes = possible decoupling of payment processors from exchanges. >=20 > We believe this BIP will gather a lot of interest among local = exchanges which do not have the resources to develop their own payment = solutions. >=20 > Their customers can decide which payment processor solution they = prefer, while the exchanges give them a way to protect against = cryptocurrency volatility. >=20 > =3D=3DSummary=3D=3D >=20 > The merchant log in to its exchange website, go into "Address sources" = section of it, an click on "Create a new address source". >=20 > The address source creation wizard asks him questions about what to do = when crypto currency is sent to this the address source. = (Cryptocurrency, Market sell order, limit order of past day average = etc...) >=20 > The merchant receives an "address source URI" which they can input = inside the payment processor. >=20 > An exchange compatible with the Crypto Open Exchange Protocol would = reply to any HTTP POST request to this "address source URI" returning = the following information (more details in the Specification part) >=20 > # A deposit address for accepting a payment > # The current rate > # Optional: If the exchange is willing to take the risk of rate = fluctuation, until when this rate is guaranteed and under which = conditions. >=20 > >=20 > =3D=3D=3DInteraction=3D=3D=3D >=20 > * Manny (the "merchant") wants to accept Bitcoin payments on his = e-commerce website. > * Manny chooses the payment processor "PROCCO" which has a powerful = plugin for his e-commerce website. > * Manny is based in Canada and already has an account on the exchange = "MYCOIN" which supports the Crypto Open Exchange Protocol. > * Manny connects to the exchange website, and creates a new address = source. > * In the configuration screen of the address source, for each payment = sent to this address source, Manny decides to keep 30% in Bitcoin and = place a market sell order for the remaining 70% of the amount. > * "MYCOIN" creates the address source, and gives the "address source = URI" to the merchant. (e.g. = https://example.com/addresssources/abd29ddn92 = ) > * Manny copies the address source URI and goes inside "PROCCO" = settings, and configures his store to use this address source URI. >=20 > Now a customer, Carol, wants to order a brand new phone for 0.01 BTC = on Manny's store and decides to pay in Bitcoin. >=20 > * The E-Commerce website plugin requests the creation of an invoice = from PROCCO. > * PROCCO queries the "address source URI" and retrieves the rate, the = expiration of this rate and conditions. > * PROCCO can now show the Bitcoin Payment Checkout page. > * Carla pays. > * PROCCO marks the payment as paid and redirects to the e-commerce = website. > * MYCOIN, under its own policy (typically after 6 confirmations), = credits Manny's account of 0.01 BTC and simultaneously creates a market = sell order of 0.007 BTC on behalf of Manny. >=20 > =3D=3DSpecification=3D=3D >=20 > The payment processor sends a POST request to the "address source = URI", the response from a Crypto Open Exchange Protocol exchange would = be: >=20 > If the exchange does not guarantee the rate: >=20 > { > "depositAddress" : "13....abd", > "currencyCode" : "CAD", > "cryptoCurrencyCode" : "BTC", > "rate" : "15600", > # When the merchant account get credited on the exchange > "requiredConfirmations" : blockcount > } >=20 >=20 > If the exchange guarantee the rate: >=20 > { > "depositAddress" : "13....abd", > "currencyCode" : "CAD", > "cryptoCurrencyCode" : "BTC", > "rate" : "15600", > "requiredConfirmations" : blockcount > "conditions" : > { > # When the transaction should be seen on the blockchain to = guarantee the rate > "receivedBefore" : timestamp, > # When the transaction should be confirmed on the = blockchain to guarantee the rate > "confirmedBefore" : timestamp > } > } >=20 >=20 > The payment processor is responsible for giving feedback to the = customer if the fees of the received transaction are not enough to = guarantee the rate. >=20 > =3D=3DNote on adoption=3D=3D >=20 > While local exchanges have incentives to implement this simple = protocol, it is not strictly needed. >=20 > An alternative is to develop an adapter server which expose Crypto = Open Exchange Protocol endpoint and connect to underlying exchange's = API. >=20 > The only downside is that the rate can't be guaranteed. >=20 > =3D=3DCopyright=3D=3D >=20 > This document is dual licensed as BSD 3-clause, and Creative Commons = CC0 1.0 Universal. >=20 >=20 > Nicolas, > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_49C21D35-A3AB-4732-BCCD-A8A62DE2F8F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I think = this could be quite useful, although I don=E2=80=99t know if it will get = adopted. If any such small local exchanges want to weigh in on this = proposal, that would help. Same goes for shopping cart integrators, e.g. = the folks writing WooCommerce and Shopify plugins. 

Consider adding some = requirements around the use of SSL and certificate pinning. Can you = refer to the kind of best practices Stripe and PayPal recommend? Should = some additional shared-secret or cookie / macaroon based authentication = be added? 

Can you clarify if this integration can run in a browser, or = due to security / privacy constraints must be = server-to-server?

Though it=E2=80=99s important to remain future-proof by being = flexible, leaving the above details to individual implementers is = probably going to result in bad things.

What are your thoughts on rate limiting = vs. privacy? Should a payment source never return the same address even = if nothing is paid to it? Otherwise someone could just crawl webshops to = create an inventory of payment addresses. A new address every page = reload could be a DDOS vector. It also wouldn't be compatible with BIP44 = because of its gap limit, although I don=E2=80=99t think that=E2=80=99s = a huge problem for exchanges.

Can this be combined with an invoice = mechanism similar to Lightning, e.g. where the exchange sends a = pre-image to the users wallet (relayed via and retained by the web shop) = upon receipt of the funds, which they can then present to the merchant = in case something went wrong. Exchanges might be happy to support this = protocol, but they don=E2=80=99t want the burden of dealing with user = support requests, so having signed invoices could help with = that.

I would = consider a more specific name like Delegated UTXO or something. = =E2=80=9CExchange=E2=80=9D suggests is more like 0X or Bisq.

Speaking of Bisq, it = would be neat if merchants can rely on random peer to peer = counterparties to convert to fiat, so their customer information and = revenue figures aren=E2=80=99t in the hands of a single counter party. = Obviously that=E2=80=99s a can of worms today, but it would be nice if = the protocol was able to support that if one day someone figures out the = fraud, compliance and bookkeeping stuff.

Finally, why only exchanges? It could = make sense fo shopping cart software to talk to a Bitcoin wallet = that=E2=80=99s hosted somewhere else for similar reasons. Right now the = best these plugins can do is hold on to an XPUB, and I=E2=80=99ve even = seen solutions that just send the customers coins to their own backend = wallet and then forward it.

Sjors

Op 20 dec. 2017, om 07:28 heeft = Nicolas Dorier via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende = geschreven:

Hi everyone,

As some of you know, I am working on a = complete open source replacement of Bitpay for allowing merchant to = accept cryptocurrency payments while having a way to sell = automatically.

A= crucial, missing part, is fiat conversion. And I figured out a simple = protocol that exchanges (or adapters) can implement to allow any = merchant to cash out BTC in fiat while giving them the freedom to choose = their own payment processor solution.

This also have positive impact on = scalability: Before, a merchant would receive the bitcoin from the = customer then would send to the exchange, resulting in two = transactions.
With this specification, it would be = one transaction.

Special thanks to anditto and kallewoof for reviewing. I am = waiting for your feedback:

Github link: https://github.com/NicolasDorier/bips/blob/master/bip-xxx.media= wiki

<pre>
  BIP: XXX
  Layer: Applications
  Title: = Crypto Open Exchange Protocol (COX)
  Author: = Nicolas Dorier <nicolas.dorier@gmail.com>
  = Comments-Summary: No comments yet.
  = Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXX
=
  Status: Draft
  Type: = Standards Track
  Created: = 2017-12-20
  License: BSD-3-Clause
           CC0-1.0
</pre>

=3D=3DAbstract=3D=3D

A simple protocol for decoupling = payment processor solutions from exchanges.

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

Cryptocurrency merchant = adoption is mainly driven by availability, ease of use and means of = acceptance.
We call such solutions `Payment = Processors`.

Until now, payment processing solutions fall into one of the = two following categories:

# Self-hosted with the customer paying in cryptocurrency and = the merchant receiving it directly.
# Centralized, = coupled with an exchange feature, with the customer paying in = cryptocurrency to the merchant, and receiving fiat or cryptocurrency on = his exchange account.

The self-hosted solution has two issues:

# The merchant becomes = vulnerable to the wild volatility of cryptocurrencies.
# It is wasteful of blockchain space, if the merchant does = not pay suppliers in crypto, as they need a second transaction to change = to his exchange,

The centralized solution has two issues:

# It locks-in the = merchant to a particular payment processor whose intentions might not be = aligned (e.g. Bitpay who tried to redefine Bitcoin as being a different = chain, without merchant approval)
# It has to deal = with local regulations (e.g. Bitpay does not provide fiat CAD to = canadian merchants)

The goal of this BIP is to specify a simple protocol which = makes possible decoupling of payment processors from = exchanges.

We = believe this BIP will gather a lot of interest among local exchanges = which do not have the resources to develop their own payment = solutions.

Their= customers can decide which payment processor solution they prefer, = while the exchanges give them a way to protect against cryptocurrency = volatility.

=3D=3DSummary=3D=3D

The merchant log in to its exchange = website, go into "Address sources" section of it, an click on "Create a = new address source".

The address source creation wizard asks him questions about = what to do when crypto currency is sent to this the address source. = (Cryptocurrency, Market sell order, limit order of past day average = etc...)

The = merchant receives an "address source URI" which they can input inside = the payment processor.

An exchange compatible with the Crypto Open Exchange Protocol = would reply to any HTTP POST request to this  "address source URI" = returning the following information (more details in the Specification = part)

# A = deposit address for accepting a payment
# The = current rate
# Optional: If the exchange is willing = to take the risk of rate fluctuation, until when this rate is guaranteed = and under which conditions.

<img src=3D"bip-xxx/overview.png"></img>

=3D=3D=3DInteraction=3D=3D=3D

* Manny (the "merchant") wants to = accept Bitcoin payments on his e-commerce website.
* = Manny chooses the payment processor "PROCCO" which has a powerful plugin = for his e-commerce website.
* Manny is based in = Canada and already has an account on the exchange "MYCOIN" which = supports the Crypto Open Exchange Protocol.
* Manny = connects to the exchange website, and creates a new address = source.
* In the configuration screen of the = address source, for each payment sent to this address source, Manny = decides to keep 30% in Bitcoin and place a market sell order for the = remaining 70% of the amount.
* "MYCOIN" creates the = address source, and gives the "address source URI" to the merchant. = (e.g. https://example.com/addresssources/abd29ddn92)
* Manny copies the address source URI and goes inside = "PROCCO" settings, and configures his store to use this address source = URI.

Now a = customer, Carol, wants to order a brand new phone for 0.01 BTC on = Manny's store and decides to pay in Bitcoin.

* The E-Commerce website plugin = requests the creation of an invoice from PROCCO. 
* PROCCO queries the "address source URI" and retrieves the = rate, the expiration of this rate and conditions.
* = PROCCO can now show the Bitcoin Payment Checkout page.
* Carla pays.
* PROCCO marks the payment = as paid and redirects to the e-commerce website.
* = MYCOIN, under its own policy (typically after 6 confirmations), credits = Manny's account of 0.01 BTC and simultaneously creates a market sell = order of 0.007 BTC on behalf of Manny.

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

The payment processor = sends a POST request to the "address source URI", the response from a = Crypto Open Exchange Protocol exchange would be:

If the exchange does not guarantee the = rate:

  =   {
        = "depositAddress" : "13....abd",
    =     "currencyCode" : "CAD",
    =     "cryptoCurrencyCode" : "BTC",
  =       "rate" : "15600",
  =       # When the merchant account get credited on the = exchange
        = "requiredConfirmations" : blockcount
    = }


If the exchange guarantee the = rate:

  =   {
        = "depositAddress" : "13....abd",
    =     "currencyCode" : "CAD",
    =     "cryptoCurrencyCode" : "BTC",
  =       "rate" : "15600",
  =       "requiredConfirmations" : blockcount
        "conditions" : 
        {
  =           # When the transaction should be seen = on the blockchain to guarantee the rate
  =           "receivedBefore" : = timestamp,
          =   # When the transaction should be confirmed on the blockchain to = guarantee the rate
        =     "confirmedBefore" : timestamp
  =       }
    }


The payment processor is responsible for giving feedback to = the customer if the fees of the received transaction are not enough to = guarantee the rate.

=3D=3DNote on adoption=3D=3D

While local exchanges have incentives = to implement this simple protocol, it is not strictly needed.

An alternative is to = develop an adapter server which expose Crypto Open Exchange Protocol = endpoint and connect to underlying exchange's API.

The only downside is = that the rate can't be guaranteed.

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

This document is dual = licensed as BSD 3-clause, and Creative Commons CC0 1.0 = Universal.


Nicolas,
_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">

= --Apple-Mail=_49C21D35-A3AB-4732-BCCD-A8A62DE2F8F8-- --Apple-Mail=_9AD3BDD0-7B31-4573-883B-24A7583359AD 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----- iQIzBAEBCAAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAlo6JAUACgkQV/+b28ww EAlQShAArarVXEfutFB4TYnD8seBXVcLMFv42FnqcMJgaaeJrkOrWPOYHw4lIqHe S4wUnUeRPAczUIjBrV6q3jdIzjhevgZN3ekgUs4NVp2fN9RFJZkxB1sqiroCYk7J UDSQYzgv/AeeBMSH0TeulPcA47rzpTT+eCpgoCcKizuWT8RnohYJF76b1pgmUxlX KThcPtuNVE8X5nVGVAkesBmBGjZxfqaObDhLWSPQ3cA2XtlNUPdhzQqTPczYD5h7 ZN/2AsoptEHZ5pFmqpWOHAIMsz1825QDy1uDK+ofLVP4zlfK1KA0K8k44XRmrSxA aCGBOJymkkbGE3krOkfofV7uPGF/Tawh2DWrIWC+/h/UgUVXiRHHBRltxRr60Kdv 57GnUegw9RbFJ4OnxDIVHz7NBecMWpB774lF6S9O1H/ODTU2DKfo7uqHSFHVIBwo sHh5ni3WPiyengvoxLAeW6Cm2oaFmXHiMexlzPfDOwZvG/Ee5mjebARTYdagKuv3 46N4b8CaRmqnwUkph4/XMXQbSeVC6HSRaQoSEpnUxsI66zLVtk4Ox+a+17S3opWI jha2wzoBX1LX0CdgH1U8Q2G/ESbyVwyXyR+ZbyU4ysi/s2eNlMBOXLyE3j5YNfds pOT1dYCxzDaYBBh4T+06350WiorNonUE/plfOE5zetpj143+AJ4= =/Zdv -----END PGP SIGNATURE----- --Apple-Mail=_9AD3BDD0-7B31-4573-883B-24A7583359AD--