BIP 0035 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/2d9e431fbe654640/bip-0035.mediawiki

2024-04-30T20:16:09Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/2d9e431fbe654640/bip-0035.mediawiki

← Older revision		Revision as of 20:16, 30 April 2024
Line 20:		Line 20:
	==Motivation==		==Motivation==

	Several use cases make it ~~desireable~~ to expose a network node's transaction memory pool:		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.

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0035.mediawiki

2019-09-24T18:00:22Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0035.mediawiki

@@ Line 1: / Line 1: @@
 {{bip}}
 <pre>
    BIP: 35
    Title: mempool message
    Author: Jeff Garzik <jgarzik@exmulti.com>
-   Status: Accepted
+  Comments-Summary: No comments yet.
    Type: Standards Track
    Created: 2012-08-16
 </pre>
-{{BipMoved|bip-0035.mediawiki}}
+==Abstract==
-[[Category:Developer]]
+https://github.com/bitcoin/bitcoin/pull/1641

934: Removing redundant parameter.

2015-12-29T13:45:59Z

Removing redundant parameter.

← Older revision		Revision as of 13:45, 29 December 2015
Line 10:		Line 10:
	</pre>		</pre>

	{{BipMoved\|bip-0035.mediawiki~~\|BIP 0035~~}}		{{BipMoved\|bip-0035.mediawiki}}

	[[Category:Developer]]		[[Category:Developer]]
	[[Category:Technical]]		[[Category:Technical]]
	[[Category:BIP\|D]]		[[Category:BIP\|D]]

Wumpus: Move to github

2013-12-06T07:54:17Z

Move to github

@@ Line 10: / Line 10: @@
 </pre>
-==Abstract==
+{{BipMoved|bip-0035.mediawiki|BIP 0035}}
 [[Category:Developer]]
 [[Category:Technical]]
 [[Category:BIP|D]]

Genjix at 21:50, 27 August 2012

2012-08-27T21:50:01Z

← Older revision		Revision as of 21:50, 27 August 2012
Line 5:		Line 5:
	Title: mempool message		Title: mempool message
	Author: Jeff Garzik <jgarzik@exmulti.com>		Author: Jeff Garzik <jgarzik@exmulti.com>
	Status: ~~Draft~~		Status: Accepted
	Type: Standards Track		Type: Standards Track
	Created: 2012-08-16		Created: 2012-08-16

Jgarzik: /* Specification */

2012-08-17T20:04:34Z

Specification

← Older revision		Revision as of 20:04, 17 August 2012
Line 24:		Line 24:

	# 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:

Jgarzik: /* Specification */

2012-08-17T20:04:18Z

Specification

← Older revision		Revision as of 20:04, 17 August 2012
Line 24:		Line 24:

	# 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~~. An "inv" message is always returned, even if empty~~.		# 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.
	# 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:

Jgarzik: /* Specification */

2012-08-16T17:46:39Z

Specification

← Older revision		Revision as of 17:46, 16 August 2012
Line 24:		Line 24:

	# 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. An "inv" message is always returned, even if empty~~. Note that existing implementations drop "inv" messages with a vector size > 50000~~.		# 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.		# 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==

Jgarzik: /* Specification */

2012-08-16T17:46:19Z

Specification

← Older revision		Revision as of 17:46, 16 August 2012
Line 24:		Line 24:

	# 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. An "inv" message is always returned, even if empty.		# 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. Note that existing implementations drop "inv" messages with a vector size > 50000.
	# 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:

Jgarzik: /* Motivation */

2012-08-16T17:44:40Z

Motivation

← Older revision		Revision as of 17:44, 16 August 2012
Line 18:		Line 18:
	Several use cases make it desireable to expose a network node's transaction memory pool:		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, to avoid missing lucrative fees, downloading existing network transactions after a restart.
	# Remote network diagnostics.		# Remote network diagnostics.