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
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mike@coinlab.com>) id 1Sfarb-0005jB-Ek
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 18:03:15 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.212.47 as permitted sender)
client-ip=209.85.212.47; envelope-from=mike@coinlab.com;
helo=mail-vb0-f47.google.com;
Received: from mail-vb0-f47.google.com ([209.85.212.47])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SfarZ-0001Cd-5N
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 18:03:15 +0000
Received: by vbbfr13 with SMTP id fr13so2143942vbb.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 15 Jun 2012 11:03:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:x-gm-message-state;
bh=6/M1M+xYvXW+GxyhoFbqCvs39HEFUzdYJLaCGjzZ2NA=;
b=PYlGKLt0Crixqm8mGbiOQoTuxu2HtxB6En/crWzzrA/T7k+NvRtIpzHCzphnFP7Jfz
lJ4TMGdI3Z1ijwGCgdEgk7422MRSepAwDZlBQ/ytdtYaLN6KgCwGBNBHvXyAztgGUS62
CvgxJmJAMAMorS01qPcVYm+LZv/lnB1GevBUFpLMZ8sasjc2gB/D9tCHVWxFlOWt5vcR
SrjMWw9BAPkw7TsGfi4GuUzmJFvvP3XTPw1RFnE4JQGM7sUtIRXzIUsQ3dXqVsNm4FBT
jyKVCK7DML88xI6BpjeYUqXMogDsDWH3+5LDPD4SpqyP14XNx9Jkoed4CRTp8KO8lgBE
W/cg==
MIME-Version: 1.0
Received: by 10.52.174.99 with SMTP id br3mr2793939vdc.85.1339781824375; Fri,
15 Jun 2012 10:37:04 -0700 (PDT)
Received: by 10.52.68.212 with HTTP; Fri, 15 Jun 2012 10:37:04 -0700 (PDT)
In-Reply-To: <4FDB6946.2020400@justmoon.de>
References: <CANEZrP3w+AiTXmv9Wb3Zi5yyFmGPk82-ysVo4_DVvtg8HHBCdQ@mail.gmail.com>
<4FDB6946.2020400@justmoon.de>
Date: Fri, 15 Jun 2012 10:37:04 -0700
Message-ID: <CAErK2CgODFY7HMC-WZRAmts-6eOE074Tz4nX5Nr6EvB8o-QWJA@mail.gmail.com>
From: Mike Koss <mike@coinlab.com>
To: Stefan Thomas <moon@justmoon.de>
Content-Type: multipart/alternative; boundary=bcaec51ba443b7eadb04c2864361
X-Gm-Message-State: ALoCoQmrnxfBlMPuol/yy4iugbAt+uBYPZ4IP5CKHG0p/ZmJZteO5ScTo8ARm+gucc7Kt6SjbLvE
X-Spam-Score: -0.5 (/)
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1SfarZ-0001Cd-5N
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Near-term scalability
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, 15 Jun 2012 18:03:15 -0000
--bcaec51ba443b7eadb04c2864361
Content-Type: text/plain; charset=ISO-8859-1
Grouping mempool transactions based on fees of the group seems
an unnecessary complexity; it makes it harder to predict if an isolated
transaction has enough "juice" to be included in the next Block.
Given your point about economic actors adapting to conditions, would it not
be simpler to use a individual "fee per byte" priority algorithm and let
transaction generators distribute their fees accordingly (and more
predictably)?
This simpler algorithm will prune arbitrary transactions sub-optimally, but
has the benefit of being more understandable and predictable from the point
of view of transaction generators.
On Fri, Jun 15, 2012 at 9:56 AM, Stefan Thomas <moon@justmoon.de> wrote:
> Thanks Mike for the writeup - I'm very sad to have missed the discussion
> on IRC since fee economics are probably my favorite topic, but I'll try
> to contribute to the email discussion instead.
>
> > (4) Making the block size limit float is better than picking a new
> > arbitrary threshold.
>
> Fees are a product of both real and artificial limits to transaction
> validation.
>
> The artificial limits like the block size limit are essentially putting
> a floor on prices by limiting supply beyond what it would otherwise be.
> E.g. the network could confirm more transactions theoretically, but the
> block size limit prevents it.
>
> The real limits are the bandwidth, computing and memory resources of
> participating nodes. For the sake of argument suppose a 1 TB block was
> released into the network right now and we'll also assume there was no
> block size limit of any kind. Many nodes would likely not be able to
> successfully download this block in under 10-30 minutes, so there is a
> very good chance that other miners will have generated two blocks before
> this block makes its way to them.
>
> What does this mean? The miner generating a 1 TB block knows this would
> happen. So in terms of economic self interest he will generate the
> largest possible block that he is still confident that other miners will
> accept and process. A miner who receives a block will also consider
> whether to build on it based on whether they think other miners will be
> able to download it. In other words, if I receive a large block I may
> decide not to mine on it, because I believe that the majority of mining
> power will not mine on it - because it is either too large for them to
> download or because their rules against large blocks reject it.
>
> It's important to understand that in practice economic actors tend to
> plan ahead. In other words, if there is no block size limit that doesn't
> mean that there will be constant forks and total chaos. Rather, no miner
> will ever want to have a block rejected due to size, there is plenty of
> incentive to be conservative with your limits. Even if there are forks,
> this simply means that miners have decided that they can make more money
> by including more transactions at the cost of the occasional dud.
>
> Therefore, from an economic perspective, we do not need a global block
> size limit of any kind. As "guardians of the network" the only thing we
> need to do is to let miners figure out what they wanna do.
>
> HOWEVER, the existing economic incentives won't manifest unless somebody
> translates them into code. We have to give our users (miners & endusers)
> the tools to create a genuine fee-based verification market.
>
> On the miner side: I would make the block size limit configurable with a
> relatively high default. If the default is too low few people will
> bother changing it, which means that it is not worth changing (because a
> majority uses the default anyway), which means even fewer people will
> change it and so on.
>
> The block size limit should also be a soft rather than a hard limit -
> here are some ideas for this:
>
> - The default limit for accepting blocks from others should always be
> significantly greater than the default limit for blocks that the client
> itself will generate.
>
> - There should be different size limits for side chains that are longer
> than the currently active chain. In other words, I might reject a block
> for being slightly too large, but if everyone else accepts it I should
> eventually accept it too, and my client should also consider
> automatically raising my size limit if this happens a lot.
>
> The rationale for the soft limit is to allow for gradual upward
> adjustment. It needs to be risky for individual miners to raise the size
> of their blocks to new heights, but ideally there won't be one solid
> wall for them to run into.
>
> On the user side: I would display the fee on the Send Coins dialog and
> allow users to choose a different fee per transaction. We also talked
> about adding some UI feedback where the client tries to estimate how
> long a transaction will take to confirm given a certain fee, based on
> recent information about what it observed from the network. If the fee
> can be changed on the Send Coins tab, then this could be a red, yellow,
> green visual indication whether the fee is sufficient, adequate or
> dangerously low.
>
> A criticism one might raise is: "The block size limit is not to protect
> miners, but to protect end users who may have less resources than miners
> and can't download gigantic block chains." - That's a viewpoint that is
> certainly valid. I believe that we will be able to do a lot just with
> efficiency improvements, pruning, compression and whatnot. But when it
> comes down to it, I'd prefer a large network with cheap
> microtransactions even if that means that consumer hardware can't
> operate as a standalone validating node anymore. Headers-only mode is
> already a much-requested feature anyway and there are many ways of
> improving the security of various header-only or lightweight protocols.
>
> (I just saw Greg's message advocating the opposite viewpoint, I'll
> respond to that as soon as I can.)
>
>
> > (1) Change the mining code to group transactions together with their
> > mempool dependencies and then calculate all fees as a group.
>
> +1 Very good change. This would allow miners to maximize their revenue
> and in doing so better represent the existing priorities that users
> express through fees.
>
>
> > There was discussion of some one-off changes to address the current
> > situation, namely de-ranking transactions that re-use addresses.
>
> Discouraging address reuse will not change the amount of transactions, I
> think we all agree on that. As for whether it improves the
> prioritization, I'm not sure. Use cases that we seek to discourage may
> simply switch to random addresses and I don't agree in and of itself
> this is a benefit (see item 4 below). Here are a few reasons one might
> be against this proposal:
>
> 1) Certain use cases like green addresses will be forced to become more
> complicated than they would otherwise need to be.
>
> 2) It will be harder to read information straight out of the block
> chain, for example right now we can pretty easily see how much volume is
> caused by Satoshi Dice, perhaps allowing us to make better decisions.
>
> 3) The address index that is used by block explorers and lightweight
> client servers will grow unnecessarily (an address -> tx index will be
> larger if the number of unique addresses increases given the same number
> of txs), so for people like myself who work on that type of software
> you're actually making our scalability equation slightly worse.
>
> 4) You're forcing people into privacy best practices which you think are
> good, but others may not subscribe to. For example I have absolutely
> zero interest in privacy, anyone who cares that I buy Bitcoins with my
> salary and spend them on paragliding is welcome to know about it.
> Frankly, if I cared about privacy I wouldn't be using Bitcoin. If other
> people want to use mixing services and randomize their addresses and
> communicate through Tor that's fine, but the client shouldn't force me
> to do those things if I don't want to by "deprioritizing" my transactions.
>
> 5) We may not like firstbits, but the fact remains that for now they are
> extremely popular, because they improve the user experience where we
> failed to do so. If you deprioritize transactions to reused addresses
> you'll for example deprioritize all/most of Girls Gone Bitcoin, which
> (again, like it or not) is one of the few practical, sustainable niches
> that Bitcoin has managed to carve out for itself so far.
>
>
> > Having senders/buyers pay no fees is psychologically desirable even
> > though we all understand that eventually, somebody, somewhere will be
> > paying fees to use Bitcoin
>
> Free is just an extreme form of cheap, so if we can make transactions
> very cheap (through efficiency and very large blocks) then it will be
> easier for charitable miners to include free transactions. In practice,
> my prediction is that free transactions on the open network will simply
> not be possible in the long run. Dirty hacks aside there is simply no
> way of distinguishing a spam transaction from a charity-worthy
> transaction. So the way I envision free transactions in the future is
> that there may be miners in partnership with wallet providers like
> BlockChain.info that let you submit feeless transactions straight to
> them based on maybe a captcha or some ads. (For the purist, the captcha
> challenge and response could be communicated across the bitcoin network,
> but I think we agree that such things should ideally take place
> out-of-band.)
>
> That way, the available charity of miners who wish to include feeless
> transactions would go to human users as opposed to the potentially
> infinite demand of auto-generated feeless transactions.
>
>
>
> On 6/15/2012 1:29 PM, Mike Hearn wrote:
> > I had to hit the sack last night as it was 2am CET, but I'd like to
> > sum up the discussion we had on IRC about scalability and SatoshiDice
> > in particular.
> >
> > I think we all agreed on the following:
> >
> > - Having senders/buyers pay no fees is psychologically desirable even
> > though we all understand that eventually, somebody, somewhere will be
> > paying fees to use Bitcoin
> >
> > - In the ideal world Bitcoin would scale perfectly and there would be
> > no need for there to be some "winners" and some "losers" when it comes
> > to confirmation time.
> >
> > There was discussion of some one-off changes to address the current
> > situation, namely de-ranking transactions that re-use addresses. Gavin
> > and myself were not keen on this idea, primarily because it just
> > avoids the real problem and Bitcoin already has a good way to
> > prioritize transactions via the fees mechanism itself. The real issue
> > is that SatoshiDice does indeed pay fees and generates a lot of
> > transactions, pushing more traditional traffic out due to artificial
> > throttles.
> >
> > The following set of proposals were discussed:
> >
> > (1) Change the mining code to group transactions together with their
> > mempool dependencies and then calculate all fees as a group. A tx with
> > a fee of 1 BTC that depends on 5 txns with zero fees would result in
> > all 6 transactions being considered to have a fee of 1BTC and
> > therefore become prioritized for inclusion. This allows a transition
> > to "receiver pays" model for fees. There are many advantages. One is
> > that it actually makes sense ... it's always the receiver who wants
> > confirmations because it's the receiver that fears double spends.
> > Senders never do. What's more, whilst Bitcoin is designed to operate
> > on a zero-trust model in the real world trust often exists and it can
> > be used to optimize by passing groups of transactions around with
> > their dependencies, until that group passes a trust boundary and gets
> > broadcast with a send-to-self tx to add fees. Another advantage is it
> > simplifies usage for end users who primarily buy rather than sell,
> > because it avoids the need to guess at fees, one of the most
> > problematic parts of Bitcoins design now.
> >
> > The disadvantages are that it can result in extra transactions that
> > exist only for adding fees, and it requires a more modern payment
> > protocol than the direct-IP protocol Satoshi designed.
> >
> > It would help address the current situation by avoiding angry users
> > who want to buy things, but don't know what fee to set and so their
> > transactions get stuck.
> >
> > (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
> > avoid paying excessive fees and queue-jumping. Guess that's on my
> > plate.
> >
> > (3) Scalability improvements seem like a no brainer to everyone, it's
> > just a case of how complicated they are.
> >
> > (4) Making the block size limit float is better than picking a new
> > arbitrary threshold.
> >
> > On the forums Matt stated that block chain pruning was a no-go because
> > "it makes bitcoin more centralized". I think we've thrashed this one
> > out sufficiently well by now that there should be a united opinion on
> > it. There are technical ways to implement it such that there is no
> > change of trust requirements. All the other issues (finding archival
> > nodes, etc) can be again addressed with sufficient programming.
> >
> > For the case of huge blocks slowing down end user syncing and wasting
> > their resources, SPV clients like MultiBit and Android Wallet already
> > exist and will get better with time. If Jeff implements the bloom
> > filtering p2p commands I'll make bitcoinj use them and that'll knock
> > out excessive bandwidth usage and parse overheads from end users who
> > are on these clients. At some point Bitcoin-Qt can have a dual mode,
> > but who knows when that'll get implemented.
> >
> > Does that all sound reasonable?
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
--bcaec51ba443b7eadb04c2864361
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Grouping mempool transactions based on fees of the group seems an=A0unneces=
sary=A0complexity; it makes it harder to predict if an isolated transaction=
has enough "juice" to be included in the next Block.<div><br></d=
iv>
<div>Given your point about economic actors adapting to conditions, would i=
t not be simpler to use a individual "fee per byte" priority algo=
rithm and let transaction generators distribute their fees accordingly (and=
more predictably)?</div>
<div><br></div><div>This simpler algorithm will prune arbitrary transaction=
s sub-optimally, but has the benefit of being more understandable and predi=
ctable from the point of view of transaction generators.<br><div><br><div c=
lass=3D"gmail_quote">
On Fri, Jun 15, 2012 at 9:56 AM, Stefan Thomas <span dir=3D"ltr"><<a hre=
f=3D"mailto:moon@justmoon.de" target=3D"_blank">moon@justmoon.de</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Thanks Mike for the writeup - I'm very sad to have missed the discussio=
n<br>
on IRC since fee economics are probably my favorite topic, but I'll try=
<br>
to contribute to the email discussion instead.<br>
<div class=3D"im"><br>
> (4) Making the block size limit float is better than picking a new<br>
> arbitrary threshold.<br>
<br>
</div>Fees are a product of both real and artificial limits to transaction<=
br>
validation.<br>
<br>
The artificial limits like the block size limit are essentially putting<br>
a floor on prices by limiting supply beyond what it would otherwise be.<br>
E.g. the network could confirm more transactions theoretically, but the<br>
block size limit prevents it.<br>
<br>
The real limits are the bandwidth, computing and memory resources of<br>
participating nodes. For the sake of argument suppose a 1 TB block was<br>
released into the network right now and we'll also assume there was no<=
br>
block size limit of any kind. Many nodes would likely not be able to<br>
successfully download this block in under 10-30 minutes, so there is a<br>
very good chance that other miners will have generated two blocks before<br=
>
this block makes its way to them.<br>
<br>
What does this mean? The miner generating a 1 TB block knows this would<br>
happen. So in terms of economic self interest he will generate the<br>
largest possible block that he is still confident that other miners will<br=
>
accept and process. A miner who receives a block will also consider<br>
whether to build on it based on whether they think other miners will be<br>
able to download it. In other words, if I receive a large block I may<br>
decide not to mine on it, because I believe that the majority of mining<br>
power will not mine on it - because it is either too large for them to<br>
download or because their rules against large blocks reject it.<br>
<br>
It's important to understand that in practice economic actors tend to<b=
r>
plan ahead. In other words, if there is no block size limit that doesn'=
t<br>
mean that there will be constant forks and total chaos. Rather, no miner<br=
>
will ever want to have a block rejected due to size, there is plenty of<br>
incentive to be conservative with your limits. Even if there are forks,<br>
this simply means that miners have decided that they can make more money<br=
>
by including more transactions at the cost of the occasional dud.<br>
<br>
Therefore, from an economic perspective, we do not need a global block<br>
size limit of any kind. As "guardians of the network" the only th=
ing we<br>
need to do is to let miners figure out what they wanna do.<br>
<br>
HOWEVER, the existing economic incentives won't manifest unless somebod=
y<br>
translates them into code. We have to give our users (miners & endusers=
)<br>
the tools to create a genuine fee-based verification market.<br>
<br>
On the miner side: I would make the block size limit configurable with a<br=
>
relatively high default. If the default is too low few people will<br>
bother changing it, which means that it is not worth changing (because a<br=
>
majority uses the default anyway), which means even fewer people will<br>
change it and so on.<br>
<br>
The block size limit should also be a soft rather than a hard limit -<br>
here are some ideas for this:<br>
<br>
- The default limit for accepting blocks from others should always be<br>
significantly greater than the default limit for blocks that the client<br>
itself will generate.<br>
<br>
- There should be different size limits for side chains that are longer<br>
than the currently active chain. In other words, I might reject a block<br>
for being slightly too large, but if everyone else accepts it I should<br>
eventually accept it too, and my client should also consider<br>
automatically raising my size limit if this happens a lot.<br>
<br>
The rationale for the soft limit is to allow for gradual upward<br>
adjustment. It needs to be risky for individual miners to raise the size<br=
>
of their blocks to new heights, but ideally there won't be one solid<br=
>
wall for them to run into.<br>
<br>
On the user side: I would display the fee on the Send Coins dialog and<br>
allow users to choose a different fee per transaction. We also talked<br>
about adding some UI feedback where the client tries to estimate how<br>
long a transaction will take to confirm given a certain fee, based on<br>
recent information about what it observed from the network. If the fee<br>
can be changed on the Send Coins tab, then this could be a red, yellow,<br>
green visual indication whether the fee is sufficient, adequate or<br>
dangerously low.<br>
<br>
A criticism one might raise is: "The block size limit is not to protec=
t<br>
miners, but to protect end users who may have less resources than miners<br=
>
and can't download gigantic block chains." - That's a viewpoin=
t that is<br>
certainly valid. I believe that we will be able to do a lot just with<br>
efficiency improvements, pruning, compression and whatnot. But when it<br>
comes down to it, I'd prefer a large network with cheap<br>
microtransactions even if that means that consumer hardware can't<br>
operate as a standalone validating node anymore. Headers-only mode is<br>
already a much-requested feature anyway and there are many ways of<br>
improving the security of various header-only or lightweight protocols.<br>
<br>
(I just saw Greg's message advocating the opposite viewpoint, I'll<=
br>
respond to that as soon as I can.)<br>
<div class=3D"im"><br>
<br>
> (1) Change the mining code to group transactions together with their<b=
r>
> mempool dependencies and then calculate all fees as a group.<br>
<br>
</div>+1 Very good change. This would allow miners to maximize their revenu=
e<br>
and in doing so better represent the existing priorities that users<br>
express through fees.<br>
<div class=3D"im"><br>
<br>
> There was discussion of some one-off changes to address the current<br=
>
> situation, namely de-ranking transactions that re-use addresses.<br>
<br>
</div>Discouraging address reuse will not change the amount of transactions=
, I<br>
think we all agree on that. As for whether it improves the<br>
prioritization, I'm not sure. Use cases that we seek to discourage may<=
br>
simply switch to random addresses and I don't agree in and of itself<br=
>
this is a benefit (see item 4 below). Here are a few reasons one might<br>
be against this proposal:<br>
<br>
1) Certain use cases like green addresses will be forced to become more<br>
complicated than they would otherwise need to be.<br>
<br>
2) It will be harder to read information straight out of the block<br>
chain, for example right now we can pretty easily see how much volume is<br=
>
caused by Satoshi Dice, perhaps allowing us to make better decisions.<br>
<br>
3) The address index that is used by block explorers and lightweight<br>
client servers will grow unnecessarily (an address -> tx index will be<b=
r>
larger if the number of unique addresses increases given the same number<br=
>
of txs), so for people like myself who work on that type of software<br>
you're actually making our scalability equation slightly worse.<br>
<br>
4) You're forcing people into privacy best practices which you think ar=
e<br>
good, but others may not subscribe to. For example I have absolutely<br>
zero interest in privacy, anyone who cares that I buy Bitcoins with my<br>
salary and spend them on paragliding is welcome to know about it.<br>
Frankly, if I cared about privacy I wouldn't be using Bitcoin. If other=
<br>
people want to use mixing services and randomize their addresses and<br>
communicate through Tor that's fine, but the client shouldn't force=
me<br>
to do those things if I don't want to by "deprioritizing" my =
transactions.<br>
<br>
5) We may not like firstbits, but the fact remains that for now they are<br=
>
extremely popular, because they improve the user experience where we<br>
failed to do so. If you deprioritize transactions to reused addresses<br>
you'll for example deprioritize all/most of Girls Gone Bitcoin, which<b=
r>
(again, like it or not) is one of the few practical, sustainable niches<br>
that Bitcoin has managed to carve out for itself so far.<br>
<div class=3D"im"><br>
<br>
> Having senders/buyers pay no fees is psychologically desirable even<br=
>
> though we all understand that eventually, somebody, somewhere will be<=
br>
> paying fees to use Bitcoin<br>
<br>
</div>Free is just an extreme form of cheap, so if we can make transactions=
<br>
very cheap (through efficiency and very large blocks) then it will be<br>
easier for charitable miners to include free transactions. In practice,<br>
my prediction is that free transactions on the open network will simply<br>
not be possible in the long run. Dirty hacks aside there is simply no<br>
way of distinguishing a spam transaction from a charity-worthy<br>
transaction. So the way I envision free transactions in the future is<br>
that there may be miners in partnership with wallet providers like<br>
BlockChain.info that let you submit feeless transactions straight to<br>
them based on maybe a captcha or some ads. (For the purist, the captcha<br>
challenge and response could be communicated across the bitcoin network,<br=
>
but I think we agree that such things should ideally take place<br>
out-of-band.)<br>
<br>
That way, the available charity of miners who wish to include feeless<br>
transactions would go to human users as opposed to the potentially<br>
infinite demand of auto-generated feeless transactions.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On 6/15/2012 1:29 PM, Mike Hearn wrote:<br>
> I had to hit the sack last night as it was 2am CET, but I'd like t=
o<br>
> sum up the discussion we had on IRC about scalability and SatoshiDice<=
br>
> in particular.<br>
><br>
> I think we all agreed on the following:<br>
><br>
> - Having senders/buyers pay no fees is psychologically desirable even<=
br>
> though we all understand that eventually, somebody, somewhere will be<=
br>
> paying fees to use Bitcoin<br>
><br>
> - In the ideal world Bitcoin would scale perfectly and there would be<=
br>
> no need for there to be some "winners" and some "losers=
" when it comes<br>
> to confirmation time.<br>
><br>
> There was discussion of some one-off changes to address the current<br=
>
> situation, namely de-ranking transactions that re-use addresses. Gavin=
<br>
> and myself were not keen on this idea, primarily because it just<br>
> avoids the real problem and Bitcoin already has a good way to<br>
> prioritize transactions via the fees mechanism itself. The real issue<=
br>
> is that SatoshiDice does indeed pay fees and generates a lot of<br>
> transactions, pushing more traditional traffic out due to artificial<b=
r>
> throttles.<br>
><br>
> The following set of proposals were discussed:<br>
><br>
> (1) Change the mining code to group transactions together with their<b=
r>
> mempool dependencies and then calculate all fees as a group. A tx with=
<br>
> a fee of 1 BTC that depends on 5 txns with zero fees would result in<b=
r>
> all 6 transactions being considered to have a fee of 1BTC and<br>
> therefore become prioritized for inclusion. This allows a transition<b=
r>
> to "receiver pays" model for fees. There are many advantages=
. One is<br>
> that it actually makes sense ... it's always the receiver who want=
s<br>
> confirmations because it's the receiver that fears double spends.<=
br>
> Senders never do. What's more, whilst Bitcoin is designed to opera=
te<br>
> on a zero-trust model in the real world trust often exists and it can<=
br>
> be used to optimize by passing groups of transactions around with<br>
> their dependencies, until that group passes a trust boundary and gets<=
br>
> broadcast with a send-to-self tx to add fees. Another advantage is it<=
br>
> simplifies usage for end users who primarily buy rather than sell,<br>
> because it avoids the need to guess at fees, one of the most<br>
> problematic parts of Bitcoins design now.<br>
><br>
> The disadvantages are that it can result in extra transactions that<br=
>
> exist only for adding fees, and it requires a more modern payment<br>
> protocol than the direct-IP protocol Satoshi designed.<br>
><br>
> It would help address the current situation by avoiding angry users<br=
>
> who want to buy things, but don't know what fee to set and so thei=
r<br>
> transactions get stuck.<br>
><br>
> (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to<br=
>
> avoid paying excessive fees and queue-jumping. Guess that's on my<=
br>
> plate.<br>
><br>
> (3) Scalability improvements seem like a no brainer to everyone, it=
9;s<br>
> just a case of how complicated they are.<br>
><br>
> (4) Making the block size limit float is better than picking a new<br>
> arbitrary threshold.<br>
><br>
> On the forums Matt stated that block chain pruning was a no-go because=
<br>
> "it makes bitcoin more centralized". I think we've thras=
hed this one<br>
> out sufficiently well by now that there should be a united opinion on<=
br>
> it. There are technical ways to implement it such that there is no<br>
> change of trust requirements. All the other issues (finding archival<b=
r>
> nodes, etc) can be again addressed with sufficient programming.<br>
><br>
> For the case of huge blocks slowing down end user syncing and wasting<=
br>
> their resources, SPV clients like MultiBit and Android Wallet already<=
br>
> exist and will get better with time. If Jeff implements the bloom<br>
> filtering p2p commands I'll make bitcoinj use them and that'll=
knock<br>
> out excessive bandwidth usage and parse overheads from end users who<b=
r>
> are on these clients. At some point Bitcoin-Qt can have a dual mode,<b=
r>
> but who knows when that'll get implemented.<br>
><br>
> Does that all sound reasonable?<br>
><br>
> ----------------------------------------------------------------------=
--------<br>
> Live Security Virtual Conference<br>
> Exclusive live event will cover all the ways today's security and<=
br>
> threat landscape has changed and how IT managers can respond. Discussi=
ons<br>
> will include endpoint security, mobile security and the latest in malw=
are<br>
> threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/50=
122263/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/=
50122263/</a><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
><br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today's security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Mike Koss<div>CTO, CoinLab</div><div>(425) 246-7701 (m)</div><div><br></div=
><div><a href=3D"http://coinlab.com/a-bitcoin-primer.pdf" target=3D"_blank"=
>A Bitcoin Primer</a>=A0- What you need to know about Bitcoins.</div>
<br>
</div></div>
--bcaec51ba443b7eadb04c2864361--
|