summaryrefslogtreecommitdiff
path: root/1d/f45e7158e07a9fd81ef30888fa9a96820f082b
blob: cb7d34b643f9e7dc57b711bad156d2d73d757284 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
Return-Path: <raystonn@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5EB8F49C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 23:11:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from COL004-OMC4S14.hotmail.com (col004-omc4s14.hotmail.com
	[65.55.34.216])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E705379
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 23:11:13 +0000 (UTC)
Received: from COL131-DS9 ([65.55.34.199]) by COL004-OMC4S14.hotmail.com over
	TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); 
	Wed, 29 Jul 2015 16:11:13 -0700
X-TMN: [Nh13W06CDkmCFzru6f32Vun1O29TCEnN]
X-Originating-Email: [raystonn@hotmail.com]
Message-ID: <COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
From: "Raystonn ." <raystonn@hotmail.com>
To: <venzen@mail.bihthai.net>
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>
In-Reply-To: <55B94FAD.7040205@mail.bihthai.net>
Date: Wed, 29 Jul 2015 16:10:56 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
X-OriginalArrivalTime: 29 Jul 2015 23:11:13.0772 (UTC)
	FILETIME=[DD4E0AC0:01D0CA53]
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, STOX_REPLY_TYPE,
	TVD_FINGER_02 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@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: Wed, 29 Jul 2015 23:11:14 -0000

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