Re: [Bitcoin-development] Miners MiTM

2014-08-08 Thread Mike Hearn
AFAIK the only protection is SSL + certificate validation on client side. However certificate revocation and updates in miners are pain in the ass, that's why majority of pools (mine including) don't want to play with that... Why would miners need updates? If they implement the standard SSL

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Mike Hearn
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?

Re: [Bitcoin-development] Miners MiTM

2014-08-08 Thread Mike Hearn
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Mike Hearn
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Christian Decker
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
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,

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Mike Hearn
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Mike Hearn
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Mike Hearn
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
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:

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Jeff Garzik
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,

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
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

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Wladimir
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

[Bitcoin-development] BIP32 - invalidation

2014-08-08 Thread Pavol Rusnak
Hi all! I would like to discuss invalidation of nodes in BIP32. Currently the document says: a) Public CKD In case I_L = n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i. b) Private CKD In case I_L = n or Ki is the point at infinity, the resulting

Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services

2014-08-08 Thread Mike Hearn
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

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-08 Thread Tom Harding
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,

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-08 Thread Jeff Garzik
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

Re: [Bitcoin-development] Miners MiTM

2014-08-08 Thread Jeff Garzik
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

Re: [Bitcoin-development] Miners MiTM

2014-08-08 Thread Luke Dashjr
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

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-08 Thread Kaz Wesley
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

Re: [Bitcoin-development] Miners MiTM

2014-08-08 Thread Laszlo Hanyecz
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