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
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DD58D4D3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Aug 2015 23:05:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com
[209.85.192.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D477E13B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Aug 2015 23:05:24 +0000 (UTC)
Received: by qgj62 with SMTP id 62so71665637qgj.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 08 Aug 2015 16:05:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=content-type:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=xuYYYdjKATOWfsAYG0YLcvkCliMHzuUqLsXZ7byxoyI=;
b=BuxRItbphzr4oqaDFp8va8fVFIKAFkJhQ75uJ5iW3lCr5XEq/IpZAe1jNa5nrdZTAx
2UJweZJd7DnWPWucbKcvZeOi0pU/V1yvSXKRI+AejooEZe8gpW3eG9HgD4RIyQMx4d5g
WZ4E5FmtOad3qS00i9GZt6Kg7v3gB/542Op++z9L2pVR0P/DAVMCP77whp8LXzjHJcwD
hLlCfADgdwJHL0c5HK900PqiYt9nMGP2y8d4PnRPOIZdYCJuV1+cwx5Cot1+tsR7ZrBR
aXRj/wwMPHOilCdMe3gpEdJeSLl2sHSZY7yEropy/89HCxFEXHM7ppFmqA4HZX+aZpoU
09WQ==
X-Received: by 10.140.104.45 with SMTP id z42mr25594829qge.76.1439075123909;
Sat, 08 Aug 2015 16:05:23 -0700 (PDT)
Received: from [192.168.1.48] (ool-689495a2.dyn.optonline.net.
[104.148.149.162]) by smtp.gmail.com with ESMTPSA id
w68sm7283881qge.18.2015.08.08.16.05.23
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 08 Aug 2015 16:05:23 -0700 (PDT)
Content-Type: multipart/alternative;
boundary=Apple-Mail-01E03DB6-C43C-442A-B823-BA119A6C00A8
Mime-Version: 1.0 (1.0)
From: Alex Morcos <morcos@gmail.com>
X-Mailer: iPad Mail (11B511)
In-Reply-To: <CAGLBAhcfUv0ptwczgCkgwVxo7d=pK4GLowkwV2viqAbq6vRaDQ@mail.gmail.com>
Date: Sat, 8 Aug 2015 19:05:29 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <CFD5F030-D518-4998-93BD-A19054C54058@gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CABsx9T10y6-=c7Qg6jysnf38wRX3NA3wWozxGfE+mEYJvPeqWA@mail.gmail.com>
<CABm2gDpwMQzju+Gsoe3qMi60MPr7OAiSuigy3RdA1xh-SwFzbw@mail.gmail.com>
<2586092.4ZtH253X8E@coldstorage>
<CALqxMTGDET0dEuw9bi=LBXF8jiuLdoPoGYaDCPpXtPvqeDW30A@mail.gmail.com>
<CAGLBAhcfUv0ptwczgCkgwVxo7d=pK4GLowkwV2viqAbq6vRaDQ@mail.gmail.com>
To: Dave Scotese <dscotese@litmocracy.com>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
MIME_QP_LONG_LINE,
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] Fees and the block-finding process
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: Sat, 08 Aug 2015 23:05:26 -0000
--Apple-Mail-01E03DB6-C43C-442A-B823-BA119A6C00A8
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
I agree
There are a lot of difficult technical problems introduced by insufficient b=
lock space that are best addressed now. As well as problems that scale will=
exacerbate like bootstrapping that we should develop solutions for first. =20=
Sent from my iPad
> On Aug 8, 2015, at 6:45 PM, Dave Scotese via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>=20
> I see value in lowering the block size or leaving it where it is. We expec=
t to run out of space, and I think it's a good idea to prepare for that, rat=
her than avoid it. When we run out of space and the block size is low, we w=
ill see problems. If we raise the block size, we will NOT see these problem=
s until bitcoin is bigger and more important and the pressure is higher.
>=20
> Someone mentioned that when the backlog grows faster than it shrinks, that=
is a real problem. I don't think it is. It is a problem for those who don=
't wait for even one confirmation, but backlogs in the past have already sta=
rted training users to wait for at least one confirmation, or go off-chain. =
I am comfortable leaving those zero-conf people in a little bit of trouble.=
Everyone else can double-spend (perhaps that's not as easy as it should be=
in bitcoin core) and use a higher fee, thus competing for block space. Yes=
, $5 transactions suck, but $0.15 is not so bad and about twice the average r=
ight now.
>=20
> Meanwhile, the higher fees everyone starts feeling like paying, along with=
the visibility of the problems caused by full-blocks, will provide excellen=
t justification and motivation for increasing the limit. My favorite thing t=
o do is to have a solution ready for a problem I expect to see, see the prob=
lem (so I can measure things about it) and then implement the solution.
>=20
> In my experience, the single biggest reason not to run a full node has to d=
o with starting from scratch: "I used to run a full node, but last time I ha=
d to download the full blockchain, it took ___ days, so I just use (some wal=
let) now." I think that has been improved with headers-first, but many peop=
le don't know it.
>=20
> I have some ideas how a "full node" could postpone being "full" but still b=
e nearly completely operational so that the delay between startup and having=
a full blockchain is nearly painless. It involves bonded representation of=
important not-so-large pieces of data (blocks that have my transactions, th=
e complete UTXO as of some height, etc.). If I know that I have some btc, I=
could offer it (say, 100 or 1000 transaction fees' worth) to anyone who wil=
l guarantee good data to me, and then when I have the whole blockchain, I wi=
ll know if they were honest. If done right, the whole network could know wh=
ether or not they were honest and enforce the bond if they weren't. Credit t=
he Lightening paper for parts of this idea.
>=20
> Dave
>=20
>> On Fri, Aug 7, 2015 at 4:06 PM, Adam Back via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>> Please try to focus on constructive technical comments.
>>=20
>> On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > What will the backlash be when people here that are pushing for "off-ch=
ain-
>> > transactions" fail to produce a properly working alternative, which
>> > essentially means we have to say NO to more users.
>>=20
>> But > 99% of Bitcoin transactions are already off-chain. There are
>> multiple competing companies offering consumer & retail service with
>> off-chain settlement.
>>=20
>> I wasnt clear but it seemed in your previous mail that you seemed to
>> say you dont mind trusting other people with your money, and so
>> presumably you are OK using these services, and so have no problem?
>>=20
>> > At this time and this size of bitcoin community, my personal experience=
(and
>> > I've been part of many communities) saying NO to new customers
>>=20
>> Who said no to anything? The systems of off-chain transfer already
>> exist and are by comparison to Bitcoins protocol simple and rapid to
>> adapt and scale.
>>=20
>> Indications are that we can even do off-chain at scale with Bitcoin
>> similar trust-minimisation with lightning, and duplex payment
>> channels; and people are working on that right now.
>>=20
>> I think it would be interesting and useful for someone, with an
>> interest in low trust, high scale transactions, to work on and propose
>> an interoperability standard and API for such off-chain services to be
>> accessed by wallets, and perhaps periodic on-chain inter-service
>> netting.
>>=20
>> Adam
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
>=20
> --=20
> I like to provide some work at no charge to prove my value. Do you need a t=
echie? =20
> I own Litmocracy and Meme Racing (in alpha).=20
> I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
> I also code for The Dollar Vigilante.
> "He ought to find it more profitable to play by the rules" - Satoshi Nakam=
oto
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail-01E03DB6-C43C-442A-B823-BA119A6C00A8
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><div>I agree</div><div>There are a lot=
of difficult technical problems introduced by insufficient block space that=
are best addressed now. As well as problems that scale will exacerbat=
e like bootstrapping that we should develop solutions for first. </div=
><div><br></div><br>Sent from my iPad</div><div><br>On Aug 8, 2015, at 6:45 P=
M, Dave Scotese via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br><br=
></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><div><div><div><div>I=
see value in lowering the block size or leaving it where it is. We expect t=
o run out of space, and I think it's a good idea to prepare for that, rather=
than avoid it. When we run out of space and the block size is low, we=
will see problems. If we raise the block size, we will NOT see these p=
roblems until bitcoin is bigger and more important and the pressure is highe=
r.<br><br></div>Someone mentioned that when the backlog grows faster than it=
shrinks, that is a real problem. I don't think it is. It is a p=
roblem for those who don't wait for even one confirmation, but backlogs in t=
he past have already started training users to wait for at least one confirm=
ation, or go off-chain. I am comfortable leaving those zero-conf peopl=
e in a little bit of trouble. Everyone else can double-spend (perhaps t=
hat's not as easy as it should be in bitcoin core) and use a higher fee, thu=
s competing for block space. Yes, $5 transactions suck, but $0.15 is n=
ot so bad and about twice the average right now.<br><br></div>Meanwhile, the=
higher fees everyone starts feeling like paying, along with the visibility o=
f the problems caused by full-blocks, will provide excellent justification a=
nd motivation for increasing the limit. My favorite thing to do is to h=
ave a solution ready for a problem I expect to see, see the problem (so I ca=
n measure things about it) and then implement the solution.<br><br></div>In m=
y experience, the single biggest reason not to run a full node has to do wit=
h starting from scratch: "I used to run a full node, but last time I had to d=
ownload the full blockchain, it took ___ days, so I just use (some wallet) n=
ow." I think that has been improved with headers-first, but many peopl=
e don't know it.<br><br></div><div>I have some ideas how a "full node" could=
postpone being "full" but still be nearly completely operational so that th=
e delay between startup and having a full blockchain is nearly painless.&nbs=
p; It involves bonded representation of important not-so-large pieces of dat=
a (blocks that have my transactions, the complete UTXO as of some height, et=
c.). If I know that I have some btc, I could offer it (say, 100 or 100=
0 transaction fees' worth) to anyone who will guarantee good data to me, and=
then when I have the whole blockchain, I will know if they were honest.&nbs=
p; If done right, the whole network could know whether or not they were hone=
st and enforce the bond if they weren't. Credit the Lightening paper f=
or parts of this idea.<br></div><div><br></div>Dave<br></div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Fri, Aug 7, 2015 at 4:06 PM, A=
dam Back via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundat=
ion.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please try to=
focus on constructive technical comments.<br>
<br>
On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev<br>
<span class=3D""><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> What will the backlash be when people here that are pushing for "off-ch=
ain-<br>
> transactions" fail to produce a properly working alternative, which<br>=
> essentially means we have to say NO to more users.<br>
<br>
</span>But > 99% of Bitcoin transactions are already off-chain. The=
re are<br>
multiple competing companies offering consumer & retail service with<br>=
off-chain settlement.<br>
<br>
I wasnt clear but it seemed in your previous mail that you seemed to<br>
say you dont mind trusting other people with your money, and so<br>
presumably you are OK using these services, and so have no problem?<br>
<span class=3D""><br>
> At this time and this size of bitcoin community, my personal experience=
(and<br>
> I've been part of many communities) saying NO to new customers<br>
<br>
</span>Who said no to anything? The systems of off-chain transfer alre=
ady<br>
exist and are by comparison to Bitcoins protocol simple and rapid to<br>
adapt and scale.<br>
<br>
Indications are that we can even do off-chain at scale with Bitcoin<br>
similar trust-minimisation with lightning, and duplex payment<br>
channels; and people are working on that right now.<br>
<br>
I think it would be interesting and useful for someone, with an<br>
interest in low trust, high scale transactions, to work on and propose<br>
an interoperability standard and API for such off-chain services to be<br>
accessed by wallets, and perhaps periodic on-chain inter-service<br>
netting.<br>
<br>
Adam<br>
<div class=3D"HOEnZb"><div class=3D"h5">____________________________________=
___________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D=
"gmail_signature"><div dir=3D"ltr">I like to provide some work at no charge t=
o prove my value. Do you need a techie? <br>I own <a href=3D"http://ww=
w.litmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www=
.memeracing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I'm the w=
ebmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">The V=
oluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=3D"htt=
p://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>.<br>"He=
ought to find it more profitable to play by the rules" - Satoshi Nakamoto</=
div></div>
</div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=
--Apple-Mail-01E03DB6-C43C-442A-B823-BA119A6C00A8--
|
