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
|
Return-Path: <patrick.strateman@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4687140A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 19:46:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com
[209.85.192.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D7BD153
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 19:46:03 +0000 (UTC)
Received: by pdrg1 with SMTP id g1so79588158pdr.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 12:46:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:disposition-notification-to:date:from:user-agent
:mime-version:to:subject:references:in-reply-to:content-type;
bh=aHtL8jepvW+HZ+lcUV8OLA32EhpvxplihCCz7mkn5JQ=;
b=OT3fpLij0Q0nNBQF+v4NXKyehX9YQbTsWnKEn9R3B6opb/Yd1GrJAAF/XjhQ6nJHqM
obv4Ui5QflBdy7RlEyY1epSTfSWd/0Tdo9FpLO8Qhkj2+V0UUFDFl1iCMydxsBJjo7AT
Kj/P788iws0ZvnRaG4/Ut7LQpvwdM5LRvxmZbPlIwSZt1Aedn47LERtDFfCDePd1z1Bh
Suj1ET1mMN/xs6lTXO3/zmJ3ZT2fPB6CP1QA68o+oemnZ4zv2cyKC6NQR9Y5l0K5iYt8
wVeqXhUH5r/wx+8UGpedaD3TY87JaAC7KmGJ4quUSvnHsCqEVwy+9V1nov0F+vOc9PNE
5/2Q==
X-Received: by 10.68.206.68 with SMTP id lm4mr42400695pbc.147.1437248763362;
Sat, 18 Jul 2015 12:46:03 -0700 (PDT)
Received: from [192.168.43.241] ([166.170.42.137])
by smtp.googlemail.com with ESMTPSA id
pq3sm15086896pbb.24.2015.07.18.12.46.01
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 18 Jul 2015 12:46:02 -0700 (PDT)
Message-ID: <55AAACF9.90007@gmail.com>
Date: Sat, 18 Jul 2015 12:46:01 -0700
From: Patrick Strateman <patrick.strateman@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <20150718185259.GA3477@muck>
In-Reply-To: <20150718185259.GA3477@muck>
Content-Type: multipart/alternative;
boundary="------------030202040003040402040300"
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] Do we really need a mempool? (for relay nodes)
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: Sat, 18 Jul 2015 19:46:04 -0000
This is a multi-part message in MIME format.
--------------030202040003040402040300
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Relay nodes do not need a mempool, but do need some mechanism to avoid
DoS issues.
Wallet nodes can use the mempool for fee estimation (in addition to
looking at past blocks).
On 07/18/2015 11:52 AM, Peter Todd via bitcoin-dev wrote:
> As in, do relay nodes need to keep a record of the transactions they've
> relayed? Strictly speaking, the answer is no: one a tx is relayed modulo
> DoS concerns the entire thing can be discarded by the node. (unconfirmed
> txs spending other unconfirmed txs can be handled by creating packages
> of transactions, evaluated as a whole)
>
> To mitigate DoS concerns, we of course have to have some per-UTXO limit
> on bandwidth relayed, but that task can be accomplished by simply
> maintaining some kind of per-UTXO record of bandwidth used. For instance
> if the weighted fee and fee/KB were recorded, and forced to - say -
> double for each additional tx relayed that spent a given UTXO you would
> have a clear and simple upper limit of lifetime bandwidth. Equally it's
> easy to limit bandwidth moment to moment by asking peers for highest
> fee/KB transactions they advertise first, stopping when our bandwidth
> limit is reached.
>
> You probably could even remove IsStandard() pretty much entirely with
> the right increasingly expensive "replacement" policy, relying on it
> alone to provide anti-DoS. Obviously this would simplify some of the
> debates around mining policy! This could even be re-used for scalable a
> general-purpose messaging network paid by coin ownership if the UTXO set
> is split up, and some kind of expiration over time policy is
> implemented.
>
> Miners of course would still want to have a mempool, but that codebase
> may prove simpler if it doesn't have to work double-duty for relaying as
> well.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--------------030202040003040402040300
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Relay nodes do not need a mempool, but do need some mechanism to
avoid DoS issues.<br>
<br>
Wallet nodes can use the mempool for fee estimation (in addition to
looking at past blocks).<br>
<br>
<div class="moz-cite-prefix">On 07/18/2015 11:52 AM, Peter Todd via
bitcoin-dev wrote:<br>
</div>
<blockquote cite="mid:20150718185259.GA3477@muck" type="cite">
<pre wrap="">As in, do relay nodes need to keep a record of the transactions they've
relayed? Strictly speaking, the answer is no: one a tx is relayed modulo
DoS concerns the entire thing can be discarded by the node. (unconfirmed
txs spending other unconfirmed txs can be handled by creating packages
of transactions, evaluated as a whole)
To mitigate DoS concerns, we of course have to have some per-UTXO limit
on bandwidth relayed, but that task can be accomplished by simply
maintaining some kind of per-UTXO record of bandwidth used. For instance
if the weighted fee and fee/KB were recorded, and forced to - say -
double for each additional tx relayed that spent a given UTXO you would
have a clear and simple upper limit of lifetime bandwidth. Equally it's
easy to limit bandwidth moment to moment by asking peers for highest
fee/KB transactions they advertise first, stopping when our bandwidth
limit is reached.
You probably could even remove IsStandard() pretty much entirely with
the right increasingly expensive "replacement" policy, relying on it
alone to provide anti-DoS. Obviously this would simplify some of the
debates around mining policy! This could even be re-used for scalable a
general-purpose messaging network paid by coin ownership if the UTXO set
is split up, and some kind of expiration over time policy is
implemented.
Miners of course would still want to have a mempool, but that codebase
may prove simpler if it doesn't have to work double-duty for relaying as
well.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------030202040003040402040300--
|
