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-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WILIa-0003ck-F8
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Feb 2014 16:56:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.46 as permitted sender)
client-ip=209.85.219.46; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f46.google.com;
Received: from mail-oa0-f46.google.com ([209.85.219.46])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WILIZ-0007mg-H8
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Feb 2014 16:56:04 +0000
Received: by mail-oa0-f46.google.com with SMTP id l6so696774oag.19
for <bitcoin-development@lists.sourceforge.net>;
Tue, 25 Feb 2014 08:55:58 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.219.167 with SMTP id pp7mr865918obc.85.1393347358112;
Tue, 25 Feb 2014 08:55:58 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Tue, 25 Feb 2014 08:55:58 -0800 (PST)
In-Reply-To: <20140225144922.GA25549@savin>
References: <20140225044116.GA28050@savin>
<f35865264f37315d580a30dc49789a5a.squirrel@fulvetta.riseup.net>
<CANEZrP1wB9zpnD+DOnmCNycEGB+nZMt8gQrjpn5V92MMkausaA@mail.gmail.com>
<20140225144922.GA25549@savin>
Date: Tue, 25 Feb 2014 22:25:58 +0530
X-Google-Sender-Auth: sEi_-s72mA-Rr6yivh6v0w3TPsE
Message-ID: <CANEZrP0pDjHr3v2w_zKnME+6GjVdvV5HYjrLH7xthbNdBniK4g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0141ab82546ee504f33df6d2
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1WILIZ-0007mg-H8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fee drop
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: Tue, 25 Feb 2014 16:56:04 -0000
--089e0141ab82546ee504f33df6d2
Content-Type: text/plain; charset=UTF-8
There are two possibilities.
One is that the value of transactions with the new lower fee is outweighed
by increased orphan costs and miners refuse to include them en-masse.
Wallet authors lose the staring match and go back to setting higher fees
until such a time as block propagation is optimised and the orphan costs go
down. Nodes that are encountering memory pressure can increase their min
relay fee locally until their usage fits inside their resources. It's
annoying to do this by hand but by no means infeasible.
The other is that the total value of transactions even with the lower fee
is not outweighed by orphan costs. The value of a transaction is higher
than its simple monetary value - the fact that Bitcoin is useful, growing
and considered cheap also has a value which is impossible to calculate, but
we know it's there (because Bitcoin does not exist in a vacuum and has
competitors). In this case miners stop including lots of useful
transactions that represent desired economic activity and are put under
pressure by the community to change their policies. If all miners do this
and making small blocks is considered errant behaviour, then we're back to
the same situation we're in today.
The possibility you're worried about - that someone does a DoS attack by
flooding the network with small transactions - is only an issue in the
first situation, and it is by no means the easiest or cheapest way to DoS
Bitcoin. We all want to see more DoS resistance but basically any change to
Bitcoin can be objected to on anti-DoS grounds at the moment, and this will
remain the case until someone steps up to spend significant time on
resource scheduling and code audits.
--089e0141ab82546ee504f33df6d2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There are two possibilities.=C2=A0<div><br></div><div>One =
is that the value of transactions with the new lower fee is outweighed by i=
ncreased orphan costs and miners refuse to include them en-masse. Wallet au=
thors lose the staring match and go back to setting higher fees until such =
a time as block propagation is optimised and the orphan costs go down. Node=
s that are encountering memory pressure can increase their min relay fee lo=
cally until their usage fits inside their resources. It's annoying to d=
o this by hand but by no means infeasible.</div>
<div><br></div><div>The other is that the total value of transactions even =
with the lower fee is not outweighed by orphan costs. The value of a transa=
ction is higher than its simple monetary value - the fact that Bitcoin is u=
seful, growing and considered cheap also has a value which is impossible to=
calculate, but we know it's there (because Bitcoin does not exist in a=
vacuum and has competitors). In this case miners stop including lots of us=
eful transactions that represent desired economic activity and are put unde=
r pressure by the community to change their policies. If all miners do this=
and making small blocks is considered errant behaviour, then we're bac=
k to the same situation we're in today.</div>
<div><br></div><div>The possibility you're worried about - that someone=
does a DoS attack by flooding the network with small transactions - is onl=
y an issue in the first situation, and it is by no means the easiest or che=
apest way to DoS Bitcoin. We all want to see more DoS resistance but basica=
lly any change to Bitcoin can be objected to on anti-DoS grounds at the mom=
ent, and this will remain the case until someone steps up to spend signific=
ant time on resource scheduling and code audits.</div>
<div><br></div><div><br></div></div>
--089e0141ab82546ee504f33df6d2--
|
