path: root/76/18cc7146425b29a388dcff5ff443e064a34b08

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 864C5FF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 08:21:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com
	[209.85.192.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 668A98D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 08:21:06 +0000 (UTC)
Received: by pdbnt7 with SMTP id nt7so20684037pdb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 01:21:06 -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=i2qtKS/f1iggfje5rccLIhcEv4t7sp8IqYPM0kzm5Ho=;
	b=kwInZRcO3cq+lEI2+r1UehNP69nFNZZFz3DA7zJIgqBXSARzvZNgoEJDHxR5cdBBBq
	YLEA7UKpNBiEFUIMLzoDw6GPDq0xDa1uXCE0iLdItPh9kCys2+qI8+z0uBhARMkbq+WO
	6u5Xyui71wAwU3zJMZD86Wfoi3nGJHQqsmkANQ+osENt+6Pgv2O2f7j8g7ocTvOO+yCn
	VGYE7a6tJ6vcLTGP2fG5J+msxbkd7rBz/AyVNxpxOiNdeByqwpjDjWZLezbl9CP9M3Cm
	D+16I22mX8d9yiQqnWw7f5SnnvLILujb8JP7VMdJwjLKk0JEPwikrgxtm7gIGJih0Hcg
	RshA==
X-Received: by 10.70.103.98 with SMTP id fv2mr83164518pdb.9.1438244466117;
	Thu, 30 Jul 2015 01:21:06 -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 v3sm755654pdp.8.2015.07.30.01.21.03
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 30 Jul 2015 01:21:04 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
Date: Thu, 30 Jul 2015 01:21:02 -0700
Message-Id: <74767203-7F7A-4848-9923-DE1DE60A28B4@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>
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 08:21:07 -0000


--Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I usually avoid troll-infested Dunning-Kruger-gone-wild fests like =
reddit, so I=E2=80=99ll leave that to others.

But I do want to clarify a couple things here, though, Andrew.

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:

- 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.

- 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.


> 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


--Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262
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

iQIcBAEBCgAGBQJVud5uAAoJEJNAI64YFENUz/cQALrf9GmKH3pHTc8nLfqYxlNq
I2fnHEbVp7MdbXj0gLITBfXbajghrSNTeLaIVkV0h9wiRytUdIBEh/6nHtoMo4GL
0qlHuteapyeXYKyy2cWUw4GTEcNGM2X4AcBJzyj6h7ouJw+OaiXmTxe1ArrXZfea
9Rx63RBbXLeYY3w2lqw+JA/hmPnEr60IJhCYuXjq5MPGjK0+ms6MeryLj14aC1ut
LxXVBCEUOAv4WziCrNl4Co6QOLY+GFlXV0GoOmF1cY1xJiX/gd2suLZs1bJFsGyR
6VdXfTX7ccYxwebGjI3cBfo6zNAPWIfS9XgO5g1QwlEtrX1Y4NnT9hOO1KwfvENi
/5IGOWZKtm1aYS00CgQClhTyQ4cs9esI032gN6G4Wj4QmtjbtLdH1QEMl+VGoXcg
NT73fCDEvnSJVJGL7OosVIKOGZlgywfDnY1P6LbOzpnIK1n0EPSxxZXmshxsPoD8
9VxesunM6mX8zZInNayW+YATLBKYV0VvCJKc81qisOtqBCzGBgzjt9zh6RaoSUHh
X5+7L6pLhAKatDNyM11mAS+Yvw7QKcic7qfs1FBxYdZ3VWMw1p8WEssqmzvDG9XT
w4nkphYBkIcfw9zDUx3aWCqDJzyeRlRA48/gSTGlzl0UsTHT3U80kuCGV6xLKjAt
yTUH24tuy9Wx7ZZ/iW6z
=zED1
-----END PGP SIGNATURE-----

--Apple-Mail=_92CCBEA4-6237-4C46-9A6B-65935BBCC262--