Hey everyone,
I was working on some custom protocol extensions for Bitcoin that I
wanted to experiment with and I noticed that in order to enable nodes to
announce these services the only mechanism the protocol currently
provides is to use one of the 64 bits of the services field. This is
I think it's pretty reasonable, although people will want to use node
flags to get into the addr broadcasts anyway.
That said, I suspect (based on previous discussions) that there would
be quite some pushback against putting extra functionality into the
core Bitcoin network. Most likely people
On Mon, Aug 13, 2012 at 3:41 AM, Stefan Thomas m...@justmoon.de wrote:
I was working on some custom protocol extensions for Bitcoin that I
wanted to experiment with and I noticed that in order to enable nodes to
announce these services the only mechanism the protocol currently
provides is to
On Mon, Aug 13, 2012 at 10:24 AM, Jeff Garzik jgar...@exmulti.com wrote:
My only response is a weak one: inevitability. It seems likely that
-somebody- will implement their own P2P commands for their own client
subset, even if only a simple use 'getstatus' with strSubVer matching
/FooClient/
A small change to the protocol is proposed for satoshi client v0.7
(upcoming release):
Add 'mempool' P2P command, and extend 'getdata' behavior
https://github.com/bitcoin/bitcoin/pull/1641
The genesis of this command is to permit SPV clients to access the
memory pool, but secondary uses
More elaboration of the use cases might therefore be useful.
I'm implementing a DHT, rather than storing the whole blockchain index
locally, a future version of BitcoinJS will store only a user defined
percentage (anywhere from 0-100%.) Any misses will be resolved by
querying the network.
6 matches
Mail list logo
