JSON-RPC is BIP territory or not?

Hi,

I got sent this BIP:

https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool

What is your opinion on this? Is it BIP related?

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.

That BIPs especially focus on the protocol, and that something like this is outside the mandate of the BIP process.

For instance, we could imagine a future scenario. Bitcoin-Qt is currently based off bitcoind's codebase. However wumpus built the client in mind with an abstraction layer to enable multiple backends (a good design). In our hypothetical situation, there are 3 different backend codebases using Bitcoin-Qt. I do not think a proposal to mandate a changing to Bitcoin-Qt's abstraction layer or a change in the UI placement would be appropriate BIP material.

OTOH, many clients do need to make use of URIs and the BIP process is totally correct, as it standardises a behaviour which is needed for interoperability of the network and community.

Thoughts?

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.

Since several independent clients (I know at least libcoin <https://github.com/ceptacle/libcoin/blob/master/src/coinHTTP/RequestHandler.cpp> and BitcoinJS <https://github.com/bitcoinjs/bitcoinjs-server/tree/master/lib/rpc>) aim to implement JSON-RPC APIs which are either a superset of the original client's or have at least some compatible functions, I think you can make a case for including JSON-RPC API calls within the domain of BIPs.

In this instance the BIP aims to create a common protocol between different clients, miners, mining proxies and pools. That's a lot of software, so standardization definitely seems like a good idea and I can't think of a reason not to use the BIP process.

I have some comments on the content of the BIP, but since this thread is more of a meta-discussion I'll wait until the BIP is officially proposed.

On 3/2/2012 7:51 PM, Amir Taaki wrote:

> Hi,
>
> I got sent this BIP:
>
> https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool
>
> What is your opinion on this? Is it BIP related?
>
> 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.
>
> That BIPs especially focus on the protocol, and that something like
> this is outside the mandate
> of the BIP process.
>
> For instance, we could imagine a future scenario. Bitcoin-Qt is
> currently based off bitcoind's
> codebase. However wumpus built the client in mind with an abstraction
> layer to enable multiple
> backends (a good design). In our hypothetical situation, there are 3
> different backend codebases
> using Bitcoin-Qt. I do not think a proposal to mandate a changing to
> Bitcoin-Qt's abstraction
> layer or a change in the UI placement would be appropriate BIP material.
>
> OTOH, many clients do need to make use of URIs and the BIP process is
> totally correct, as it
> standardises a behaviour which is needed for interoperability of the
> network and community.
>
> Thoughts?
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

On Saturday, March 03, 2012 8:44:45 AM Stefan Thomas wrote:

> I have some comments on the content of the BIP, but since this thread is
> more of a meta-discussion I'll wait until the BIP is officially proposed.

Please do comment on the content, in the original thread if you prefer:

Message-Id: <201202281706.22650.luke@dashjr•org> Subject: [Bitcoin-development] getmemorypool BIP process Date: Tue, 28 Feb 2012 17:06:20 -0500