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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@exmulti.com>) id 1T2Pls-0001wk-ET
for bitcoin-development@lists.sourceforge.net;
Fri, 17 Aug 2012 16:51:40 +0000
X-ACL-Warn:
Received: from mail-qa0-f54.google.com ([209.85.216.54])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1T2Plr-00024k-FE
for bitcoin-development@lists.sourceforge.net;
Fri, 17 Aug 2012 16:51:40 +0000
Received: by qatn12 with SMTP id n12so2005159qat.13
for <bitcoin-development@lists.sourceforge.net>;
Fri, 17 Aug 2012 09:51:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-originating-ip:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=TBXCpVNJtm8VuhCTs1yhqj9wXlFxJNzceOt5neO9whE=;
b=i3KtQPeJFFUSCLRoC03Aoykl1iJtDWBjJjEP1s0xkwBZ6Ue05Wc2QZBKDPfSrJ36UV
d1oTCpPyCtKw/MsxrMXHQMwgqMOTyL3XsXdySssxGYBA+VXdF5McZipTROLV6YtxEwpr
/MY+xO38ts7ILqOQ83As2tw1zUib46pCWERcgwCppeYZ9jGgXvIDBH6bnbk5JZ3ep60u
KJZK7H0Ruw6r50IXC0V3ufpm8to3NKNjo+kNvqj8n0mSka5pJKLnYqhV3YerLIK8dtkb
nFLNaskalkFZ755AAbmYMj3OC9ya9D9I+6gUmhPIrNNOjyci+fiee+U07keMXY04DG2r
gOIg==
MIME-Version: 1.0
Received: by 10.229.135.149 with SMTP id n21mr4104782qct.131.1345222293823;
Fri, 17 Aug 2012 09:51:33 -0700 (PDT)
Received: by 10.49.97.6 with HTTP; Fri, 17 Aug 2012 09:51:33 -0700 (PDT)
X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2]
In-Reply-To: <20120817134000.GA30465@vps7135.xlshosting.net>
References: <CA+8xBpcfxdpg-z4OQab3379amznM30Ae-Kurko0BKuySwfBy+Q@mail.gmail.com>
<20120816175637.GA13454@vps7135.xlshosting.net>
<502D482A.2090609@justmoon.de>
<1345150660.5139.YahooMailNeo@web121003.mail.ne1.yahoo.com>
<CA+8xBpd4uHO63QCFtOqLB6SPLYO_9y2fQGbNLFH81ovGukhBmg@mail.gmail.com>
<20120817134000.GA30465@vps7135.xlshosting.net>
Date: Fri, 17 Aug 2012 12:51:33 -0400
Message-ID: <CA+8xBpcLk04m8pX3bA14H4MBamT1-1Exd6EyxOZqER8u9C0WAA@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQllJAU4zB+15iHJTFcSkL5UCCZEK4TUcxvps/jsFTsY4efOQ7Pc7DVsErKUL4NmU2lnszGw
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1T2Plr-00024k-FE
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: Fri, 17 Aug 2012 16:51:40 -0000
On Fri, Aug 17, 2012 at 9:40 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> On Thu, Aug 16, 2012 at 05:05:58PM -0400, Jeff Garzik wrote:
>> On MSG_MEMTX: The current version has a much higher Just Works value.
>>
>> On empty "inv": It is generally better to do something
>> unconditionally, than have a response generated only under certain
>> conditions.
>>
>> And Alan is correct to note that unknown messages are ignored
>> (intentionally, for expansion). However, unconditionally returning a
>> response has little to do with feature probing/discovery. It is
>> simply a clear, deterministic indication that processing is complete,
>> for each invocation.
>
> I disagree. Returning an empty "inv" is a very strange way of replying
> "empty mempool". Bitcoin P2P is not a request-response protocol, and
> "inv" messages are sent where there are inventory items to send. The
> reaction to a request (for example "getblocks") can be nothing, or one
> or more "inv" messages if necessary. Special casing an empty "inv" to
> mean empty mempool is trying to hack a request-response system on top
> of the asynchronous system.
OK, just updated 'mempool' branch to not return "inv" if mempool is empty.
> If there is need for confirming the transmission of the mempool is
> complete, the proposal to use a MSG_MEMTX sounds good to me. No client
> will ever receive such an inv without requesting the mempool, and
> implementing handling MSG_MEMTX is trivial.
MSG_MEMTX is not a good idea for this use case. Just sent a ping(nonce).
Bitcoin P2P processes requests in-order, and responds accordingly.
The remote end may insert asynchronous messages into the response
stream, certainly, but responses to queries are processed and returned
in-order. A 'getdata' response is fully sent before a 'ping' response
is sent, etc.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
