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?
Certificate validation isn't needed unless the attacker can do a direct
MITM
at connection time, which is a lot harder to maintain than injecting a
client.reconnect.
Surely the TCP connection will be reset once the route reconfiguration is
completed, either by the MITM server or by the
On Fri, Aug 8, 2014 at 11:45 AM, Mike Hearn m...@plan99.net 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
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 to get
On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net 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
On Fri, Aug 8, 2014 at 12:15 PM, Wladimir laa...@gmail.com wrote:
On Fri, Aug 8, 2014 at 12:01 PM, Mike Hearn m...@plan99.net 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
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
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,
n Fri, Aug 8, 2014 at 6:01 AM, Mike Hearn m...@plan99.net 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
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
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
On Fri, Aug 8, 2014 at 7:59 AM, Wladimir laa...@gmail.com wrote:
On Fri, Aug 8, 2014 at 1:38 PM, Mike Hearn m...@plan99.net 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
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 laa...@gmail.com 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
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
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:
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,
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn m...@plan99.net 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
On Fri, Aug 8, 2014 at 2:11 PM, Mike Hearn m...@plan99.net wrote:
Maybe, that feels like it could be overkill though. Probably just something
like
./bitcoind -servicecookie=long random string -allowextservices=127.0.0.1/8
I don't like conflating the external and internal interface. The
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
Having explored more drastic approaches, it looks like Kaz' basic idea
stands well. His #1...
1. start setting nLockTime to the current height by default in newly
created transactions (or slightly below the current height, for
reorg-friendliness)
is already implemented in bitcoin-qt #2340,
On Fri, Aug 8, 2014 at 1:38 PM, Tom Harding t...@thinlink.com wrote:
4. add a new IsStandard rule rejecting transactions with an nLockTime
more than N blocks behind the current tip (for some fixed value N, to
be determined)
It cannot be assumed that transaction creation time and transaction
gmaxwell noted on IRC that enabling TLS could be functionally, if not
literally, a DoS on the pool servers. Hence the thought towards a
more lightweight method that simply prevents client payout redirection
+ server impersonation.
On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn m...@plan99.net
On Friday, August 08, 2014 6:21:18 PM Jeff Garzik wrote:
gmaxwell noted on IRC that enabling TLS could be functionally, if not
literally, a DoS on the pool servers. Hence the thought towards a
more lightweight method that simply prevents client payout redirection
+ server impersonation.
My
A new network tx field would have the same problem, right?
With a child-refreshes-parent policy, someone wishing to redeem a
transaction that has passed its relay window without being confirmed could
still do so.
On Aug 8, 2014 11:16 AM, Jeff Garzik jgar...@bitpay.com wrote:
On Fri, Aug 8, 2014
Mutual CHAP could work. This is commonly done in PPP and iSCSI. The idea is
simply that both sides authenticate. The server expects the client to provide
a password, and the client expects the server to provide a (different)
password. If you masquerade as the server, you won't be able to
26 matches
Mail list logo
