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
|
Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 06AD7409
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Jul 2015 08:59:52 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 068FD190
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Jul 2015 08:59:50 +0000 (UTC)
Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id 79B23420BA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 19 Jul 2015 08:59:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1437296390; bh=5H3EsVtmiW4/Q3O/NwaimQN98qWercL6mIpowHcgG4g=;
h=Date:From:To:Subject:References:In-Reply-To:From;
b=Duhe/YowZhEdi/frBqOaDG1lVXWQkGuNdFan7S8fEgFYsXcuaKRYPkSHmgM0BXbwT
fehz5spD3eSzHy1nQgG1gmBoAgxA6YjC46RW3EqyIUJNxcGlBuySQXn2isS1So9vkw
9Xf0PtFraLBRIlUvuJR1+sLOjhajoKa1lxu/oMeQ=
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla)
with ESMTPSA id 334C71FC52
Message-ID: <55AB6705.7080701@riseup.net>
Date: Sun, 19 Jul 2015 01:59:49 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <20150718185259.GA3477@muck> <55AAACF9.90007@gmail.com>
In-Reply-To: <55AAACF9.90007@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1
X-Virus-Status: Clean
X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD,
UNPARSEABLE_RELAY 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: Sun, 19 Jul 2015 08:59:52 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Some brief thoughts, adding here a suggestion for a dynamic approach
to the issue. (e.g. each additional tx relayed has some thing
associated with it, that is, a "doubling" for each additional tx
relayed that spends a given UTXO, doesn't sound like it would be the
most dynamic approach to the issue; considering that full nodes use
the (UTXOs) to establish if transactions are valid – all inputs to a
transaction must be in the UTXO database for it to be valid, but
rather, would end up ratcheting upward the fee/kB for each additional
tx relayed, as proposed).
A more dynamic fee approach would be a better one, imho, but how is
this to occur?
Quoting from Gavin Andresen's http://gavinandresen.ninja/utxo-uhoh,
"The entire UTXO set doesn’t have to be in RAM; it can be stored on an
SSD or spinning hard disk. The access pattern to the UTXO is not
random; outputs that were spent recently are more likely to be
re-spent than outputs that have not been spent in a long time. Bitcoin
Core already has a multi-level UTXO cache, thanks to the hard work of
Pieter Wuille."
The relay nodes would, in this scenario that is proposed here in this
message, be confirming and discarding; the wallet nodes, if I
understand properly, in this scenario, as proposed, should be
retaining (keeping a record of the transactions they've relayed and
using a mempool).
There are some questions here:
- - How is the mempool to be limited?
- - What is the mechanism by which the UTXO set is stored (or proposed
to be stored)?
- - How would dynamic fee determinations be calculated?
- - Please describe more the general purpose messaging network?
Thank you
On 07/18/2015 12:46 PM, Patrick Strateman via bitcoin-dev wrote:
> 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
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVq2cFAAoJEGxwq/inSG8CIo4IAJAZ97NvW6Qdjd6HLN8q2074
sEUGdDeonARiQZXLfGyTJVg43Yb6LKPqkjWPQEgl9LLNni8t99iUqu3BJxedRDjd
8x+/F8n5VJrUrn1pXUcbC1aWss1y8JPTO2KpF/WL254IFc8iE8MJf4YF8PDSgy5j
9uW8NvWvdT4dz+rXu9vqfcplz8x7NGQ+CWN2N2JlChhKLMFprXPIx8a7NQwaKdrY
lTpgAJWGMyPGNCmYQprBjIjOfp8tdTLQFlsLUAsXDmEisJX9goRVGMsHOWLTREoA
l3kTgM0WMv6MIG7NOQQcWLD7cZdwWYR9e49hc27VcHt2R/FTepvnwPqo2GtE0tM=
=eRbR
-----END PGP SIGNATURE-----
|
