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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <odinn.cyberguerrilla@riseup.net>) id 1WIQjN-0007nm-OH
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Feb 2014 22:44:05 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net
designates 198.252.153.129 as permitted sender)
client-ip=198.252.153.129;
envelope-from=odinn.cyberguerrilla@riseup.net;
helo=mx1.riseup.net;
Received: from mx1.riseup.net ([198.252.153.129])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WIQjM-000464-Ov
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Feb 2014 22:44:05 +0000
Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "Gandi Standard SSL CA" (not verified))
by mx1.riseup.net (Postfix) with ESMTPS id BA4BD48D48;
Tue, 25 Feb 2014 14:43:58 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla@fulvetta.riseup.net)
with ESMTPSA id 467E3362
Received: from localhost (127.0.0.1)
(SquirrelMail authenticated user odinn.cyberguerrilla)
by fulvetta.riseup.net with HTTP; Tue, 25 Feb 2014 14:43:58 -0800
Message-ID: <4aa09921d781ac54695325935fa36920.squirrel@fulvetta.riseup.net>
In-Reply-To: <CANEZrP0pDjHr3v2w_zKnME+6GjVdvV5HYjrLH7xthbNdBniK4g@mail.gmail.com>
References: <20140225044116.GA28050@savin>
<f35865264f37315d580a30dc49789a5a.squirrel@fulvetta.riseup.net>
<CANEZrP1wB9zpnD+DOnmCNycEGB+nZMt8gQrjpn5V92MMkausaA@mail.gmail.com>
<20140225144922.GA25549@savin>
<CANEZrP0pDjHr3v2w_zKnME+6GjVdvV5HYjrLH7xthbNdBniK4g@mail.gmail.com>
Date: Tue, 25 Feb 2014 14:43:58 -0800
From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: "Mike Hearn" <mike@plan99.net>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.97.8 at mx1
X-Virus-Status: Clean
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [198.252.153.129 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
X-Headers-End: 1WIQjM-000464-Ov
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 22:44:05 -0000
Am suggesting a (possible) mitigation of [possible flooding, etc], via
some kind of discussion (potentially process BIP, related to bundling and
/ or randomization) not now, but down the road. However, needs more
thought and analysis (you mentioned code audit?) before it could be
floated around or acted on in any way shape or form. Thanks for this
discussion, things to think about.... am watching, listening (...)
> There are two possibilities.
>
> One is that the value of transactions with the new lower fee is outweig=
hed
> by increased orphan costs and miners refuse to include them en-masse.
> Wallet authors lose the staring match and go back to setting higher fee=
s
> until such a time as block propagation is optimised and the orphan cost=
s
> go
> down. Nodes that are encountering memory pressure can increase their mi=
n
> 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 f=
ee
> is not outweighed by orphan costs. The value of a transaction is higher
> than its simple monetary value - the fact that Bitcoin is useful, growi=
ng
> 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 th=
is
> 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 b=
y
> 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 D=
oS
> Bitcoin. We all want to see more DoS resistance but basically any chang=
e
> 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.
>
|
