summaryrefslogtreecommitdiff
path: root/fa/fbb63becda81c91940ed476c5f983325b8f8ae
blob: ecab2d9325222ab7278f98db2244496c7ce940d8 (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
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
242
243
244
245
246
247
248
249
250
251
252
253
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1Yqjkl-0000Az-E6
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 14:59:51 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.169 as permitted sender)
	client-ip=209.85.220.169; envelope-from=etotheipi@gmail.com;
	helo=mail-qk0-f169.google.com; 
Received: from mail-qk0-f169.google.com ([209.85.220.169])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yqjkj-0005eI-U9
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 14:59:51 +0000
Received: by qkhg7 with SMTP id g7so49609823qkh.2
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 08 May 2015 07:59:44 -0700 (PDT)
X-Received: by 10.140.41.148 with SMTP id z20mr5289819qgz.40.1431097184545;
	Fri, 08 May 2015 07:59:44 -0700 (PDT)
Received: from [192.168.1.28] (c-69-143-204-74.hsd1.md.comcast.net.
	[69.143.204.74])
	by mx.google.com with ESMTPSA id 93sm3735047qkx.38.2015.05.08.07.59.39
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 08 May 2015 07:59:43 -0700 (PDT)
Message-ID: <554CCF56.3000604@gmail.com>
Date: Fri, 08 May 2015 10:59:34 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Jeff Garzik <jgarzik@bitpay.com>
References: <554A91BE.6060105@bluematt.me>
	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>
	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>
	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>
	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>
	<554BA032.4040405@bluematt.me>
	<CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com>
	<CADJgMzti7ROH90APiwg4NOAT5+Av=4i295b8VN0sbSLr4+WWRw@mail.gmail.com>
	<CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
	<554BBDA2.7040508@gmail.com>
	<CAJHLa0NcxOHkrtW2=-JgfsXQJkCO8Ym7icBwMx_2RsaWcPBnTw@mail.gmail.com>
In-Reply-To: <CAJHLa0NcxOHkrtW2=-JgfsXQJkCO8Ym7icBwMx_2RsaWcPBnTw@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------070102000903090608040604"
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(etotheipi[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yqjkj-0005eI-U9
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 14:59:51 -0000

This is a multi-part message in MIME format.
--------------070102000903090608040604
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


This isn't about "everyone's coffee".  This is about an absolute minimum
amount of participation by people who wish to use the network.   If our
goal is really for bitcoin to really be a global, open transaction
network that makes money fluid, then 7tps is already a failure.  If even
5% of the world (350M people) was using the network for 1 tx per month
(perhaps to open payment channels, or shift money between side chains),
we'll be above 100 tps.  And that doesn't include all the
non-individuals (organizations) that want to use it.

The goals of "a global transaction network" and "everyone must be able
to run a full node with their $200 dell laptop" are not compatible.  We
need to accept that a global transaction system cannot be
fully/constantly audited by everyone and their mother.  The important
feature of the network is that it is open and anyone *can* get the
history and verify it.  But not everyone is required to.   Trying to
promote a system where the history can be forever handled by a low-end
PC is already falling out of reach, even with our miniscule 7 tps. 
Clinging to that goal needlessly limits the capability for the network
to scale to be a useful global payments system



On 05/07/2015 03:54 PM, Jeff Garzik wrote:
> On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <etotheipi@gmail.com
> <mailto:etotheipi@gmail.com>> wrote:
>  
>
>     (2) Leveraging fee pressure at 1MB to solve the problem is
>     actually really a bad idea.  It's really bad while Bitcoin is
>     still growing, and relying on fee pressure at 1 MB severely
>     impacts attractiveness and adoption potential of Bitcoin (due to
>     high fees and unreliability).  But more importantly, it ignores
>     the fact that for a 7 tps is pathetic for a global transaction
>     system.  It is a couple orders of magnitude too low for any
>     meaningful commercial activity to occur.  If we continue with a
>     cap of 7 tps forever, Bitcoin *will* fail.  Or at best, it will
>     fail to be useful for the vast majority of the world (which
>     probably leads to failure).  We shouldn't be talking about fee
>     pressure until we hit 700 tps, which is probably still too low. 
>
>  [...]
>
> 1) Agree that 7 tps is too low
>
> 2) Where do you want to go?  Should bitcoin scale up to handle all the
> world's coffees? 
>
> This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day --
> just for a single feed.  If you include relaying to multiple nodes,
> plus serving 500 million SPV clients en grosse, who has the capacity
> to run such a node?  By the time we get to fee pressure, in your
> scenario, our network node count is tiny and highly centralized.
>
> 3) In RE "fee pressure" -- Do you see the moral hazard to a
> software-run system?  It is an intentional, human decision to flood
> the market with supply, thereby altering the economics, forcing fees
> to remain low in the hopes of achieving adoption.  I'm pro-bitcoin and
> obviously want to see bitcoin adoption - but I don't want to sacrifice
> every decentralized principle and become a central banker in order to
> get there.
>


--------------070102000903090608040604
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    This isn't about "everyone's coffee".  This is about an absolute
    minimum amount of participation by people who wish to use the
    network.   If our goal is really for bitcoin to really be a global,
    open transaction network that makes money fluid, then 7tps is
    already a failure.  If even 5% of the world (350M people) was using
    the network for 1 tx per month (perhaps to open payment channels, or
    shift money between side chains), we'll be above 100 tps.  And that
    doesn't include all the non-individuals (organizations) that want to
    use it.<br>
    <br>
    The goals of "a global transaction network" and "everyone must be
    able to run a full node with their $200 dell laptop" are not
    compatible.  We need to accept that a global transaction system
    cannot be fully/constantly audited by everyone and their mother. 
    The important feature of the network is that it is open and anyone
    *can* get the history and verify it.  But not everyone is required
    to.   Trying to promote a system where the history can be forever
    handled by a low-end PC is already falling out of reach, even with
    our miniscule 7 tps.  Clinging to that goal needlessly limits the
    capability for the network to scale to be a useful global payments
    system <br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/07/2015 03:54 PM, Jeff Garzik
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJHLa0NcxOHkrtW2=-JgfsXQJkCO8Ym7icBwMx_2RsaWcPBnTw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Thu, May 7, 2015 at 3:31 PM, Alan
            Reiner <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:etotheipi@gmail.com" target="_blank">etotheipi@gmail.com</a>&gt;</span>
            wrote:<br>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> (2) Leveraging fee
                pressure at 1MB to solve the problem is actually really
                a bad idea.  It's really bad while Bitcoin is still
                growing, and relying on fee pressure at 1 MB severely
                impacts attractiveness and adoption potential of Bitcoin
                (due to high fees and unreliability).  But more
                importantly, it ignores the fact that for a 7 tps is
                pathetic for a global transaction system.  It is a
                couple orders of magnitude too low for any meaningful
                commercial activity to occur.  If we continue with a cap
                of 7 tps forever, Bitcoin <b>will</b> fail.  Or at
                best, it will fail to be useful for the vast majority of
                the world (which probably leads to failure).  We
                shouldn't be talking about fee pressure until we hit 700
                tps, which is probably still too low.  <br>
              </div>
            </blockquote>
            <div> [...]<br>
              <br>
            </div>
            <div>1) Agree that 7 tps is too low<br>
              <br>
            </div>
            <div>2) Where do you want to go?  Should bitcoin scale up to
              handle all the world's coffees?  <br>
            </div>
            <div><br>
            </div>
            <div>This is hugely unrealistic.  700 tps is 100MB blocks,
              14.4 GB/day -- just for a single feed.  If you include
              relaying to multiple nodes, plus serving 500 million SPV
              clients en grosse, who has the capacity to run such a
              node?  By the time we get to fee pressure, in your
              scenario, our network node count is tiny and highly
              centralized.<br>
              <br>
            </div>
            3) In RE "fee pressure" -- Do you see the moral hazard to a
            software-run system?  It is an intentional, human decision
            to flood the market with supply, thereby altering the
            economics, forcing fees to remain low in the hopes of
            achieving adoption.  I'm pro-bitcoin and obviously want to
            see bitcoin adoption - but I don't want to sacrifice every
            decentralized principle and become a central banker in order
            to get there.<br>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------070102000903090608040604--