blob: 55b21944e4382435f0d2bb239d983f08a36fff6c (
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
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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thyshizzle@outlook.com>) id 1Yx58c-0005Mx-9N
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 03:02:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of outlook.com
designates 65.54.190.91 as permitted sender)
client-ip=65.54.190.91; envelope-from=thyshizzle@outlook.com;
helo=BAY004-OMC2S16.hotmail.com;
Received: from bay004-omc2s16.hotmail.com ([65.54.190.91])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Yx58Z-0000k1-S7
for bitcoin-development@lists.sourceforge.net;
Tue, 26 May 2015 03:02:42 +0000
Received: from BAY403-EAS63 ([65.54.190.123]) by BAY004-OMC2S16.hotmail.com
over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751);
Mon, 25 May 2015 20:02:34 -0700
X-TMN: [1cfl6MNB6C4GhXsqTb1uM57FrlVZRDJO]
X-Originating-Email: [thyshizzle@outlook.com]
Message-ID: <BAY403-EAS63EE0AAE718842E0E3EFD6C2CC0@phx.gbl>
Content-Type: multipart/alternative;
boundary="_7c0a5ea1-0010-4365-9e90-352d3b2feb13_"
MIME-Version: 1.0
To: Jim Phillips <jim@ergophobia.org>
From: Thy Shizzle <thyshizzle@outlook.com>
Date: Tue, 26 May 2015 13:02:00 +1000
X-OriginalArrivalTime: 26 May 2015 03:02:34.0296 (UTC)
FILETIME=[69E42B80:01D09760]
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [65.54.190.91 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(thyshizzle[at]outlook.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.0 T_REMOTE_IMAGE Message contains an external image
X-Headers-End: 1Yx58Z-0000k1-S7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
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: Tue, 26 May 2015 03:02:42 -0000
--_7c0a5ea1-0010-4365-9e90-352d3b2feb13_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Indeed Jim=2C your internet connection makes a good reason why I don't like=
20mb blocks (right now). It would take you well over a minute to download =
the block before you could even relay it on=2C so much slow down in propaga=
tion! Yes I do see how decreasing the time to create blocks is a bit of a b=
and-aid fix=2C and to use tge term I've seen mentioned here "kicking the ca=
n down the road" I agree that this is doing this=2C however as you say band=
width is our biggest enemy right now and so hopefully by the time we exceed=
the capacity gained by the decrease in block time=2C we can then look to b=
ump up block size because hopefully 20mbps connections will be baseline by =
then etc.
________________________________
From: Jim Phillips<mailto:jim@ergophobia.org>
Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:53 PM
To: Thy Shizzle<mailto:thyshizzle@outlook.com>
Cc: Mike Hearn<mailto:mike@plan99.net>=3B Bitcoin Dev<mailto:bitcoin-develo=
pment@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] No Bitcoin For You
Frankly I'm good with either way. I'm definitely in favor of faster
confirmation times.
The important thing is that we need to increase the amount of transactions
that get into blocks over a given time frame to a point that is in line
with what current technology can handle. We can handle WAY more than we are
doing right now. The Bitcoin network is not currently Disk=2C CPU=2C or RAM
bound.. Not even close. The metric we're closest to being restricted by
would be Network bandwidth. I live in a developing country. 2Mbps is a
typical broadband speed here (although 5Mbps and 10Mbps connections are
affordable). That equates to about 17MB per minute=2C or 170x more capacity
than what I need to receive a full copy of the blockchain if I only talk to
one peer. If I relay to say 10 peers=2C I can still handle 17x larger block
sizes on a slow 2Mbps connection.
Also=2C even if we reduce the difficulty so that we're doing 1MB blocks eve=
ry
minute=2C that's still only 10MB every 10 minutes. Eventually we're going t=
o
have to increase that=2C and we can only reduce the confirmation period so
much. I think someone once said 30 seconds or so is about the shortest
period you can practically achieve.
--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>
*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*
*This message was created with 100% recycled electrons. Please think twice
before printing.*
On Mon=2C May 25=2C 2015 at 9:30 PM=2C Thy Shizzle <thyshizzle@outlook.com>=
wrote:
> Nah don't make blocks 20mb=2C then you are slowing down block propagatio=
n
> and blowing out conf tikes as a result. Just decrease the time it takes t=
o
> make a 1mb block=2C then you still see the same propagation times today a=
nd
> just increase the transaction throughput.
> ------------------------------
> From: Jim Phillips <jim@ergophobia.org>
> Sent: =E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM
> To: Mike Hearn <mike@plan99.net>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] No Bitcoin For You
>
>
> On Mon=2C May 25=2C 2015 at 1:36 PM=2C Mike Hearn <mike@plan99.net> wrote=
:
>
> This meme about datacenter-sized nodes has to die. The Bitcoin wiki is
> down right now=2C but I showed years ago that you could keep up with VISA=
on
> a single well specced server with today's technology. Only people living =
in
> a dreamworld think that Bitcoin might actually have to match that level o=
f
> transaction demand with today's hardware. As noted previously=2C "too man=
y
> users" is simply not a problem Bitcoin has .... and may never have!
>
>
> ... And will certainly NEVER have if we can't solve the capacity problem
> SOON.
>
> In a former life=2C I was a capacity planner for Bank of America's
> mid-range server group. We had one hard and fast rule. When you are
> typically exceeding 75% of capacity on a given metric=2C it's time to exp=
and
> capacity. Period. You don't do silly things like adjusting the business
> model to disincentivize use. Unless there's some flaw in the system and
> it's leaking resources=2C if usage has increased to the point where you a=
re
> at or near the limits of capacity=2C you expand capacity. It's as simple =
as
> that=2C and I've found that same rule fits quite well in a number of syst=
ems.
>
> In Bitcoin=2C we're not leaking resources. There's no flaw. The system i=
s
> performing as intended. Usage is increasing because it works so well=2C a=
nd
> there is huge potential for future growth as we identify more uses and
> attract more users. There might be a few technical things we can do to
> reduce consumption=2C but the metric we're concerned with right now is ho=
w
> many transactions we can fit in a block. We've broken through the 75%
> marker and are regularly bumping up against the 100% limit.
>
> It is time to stop debating this and take action to expand capacity. The
> only questions that should remain are how much capacity do we add=2C and =
how
> soon can we do it. Given that most existing computer systems and networks
> can easily handle 20MB blocks every 10 minutes=2C and given that that wil=
l
> increase capacity 20-fold=2C I can't think of a single reason why we can'=
t go
> to 20MB as soon as humanly possible. And in a few years=2C when the avera=
ge
> block size is over 15MB=2C we bump it up again to as high as we can go th=
en
> without pushing typical computers or networks beyond their capacity. We c=
an
> worry about ways to slow down growth without affecting the usefulness of
> Bitcoin as we get closer to the hard technical limits on our capacity.
>
> And you know what else? If miners need higher fees to accommodate the
> costs of bigger blocks=2C they can configure their nodes to only mine
> transactions with higher fees.. Let the miners decide how to charge enoug=
h
> to pay for their costs. We don't need to cripple the network just for the=
m.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals.=
"
> -- David Ogilvy *
>
> *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
>
--_7c0a5ea1-0010-4365-9e90-352d3b2feb13_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dutf-8">
</head>
<body>
<div>
<div style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B">Inde=
ed Jim=2C your internet connection makes a good reason why I don't like 20m=
b blocks (right now). It would take you well over a minute to download the =
block before you could even relay it on=2C so
much slow down in propagation! Yes I do see how decreasing the time to cre=
ate blocks is a bit of a band-aid fix=2C and to use tge term I've seen ment=
ioned here "=3Bkicking the can down the road"=3B I agree that this =
is doing this=2C however as you say bandwidth is our
biggest enemy right now and so hopefully by the time we exceed the capacit=
y gained by the decrease in block time=2C we can then look to bump up block=
size because hopefully 20mbps connections will be baseline by then etc.</d=
iv>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">From:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:jim@ergophobia.org">Jim Phillips</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Sent:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">=E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:53 PM</span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">To:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:thyshizzle@outlook.com">Thy Shizzle</a></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Cc:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B"><a href=3D"mailto:mike@plan99.net">Mike Hearn</a>=3B
<a href=3D"mailto:bitcoin-development@lists.sourceforge.net">Bitcoin Dev</a=
></span><br>
<span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=3B font=
-weight: bold=3B">Subject:
</span><span style=3D"font-family: Calibri=2Csans-serif=3B font-size: 11pt=
=3B">Re: [Bitcoin-development] No Bitcoin For You</span><br>
<br>
</div>
<div>
<div dir=3D"ltr">Frankly I'm good with either way. I'm definitely in favor =
of faster confirmation times. =3B
<div><br>
</div>
<div>The important thing is that we need to increase the amount of transact=
ions that get into blocks over a given time frame to a point that is in lin=
e with what current technology can handle. We can handle WAY more than we a=
re doing right now. The Bitcoin
network is not currently Disk=2C CPU=2C or RAM bound.. Not even close. The=
metric we're closest to being restricted by would be Network bandwidth. I =
live in a developing country. 2Mbps is a typical broadband speed here (alth=
ough 5Mbps and 10Mbps connections are
affordable). That equates to about 17MB per minute=2C or 170x more capacit=
y than what I need to receive a full copy of the blockchain if I only talk =
to one peer. If I relay to say 10 peers=2C I can still handle 17x larger bl=
ock sizes on a slow 2Mbps connection.
<div><br>
</div>
<div>Also=2C even if we reduce the difficulty so that we're doing 1MB block=
s every minute=2C that's still only 10MB every 10 minutes. Eventually we're=
going to have to increase that=2C and we can only reduce the confirmation =
period so much. I think someone once said
30 seconds or so is about the shortest period you can practically achieve.=
</div>
</div>
</div>
<div class=3D"x_gmail_extra"><br clear=3D"all">
<div>
<div class=3D"x_gmail_signature">
<div>--
<div><b>James G. Phillips IV</b> =3B<a href=3D"https://plus.google.com/=
u/0/113107039501292625391/posts" target=3D"_blank" style=3D"font-size:x-sma=
ll"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>&nbs=
p=3B<a href=3D"http://www.linkedin.com/in/ergophobe" target=3D"_blank"><img=
src=3D"http://developer.linkedin.com/sites/default/files/LinkedIn_Logo16px=
.png"></a></div>
</div>
<div><font size=3D"1"><i>"=3BDon't bunt. Aim out of the ball park. Aim =
for the company of immortals."=3B -- David Ogilvy<br>
</i></font>
<div><font size=3D"1"><br>
</font></div>
</div>
<div><font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fug=
ue/16/leaf.png"> =3B<em style=3D"background-color:rgb(255=2C255=2C255)=
=3B font-family:verdana=2Cgeneva=2Csans-serif=3B line-height:16px=3B color:=
green">This message was created with 100% recycled electrons.
Please think twice before printing.</em></font></div>
</div>
</div>
<br>
<div class=3D"x_gmail_quote">On Mon=2C May 25=2C 2015 at 9:30 PM=2C Thy Shi=
zzle <span dir=3D"ltr">
<=3B<a href=3D"mailto:thyshizzle@outlook.com" target=3D"_blank">thyshizzl=
e@outlook.com</a>>=3B</span> wrote:<br>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex=3B border-le=
ft:1px #ccc solid=3B padding-left:1ex">
<div>
<div>
<div style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt">Nah don't=
make blocks 20mb=2C then you are slowing down block propagation and blowin=
g out conf tikes as a result. Just decrease the time it takes to make a 1mb=
block=2C then you still see the same propagation
times today and just increase the transaction throughput.</div>
</div>
<div dir=3D"ltr">
<hr>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">From:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt"><=
a href=3D"mailto:jim@ergophobia.org" target=3D"_blank">Jim Phillips</a></sp=
an><br>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">Sent:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt">=
=E2=80=8E26/=E2=80=8E05/=E2=80=8E2015 12:27 PM</span><br>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">To:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt"><=
a href=3D"mailto:mike@plan99.net" target=3D"_blank">Mike Hearn</a></span><b=
r>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">Cc:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt"><=
a href=3D"mailto:bitcoin-development@lists.sourceforge.net" target=3D"_blan=
k">Bitcoin Dev</a></span><br>
<span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt=3B font-w=
eight:bold">Subject:
</span><span style=3D"font-family:Calibri=2Csans-serif=3B font-size:11pt">R=
e: [Bitcoin-development] No Bitcoin For You</span><br>
<br>
</div>
<div>
<div class=3D"x_h5">
<div>
<div dir=3D"ltr">
<div><br>
<div>On Mon=2C May 25=2C 2015 at 1:36 PM=2C Mike Hearn <span dir=3D"ltr">&l=
t=3B<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a=
>>=3B</span> wrote:</div>
<div><br>
<blockquote style=3D"margin:0px 0px 0px 0.8ex=3B border-left-width:1px=3B b=
order-left-color:rgb(204=2C204=2C204)=3B border-left-style:solid=3B padding=
-left:1ex">
<div dir=3D"ltr">
<div>
<div>
<div>This meme about datacenter-sized nodes has to die. The Bitcoin wiki is=
down right now=2C but I showed years ago that you could keep up with VISA =
on a single well specced server with today's technology. Only people living=
in a dreamworld think that Bitcoin
might actually have to match that level of transaction demand with today's=
hardware. As noted previously=2C "=3Btoo many users"=3B is simply =
not a problem Bitcoin has .... and may never have!</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<div>... And will certainly NEVER have if we can't solve the capacity probl=
em SOON. =3B</div>
<div><br>
</div>
<div>In a former life=2C I was a capacity planner for Bank of America's mid=
-range server group. We had one hard and fast rule. When you are typically =
exceeding 75% of capacity on a given metric=2C it's time to expand capacity=
. Period. You don't do silly things
like adjusting the business model to disincentivize use. Unless there's so=
me flaw in the system and it's leaking resources=2C if usage has increased =
to the point where you are at or near the limits of capacity=2C you expand =
capacity. It's as simple as that=2C and
I've found that same rule fits quite well in a number of systems. =3B<=
/div>
<div><br>
</div>
<div>In Bitcoin=2C we're not leaking resources. There's no flaw. The system=
is performing as intended. Usage is increasing because it works so well=2C=
and there is huge potential for future growth as we identify more uses and=
attract more users. There might be
a few technical things we can do to reduce consumption=2C but the metric w=
e're concerned with right now is how many transactions we can fit in a bloc=
k. We've broken through the 75% marker and are regularly bumping up against=
the 100% limit.</div>
<div><br>
</div>
<div>It is time to stop debating this and take action to expand capacity. T=
he only questions that should remain are how much capacity do we add=2C and=
how soon can we do it. Given that most existing computer systems and netwo=
rks can easily handle 20MB blocks
every 10 minutes=2C and given that that will increase capacity 20-fold=2C =
I can't think of a single reason why we can't go to 20MB as soon as humanly=
possible. And in a few years=2C when the average block size is over 15MB=
=2C we bump it up again to as high as we can
go then without pushing typical computers or networks beyond their capacit=
y. We can worry about ways to slow down growth without affecting the useful=
ness of Bitcoin as we get closer to the hard technical limits on our capaci=
ty.</div>
<div><br>
</div>
<div>And you know what else? If miners need higher fees to accommodate the =
costs of bigger blocks=2C they can configure their nodes to only mine trans=
actions with higher fees.. Let the miners decide how to charge enough to pa=
y for their costs. We don't need to
cripple the network just for them.</div>
<div><br clear=3D"all">
<div>
<div>
<div>--
<div><b>James G. Phillips IV</b> =3B<a href=3D"https://plus.google.com/=
u/0/113107039501292625391/posts" target=3D"_blank" style=3D"font-size:x-sma=
ll"><img src=3D"https://ssl.gstatic.com/images/icons/gplus-16.png"></a>&nbs=
p=3B</div>
</div>
<div><font size=3D"1"><i>"=3BDon't bunt. Aim out of the ball park. Aim =
for the company of immortals."=3B -- David Ogilvy<br>
</i></font>
<div><font size=3D"1"><br>
</font></div>
</div>
<div><font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fug=
ue/16/leaf.png"> =3B<em style=3D"font-family:verdana=2Cgeneva=2Csans-se=
rif=3B line-height:16px=3B color:green">This message was created with 100% =
recycled electrons. Please think twice before printing.</em></font></div>
<div><font size=3D"1"><em style=3D"font-family:verdana=2Cgeneva=2Csans-seri=
f=3B line-height:16px=3B color:green"><br>
</em></font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>
--_7c0a5ea1-0010-4365-9e90-352d3b2feb13_--
|