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
|
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 <operator@bitminter.com>) id 1S3zfp-0007wG-I1
for bitcoin-development@lists.sourceforge.net;
Sun, 04 Mar 2012 00:51:41 +0000
X-ACL-Warn:
Received: from thalia-smout.broadpark.no ([80.202.8.21])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1S3zfo-0005gt-5g for bitcoin-development@lists.sourceforge.net;
Sun, 04 Mar 2012 00:51:41 +0000
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from terra-smin.broadpark.no ([80.202.8.13])
by thalia-smout.broadpark.no
(Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12
2010)) with ESMTP id <0M0C00CJQ29RFY80@thalia-smout.broadpark.no> for
bitcoin-development@lists.sourceforge.net; Sun,
04 Mar 2012 00:51:27 +0100 (CET)
Received: from xr4.com ([80.203.26.133]) by terra-smin.broadpark.no
(Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12
2010)) with ESMTP id <0M0C00EAY29RBAJ0@terra-smin.broadpark.no> for
bitcoin-development@lists.sourceforge.net; Sun,
04 Mar 2012 00:51:27 +0100 (CET)
Received: from [192.168.1.4] (grimreaper.xr4.com [192.168.1.4])
by xr4.com (Postfix) with ESMTP id B686F27100 for
<bitcoin-development@lists.sourceforge.net>; Sun,
04 Mar 2012 00:51:27 +0100 (CET)
Message-id: <4F52AE86.2060102@bitminter.com>
Date: Sun, 04 Mar 2012 00:51:34 +0100
From: Geir Harald Hansen <operator@bitminter.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216
Thunderbird/10.0.2
To: bitcoin-development@lists.sourceforge.net
References: <201202281706.22650.luke@dashjr.org>
In-reply-to: <201202281706.22650.luke@dashjr.org>
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: 1S3zfo-0005gt-5g
Subject: Re: [Bitcoin-development] getmemorypool BIP process
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: Sun, 04 Mar 2012 00:51:41 -0000
On 28.02.2012 23:06, Luke-Jr wrote:
> Please review and comment/critique:
> https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool
Looking forward to implementing this in my pool backend and miner.
A few comments:
"transactions add or remove transactions (both of the above; default if
"transactions" omitted) "
In the above, you may want to specify that the "transactions" referred
to here is the one in the first table (JSON-RPC response object) and not
the mutations. For a moment I thought free tx editing was the default.
Long polling as currently implemented in pools has a race condition.
Does the miner reconnect first or does another block change happen
first? "Double" block changes are common with merged mining and I'm
doing all sorts of tricks in my pool backend to reduce this problem.
How about another entry "longpollid" in long poll responses. The last
seen longpollid should be included by the client in future long poll
requests. This enables the server to see if the client has missed any
block changes. The ID could perhaps be submitted in an HTTP header
(X-LongPollID?) if we wish to keep the JSON-RPC params empty, or params
could hold an object with a key "longpollid". Could be a string or
number, like "workid".
Another useful value in the getmemorypool response would be "height", so
the miner can include the correct height in the coinbase. I would like
that in bitcoind as well. One JSON-RPC call instead of two, and no race
condition between getmemorypool and getblocknumber.
It should be explained how target vs. fulltarget works.
Perhaps some things should be optional for a client to implement? I
think "noncerange" is of limited use and there's a good chance of
getting the endianness wrong.
Regards,
Geir Harald Hansen
|
