summaryrefslogtreecommitdiff
path: root/44/3c8bfabd4741ebf2c478eebd44eeb67565397c
blob: c0666048fced301d40fc41d3ae84aaa68418d3ff (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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1Yy1TE-0005Ch-2R
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 17:19:52 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.41 as permitted sender)
	client-ip=209.85.215.41; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f41.google.com; 
Received: from mail-la0-f41.google.com ([209.85.215.41])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yy1TC-0000lO-Ry
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 17:19:52 +0000
Received: by laat2 with SMTP id t2so37274759laa.1
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 28 May 2015 10:19:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.5.134 with SMTP id s6mr3701813las.99.1432833584324; Thu,
	28 May 2015 10:19:44 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Thu, 28 May 2015 10:19:44 -0700 (PDT)
In-Reply-To: <CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
	<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
Date: Thu, 28 May 2015 13:19:44 -0400
Message-ID: <CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e013d1010d0e48905172790a2
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
	(gavinandresen[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: 1Yy1TC-0000lO-Ry
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
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: Thu, 28 May 2015 17:19:52 -0000

--089e013d1010d0e48905172790a2
Content-Type: text/plain; charset=UTF-8

On Thu, May 28, 2015 at 1:05 PM, Mike Hearn <mike@plan99.net> wrote:

> Isn't that a step backwards, then? I see no reason for fee pressure to
>> exist at the moment. All it's doing is turning away users for no purpose:
>> mining isn't supported by fees, and the tiny fees we use right now seem to
>> be good enough to stop penny flooding.
>>
>
> Why not set the max size to be 20x the average size? Why 2x, given you
> just pointed out that'd result in blocks shrinking rather than growing.
>

Twenty is scary.

And two is a very neutral number: if 50% of hashpower want the max size to
grow as fast as possible and 50% are dead-set opposed to any increase in
max size, then half produce blocks 2 times as big, half produce empty
blocks, and the max size doesn't change. If it was 20, then a small
minority of miners could force a max size increase.  (if it is less than 2,
then a minority of minors can force the block size down)


As for whether there "should" be fee pressure now or not: I have no
opinion, besides "we should make block propagation faster so there is no
technical reason for miners to produce tiny blocks." I don't think us
developers should be deciding things like whether or not fees are too high,
too low, .....

-- 
--
Gavin Andresen

--089e013d1010d0e48905172790a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, May 28, 2015 at 1:05 PM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Isn&#39;t =
that a step backwards, then? I see no reason for fee pressure to exist at t=
he moment. All it&#39;s doing is turning away users for no purpose: mining =
isn&#39;t supported by fees, and the tiny fees we use right now seem to be =
good enough to stop penny flooding.<br></div></div></div></div></blockquote=
><div><br></div><div>Why not set the max size to be 20x the average size? W=
hy 2x, given you just pointed out that&#39;d result in blocks shrinking rat=
her than growing.</div></div></div></div>
</blockquote></div><br>Twenty is scary.</div><div class=3D"gmail_extra"><br=
></div><div class=3D"gmail_extra">And two is a very neutral number: if 50% =
of hashpower want the max size to grow as fast as possible and 50% are dead=
-set opposed to any increase in max size, then half produce blocks 2 times =
as big, half produce empty blocks, and the max size doesn&#39;t change. If =
it was 20, then a small minority of miners could force a max size increase.=
 =C2=A0(if it is less than 2, then a minority of minors can force the block=
 size down)</div><div class=3D"gmail_extra"><br clear=3D"all"><div><br></di=
v><div>As for whether there &quot;should&quot; be fee pressure now or not: =
I have no opinion, besides &quot;we should make block propagation faster so=
 there is no technical reason for miners to produce tiny blocks.&quot; I do=
n&#39;t think us developers should be deciding things like whether or not f=
ees are too high, too low, .....</div><div><br></div>-- <br><div class=3D"g=
mail_signature">--<br>Gavin Andresen<br></div>
</div></div>

--089e013d1010d0e48905172790a2--