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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1Yqkec-0000Kr-8j
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 15:57:34 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.171 as permitted sender)
client-ip=209.85.212.171; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wi0-f171.google.com;
Received: from mail-wi0-f171.google.com ([209.85.212.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yqkeb-0007bp-87
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 15:57:34 +0000
Received: by widdi4 with SMTP id di4so32342282wid.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 08:57:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.37.207 with SMTP id a15mr7450959wik.2.1431100647228;
Fri, 08 May 2015 08:57:27 -0700 (PDT)
Received: by 10.27.12.78 with HTTP; Fri, 8 May 2015 08:57:27 -0700 (PDT)
In-Reply-To: <16096345.A1MpJQQkRW@crushinator>
References: <16096345.A1MpJQQkRW@crushinator>
Date: Fri, 8 May 2015 18:57:27 +0300
Message-ID: <CAE28kUSkQ6YWzkcqU9RqRkZzHUR_8wYj1pTxGF8Z4gp5SztdAA@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=e89a8f6473ebb74ad005159415f3
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
(alex.mizrahi[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: 1Yqkeb-0007bp-87
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: Fri, 08 May 2015 15:57:34 -0000
--e89a8f6473ebb74ad005159415f3
Content-Type: text/plain; charset=UTF-8
Adaptive schedules, i.e. those where block size limit depends not only on
block height, but on other parameters as well, are surely attractive in the
sense that the system can adapt to the actual use, but they also open a
possibility of a manipulation.
E.g. one of mining companies might try to bankrupt other companies by
making mining non-profitable. To do that they will accept transactions with
ridiculously low fees (e.g. 1 satoshi per transaction). Of course, they
will suffer losees themselves, but the they might be able to survive that
if they have access to financial resources. (E.g. companies backed by banks
and such will have an advantage).
Once competitors close down their mining operations, they can drive fees
upwards.
So if you don't want to open room for manipulation (which is very hard to
analyze), it is better to have a block size hard limit which depends only
on block height.
On top of that there might be a soft limit which is enforced by the
majority of miners.
--e89a8f6473ebb74ad005159415f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">Adaptive schedules, i.e. those =
where block size limit depends not only on block height, but on other param=
eters as well, are surely attractive in the sense that the system can adapt=
to the actual use, but they also open a possibility of a manipulation.</di=
v><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">E.g. one =
of mining companies might try to bankrupt other companies by making mining =
non-profitable. To do that they will accept transactions with ridiculously =
low fees (e.g. 1 satoshi per transaction). Of course, they will suffer lose=
es themselves, but the they might be able to survive that if they have acce=
ss to financial resources. (E.g. companies backed by banks and such will ha=
ve an advantage).</div><div class=3D"gmail_extra">Once competitors close do=
wn their mining operations, they can drive fees upwards.</div><div class=3D=
"gmail_extra"><br></div><div class=3D"gmail_extra">So if you don't want=
to open room for manipulation (which is very hard to analyze), it is bette=
r to have a block size hard limit which depends only on block height.</div>=
<div class=3D"gmail_extra">On top of that there might be a soft limit which=
is enforced by the majority of miners.</div></div>
--e89a8f6473ebb74ad005159415f3--
|
