BIP 0035: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Jgarzik (talk | contribs)
Add new BIP 35
 
Jgarzik (talk | contribs)
m →‎Specification: presentation editing
Line 23: Line 23:
==Specification==
==Specification==


# 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.
# 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.
  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:
# Feature discovery is enabled by checking two "version" message attributes:



Revision as of 17:27, 16 August 2012

This page describes a BIP (Bitcoin Improvement Proposal).
Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.

  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 expore a network node's transaction memory pool:

  1. SPV clients, wishing to obtain zero-confirmation transactions sent or received.
  2. Miners, downloading existing network transactions after a restart.
  3. Remote network diagnostics.

Specification

  1. 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.
  2. 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.
  3. Feature discovery is enabled by checking two "version" message attributes:
    1. Protocol version >= 60002
    2. NODE_NETWORK bit set in nServices

Backward compatibility

Older clients remain 100% compatible and interoperable after this change.

Implementation

https://github.com/bitcoin/bitcoin/pull/1641