Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SSrrF-0008Gt-6M for bitcoin-development@lists.sourceforge.net; Fri, 11 May 2012 15:34:17 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1SSrr9-0002hv-Gj for bitcoin-development@lists.sourceforge.net; Fri, 11 May 2012 15:34:17 +0000 Received: from ishibashi.localnet (unknown [97.96.85.141]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id BC655560540; Fri, 11 May 2012 15:34:05 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Fri, 11 May 2012 15:33:53 +0000 User-Agent: KMail/1.13.7 (Linux/3.2.12-gentoo; KDE/4.8.1; x86_64; ; ) X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Message-Id: <201205111533.55960.luke@dashjr.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1SSrr9-0002hv-Gj Cc: Inaba , kinlo@triplemining.com Subject: [Bitcoin-development] Please review: getmemorypool (BIP 22) revision X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 15:34:17 -0000 I have finally got around to revising the BIP 22 draft, and would appreciate further review: https://en.bitcoin.it/wiki/BIP_0022 I believe this revision addresses Geir's last email in March, as well as some practical problems some pools recently came across. To summarize the changes from the last revision in March: - The submitblock(, ) method is renamed to getmemorypool - Requesting a job now uses getmemorypool() to provide client capabilities and other information to the server - Longpolls use a parameter in the getmemorypool request, not necessarily a separate URI - The client can inform the server of its own size and sigop requirements in advance - The client can request detailed transaction data from the server, necessary to sanely manipulate the transactions included in the final block without discarding fees or making the block invalid due to not having enough - With both client and server support, blocks can be proposed before wasting time mining them, to ensure they are otherwise valid - Servers can be arranged into single logical services, with failover and load balancing (similar to the getwork X-Host-List and X-Switch-To extensions). You can see the full diff here: https://en.bitcoin.it/w/?title=BIP_0022&action=historysubmit&diff=26408&oldid=25544 Luke