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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YqM2R-000349-Ac
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 13:40:31 +0000
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqM2P-0001Gw-UQ
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 13:40:31 +0000
Received: by wiun10 with SMTP id n10so60317395wiu.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 06:40:24 -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=olv/6TgqCk5DTEFuN5HIQ7n/1pqd7Xm7wY2eHaEK7x0=;
b=jH0yb8nw88471Hbww2MVXp3VH1NtStv8RF7D3sOSMCS74G6pxvV9wHfd9crs5f22zC
2zVrg6Egx6Ey7JyOhAgoD9Tt+BQu+8n6vSL6hTlX7Jprw0X9cZ+UzXknD0GD6jCAMP5y
pkaEVf4hR50pdX8iGBQZ1IAoNLg4R42uOO/FODh6wAhS4PZWWHOgiEvRtO811ojbdyHG
DQ7rorL5SnBArM7bPCDbWKyoi4wB1+XWK1iMK8YsuXlbkOlI1rS7FJ9do3627FBGhgbO
11By85qXAIBhy3C/LZpJf9Qb5B1h19ZWME4kMx6HuM3PAlIxU0SVF/tKjJPBboSn08Rn
aveA==
X-Gm-Message-State: ALoCoQl9h2h7VS31zG2HMFsDlW/Yel1zCVWhGyWcK74EqZ9BHrdG/mRrFNcn3+0NZY4ojEzpADLO
MIME-Version: 1.0
X-Received: by 10.194.60.164 with SMTP id i4mr7710552wjr.133.1431006023862;
Thu, 07 May 2015 06:40:23 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Thu, 7 May 2015 06:40:23 -0700 (PDT)
In-Reply-To: <5049F137-E123-47F6-9D24-FE51B92629FF@hashingit.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
<5049F137-E123-47F6-9D24-FE51B92629FF@hashingit.com>
Date: Thu, 7 May 2015 15:40:23 +0200
Message-ID: <CABm2gDpceBQ=SqH-axgbMgOGOf8cOe1wLyJgJY5TEFu4taiNwA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Dave Hudson <dave@hashingit.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YqM2P-0001Gw-UQ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
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, 07 May 2015 13:40:31 -0000
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson <dave@hashingit.com> wrote:
> Known: There has been a steady trend towards the mean block size getting
> larger. See
> https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=
Looking at this graph and in retrospective, we shouldn't have removed
the standard policy limit without observing the supposedly disastrous
effects of hitting the limit first.
Removing the standard limit would have been trivial (bdb issues aside)
at any point after seeing the effects.
> Known: If we reach the point where all blocks are 1M bytes then there's a
> major problem in terms of transaction confirmation. I published an analysis
> of the impact of different mean block sizes against confirmation times:
> http://hashingit.com/analysis/34-bitcoin-traffic-bulletin. The current 35%
> to 45% mean block size doesn't have a huge impact on transaction
> confirmations (assuming equal fees for all) but once we're up at 80% then
> things start to get unpleasant. Instead of 50% of first confirmations taking
> about 7 minutes they instead take nearer to 19 minutes.
Well, this is only for first confirmations of free transaction.
A higher fee should increase your probabilities, but if you're sending
free transactions you may not care about them taking longer to be
included.
> Known: There are currently a reasonably large number of zero-fee
> transactions getting relayed and mined. If things start to slow down then
> there will be a huge incentive to delay them (or drop them altogether).
Well, maybe "instant and free" it's not a honest form of bitcoin
marketing and it just has to disappear.
Maybe we just need to start being more honest about pow being good for
processing micro-transactions: it is not.
Hopefully lightning will be good for that.
Free and fast in-chain transactions is something temporary that we
know will eventually disappear.
If people think it would be a adoption disaster that it happens soon,
then they could also detail an alternative plan to roll that out
instead of letting it happen.
But if the plan is to delay it forever...then I'm absolutely against.
> Known: There's a major problem looming for miners at the next block reward
> halving. Many are already in a bad place and without meaningful fees then
> sans a 2x increase in the USD:BTC ratio then many will simply have to leave
> the network, increasing centralisation risks. There seems to be a fairly
> pervasive assumption that the 300-ish MW of power that they currently use is
> going to pay for itself (ignoring capital and other operating costs).
I take this as an argument for increasing fee competition and thus,
against increasing the block size.
> Known: the orphan rate is still pretty-high even with everyone's fast
> connections. If we assume that 20M byte blocks become possible then that's
> likely to increase.
>
> Unknown: What are the security implications for larger blocks (this one (at
> least) can be simulated though)? For example, could large blocks with huge
> numbers of trivial transactions be used to put other validators at a
> disadvantage in a variant of a selfish mining attack? I've seen objections
> that such bad actors could be blacklisted in the future but it's not clear
> to me how. A private mining pool can trivially be made to appear like 100
> pools of 1% of the size without significantly affecting the economics of
> running that private mine.
No blacklisting, please, that's centralized.
In any case, a related known: bigger blocks give competitive advantage
to bigger miners.
|
