BIP 0035: Difference between revisions
Jump to navigation
Jump to search
→Specification: specifically define mempool message as empty message |
|||
Line 16: | Line 16: | ||
==Motivation== | ==Motivation== | ||
Several use cases make it desireable to | Several use cases make it desireable to expose a network node's transaction memory pool: | ||
# SPV clients, wishing to obtain zero-confirmation transactions sent or received. | # SPV clients, wishing to obtain zero-confirmation transactions sent or received. | ||
# Miners, downloading existing network transactions after a restart. | # Miners, downloading existing network transactions after a restart. |
Revision as of 17:44, 16 August 2012
This page describes a BIP (Bitcoin Improvement Proposal). |
BIP: 35 Title: mempool message Author: Jeff Garzik <jgarzik@exmulti.com> Status: Draft Type: Standards Track Created: 2012-08-16
Abstract
Make a network node's transaction memory pool accessible via a new "mempool" message. Extend the existing "getdata" message behavior to permit accessing the transaction memory pool.
Motivation
Several use cases make it desireable to expose a network node's transaction memory pool:
- SPV clients, wishing to obtain zero-confirmation transactions sent or received.
- Miners, downloading existing network transactions after a restart.
- Remote network diagnostics.
Specification
- The mempool message is defined as an empty message where pchCommand == "mempool"
- Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool. An "inv" message is always returned, even if empty.
- The typical node behavior in response to an "inv" is "getdata". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support "mempool", an implementation must extend its "getdata" message support to querying the memory pool.
- Feature discovery is enabled by checking two "version" message attributes:
- Protocol version >= 60002
- NODE_NETWORK bit set in nServices
Backward compatibility
Older clients remain 100% compatible and interoperable after this change.