EDIT: p2pool has been actively using this RPC call on bitcoind, too
Topic: Proposal: New RPC call to get the transactions to be included in the next block (Read 1314 times)
September 24, 2011, 05:17:22 PM
I have an instance of bitcoind that's been running with this patch (against 0.3.24) for just under 2 weeks continually, and encountered no issues. It's stable.
EDIT: p2pool has been actively using this RPC call on bitcoind, too
EDIT: p2pool has been actively using this RPC call on bitcoind, too
September 02, 2011, 01:09:22 AM
Updated the pull request, this new revision is much better: It's more general, blocks can be submitted via it, and it provides all that's needed to create blocks. It's essentially a complete alternative to getwork for intelligent clients.
https://github.com/bitcoin/bitcoin/pull/476/files
Code:
getmemorypool [data]
If [data] is not specified, returns data needed to construct a block to work on:
"version" : block version
"previousblockhash" : hash of current highest block
"transactions" : contents of non-coinbase transactions that should be included in the next block
"coinbasevalue" : maximum allowable input to coinbase transaction, including the generation award and transaction fees
"time" : timestamp appropriate for next block
"bits" : compressed target of next block
If [data] is specified, tries to solve the block and returns true if it was successful.
https://github.com/bitcoin/bitcoin/pull/476/files
August 24, 2011, 06:16:33 PM
just wanted to make sure i understand. if this makes it into the client, then those mining on p2pool can use the classic bitcoin client. if it doesn't make it in, they either need to use the bitcoin client patched with this or they can mine without this path but if that node happens to solve the block, it will be absent any transactions?
Exactly.
specifically, what i am wondering is lets say half the p2pool miners are running with this and half aren't. do they work together or are there forking p2pool sharechains?
The p2pool sharechain won't fork, each share has its own set of transactions and each node has freedom to include whichever it wants.
August 24, 2011, 06:02:31 PM
just wanted to make sure i understand. if this makes it into the client, then those mining on p2pool can use the classic bitcoin client. if it doesn't make it in, they either need to use the bitcoin client patched with this or they can mine without this path but if that node happens to solve the block, it will be absent any transactions?
specifically, what i am wondering is lets say half the p2pool miners are running with this and half aren't. do they work together or are there forking p2pool sharechains?
now that p2pool is more than 10 ghash/s and growing this will start to matter.
specifically, what i am wondering is lets say half the p2pool miners are running with this and half aren't. do they work together or are there forking p2pool sharechains?
now that p2pool is more than 10 ghash/s and growing this will start to matter.
August 24, 2011, 03:20:57 PM
A new command ("getmemorypool", possibly) that let a JSON-RPC client access bitcoin's transaction pool would be useful. It would help anybody that wants to mine, but compute their own generation transaction instead of letting bitcoind do it.
Initial revision: https://github.com/bitcoin/bitcoin/pull/476
EDIT: That revision adds a call "getmemorypool" that takes no arguments and returns a JSON Object with the following members:
* transactions: list of hex-encoded transaction hashes
* fees: integer amount of total fees for those transactions, in satoshis
* previous_block: hash of block that these transactions are valid for following
Initial revision: https://github.com/bitcoin/bitcoin/pull/476
EDIT: That revision adds a call "getmemorypool" that takes no arguments and returns a JSON Object with the following members:
* transactions: list of hex-encoded transaction hashes
* fees: integer amount of total fees for those transactions, in satoshis
* previous_block: hash of block that these transactions are valid for following
Jump to: