path: root/8d/a52d50f7e52b458352931481d43d20c3d6ff56

Return-Path: <andrewlecody@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 62E7D40D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 04:52:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com
	[209.85.214.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6BA78116
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 04:52:00 +0000 (UTC)
Received: by obdeg2 with SMTP id eg2so23025586obd.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 21:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc:content-type;
	bh=FOo6p9PcgCMN9ZTQjUMxAmn5KnMGk4EKwAU/ronnm6M=;
	b=hnbDxsKMYwym9+sgKbKsaH3nksGbn8Yy1sZnT1nSMo7gyzmTWHzzDGjX3FFsAOdoC7
	dKn97ncFj2vUs5IRX/A3KUpVVOuRtWJhqH/NM49alcuGzAWan8wRKVYryWR4eOkhDaaK
	5XAxW3TKALJnv1VRA0lHsYRbeDzN/eeStz4zSL084jcphznKmFP3vv1tLvLBBLiUuWm5
	c4xLi6suyZwRgzhjBYO1ucvDVDnhbTBVw8r3Eps4osmvTwHkdibafiGm9nI7knIJmaoD
	OWAa6H5HZFFrTxOqG2OHZmCMmRQI/PSYCanbjBfBuXcm3P4u9U/hAbw2Cw+G4Ksfcjbk
	mYZQ==
X-Received: by 10.60.134.19 with SMTP id pg19mr45655115oeb.12.1438231919729;
	Wed, 29 Jul 2015 21:51:59 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
From: Andrew LeCody <andrewlecody@gmail.com>
Date: Thu, 30 Jul 2015 04:51:50 +0000
Message-ID: <CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>, "Raystonn ." <raystonn@hotmail.com>
Content-Type: multipart/alternative; boundary=047d7b471dbeae37f9051c1076c4
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
	isn'ttemporary
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 04:52:02 -0000

--047d7b471dbeae37f9051c1076c4
Content-Type: text/plain; charset=UTF-8

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.

----

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.

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.

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

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.

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.

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

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

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.

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.

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

On Wed, Jul 29, 2015 at 10:49 PM Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.
>
> 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.
>
> 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.
>
> Adam
>
> 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.
>
>
> 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!
> >
> >
> > 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.
> >
> >> ... 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.
> >
> >
> > 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.
> >
> >
> > -----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
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Raystonn, I'm aware that you're addressing your question to Greg
> > Maxwell, however a point you keep stating as fact calls for reference:
> >
> > On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
> > [snip]
> >>
> >> 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?
> >
> > 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!
> >
> >> Modern economic study has shown that liquidity moves to the
> >> location of least friction.
> >
> > Modern economic study? Can you please provide a link or reference to
> > the study you are referring to.
> >
> > "liquidity moves to the location of least friction"
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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
> >
> > iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
> > RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
> > h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
> > Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
> > YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
> > BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
> > =lQvy
> > -----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
>

--047d7b471dbeae37f9051c1076c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

--047d7b471dbeae37f9051c1076c4--