Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C9DCF8A6 for ; Sat, 15 Aug 2015 23:07:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B8DE11E for ; Sat, 15 Aug 2015 23:07:48 +0000 (UTC) Received: by pacgr6 with SMTP id gr6so82072975pac.2 for ; Sat, 15 Aug 2015 16:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=BMZiA+tYJeQdLEHCMMAk2NlFyj/sJfEVUNvwNtfDh1E=; b=Eymun/QaLbvmwWemzvfA8gpCh7P3ZyQEHY19BeoveHfgh6SbcW+TVc/+gU9SVWyqPq f11k6NYotbVz/M6eZgOk+cbRfiiva9YMuAvulCPZcmyYdGL8MmZfL30CH3DMoytn3ApK r6lSgtRfPYq7bE8qwEPF/YKa8TjbCkAljX1RFtaGoSZc115IBAoxf7AoNMBGLXZSecqt jyTlRjpJpqTlTsCMsxu3MA1q+DzSKHbXaj6lS9T6S9m3W5puGCBkMTNIJbzqg+cD3m87 T6+lpM8ARfxGmyVswmhcFG/OC+JpHSpduhn/SfknG1ipp8r5xfEIgpbgWk4oEWXNduBr joDQ== X-Received: by 10.68.191.130 with SMTP id gy2mr53376211pbc.124.1439680068041; Sat, 15 Aug 2015 16:07:48 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id le8sm9803322pbc.24.2015.08.15.16.07.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Aug 2015 16:07:47 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9EB5D894-B637-4D65-A9E1-6B5C8D35C675"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Eric Lombrozo In-Reply-To: Date: Sat, 15 Aug 2015 16:07:45 -0700 Message-Id: <90267BA3-06D8-412B-8FF6-BA21BCCA8AB8@gmail.com> References: To: Ken Friece X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 23:07:49 -0000 --Apple-Mail=_9EB5D894-B637-4D65-A9E1-6B5C8D35C675 Content-Type: multipart/alternative; boundary="Apple-Mail=_5F12ACE6-10D0-4EA9-91D4-ED691C3E3E65" --Apple-Mail=_5F12ACE6-10D0-4EA9-91D4-ED691C3E3E65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please take the lightning 101 discussion to another thread. The main point I was trying to make was that Mike is clearly = misrepresenting the views of a great number of people who have deep, = intimate knowledge of how things work and are almost certainly not = primarily motivated by their own potential for profits. > On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev = wrote: >=20 > Being an early hub provider would be an obvious place to start = capitalizing on lightning. Early lightning adopters would be in the best = position to do this. >=20 > Long term, Bitcoin needs to scale the blockchain in a reasonable = manner and implement things like lightning. >=20 > Limiting the blocksize is a blatant conflict of interest because it = creates artificial demand for lightning that would not otherwise exist = if the blockchain scaled in a reasonable manner. >=20 > On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach = > wrote: > I would like very much to know how it is that we're supposed to be = making money off of lightning, and therefore how it represents a = conflict of interest. Apparently there is tons of money to be made in = releasing open-source protocols! I would hate to miss out on that. >=20 > We are working on lightning because Mike of all people said, = essentially, " if you're so fond of micro payment channels, why aren't = you working on them?" And he was right! So we looked around and found = the best proposal and funded it. >=20 > On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" = > wrote: > I know full well who works for Blockstream and I know you're not one = of those folks. The Blockstream core devs are very vocal against a = reasonable blocksize increase (17% growth per year in Pieter's BIP is = not what I consider reasonable because it doesn't come close to keeping = with technological increases). I think we can both agree that more = on-chain space means less demand for lightning, and vice versa, which is = a blatant conflict of interest. >=20 > I'm also trying to figure out how things like lightning are not = competing directly with miners for fees. More off-chain transactions = means less blockchain demand, which would lower on-chain fees. I'm not = sure what is controversial about that statement. >=20 > The lightning network concept is actually a brilliant way to take fees = away from miners without having to make any investment at all in SSH-256 = ASIC mining hardware. >=20 > On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo > wrote: >=20 >> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev = > wrote: >>=20 >> What are you so afraid of, Eric? If Mike's fork is successful, = consensus is reached around larger blocks. If it is rejected, the status = quo will remain for now. Network consensus, NOT CORE DEVELOPER = CONSENSUS, is the only thing that matters, and those that go against = network consensus will be severely punished with complete loss of = income. >=20 > I fully agree that core developers are not the only people who should = have a say in this. But again, we=E2=80=99re not talking about merely = forking some open source project - we=E2=80=99re talking about forking a = ledger representing real assets that real people are holding=E2=80=A6and = I think it=E2=80=99s fair to say that the risk of permanent ledger forks = far outweighs whatever benefits any change in the protocol might bring. = And this would be true even if there were unanimous agreement that the = change is good (which there clearly IS NOT in this case) but the = deployment mechanism could still break things. >=20 > If anything we should attempt a hard fork with a less contentious = change first, just to test deployability. >=20 >> I'm not sure who appointed the core devs some sort of Bitcoin Gods = that can hold up any change that they happen to disagree with. It seems = like the core devs are scared to death that the bitcoin network may = change without their blessing, so they go on and on about how terrible = hard forks are. Hard forks are the only way to keep core devs in check. >=20 > Again, let=E2=80=99s figure out a hard fork mechanism and test it with = a far less contentious change first >=20 >> Despite significant past technical bitcoin achievements, two of the = most vocal opponents to a reasonable blocksize increase work for a = company (Blockstream) that stands to profit directly from artificially = limiting the blocksize. The whole situation reeks. Because of such a = blatant conflict of interest, the ethical thing to do would be for them = to either resign from Blockstream or immediately withdraw themselves = from the blocksize debate. This is the type of stuff that I hoped would = end with Bitcoin, but alas, I guess human nature never changes. >=20 > For the record, I do not work for Blockstream. Neither do a bunch of = other people who have published a number of concerns. Very few of the = concerns I=E2=80=99ve seen from the technical community seem to be = motivated primarily by profit motives. >=20 > It should also be pointed out that *not* making drastic changes is the = default consensus policy=E2=80=A6and the burden of justifying a change = falls on those who want to make the change. Again, the risk of permanent = ledger forks far outweighs whatever benefits protocol changes might = bring. >=20 >> Personally, I think miners should give Bitcoin XT a serious look. = Miners need to realize that they are in direct competition with the = lightning network and sidechains for fees. Miners, ask yourselves if you = think you'll earn more fees with 1 MB blocks and more off-chain = transactions or with 8 MB blocks and more on-chain transactions=E2=80=A6 >=20 > Miners are NOT in direct competition with the lightning network and = sidechains - these claims are patently false. I recommend you take a = look at these ideas and understand them a little better before trying to = make any such claims. Again, I do not work for Blockstream=E2=80=A6and = my agenda in this post is not to promote either of these ideas=E2=80=A6but= with all due respect, I do not think you properly understand them at = all. >=20 >> The longer this debate drags on, the more I agree with BIP 100 and = Jeff Garzik because the core devs are already being influenced by = outside forces and should not have complete control of the blocksize. = It's also interesting to note that most of the mining hashpower is = already voting for 8MB blocks BIP100 style. >=20 > I don=E2=80=99t think the concern here is so much that some people = want to increase block size. It=E2=80=99s the *way* in which this change = is being pushed that is deeply problematic. >=20 >> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev = > wrote: >> You deeply disappoint me, Mike. >>=20 >> Not only do you misrepresent many cogent, well thought out positions = from a great number of people who have published and posted a number of = articles detailing an explaining in-depth technical concerns=E2=80=A6you = also seem to fancy yourself more capable of reading into the intentions = of someone who disappeared from the scene years ago, before we even were = fully aware of many things we now know that bring the original = =E2=80=9Cplan=E2=80=9D into question. >>=20 >> I ask of you, as a civilized human being, to stop doing this divisive = crap. Despite your protestations to the contrary, YOU are the one who is = proposing a radical departure from the direction of the project. Also, = as several of us have clearly stated before, equating the fork of an = open source project with a fork of a cryptoledger is completely bogus - = there=E2=80=99s a lot of other people=E2=80=99s money at stake. This = isn=E2=80=99t a democracy - consensus is all or nothing. The fact that a = good number of the people most intimately familiar with the inner = workings of Satoshi=E2=80=99s invention do not believe doing this is a = good idea should give you pause. >>=20 >> Please stop using Bitcoin as your own political football=E2=80=A6for = the sake of Bitcoin=E2=80=A6and for your own sake. Despite your obvious = technical abilities (and I sincerely do believe you have them) you are = discrediting yourself and hurting your own reputation. >>=20 >>=20 >> - Eric >>=20 >>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev = > wrote: >>>=20 >>> Hello, >>>=20 >>> As promised, we have released Bitcoin XT 0.11A which includes the = bigger blocks patch set. You can get it from >>>=20 >>> https://bitcoinxt.software/ >>>=20 >>> I feel sad that it's come to this, but there is no other way. The = Bitcoin Core project has drifted so far from the principles myself and = many others feel are important, that a fork is the only way to fix = things. >>>=20 >>> Forking is a natural thing in the open source community, Bitcoin is = not the first and won't be the last project to go through this. Often in = forks, people say there was insufficient communication. So to ensure = everything is crystal clear I've written a blog post and a kind of = "manifesto" to describe why this is happening and how XT plans to be = different from Core (assuming adoption, of course). >>>=20 >>> The article is here: >>>=20 >>> = https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1 = >>>=20 >>> It makes no attempt to be neutral: this explains things from our = point of view. >>>=20 >>> The manifesto is on the website. >>>=20 >>> I say to all developers on this list: if you also feel that Core is = no longer serving the interests of Bitcoin users, come join us. We don't = bite. >>>=20 >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org = >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org = >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org = >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >=20 >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_5F12ACE6-10D0-4EA9-91D4-ED691C3E3E65 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please take the lightning 101 discussion to another = thread.

The main = point I was trying to make was that Mike is clearly misrepresenting the = views of a great number of people who have deep, intimate knowledge of = how things work and are almost certainly not primarily motivated by = their own potential for profits.

On = Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Being an early hub provider would be an obvious place to = start capitalizing on lightning. Early lightning adopters would be in = the best position to do this.

Long= term, Bitcoin needs to scale the blockchain in a reasonable manner and = implement things like lightning.

Limiting the blocksize is a blatant conflict of = interest because it creates artificial demand for lightning that would = not otherwise exist if the blockchain scaled in a reasonable manner.

On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach = <mark@friedenbach.org> = wrote:

I would like very much to know how it is that we're supposed = to be making money off of lightning, and therefore how it represents a = conflict of interest. Apparently there is tons of money to be made in = releasing open-source protocols! I would hate to miss out on that.

We are working on lightning because Mike of all = people said, essentially, " if you're so fond of micro payment channels, = why aren't you working on them?" And he was right! So we looked around = and found the best proposal and funded it.

On Aug 15, 2015 3:28 PM, "Ken Friece via = bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>= wrote:
I know full well who works for Blockstream and I know you're = not one of those folks. The Blockstream core devs are very vocal against = a reasonable blocksize increase (17% growth per year in Pieter's BIP is = not what I consider reasonable because it doesn't come close to keeping = with technological increases). I think we can both agree that more = on-chain space means less demand for lightning, and vice versa, which is = a blatant conflict of interest.

I'm = also trying to figure out how things like lightning are not competing = directly with miners for fees. More off-chain transactions means less = blockchain demand, which would lower on-chain fees. I'm not sure what is = controversial about that statement.

The lightning network concept is = actually a brilliant way to take fees away from miners without having to = make any investment at all in SSH-256 ASIC mining hardware.

On Sat, = Aug 15, 2015 at 6:16 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:

On Aug = 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

What are you so afraid of, Eric? If Mike's = fork is successful, consensus is reached around larger blocks. If it is = rejected, the status quo will remain for now. Network consensus, NOT = CORE DEVELOPER CONSENSUS, is the only thing that matters, and those that = go against network consensus will be severely punished with complete = loss of income.

I fully agree that core developers are = not the only people who should have a say in this. But again, we=E2=80=99r= e not talking about merely forking some open source project - we=E2=80=99r= e talking about forking a ledger representing real assets that real = people are holding=E2=80=A6and I think it=E2=80=99s fair to say that the = risk of permanent ledger forks far outweighs whatever benefits any = change in the protocol might bring. And this would be true even if there = were unanimous agreement that the change is good (which there clearly IS = NOT in this case) but the deployment mechanism could still break = things.

If = anything we should attempt a hard fork with a less contentious change = first, just to test deployability.

I'm= not sure who appointed the core devs some sort of Bitcoin Gods that can = hold up any change that they happen to disagree with. It seems like the = core devs are scared to death that the bitcoin network may change = without their blessing, so they go on and on about how terrible hard = forks are. Hard forks are the only way to keep core devs in = check.

Again, let=E2=80=99s figure out a hard = fork mechanism and test it with a far less contentious change = first

Despite = significant past technical bitcoin achievements, two of the most vocal = opponents to a reasonable blocksize increase work for a company = (Blockstream) that stands to profit directly from artificially limiting = the blocksize. The whole situation reeks. Because of such a blatant = conflict of interest, the ethical thing to do would be for them to = either resign from Blockstream or immediately withdraw themselves from = the blocksize debate. This is the type of stuff that I hoped would end = with Bitcoin, but alas, I guess human nature never changes.

For the record, I do not work for = Blockstream. Neither do a bunch of other people who have published a = number of concerns. Very few of the concerns I=E2=80=99ve seen from the = technical community seem to be motivated primarily by profit = motives.

It = should also be pointed out that *not* making drastic changes is the = default consensus policy=E2=80=A6and the burden of justifying a change = falls on those who want to make the change. Again, the risk of permanent = ledger forks far outweighs whatever benefits protocol changes might = bring.

Personally, I = think miners should give Bitcoin XT a serious look. Miners need to = realize that they are in direct competition with the lightning network = and sidechains for fees. Miners, ask yourselves if you think you'll earn = more fees with 1 MB blocks and more off-chain transactions or with 8 MB = blocks and more on-chain transactions=E2=80=A6

Miners are NOT in direct competition with the lightning = network and sidechains - these claims are patently false. I recommend = you take a look at these ideas and understand them a little better = before trying to make any such claims. Again, I do not work for = Blockstream=E2=80=A6and my agenda in this post is not to promote either = of these ideas=E2=80=A6but with all due respect, I do not think you = properly understand them at all.

The longer this debate drags on, the more I agree with BIP = 100 and Jeff Garzik because the core devs are already being influenced = by outside forces and should not have complete control of the blocksize. = It's also interesting to note that most of the mining hashpower is = already voting for 8MB blocks BIP100 style. =  

I don=E2=80=99t think the concern here is so much that = some people want to increase block size. It=E2=80=99s the *way* in which = this change is being pushed that is deeply problematic.

On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
You deeply = disappoint me, Mike.

Not only do you misrepresent many cogent, well thought out = positions from a great number of people who have published and posted a = number of articles detailing an explaining in-depth technical = concerns=E2=80=A6you also seem to fancy yourself more capable of reading = into the intentions of someone who disappeared from the scene years ago, = before we even were fully aware of many things we now know that bring = the original =E2=80=9Cplan=E2=80=9D into question.

I ask of you, as a = civilized human being, to stop doing this divisive crap. Despite your = protestations to the contrary, YOU are the one who is proposing a = radical departure from the direction of the project. Also, as several of = us have clearly stated before, equating the fork of an open source = project with a fork of a cryptoledger is completely bogus - there=E2=80=99= s a lot of other people=E2=80=99s money at stake. This isn=E2=80=99t a = democracy - consensus is all or nothing. The fact that a good number of = the people most intimately familiar with the inner workings of = Satoshi=E2=80=99s invention do not believe doing this is a good idea = should give you pause.

Please stop using Bitcoin as your own political = football=E2=80=A6for the sake of Bitcoin=E2=80=A6and for your own sake. = Despite your obvious technical abilities (and I sincerely do believe you = have them) you are discrediting yourself and hurting your own = reputation.


- Eric

On Aug 15, 2015, at 10:02 AM, Mike Hearn via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>= wrote:

Hello,

As = promised, we have released Bitcoin XT 0.11A which includes the bigger = blocks patch set. You can get it from

     https://bitcoinxt.software/

I feel sad that it's = come to this, but there is no other way. The Bitcoin Core project has = drifted so far from the principles myself and many others feel are = important, that a fork is the only way to fix things.

Forking is a natural = thing in the open source community, Bitcoin is not the first and won't = be the last project to go through this. Often in forks, people say there = was insufficient communication. So to ensure everything is crystal clear = I've written a blog post and a kind of "manifesto" to describe why this = is happening and how XT plans to be different from Core (assuming = adoption, of course).

The article is here:

    https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d2= 2c1

It makes no attempt to be neutral: this explains things from = our point of view.

The manifesto is on the website.

I say to all developers on this list: = if you also feel that Core is no longer serving the interests of Bitcoin = users, come join us. We don't bite.

_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>


_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>


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

= --Apple-Mail=_5F12ACE6-10D0-4EA9-91D4-ED691C3E3E65-- --Apple-Mail=_9EB5D894-B637-4D65-A9E1-6B5C8D35C675 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVz8ZBAAoJEJNAI64YFENUqQsP/A3widja6W7mgYKM+wwoGUxh cqSFfYTZ/q2GV5ID389308MYCmzgPkDD5P/SVjgSbyizzy8nGi67Tx7KGWx+xjOv Dki4SlHLaMCQxmZBf6qqPo4g6n8YHEHosYtr9ZaCml6912DwtcRHR9sDIcE9EAo0 zShk0Hdblti8dmEiyExFpWfveSb8Q6pEK1OQVpsDIEGVLYN92iwpjiFba+aFRRkW OJjIFKVYbxZq1CZUiPLs1ktbtoDlWXAlPWjXnrK6XI7MA8sbIhdsKF3CO9ofDQts Q6w7TE0XoC2IPI5smAvjV8bKUpzSOLIfroATW3XpOGt/i+5Uk4xzx78OFenBuW+/ p0gOoRdnlwtK/mLLgo9In2S+5MB4n1crUW80xAIJLirxGBQVq/2OyYrt9HiBQqYz iU7XmYx/nRDTU3kCFvG7oWpY9jpEur1wPUYhU1kBWqzciO+EsIykIrbJ05p9yeRz JcAjY6Oq/etlxfqF3iFX9TjUcVow87VINroxc39xi883yIbpcFIHituzHKJ98P4f Ec3oMBbzPoY620OmYI+591yy+CQRb1+KjKh8i7VLgrg+Wmvj7EIZaIpKX+kKLY3T iRBUFSmhGlT7FT/viZa/iGQa8w3j6/JBppzh6JJpaC7uGVCia+4MW4Re7wrs4esQ Gi5VTswkikDRmE9zPPDH =qr6i -----END PGP SIGNATURE----- --Apple-Mail=_9EB5D894-B637-4D65-A9E1-6B5C8D35C675--