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
On Thu, Aug 16, 2012 at 1:40 PM, Amir Taaki zgen...@yahoo.com wrote:
The format for mempool packet is missing. I'm guessing that it is an empty
message, right?
Yes, it is an empty message. BIP updated.
--
Jeff Garzik
exMULTI, Inc.
jgar...@exmulti.com
On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
I suppose it is interesting in general for nodes to
get a memory pool refill at startup anyway.
Yes.
An inv message is always returned, even if empty.
I'm not sure about this last. What is it good for? inv
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
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
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?
BitcoinJS will implement it, it's a useful feature and there is no
reason not to support it.
Two comments from my end:
-
On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik jgar...@exmulti.com wrote:
On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
I suppose it is interesting in general for nodes to
get a memory pool refill at startup anyway.
Yes.
An inv message is always
MSG_MEMTX solves the issue of not knowing whether a given inv is in response to
a mempool command or not.
I don't buy the argument that always sending a response inv makes things
easier because code should always be able to handle misbehaviour from the
remote node (ommiting the inv). However I
On MSG_MEMTX: The current version has a much higher Just Works value.
On empty inv: It is generally better to do something
unconditionally, than have a response generated only under certain
conditions.
And Alan is correct to note that unknown messages are ignored
(intentionally, for
9 matches
Mail list logo
