📅 Original date posted:2012-08-16
📝 Original message:My thoughts:
The extension is simple. It's only really useful for the use-cases listed if the majority of nodes implement it. As I view the proposal, it is perfectly simple and uncomplicated. If it's implemented, then I suggest to just increment version and make it part of the protocol.
On the flipside it is another notch in complicating an already diffuse protocol, but it seems a rather benign offense in that regard compared to other changes (past and future).
----- Original Message -----
From: Pieter Wuille <pieter.wuille at gmail.com>
To: Jeff Garzik <jgarzik at exmulti.com>
Cc: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Sent: Thursday, August 16, 2012 6:56 PM
Subject: Re: [Bitcoin-development] BIP 35: add mempool message
On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote:
> Consensus was we should do a BIP for all P2P changes, so here it is...
> feedback requested.
>
> https://en.bitcoin.it/wiki/BIP_0035
I like the idea of being able to query the memory pool of a node; the
implementation is straightforward, which is good. Maybe effectively using the
command can be added? I suppose it is interesting in general for nodes to
get a memory pool refill at startup anyway.
> 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.
I'm not sure about this last. What is it good for? inv packets can always be
sent, even not in response to others, so it is not that this gives you an
acknowledgement the mempool is updated?
> 3) Feature discovery is enabled by checking two "version" message attributes:
>
> a) Protocol version >= 60002
> b) NODE_NETWORK bit set in nServices
This seems safe, although it forces other full implementations that want to
expose protocol version 60002 (or later) to also implement this. What do they
think about this?
I would like to suggest to allocate an extra service bit for this. We still
have 63 left, and this is a well-defined and useful extra service that was
not yet provided by any earlier node. Doing that would also mean that
mempool-providing survices may be discovered before connecting to them, as
the service bits are carried around in addr messages. Any opinions about that?
--
Pieter
------------------------------------------------------------------------------
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
Amir Taaki [ARCHIVE] /
npub1ep…m3rel
2023-06-07 10:28:49
in reply to nevent1q…mw3c
Author Public Key
npub1ep4j5tjp6cd2774hrx96vh845dwqzhe3z7n3a2a9uxdm2dajqpgscm3relSeen on
wss://relay.noswhere.comPublished at
2023-06-07 10:28:49Event JSON
{
"id": "724b9a23d4663c5b91f583bde333ff6ab1e9da1813c13e9a10142d9336b5994b",
"pubkey": "c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051",
"created_at": 1686133729,
"kind": 1,
"tags": [
[
"e",
"230151bb9ac0f5af1d29fc832b378f46a6a5a710d215c859a985fc5e0d75bc92",
"",
"root"
],
[
"e",
"5f6ca3ab2ce3fc28783937f5cc03556f304af64acf33e1dbfcbb45d506764dc7",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2012-08-16\n📝 Original message:My thoughts:\n\nThe extension is simple. It's only really useful for the use-cases listed if the majority of nodes implement it. As I view the proposal, it is perfectly simple and uncomplicated. If it's implemented, then I suggest to just increment version and make it part of the protocol.\n\nOn the flipside it is another notch in complicating an already diffuse protocol, but it seems a rather benign offense in that regard compared to other changes (past and future).\n\n\n\n----- Original Message -----\nFrom: Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\nTo: Jeff Garzik \u003cjgarzik at exmulti.com\u003e\nCc: Bitcoin Development \u003cbitcoin-development at lists.sourceforge.net\u003e\nSent: Thursday, August 16, 2012 6:56 PM\nSubject: Re: [Bitcoin-development] BIP 35: add mempool message\n\nOn Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote:\n\u003e Consensus was we should do a BIP for all P2P changes, so here it is...\n\u003e feedback requested.\n\u003e \n\u003e https://en.bitcoin.it/wiki/BIP_0035\n\nI like the idea of being able to query the memory pool of a node; the\nimplementation is straightforward, which is good. Maybe effectively using the\ncommand can be added? I suppose it is interesting in general for nodes to\nget a memory pool refill at startup anyway.\n\n\u003e 1) Upon receipt of a \"mempool\" message, the node will respond\n\u003e with an \"inv\" message containing MSG_TX hashes of all the\n\u003e transactions in the node's transaction memory pool.\n\u003e \n\u003e An \"inv\" message is always returned, even if empty.\n\nI'm not sure about this last. What is it good for? inv packets can always be\nsent, even not in response to others, so it is not that this gives you an\nacknowledgement the mempool is updated?\n\n\u003e 3) Feature discovery is enabled by checking two \"version\" message attributes:\n\u003e \n\u003e a) Protocol version \u003e= 60002\n\u003e b) NODE_NETWORK bit set in nServices\n\nThis seems safe, although it forces other full implementations that want to\nexpose protocol version 60002 (or later) to also implement this. What do they\nthink about this?\n\nI would like to suggest to allocate an extra service bit for this. We still\nhave 63 left, and this is a well-defined and useful extra service that was\nnot yet provided by any earlier node. Doing that would also mean that\nmempool-providing survices may be discovered before connecting to them, as\nthe service bits are carried around in addr messages. Any opinions about that?\n\n-- \nPieter\n\n------------------------------------------------------------------------------\nLive Security Virtual Conference\nExclusive live event will cover all the ways today's security and \nthreat landscape has changed and how IT managers can respond. Discussions \nwill include endpoint security, mobile security and the latest in malware \nthreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n_______________________________________________\nBitcoin-development mailing list\nBitcoin-development at lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "79b674036af0ce12bd5215504d09b7da11d532ad0e33d50d2ae8d93aefaada8be38d378fbd937669971490b2153b62cc26f62b22128bd8c3c616e1d0c2a6a1d2"
}