Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1S3Xvr-0002Ol-VC for bitcoin-development@lists.sourceforge.net; Fri, 02 Mar 2012 19:14:23 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1S3Xvo-00022I-Vl for bitcoin-development@lists.sourceforge.net; Fri, 02 Mar 2012 19:14:23 +0000 Received: from ishibashi.localnet (fl-184-4-164-217.dhcp.embarqhsd.net [184.4.164.217]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 8697B560548; Fri, 2 Mar 2012 19:14:15 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net, Amir Taaki Date: Fri, 2 Mar 2012 14:14:05 -0500 User-Agent: KMail/1.13.7 (Linux/3.2.2-gentoo; KDE/4.7.4; x86_64; ; ) References: <1330714301.3840.YahooMailNeo@web121006.mail.ne1.yahoo.com> In-Reply-To: <1330714301.3840.YahooMailNeo@web121006.mail.ne1.yahoo.com> X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583 X-PGP-Key-ID: 665FC11DD53E9583 X-PGP-Keyserver: x-hkp://subkeys.pgp.net MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201203021414.07109.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. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1S3Xvo-00022I-Vl Subject: Re: [Bitcoin-development] JSON-RPC is BIP territory or not? 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, 02 Mar 2012 19:14:24 -0000 On Friday, March 02, 2012 1:51:41 PM Amir Taaki wrote: > It is a implementation-specific non-bitcoin-protocol proposal. My > understanding of BIPs is that they apply across bitcoin implementations > and largely focus on the most generic use-cases (like the URIs) and the > protocol. Things which affect all clients, and allow the system to > function as a united whole. This isn't implementation-specific. If you read it, you should notice it is intentionally generic for multiple use-cases. Right now bitcoind supports getmemorypool for a few use cases, but this proposed BIP enables it to be utilized for many more. Specifically, Eligius and at least a few other pools wish to move toward a more decentralized method of pooled mining (similar to the proprietary p2pool protocol). Eligius already supports miners producing their own work with getmemorypool using this draft, and our Eloipool server is open source (AGPL-3) for others to adopt (I know of at least one other pool planning to do so). Other pools not using Eloipool also have expressed interest in this, so a standard is desirable.