summaryrefslogtreecommitdiff
path: root/cf/b5b5bf8690a1536d2f7a9f74fe357c7fec0eae
blob: 36df0c29a8bd9feeea8040b9b3b8cfe4fa641a46 (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
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 26E09360
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Jul 2015 09:26:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
	[209.85.212.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 915D5184
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Jul 2015 09:26:37 +0000 (UTC)
Received: by wibud3 with SMTP id ud3so121113007wib.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 21 Jul 2015 02:26:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=zEyWmkeieicYzVTYmWNFwmkEXDFA878TAr2atMsv+DM=;
	b=l2k1Xg0UjtK81aurJjU9pTi817BuGFTYft6ql+f+nVd/x6t4Dflc9hI/O8uwIXpUOx
	7pxWDgspsrCt9JVjFBrquDGeUZAXjU6bZVv97V0udq9hw2quwhzi1eD7pqXOxObaU0zh
	iH9VUQuS5NXKRJWd+GIhD32ki8DXZeJbt9mUPJFs0mhTh4M2JTR/kfAYpp+1QSLcwyah
	VJa372HFhaMHDAlhoAiFjxebwaQv9QPXadsRoN4UFzABJRkmuB6zERHqzb8dZ2L+fnKu
	fUi6Y7O2AkXJJcDCOORuf1GLiO4/0gWkj7tTc7bErzyA3o5G533ZCNbD5EUQKe1Cru0e
	/haQ==
X-Gm-Message-State: ALoCoQnhb6kBogziMdAd5uOoBLL7hsWKWXm1TQblPiDaae7ynVeN18cbT5He6+R6UsftR1WRnmgq
MIME-Version: 1.0
X-Received: by 10.194.120.198 with SMTP id le6mr65411281wjb.133.1437470795970; 
	Tue, 21 Jul 2015 02:26:35 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Tue, 21 Jul 2015 02:26:35 -0700 (PDT)
In-Reply-To: <55AC29DB.4060800@jrn.me.uk>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
	<55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk>
Date: Tue, 21 Jul 2015 11:26:35 +0200
Message-ID: <CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Ross Nicoll <jrn@jrn.me.uk>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
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: Tue, 21 Jul 2015 09:26:39 -0000

I still disagree. Using height instead of time may make the
implementation more complex by requiring some additional preparations
but using height is in fact a simpler design. Why relay on clocks that
we know will differ in different computers and places when we have a
universal tick with every block?

Btw, BIP16 and BIP34 could be changed to height-based activation
already. BIP16 simply should have used height instead of time from the
beginning.

On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Further to that - please disregard what I said about using block height. Had
> failed to realise that in using contextual information (block height) it
> complicates block validation (i.e. it would be impossible to tell if a block
> is too big, without having all previous blocks first). Block time is in fact
> the better option.
>
> Ross
>
>
> On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote:
>
> I'd back this if we can't find a permanent solution - 2MB gives us a lot
> more wiggle room in the interim at least; one of my concerns with block size
> is 3 transactions per second is absolutely tiny, and we need space for the
> network to search for an equilibrium between volume and pricing without risk
> of an adoption spike rendering it essentially unusable.
>
> I'd favour switching over by block height rather than time, and I'd suggest
> that given virtually every wallet/node out there will require testing (even
> if many do not currently enforce a limit and therefore do not need
> changing), 6 months should be considered a minimum target. I'd open with a
> suggestion of block 390k as a target.
>
> Ross
>
> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>
> Opening a mailing list thread on this BIP:
>
> BIP PR: https://github.com/bitcoin/bips/pull/173
> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>
> The general intent of this BIP is as a minimum viable alternative plan to my
> preferred proposal (BIP 100).
>
> If agreement is not reached on a more comprehensive solution, then this
> solution is at least available and a known quantity.  A good backup plan.
>
> Benefits:  conservative increase.  proves network can upgrade.  permits some
> added growth, while the community & market gathers data on how an increased
> block size impacts privacy, security, centralization, transaction throughput
> and other metrics.  2MB seems to be a Least Common Denominator on an
> increase.
>
> Costs:  requires a hard fork.  requires another hard fork down the road.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>