Amir Taaki [ARCHIVE] on Nostr: 📅 Original date posted:2012-08-16 📝 Original message:The format for "mempool" ...
📅 Original date posted:2012-08-16
📝 Original message:The format for "mempool" packet is missing. I'm guessing that it is an empty message, right?
Might be good to add that.
----- Original Message -----
From: Jeff Garzik <jgarzik at exmulti.com>
To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Cc:
Sent: Thursday, August 16, 2012 6:32 PM
Subject: [Bitcoin-development] BIP 35: add mempool message
Consensus was we should do a BIP for all P2P changes, so here it is...
feedback requested.
https://en.bitcoin.it/wiki/BIP_0035
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:
* SPV clients, wishing to obtain zero-confirmation transactions sent or
received.
* Miners, downloading existing network transactions after a restart.
* 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:
a) Protocol version >= 60002
b) NODE_NETWORK bit set in nServices
Backwards compatibility
-------------------------------------------
Older clients remain 100% compatible and interoperable after this change.
Implementation
-------------------------------------------
See https://github.com/bitcoin/bitcoin/pull/1641
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
📝 Original message:The format for "mempool" packet is missing. I'm guessing that it is an empty message, right?
Might be good to add that.
----- Original Message -----
From: Jeff Garzik <jgarzik at exmulti.com>
To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Cc:
Sent: Thursday, August 16, 2012 6:32 PM
Subject: [Bitcoin-development] BIP 35: add mempool message
Consensus was we should do a BIP for all P2P changes, so here it is...
feedback requested.
https://en.bitcoin.it/wiki/BIP_0035
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:
* SPV clients, wishing to obtain zero-confirmation transactions sent or
received.
* Miners, downloading existing network transactions after a restart.
* 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:
a) Protocol version >= 60002
b) NODE_NETWORK bit set in nServices
Backwards compatibility
-------------------------------------------
Older clients remain 100% compatible and interoperable after this change.
Implementation
-------------------------------------------
See https://github.com/bitcoin/bitcoin/pull/1641
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development