BIP 0035: Difference between revisions
Jump to navigation
Jump to search
Update BIP text with latest version from https://github.com/bitcoin/bips/blob/2d9e431fbe654640/bip-0035.mediawiki |
|||
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{bip}} | {{bip}} | ||
{{BipMoved|bip-0035.mediawiki}} | |||
<pre> | <pre> | ||
BIP: 35 | BIP: 35 | ||
Layer: Peer Services | |||
Title: mempool message | Title: mempool message | ||
Author: Jeff Garzik <jgarzik@exmulti.com> | Author: Jeff Garzik <jgarzik@exmulti.com> | ||
Status: | Comments-Summary: No comments yet. | ||
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0035 | |||
Status: Final | |||
Type: Standards Track | Type: Standards Track | ||
Created: 2012-08-16 | Created: 2012-08-16 | ||
| Line 16: | Line 20: | ||
==Motivation== | ==Motivation== | ||
Several use cases make it | Several use cases make it desirable 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, to avoid missing lucrative fees, downloading existing network transactions after a restart. | # Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart. | ||
| Line 24: | Line 28: | ||
# The mempool message is defined as an empty message where pchCommand == "mempool" | # 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 | # 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, if any. | ||
# 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. | # 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: | ||
## Protocol version >= 60002 | ## Protocol version >= 60002 | ||
## NODE_NETWORK bit set in nServices | ## NODE_NETWORK bit set in nServices | ||
Note that existing implementations drop "inv" messages with a vector size > 50000. | |||
==Backward compatibility== | ==Backward compatibility== | ||
| Line 37: | Line 43: | ||
https://github.com/bitcoin/bitcoin/pull/1641 | https://github.com/bitcoin/bitcoin/pull/1641 | ||
Latest revision as of 20:16, 30 April 2024
|
This page describes a BIP (Bitcoin Improvement Proposal). |
|
Please do not modify this page. This is a mirror of the BIP from the source Git repository here. |
BIP: 35 Layer: Peer Services Title: mempool message Author: Jeff Garzik <jgarzik@exmulti.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0035 Status: Final 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 desirable to expose a network node's transaction memory pool:
- SPV clients, wishing to obtain zero-confirmation transactions sent or received.
- Miners, to avoid missing lucrative fees, 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, if any.
- 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
Note that existing implementations drop "inv" messages with a vector size > 50000.
Backward compatibility
Older clients remain 100% compatible and interoperable after this change.