path: root/1a/59df27008e23a3920d599bc0c6c447efdb0a72

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9EE4F273
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 09:15:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com
	[209.85.220.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7151C10A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 09:15:29 +0000 (UTC)
Received: by pacan13 with SMTP id an13so20899608pac.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 02:15:29 -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=UvBI35AKyyVJstZXyGHBPEw54JkBLqU+Esck/C1aDAg=;
	b=STTVOvIyZp8iPkLtPZemREcoDxneE2rSiXl1/xJVSFKujNP1pSOLnv+2JL9nZaPy7r
	5Zv/PuQBTmYoAhzd9e5x8WoZeqH5VeRw2mgTJI5MHSg1uqcTbu/NLr5jFJZ9nWolZL0S
	fF6weLhqoi4jThHyA+CIQBQGeRjM/H8zhfMeoaizMfpUp/Jm7WqQRm1GAPMBqgLqXE2+
	I6rH6fmDyJxNFLtllCh2PiKPU4ACOTO3+oFJdEjLMTrwUQCFy60GYqPhG/4MjmfBFoIU
	RL2SpzyniUP5rzhhF12ssX3+CyVE18757aoEAfnGYFLQYSmXTFrfn3+XsOG6aSqqzTuQ
	SyXA==
X-Received: by 10.66.66.166 with SMTP id g6mr105590077pat.157.1438247728935;
	Thu, 30 Jul 2015 02:15:28 -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 o7sm1033403pdi.16.2015.07.30.02.15.26
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 30 Jul 2015 02:15:28 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_9BF7F32D-4F3C-4FD9-9362-DA431332B06D";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com>
Date: Thu, 30 Jul 2015 02:15:25 -0700
Message-Id: <4452AA7F-020C-4457-AAA0-0F6871C22458@gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
	<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
	<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
	<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
	<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
	<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
	<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
	<55B94FAD.7040205@mail.bihthai.net>
	<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
	<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
	<CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
	<74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com>
To: Andrew LeCody <andrewlecody@gmail.com>
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,
	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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
	temporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 30 Jul 2015 09:15:30 -0000


--Apple-Mail=_9BF7F32D-4F3C-4FD9-9362-DA431332B06D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jul 30, 2015, at 1:21 AM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>=20
> I usually avoid troll-infested Dunning-Kruger-gone-wild fests like =
reddit, so I=E2=80=99ll leave that to others.
>=20
> But I do want to clarify a couple things here, though, Andrew.
>=20
> First of all, the issue is not about whether it is affordable for a =
highly motivated, technically skilled person to continue running a node =
even if we increase block size by a factor of X. This misses the point =
for at least a couple reasons:
>=20
> - Regardless of what that X is, it isn=E2=80=99t really going to be =
what makes this technology accessible to the masses. We would likely =
need the X to be in the thousands before we start to really take on =
players like Visa. Despite what people might have thought in 2009, it =
turns out Bitcoin is probably pretty ill-suited as a database in which =
to store the entire transaction history of the entire world. It=E2=80=99s =
looking to be more of a censorship-resistant dispute resolution =
mechanism that provides very well-defined settlement guarantees with the =
potential for encoding complex rules. It=E2=80=99s possible to build =
higher level tiers on top of it that DO support high volume transaction =
processing WITHOUT costing thousands of times more, and these approaches =
are looking quite promising. However, it doesn=E2=80=99t seem very many =
people in this space quite grasp this paradigm shift yet.
>=20
> - What matters is not how a relatively small number of =
well-intentioned people in the network behave. What matters is how the =
network behaves as a whole=E2=80=A6and a number of the people most =
intimately familiar with the inner workings of the system (some of whom =
are in this thread) think that given what we now today about the Bitcoin =
network, increasing block size externalizes costs in dangerous ways. =
Remember that total cost includes not just equipment costs but also =
things like block propagation latency and specifically identified =
security risks. Some of these security risks were only appreciated =
relatively recently and were completely unknown in 2009.
>=20

Secondly, there are a few well-identified problems with the protocol =
design that might be possible to fix that would perhaps allow us to =
remove the block size limit entirely without sacrificing security. I =
listed the ones that come to my mind at the beginning of this thread. I =
EMPHATICALLY state that in no way am I fundamentally opposed to raising =
or even getting rid of the block size limit. But I believe these =
problems should be addressed first. And it=E2=80=99s easier to address =
them and tackle them if we don=E2=80=99t have to worry about potential =
security risks and higher costs that come from insisting on bigger =
blocks right now.

- Eric


>> On Jul 29, 2015, at 9:51 PM, Andrew LeCody via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> tl;dr
>> $100 worth of hardware and $1/mo of expenses, should be able to run a =
full
>> Bitcoin node until 2020 with BIP101-size blocks.
>>=20
>> ----
>>=20
>> I got into Bitcoin in the summer of 2010. I'm not a cryptographer, up =
until
>> recently my profession has been as a server administrator or systems
>> engineer.
>>=20
>> I'd like to take a second to address the concern that larger blocks =
would
>> make it harder to run a full node on limited hardware and would =
therefore
>> hurt decentralization. I run two nodes today, one on server-grade =
hardware
>> at a datacenter and another on a mini-ITX Atom (dual core) system at =
my
>> home.
>>=20
>> I detailed the operational costs of my home node today on reddit:
>> =
https://www.reddit.com/r/Bitcoin/comments/3f0h8e/mike_h_shuts_down_eric_ls=
_attempt_to_rewrite/ctkigpr
>>=20
>> If I was a new user, wanting to run a full node. The most cost =
effective
>> way would likely be with a Raspberry Pi 2 and a 2TB external HDD. =
Total
>> cost about $100, including charger, microSD card, etc. That is less =
than
>> the cost of a TREZOR hardware wallet. As far as home projects go, not
>> terribly expensive.
>>=20
>> Next, it will need power. According to the Wikipedia article, the rpi =
2
>> model B uses 3.5 watts of power max. The 2TB external drive will draw =
about
>> 5 watts at max. That's a total of 8.5 watts or 6.205 Kwh per month. =
In my
>> area (North Texas) power is about $0.10/Kwh, which means my little =
node
>> costs $0.62 per month in power.
>>=20
>> Last, lets look at bandwidth. It's difficult to quantify bandwidth =
cost in
>> the same way because this is a home connection, mainly because I =
don't know
>> how to price in the loss of enjoyment if the system impacts my =
Internet
>> usage to a noticeable degree. Luckily, I have some real world data =
from my
>> existing home node. Here is the last month:
>> http://imgur.com/YmJwQpN
>>=20
>> This system averages 120 Kbps in and 544 Kbps out. Note, this data is
>> somewhat skewed, because the system is also used for seeding torrents =
of
>> various open source projects. The Bitcoin node itself is typically
>> connected to about 20 peers at any given time (maxconnections=3D20).
>>=20
>> Subjectively, my wife and I have never noticed any degradation of
>> performance due to my home server using too much bandwidth. I think =
it's
>> safe to say that I can treat the bandwidth is uses as effectively =
free,
>> since it's piggybacking on a connection I would be paying for even if =
I was
>> not running a Bitcoin node. The bandwidth usage of this Bitcoin node =
could
>> increase significantly, without any noticeable impact. If it did, I =
could
>> always lower maxconnections back to 8.
>>=20
>> The only real constraint seems to be hard drive space, as the full
>> blockchain and indexes take up about 50GB of space currently. If =
BIP101 is
>> implemented, 2TB of storage should be enough for me to continue =
running my
>> hypothetical $100 node until about 2020.
>>=20
>> It seems to me that at least for the next 5 years, the "small =
devices" of
>> today can easily run Bitcoin nodes with BIP101-size blocks, with very
>> little operational cost.
>>=20
>> If anyone would like more detailed data on my existing nodes, please =
let me
>> know and I'll attempt to provide it (so long as it doesn't impact my
>> privacy of course).
>>=20
>> On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>>> I dont think people consider other blockchains as a competitive
>>> threat.  A PoW-blockchain is a largely singleton data structure for
>>> security reasons (single highest hashrate), it is hard for an
>>> alternative chain to bootstrap or provide meaningful security.
>>> Secondly the world largely lacks expertise to maintain a blockchain =
to
>>> bitcoin's security level, perhaps you can see a hint of this in the
>>> recently disclosed security vulnerability by Pieter Wuille and =
Gregory
>>> Maxwell.  Calls to this as an argument are not resonating and =
probably
>>> not helping your argument.  Bitcoin has security properties, and a
>>> competing system cant achieve better properties by bypassing =
security,
>>> any blockchain faces the same fundamental security / =
decentralisation
>>> limitations.
>>>=20
>>> Secondly Bitcoin can obviously compete with itself with different
>>> parameters and defacto *does* today.  I think it is a safe estimate
>>> that > 99% of Bitcoin transactions right now are happening in =
Bitcoin
>>> related systems with various degrees of audit, reconciliation,
>>> provable reserves etc.  I think we can expect this to continue and
>>> become more secure via more reconciliation, and longer term via
>>> lightning or Bitcoin sidechains with different parameters.  It is a
>>> different story to have a single central system (Bitcoin with
>>> parameters changed to the point of centralisation failure) vs having
>>> multiple choices, because some transactions can more easily use
>>> relatively centralised systems (eg micropayments), and more
>>> interestingly the combination of a secure and decentralised layer 1
>>> plus choices of less decentralised layer 2 options, can be =
interesting
>>> because the layer 2 is provided cover from attack.  There is less to
>>> be gained by attacking relatively centralised layer 2 because any
>>> payments at risk of policy abuse (which is typically a small subset)
>>> can easily switch to layer 1.  That in itself makes layer 2
>>> transactions also less susceptible to policy abuse.  Further =
lightning
>>> it appears from work so far should add significant scale while
>>> retaining trustlessness and a good degree of decentralisation.
>>>=20
>>> Finally you seem to be focusing on "artificial" limits where that is
>>> not the issue under consideration.  The limits are technical and
>>> relating to decentralisation and security.  I wont go over them =
again
>>> as this topic has been covered many times in recent months.  Any =
chain
>>> that tried to go to extreme parameters (very low block intervals, or
>>> very large blocksizes) would have the same decentralisation problems
>>> as Bitcoin would if it did the same thing.  There are a number of =
alt
>>> coins that have failed as a result of poor parameter choices, there
>>> are inherent security limits.
>>>=20
>>> Adam
>>>=20
>>> ps Etiquette note for yourself and others: please dont be repetitive
>>> or attempt to be forceful.  Many people have spent many years
>>> understanding this very complex system, from my own experience it is
>>> rare indeed to think of an entirely new concept or analysis, that
>>> hasnt' been long considered and put to bed 3 or 4 years ago.
>>> Thoughtful polite and constructive comments are welcome but I
>>> recommend to not start from an assumption that you have a clear and
>>> better insight than the entire technical community, because I have =
to
>>> say from my own experience that is very rarely the case.  It can be
>>> useful to test theories on #bitcoin IRC channel to find out what has
>>> been already concluded, find the references and avoid having to have
>>> that hashed out on this list which is trying to be focussed on
>>> technical solutions.
>>>=20
>>>=20
>>> On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>> Cheapest way to send value? Is this what Bitcoin is trying to do? =
So
>>>>> all of the smart contract, programmable money, consensus coding =
and
>>>>> tremendous developer effort is bent to the consumer demand for =
cheaper
>>>>> fees. Surely thou jests!
>>>>=20
>>>>=20
>>>> These other features can be replicated into any alternative =
blockchain,
>>>> including those with lower fees.  In the open-source world of
>>>> cryptocurrency, no feature will remain a value-add for very long =
after it
>>>> has been identified to be such.  Anything adding value will quickly =
be
>>>> absorbed into competing alternative blockchains.  That will leave
>>> economic
>>>> policy as the distinguishing factor.
>>>>=20
>>>>> ... it is not the case ... that reluctance to concede
>>>>> blocksize is an attempt to constrain capacity. Greg Maxwell =
thoroughly
>>>>> explained in this thread that the protocol's current state of
>>>>> development relies on  blocksize for security and, ultimately, as =
a
>>>>> means of protecting its degree of decentralization.
>>>>=20
>>>>=20
>>>> A slow or lack of increase to maximum transaction rate will cause
>>> pressure
>>>> on fees.  Whether this is the desired goal is not relevant.  =
Everyone has
>>>> agreed this will be the outcome.  As to a smaller block size being =
needed
>>>> for additional decentralization, one must simply ask how much we =
are all
>>>> willing to pay for that additional decentralization.  It is likely =
that
>>> the
>>>> benefit thereto will have to be demonstrated by some power =
attacking and
>>>> destroying a less decentralized currency before the benefit of this
>>> feature
>>>> is given monetary value by the market.  Until then, value will =
bleed to
>>> the
>>>> network with the least friction, because it will have the greatest
>>> ability
>>>> to grow its network effect.  That means the blockchain with =
adequate
>>>> features and cheapest fees will eventually have the largest market =
share.
>>>>=20
>>>>=20
>>>> -----Original Message----- From: Venzen Khaosan
>>>> Sent: Wednesday, July 29, 2015 3:11 PM
>>>> To: Raystonn .
>>>> Cc: bitcoin-dev@lists.linuxfoundation.org
>>>> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam =
measure
>>>> isn'ttemporary
>>>>=20
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>=20
>>>> Raystonn, I'm aware that you're addressing your question to Greg
>>>> Maxwell, however a point you keep stating as fact calls for =
reference:
>>>>=20
>>>> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
>>>> [snip]
>>>>>=20
>>>>> How do you plan to address the bleeding of value from Bitcoin to
>>>>> alternative lower-fee blockchains created by the artificially-high
>>>>> bitcoin transaction fees when users begin looking for the cheapest
>>>>> way to send value?
>>>>=20
>>>> Cheapest way to send value? Is this what Bitcoin is trying to do? =
So
>>>> all of the smart contract, programmable money, consensus coding and
>>>> tremendous developer effort is bent to the consumer demand for =
cheaper
>>>> fees. Surely thou jests!
>>>>=20
>>>>> Modern economic study has shown that liquidity moves to the
>>>>> location of least friction.
>>>>=20
>>>> Modern economic study? Can you please provide a link or reference =
to
>>>> the study you are referring to.
>>>>=20
>>>> "liquidity moves to the location of least friction"
>>>>=20
>>>> This sounds like "econo-speak" and makes no sense. The definition =
of
>>>> Liquidity is the degree to which an asset/security can be bought or
>>>> sold in the market without affecting the price.
>>>>=20
>>>> That is why bitcoin is said to have low liquidity: buying or =
selling
>>>> only 100 BTC visibly affects the exchange price. You probably mean
>>>> "people like cheap fees", which is true, but as others have said,
>>>> because of Bitcoin's powerful features, they are willing to pay =
higher
>>>> fees and wait longer for transactions to execute.
>>>>=20
>>>> As for your public cross-examination of Greg Maxwell, your case =
seems
>>>> to  be made on the assumption that limiting the size of the =
blockchain
>>>> is an attempt to artificially raise tx fees, but it is not the case
>>>> (as you and others repeatedly argue) that reluctance to concede
>>>> blocksize is an attempt to constrain capacity. Greg Maxwell =
thoroughly
>>>> explained in this thread that the protocol's current state of
>>>> development relies on  blocksize for security and, ultimately, as a
>>>> means of protecting its degree of decentralization.
>>>>=20
>>>> Surely, this is an obvious concern even for those who are =
campaigning
>>>> for the hare-brained ideal of making Bitcoin a "faster, cheaper
>>>> alternative" to visa or paypal? If we lose decentralization, we =
lose
>>>> the whole thing, right? Incorrect or correct?
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>=20
>>>> iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
>>>> RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
>>>> h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
>>>> Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
>>>> YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
>>>> BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=3D
>>>> =3DlQvy
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20


--Apple-Mail=_9BF7F32D-4F3C-4FD9-9362-DA431332B06D
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

iQIcBAEBCgAGBQJVuestAAoJEJNAI64YFENUCPgP/0AX4iCM3QKBzili7R2PdwN9
sB0o2HIxpvqTF/ZAD9MHZOOnuOrJ4giLhWmFKyiFCcsfZk500aI1KGbq/aMH6gKk
J5z1tOyapAi/8E3ca5M5YnyuxLJJ6nxPXR/ip8r/LIwAHgkCgG2dJMogp7Wnvz4D
CRl2WRUfARGBs8CHhO1xCROVuMsdmNy/sTUp8jec7q0o4IOoq7n+R2AqsfF7T/ii
WrjxVMz1Ei1Bm65BOI6FLMPDgatp/ZpM8TWdF6IlTZYIthq8wZdD2sEVTs0Kq2xT
3t4nJfdjuFNu7ua9KjckhyniNplZiVcIdDAaUEIrO0hJP/mYLpUgpLr9xpyv5pvN
bsj1WyJsZEeba6hrrXHj3Zsaojr8cHhSJB/yDXzKJcJrjeSFYHb3vimheElWFoJ7
jFwByqsWWOW/WJFZ5RkudmIwtXn/dp2Fvz9kFW5JbsEpnqjo7/X9e2adPpGSR/08
CsN0Za6+f3V8QVgJUIvF2gDvvbWuRZx+hU/Z/Wr3vV0m3QGMnv2qvBgG5MDL4wXk
klAYS5NCo7VhZ0z4hkaICUnuKNaoMp+EGPwjYmOJXsAgWsx2ah9CSTWSDinjvYrF
tIpfdNVvER9Mo2xJ7ECKOxZMa7e3oRxKrzd/J5/3I37dBsoNTaDg5N325k0Jrp7v
Ms4F/RQnlhArwBUpABFX
=oYYH
-----END PGP SIGNATURE-----

--Apple-Mail=_9BF7F32D-4F3C-4FD9-9362-DA431332B06D--