> 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.
Thank
On Mon, Aug 13, 2012 at 10:24 AM, Jeff Garzik 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/"
>
> Therefore
On Mon, Aug 13, 2012 at 3:41 AM, Stefan Thomas 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 use one of the
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 wil
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
obviousl
5 matches
Mail list logo
