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
|
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 <pw@vps7135.xlshosting.net>) id 1T24ZZ-0001VF-Sy
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Aug 2012 18:13:33 +0000
X-ACL-Warn:
Received: from vps7135.xlshosting.net ([178.18.90.41])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1T24ZY-0004Tu-Lf for bitcoin-development@lists.sourceforge.net;
Thu, 16 Aug 2012 18:13:33 +0000
Received: by vps7135.xlshosting.net (Postfix, from userid 1000)
id 67614605C9; Thu, 16 Aug 2012 19:56:39 +0200 (CEST)
Date: Thu, 16 Aug 2012 19:56:39 +0200
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Jeff Garzik <jgarzik@exmulti.com>
Message-ID: <20120816175637.GA13454@vps7135.xlshosting.net>
References: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED
0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1T24ZY-0004Tu-Lf
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
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: Thu, 16 Aug 2012 18:13:34 -0000
On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote:
> Consensus was we should do a BIP for all P2P changes, so here it is...
> feedback requested.
>
> https://en.bitcoin.it/wiki/BIP_0035
I like the idea of being able to query the memory pool of a node; the
implementation is straightforward, which is good. Maybe effectively using the
command can be added? I suppose it is interesting in general for nodes to
get a memory pool refill at startup anyway.
> 1) Upon receipt of a "mempool" message, the node will respond
> with an "inv" message containing MSG_TX hashes of all the
> transactions in the node's transaction memory pool.
>
> An "inv" message is always returned, even if empty.
I'm not sure about this last. What is it good for? inv packets can always be
sent, even not in response to others, so it is not that this gives you an
acknowledgement the mempool is updated?
> 3) Feature discovery is enabled by checking two "version" message attributes:
>
> a) Protocol version >= 60002
> b) NODE_NETWORK bit set in nServices
This seems safe, although it forces other full implementations that want to
expose protocol version 60002 (or later) to also implement this. What do they
think about this?
I would like to suggest to allocate an extra service bit for this. We still
have 63 left, and this is a well-defined and useful extra service that was
not yet provided by any earlier node. Doing that would also mean that
mempool-providing survices may be discovered before connecting to them, as
the service bits are carried around in addr messages. Any opinions about that?
--
Pieter
|
