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
|
Return-Path: <dscvlt@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BB2AB9B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Aug 2015 09:52:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com
[209.85.213.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E147163
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Aug 2015 09:52:38 +0000 (UTC)
Received: by igfj19 with SMTP id j19so32335202igf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Aug 2015 02:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=N2OiN6moMkqlMIXBl4LIWGBfa5KJEqm4fEvRJ9U6VtY=;
b=PQPugxPnia3qNmnd1yEK2aYa0z3nYjq/cPFTMNk1B48KBguLdzZiVm/Ww7KBj4SEab
uNsqH+jAxz46i8lDGmGprUCt5bAFNxVdaULyb1VvZZfy/mBbTQI8uT+Taui8MwFFcxjh
LrWw7fOzAmt6k3+1ruLd03LherQsoCOUB16UyZjP16XCdOVMgzwO05ZEk+Q1RZIQu/k5
61taRnxtpy+uuNew7iCwDlWR5nSMCbczolmTLzxKrktUb9NsK9TmKJi5YXLGkjkOurrH
qnSlAmbTIkUhvvKnA52eUhOxJu+CStXTj/E23sK2Ip16n+UmG2vWaKJfUOjFtvb/OcUM
KJ1w==
MIME-Version: 1.0
X-Received: by 10.50.43.227 with SMTP id z3mr2105550igl.12.1439459557647; Thu,
13 Aug 2015 02:52:37 -0700 (PDT)
Received: by 10.107.129.93 with HTTP; Thu, 13 Aug 2015 02:52:37 -0700 (PDT)
In-Reply-To: <CABm2gDrfB+c1QTZippYYNX-uhcd9NYUcR-VHug6FYtPmSoz4Bw@mail.gmail.com>
References: <CABm2gDrfB+c1QTZippYYNX-uhcd9NYUcR-VHug6FYtPmSoz4Bw@mail.gmail.com>
Date: Thu, 13 Aug 2015 19:52:37 +1000
Message-ID: <CAOXABZrMcpf4s=BuGsuLLoV80xt=hcd-i+h0V+AdJDQ2D8NKXg@mail.gmail.com>
From: Ashley Holman <dscvlt@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e0111c0169a2d45051d2e4be2
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Subject: Re: [bitcoin-dev] A summary list of all concerns related to not
rising the block size
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: Thu, 13 Aug 2015 09:52:38 -0000
--089e0111c0169a2d45051d2e4be2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
A concern I have is about security (hash rate) as a function of block size.
I am assuming that hash rate is correlated with revenue from mining.
Total revenue from fees as a function of block size should be a curve. On
one extreme of the curve, if blocks are too big, fee revenue tends towards
0 as there is no competition for block space. At the other extreme, if
blocks are too small, fee revenue is limited only to what the most valuable
use case(s) can afford. Somewhere in the middle there should be a sweet
spot where fee revenue is maximised. It's not a static curve though, it
should change as demand for block space changes.
Failing to scale the block size as demand grows might be forfeiting
potential miner revenue and hence security.
(I don't think that should be a primary concern though since
decentralisation should come first, but I'm just pointing it out as a
secondary concern).
On Wed, Aug 12, 2015 at 7:59 PM, Jorge Tim=C3=B3n <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I believe all concerns I've read can be classified in the following group=
s:
>
> > 1) Potential indirect consequence of rising fees.
>
> - Lowest fee transactions (currently free transactions) will become
> more unreliable.
> - People will migrate to competing systems (PoW altcoins) with lower fees=
.
>
> > 2) Software problem independent of a concrete block size that needs to
> > be solved anyway, often specific to Bitcoin Core (ie other
> > implementations, say libbitcoin may not necessarily share these
> > problems).
>
> - Bitcoin Core's mempool is unbounded in size and can make the program
> crash by using too much memory.
> - There's no good way to increase the fee of a transaction that is
> taking too long to be mined without the "double spending" transaction
> with the higher fee being blocked by most nodes which follow Bitcoin
> Core's default policy for conflicting spends replacements (aka "first
> seen" replacement policy).
>
> I have started with the 3 concerns that I read more often, but please
> suggest more concerns for these categories and suggest other
> categories if you think there's more.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e0111c0169a2d45051d2e4be2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A concern I have is about security (hash rate) as a functi=
on of block size.<div><br></div><div>I am assuming that hash rate is correl=
ated with revenue from mining.</div><div><br></div><div>Total revenue from =
fees as a function of block size should be a curve.=C2=A0 On one extreme of=
the curve, if blocks are too big, fee revenue tends towards 0 as there is =
no competition for block space.=C2=A0 At the other extreme, if blocks are t=
oo small, fee revenue is limited only to what the most valuable use case(s)=
can afford.=C2=A0 Somewhere in the middle there should be a sweet spot whe=
re fee revenue is maximised.=C2=A0 It's not a static curve though, it s=
hould change as demand for block space changes.</div><div><br></div><div>Fa=
iling to scale the block size as demand grows might be forfeiting potential=
miner revenue and hence security.</div><div><br></div><div>(I don't th=
ink that should be a primary concern though since decentralisation should c=
ome first, but I'm just pointing it out as a secondary concern).</div><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug =
12, 2015 at 7:59 PM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">I believe all concerns I've read can be classified in the following=
groups:<br>
<br>
> 1) Potential indirect consequence of rising fees.<br>
<br>
- Lowest fee transactions (currently free transactions) will become<br>
more unreliable.<br>
- People will migrate to competing systems (PoW altcoins) with lower fees.<=
br>
<br>
> 2) Software problem independent of a concrete block size that needs to=
<br>
> be solved anyway, often specific to Bitcoin Core (ie other<br>
> implementations, say libbitcoin may not necessarily share these<br>
> problems).<br>
<br>
- Bitcoin Core's mempool is unbounded in size and can make the program<=
br>
crash by using too much memory.<br>
- There's no good way to increase the fee of a transaction that is<br>
taking too long to be mined without the "double spending" transac=
tion<br>
with the higher fee being blocked by most nodes which follow Bitcoin<br>
Core's default policy for conflicting spends replacements (aka "fi=
rst<br>
seen" replacement policy).<br>
<br>
I have started with the 3 concerns that I read more often, but please<br>
suggest more concerns for these categories and suggest other<br>
categories if you think there's more.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
--089e0111c0169a2d45051d2e4be2--
|
