>
> I'd be OK with such an idea if bitcoind listens on a separate port for
> connections from plugins, a port that cannot be used for normal P2P
> traffic. This could also be a UNIX socket instead of a TCP port.
Yes, can be done this way too. I was thinking about setups where you have
services di
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn wrote:
> Maybe, that feels like it could be overkill though. Probably just something
> like
>
> ./bitcoind -servicecookie= -allowextservices=127.0.0.1/8
I don't like conflating the external and internal interface. The
interface to the outside and the int
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn wrote:
>> Something like `getutxos` or this proposal could be implemented as an
>> external application or script, instead of having to integrate
>> everything into bitcoind.
>
>
> Right, although getutxos needs access to the UTXO set which bitcoind alrea
getutxos is a special case, since we already maintain that index as
part of normal operation.
While I dislike some aspects of getutxos (covered elsewhere), if
merged, it would be more appropriate as a special case to keep
getutxos fully internal to bitcoind for implementation reasons.
On Fri, Aug
> Generally agreed, though for ZMQ it is a bit different than a P2P service.
>
> IMO, ZMQ really wants to be a plug-in that registers some internal
> signals. It wants to capture the precise points where a block was
> accepted internally. PR #4599 tries to lead by example:
> https://github.com/bi
>
> Yes, that is the one change I am still pondering: adding categories
> (classes), rather than one single bit.
>
Sure, that makes more sense I think.
As a motivating use case, Bitcoin Wallet for Android currently has a
hard-coded block explorer (biteasy.com) which it uses to find UTXOs for a
g
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir wrote:
> Bitcoind would need a local interprocess message bus for that, and
> would need to act as router for messages from/to the P2P network.
> ZeroMQ seems like a good choice for that. That's not completely crazy
> as there are already plans to add zerom
>
> Something like `getutxos` or this proposal could be implemented as an
> external application or script, instead of having to integrate
> everything into bitcoind.
>
Right, although getutxos needs access to the UTXO set which bitcoind
already has. An external plugin would have to recalculate it
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir wrote:
> On Fri, Aug 8, 2014 at 1:38 PM, Mike Hearn wrote:
>> I'd like to see a mechanism whereby a Bitcoin node can delegate processing
>> of unknown messages to an external process, so a P2P node can be composed
>> out of separated programs, but such a s
Yes, that is the one change I am still pondering: adding categories
(classes), rather than one single bit.
Thus the modified proposal would become:
- eliminate NODE_EXT_SERVICES
- for a class of services, such as insight w/ added blockchain indexes
& queries, add NODE_EXT_INDEXED_CHAIN
- for anot
On Fri, Aug 8, 2014 at 1:38 PM, Mike Hearn wrote:
> I'd like to see a mechanism whereby a Bitcoin node can delegate processing
> of unknown messages to an external process, so a P2P node can be composed
> out of separated programs, but such a service would be indistinguishable at
> the network lay
I'd like to see a mechanism whereby a Bitcoin node can delegate processing
of unknown messages to an external process, so a P2P node can be composed
out of separated programs, but such a service would be indistinguishable at
the network layer from one provided by Bitcoin Core itself, so a service
b
n Fri, Aug 8, 2014 at 6:01 AM, Mike Hearn wrote:
> What's wrong
> with the existing mechanism exactly?
It would be wrong to add NODE_INSIGHT, NODE_ELECTRUM_SERVER, etc. bits
even though you do have useful bitcoin-related APIs that exist on the
same system as bitcoind.
--
Jeff Garzik
Bitcoin cor
This is not a generic "I run a website!" advertisement feature.
NODE_EXT_SERVICES is tightly focused on services that exist
if-any-only-if a P2P bitcoin node (bitcoind) is reachable via the same
advertised address.
You may usefully create overlay networks of specialized services.
On Fri, Aug 8,
I wonder whether we actually want to support this kind of advertisement in
the P2P protocol. We have a working mechanism for protocol extensions in
the P2P network (service flags) so this is obviously only for services that
are not P2P extensions, so why have them in there at all?
I'd argue that a
On Fri, Aug 8, 2014 at 12:15 PM, Wladimir wrote:
> On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn wrote:
>>> He wants to use it to advertise services that are not part of the P2P
>>> protocol itself, but run on a different port. Reserving services bits
>>> for those is not acceptable.
>>
>>
>> Why n
On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn wrote:
>> He wants to use it to advertise services that are not part of the P2P
>> protocol itself, but run on a different port. Reserving services bits
>> for those is not acceptable.
>
>
> Why not? Does the port matter much?
Yes. The services bits are
>
> He wants to use it to advertise services that are not part of the P2P
> protocol itself, but run on a different port. Reserving services bits
> for those is not acceptable.
>
Why not? Does the port matter much?
> All the NODE_EXT_SERVICES bit does is advertise the P2P "getextsrv"
> command t
On Fri, Aug 8, 2014 at 11:45 AM, Mike Hearn wrote:
> Given that we're not running out of service bits and service bits mean you
> don't have to try connecting to every node to find out what services it
> supports, why not keep using the existing extension mechanism until we start
> running out of
Given that we're not running out of service bits and service bits mean you
don't have to try connecting to every node to find out what services it
supports, why not keep using the existing extension mechanism until we
start running out of bits?
--
Link: https://github.com/bitcoin/bitcoin/pull/4657
It is not necessary to build all functionality into bitcoind, to form
a decentralized network. BitPay's insight open source block explorer
API project requires, and runs on top of, bitcoind. Therefore, at the
same IP address as bitcoind, other ser
21 matches
Mail list logo
