summaryrefslogtreecommitdiff
path: root/3d/92e5431386a2dc04650fb302d20bcc9788be7a
blob: 76ce6c0931116c04b9547bb4b9138f58032d80d1 (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
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 <da2ce7@gmail.com>) id 1YqYiP-0002vu-Mg
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 03:12:41 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.175 as permitted sender)
	client-ip=209.85.192.175; envelope-from=da2ce7@gmail.com;
	helo=mail-pd0-f175.google.com; 
Received: from mail-pd0-f175.google.com ([209.85.192.175])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YqYiO-00023I-LL
	for bitcoin-development@lists.sourceforge.net;
	Fri, 08 May 2015 03:12:41 +0000
Received: by pdbqd1 with SMTP id qd1so59353046pdb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 07 May 2015 20:12:35 -0700 (PDT)
X-Received: by 10.68.213.135 with SMTP id ns7mr2814316pbc.157.1431054743121;
	Thu, 07 May 2015 20:12:23 -0700 (PDT)
Received: from [192.168.1.63] (42-98-198-160.static.netvigator.com.
	[42.98.198.160])
	by mx.google.com with ESMTPSA id fo5sm3492668pbb.41.2015.05.07.20.12.21
	for <bitcoin-development@lists.sourceforge.net>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 07 May 2015 20:12:22 -0700 (PDT)
Message-ID: <554C2996.5030509@gmail.com>
Date: Fri, 08 May 2015 11:12:22 +0800
From: Cameron Garnham <da2ce7@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20150507200023.GI63100@giles.gnomon.org.uk>	<CAE-z3OVgX9S0sJqq-iFdkZn_wK-a=Vs4VpNwxpcagDEYFzNSDQ@mail.gmail.com>	<20150507214200.GJ63100@giles.gnomon.org.uk>	<CAPg+sBidvTSAKa6exw-XavfDxPWN_6N83VKJpm8dNSBhbXYgUA@mail.gmail.com>	<20150507220848.GK63100@giles.gnomon.org.uk>
	<CAPg+sBg4+Hj9z6NfHMyqv=PPKpYxCGP-5RcxJFfocfUajgYGxA@mail.gmail.com>
In-Reply-To: <CAPg+sBg4+Hj9z6NfHMyqv=PPKpYxCGP-5RcxJFfocfUajgYGxA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.4 (-)
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
	(da2ce7[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (da2ce7[at]gmail.com)
	-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: 1YqYiO-00023I-LL
Subject: Re: [Bitcoin-development] Mechanics of a hard fork
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 03:12:41 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

While being in the Bitcoin community for a long time, I haven't been
so directly involved in the development.  However I wish to suggest a
different pre-hard-fork soft-fork approach:


Set a 'block size cap' in the similar same way as we set difficulty.

Every 2016 blocks take the average size of the blocks and multiply the
size by 1.5x, rejecting blocks that are larger than this size, for the
next 2016 period.

I would of-course suggest that we keep the limits at min 100kb and max
(initially) 990kb (not 1mb on purpose, as this should become the new
limit), rounding up to the nearest 10kb.

A: we don't have pressure at the 1mb limit, (we reduce the limit in a
flexible manner to 990kb).

B: we can upgrade the network to XYZ hard-limit, then slowly raze the
soft-limit after being sure the network, as-a-whole is ready.

If we on-day remove the block-size limit, this rule will stop a rouge
miner from making 10mb, or 100mb blocks, or 1gb blocks.

This could be implemented by the miners without breaking any of the
clients, and would tend to produce a better dynamic fee pressure.


This will give the mechanics to the miners to create consensus to
agree what block-sizes they believe are best for the network, and
allows the block-sizes to dynamically grow in response to larger demand.



On 5/8/2015 10:35 AM, Pieter Wuille wrote:
> On May 7, 2015 3:08 PM, "Roy Badami" <roy@gnomon.org.uk> wrote:
>> 
>> On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
>>> I would not modify my node if the change introduced a perpetual
>>> 100 BTC subsidy per block, even if 99% of miners went along
>>> with it.
>> 
>> Surely, in that scenario Bitcoin is dead.  If the fork you prefer
>> has only 1% of the hash power it is trivially vulnerably not just
>> to a 51% attack but to a 501% attack, not to mention the fact
>> that you'd only be getting one block every 16 hours.
> 
> Yes, indeed, Bitcoin would be dead if this actually happens. But
> that is still where the power lies: before anyone (miners or
> others) would think about trying such a change, they would need to
> convince people and be sure they will effectively modify their
> code.
> 
> 
> 
> ----------------------------------------------------------------------
- --------
>
> 
One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications 
> Performance metrics, stats and reports that give you Actionable
> Insights Deep dive visibility with transaction tracing using APM
> Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> 
> 
> 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlVMKZYACgkQBJ8cMDO159aTiQEApTITEBrhE1DRbj/w+GncNeqB
0hGvmIBa1z0hGww0kaMBAOhxjn/K5leRJgdt1fKhNEDKKHdeCOIX3QRgry90D3NO
=p0+H
-----END PGP SIGNATURE-----