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
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C1A74483
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 03:49:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE1C77C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 03:49:09 +0000 (UTC)
Received: from mail-qk0-f178.google.com ([209.85.220.178]) by
mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id
0LnAbb-1YfWC80hav-00hO54 for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 05:49:09 +0200
Received: by qkfc129 with SMTP id c129so14173781qkf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jul 2015 20:49:08 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.24.226 with SMTP id 95mr67621056qky.74.1438228148338;
Wed, 29 Jul 2015 20:49:08 -0700 (PDT)
Received: by 10.96.226.68 with HTTP; Wed, 29 Jul 2015 20:49:08 -0700 (PDT)
In-Reply-To: <COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
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>
Date: Wed, 29 Jul 2015 20:49:08 -0700
Message-ID: <CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: "Raystonn ." <raystonn@hotmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:70lCwyV3vp3E+49BYJuC5V3aNA7bX/x1KM/Ouz5Aht/yVPKsBeU
QQPaIvQi2M6/5L6ZO/eZjRTnzFz/5lhJRVg+qakbiyxofkWjhrcHDyChWvUcyC16sPJIGfa
xmkTN9/x169QkV22bNnUVRqXjS2B279vWHyAPsOQ8bXy/BKf4RXBwnyfkpv8tZkNfVZQzxA
G/qJguvP4ywFyUohaQsNw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ygpIVONhcvQ=:tKjDdH+mjURvzbSc0lOkvC
XrnTpLImWgJ0rILOwh+nN8F7GXvG81Y7N0LEH6eKVphQBuuL3n9FqW6+XLIjXuDNU8M6ms49p
aFtpSt/dgpkeeAxy5Ub41fj9Q6pnPcMC9fwbjHFIpJXOnrnG0t0/hbufkiRmdCLemWSXIW8+C
zb9qMPI0ngxPw0JobXc3nVZsu3ZeWkgaBPKzqzeg7bgZqe33Nm/xKDhhoXL0N1m7ZTuVOMT3o
vyJbGcX2PHTgeufGclQ3NNK76pOfEsbyR1hiL3VWtI3uF2e3760dRlJIU6keavSypoaKuly6t
pgxI8REtZS3ejAbB4XA9fz3suongTbZxTFoPO1IDSubhM/MSIce1hA8qt/VEAOQRjyAI6CILT
sm3lxaCpMgebbu3elxwoY3E2NYK204OKSHdpOkMHK9FZFpjnFNfDMKj7NJMOjO2LxhV/25Eun
4beqNqFwMGYio5O7lPlf/O5LywZ527wxK9qS4bMkxk9YW/qUIsVXQ7lpP2/9W8ZHXap0fsbmN
p0Dk6qhpcmKaP/hintUYBED4G8oW8JlWrNn/tkZCCUj2wOKl5NO2B9zGLwSqsd79D/kuWLLXy
XYbnfbxi3KP1QNnTT5V1Ef4lJ0zPeClxMgIcfiUVYlgpWrg0FJRIPDVoGuAWldT7BLAaEcxac
iLmvnEw1ozQwQ/GVK9fmqy8LJ5ValrhkwgPGoclFEMW1vHw==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 03:49:10 -0000
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
|
