Re: [Bitcoin-development] Miners MiTM
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 authenticate because every client has a different password they expect from the server, so they won't do work for you. MITM on the server can capture the exchange but CHAP protects against replay. https://en.wikipedia.org/wiki/Challenge-Handshake_Authentication_Protocol -Laszlo On Aug 8, 2014, at 6:21 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. > > > On Fri, Aug 8, 2014 at 5:53 AM, Mike Hearn wrote: >>> 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 client TCP stack when it >> discovers the server doesn't know about the connection anymore? >> >> TLS without cert validation defeats the point, you can still be connected to >> a MITM at any point by anyone who can simply interrupt or corrupt the >> stream, forcing a reconnect. >> >> -- >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
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" wrote: > On Fri, Aug 8, 2014 at 1:38 PM, Tom Harding 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 > publish-to-outside-world time are the same, even though they often > are. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
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 thought for GBT2 a while ago was to use simple ECDSA signatures for messages. It'd be nice to use the same as Bitcoin, but then we'd hit problems with RedHat/Fedora legal being stupid. :( Luke -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
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 wrote: >> 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 client TCP stack when it > discovers the server doesn't know about the connection anymore? > > TLS without cert validation defeats the point, you can still be connected to > a MITM at any point by anyone who can simply interrupt or corrupt the > stream, forcing a reconnect. > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
On Fri, Aug 8, 2014 at 1:38 PM, Tom Harding 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 publish-to-outside-world time are the same, even though they often are. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
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, and a "final call" on merging it was already sent to this list. After some thought I agree with its policy of eventually setting nLockTime at current-height + 1 by default. This is the "best reasonably expected height" of any tx created right now. It discourages fee-sniping, and if a reorg happens anyway, it won't actually delay inclusion of tx beyond the reasonable expectation sans reorg. However right now, #2340 takes a very cautious approach and sets to current-height - 10 by default, with randomness to mitigate worries about loss of privacy. Kaz' #2, #3 and #4 are future actions. #4 only goes most of the way ... > 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) ... a janitor mechanism is desirable to purge mempool of txes more than N behind current-height. Nodes dropping a tx N blocks after they became eligible to be mined (the meaning of nLockTime) makes sense. It is not an overloading or new use for nLockTime, but a logical extension of it. As Kaz pointed out, this solves a big problem with expiring by locally measured age: unintentional resurrection. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> > 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 distributed across multiple machines. However a separate port does indeed allow iptables or the like to be used. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP32 - invalidation
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 key is invalid, and one should proceed with the next value for i. c) Master Key Generation In case IL is 0 or I_L >= n, the master key is invalid. (All these cases have probability lower than 1 in 2^127.) What do you think about the following change for all 3 cases: In case I_L >= n assign I_L := I_L mod n. Rationale: It's easy to say "mark as invalid and proceed with next", but actually most of the implementations don't do the checking at all, because tjen it's rather hard at application level to implement skipping logic. OTOH it's quite straightforward to perform modulo if needed, so we probably see more implementations doing the checking. We would still need to deal with cases when I_L = 0 or ki = 0 or ki = inf, but these have probability around 1 in 2^255. Does anyone see any concerns when it comes to security of the proposed change? -- Best Regards / S pozdravom, Pavol Rusnak -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 interface to the inside should be well-separated. 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. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 already > has. An external plugin would have to recalculate it from scratch which > seems redundant. Well to play the devil's advocate, you could set it up to query the information back over RPC :-) But yeah, I didn't mean getutxos specifically, it has a trivial implementation anyway. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 8, 2014 at 8:11 AM, 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 already > has. An external plugin would have to recalculate it from scratch which > seems redundant. > > However there are many other useful services that could be added in such a > way, like -txindex or the nLockTime storage facility we talked about the > other day. > >> >> Bitcoind would need a local interprocess message bus for that > > > Maybe, that feels like it could be overkill though. Probably just something > like > > ./bitcoind -servicecookie= -allowextservices=127.0.0.1/8 > > and then any program can connect to bitcoind as normal, send "registersrv" > with the cookie and a list of command ids it's interested in, maybe a > service bit to set, and start receiving those messages wrapped in a new > structure that gives some kind of client ID (like IP address). So any > library that can do the basic P2P protocol could then be extended with not > much code to get a multiplexed stream of messages from different clients. > > An additional standalone program can then bridge this mechanism to running a > shell command for particular messages, though given the history of shell > based exploits I'd feel safer with something that doesn't do that -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> 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/bitcoin/bitcoin/pull/4599 > > A P2P service would be a slightly different sort of plug-in. ZeroMQ is just a lightweight message routing system. It could just as well make P2P messages available to other applications (if they subscribe to them). The other way around, routing messages from ZeroMQ to certain P2P clients, is easy. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> > 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 given key. This is used for its "Sweep paper wallet" feature. It must work this way because P2P nodes don't calculate such indexes. If there was a way to do block index autodiscovery, that'd help us remove this hard-coded block explorer and increase decentralisation. But because it's a GUI app we don't want users to look at a spinner for more than a few seconds, so a slow discovery process would make it unworkable. With API-based categories of service bits we could implement such a scheme. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 zeromq as an optional dependency for > notifications [1]. 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/bitcoin/bitcoin/pull/4599 A P2P service would be a slightly different sort of plug-in. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> > 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 from scratch which seems redundant. However there are many other useful services that could be added in such a way, like -txindex or the nLockTime storage facility we talked about the other day. > Bitcoind would need a local interprocess message bus for that Maybe, that feels like it could be overkill though. Probably just something like ./bitcoind -servicecookie= -allowextservices=127.0.0.1/8 and then any program can connect to bitcoind as normal, send "registersrv" with the cookie and a list of command ids it's interested in, maybe a service bit to set, and start receiving those messages wrapped in a new structure that gives some kind of client ID (like IP address). So any library that can do the basic P2P protocol could then be extended with not much code to get a multiplexed stream of messages from different clients. An additional standalone program can then bridge this mechanism to running a shell command for particular messages, though given the history of shell based exploits I'd feel safer with something that doesn't do that -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 service would be indistinguishable at >> the network layer from one provided by Bitcoin Core itself, so a service bit >> would be appropriate for those. > > This diverges from the topic but seems like a good idea to me in > general, not so much as replacement for jgarzik's proposal. > > Something like `getutxos` or this proposal could be implemented as an > external application or script, instead of having to integrate > everything into bitcoind. Seconded. Command plug-ins and such seem like an idea worth exploring. We don't need to shove everything into bitcoind. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 another class of services, add NODE_EXT_ - Re-use the same P2P message and structure (CExtService, "extservices" P2P message) for all NODE_EXT_xxx classes. This preserves vendor/API neutrality, while saving effort on the part of clients seeking these services. The point about service discovery necessitating some node walking is valid, which makes categories somewhat attractive. "Having the service run on some arbitrary other port isn't particularly useful, IMO" -- A statement disproved by reality. Multi-port is the method most commonly found in the field today. Logically so, because it is the easiest to deploy: * The most likely setup TODAY is multi-daemon: bitcoind + your own software * The most likely configuration for multi-daemon is self-evidently multi-port (versus two services appearing on the same port) It is quite useful, and indeed, the most likely setup to be found in operation. On Fri, Aug 8, 2014 at 7:38 AM, 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 layer from one provided by Bitcoin Core itself, so a service bit > would be appropriate for those. > > For instance, Insight could then offer a command set that extends the p2p > protocol for doing block explorer type queries. There's no need for the > protocol to be Insight specific. You'd just have NODE_INDEXED_CHAIN > instead. > > Having the service run on some arbitrary other port isn't particularly > useful, IMO - the biggest win from having some separated protocol would be > the ability to use TLS, but if you're connecting to an IP address rather > than a domain name (like if you discovered via service bits/getextsrv) this > doesn't add much. It boils down to minor syntax differences in how numbers > are laid out in a grid. And the performance issue remains. > > Additionally, nothing in this spec requires that a local bitcoind be > running. What stops someone from advertising just NODE_EXTENDED_SERVICES and > nothing else? I don't think a generic service advertisement mechanism is a > bad thing to have, by the way, just pointing out that nothing makes this > more focused than service bits already are. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 layer from one provided by Bitcoin Core itself, so a service bit > would be appropriate for those. This diverges from the topic but seems like a good idea to me in general, not so much as replacement for jgarzik's proposal. Something like `getutxos` or this proposal could be implemented as an external application or script, instead of having to integrate everything into bitcoind. 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 zeromq as an optional dependency for notifications [1]. [1] https://github.com/bitcoin/bitcoin/pull/4594 Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 bit would be appropriate for those. For instance, Insight could then offer a command set that extends the p2p protocol for doing block explorer type queries. There's no need for the protocol to be Insight specific. You'd just have NODE_INDEXED_CHAIN instead. Having the service run on some arbitrary other port isn't particularly useful, IMO - the biggest win from having some separated protocol would be the ability to use TLS, but if you're connecting to an IP address rather than a domain name (like if you discovered via service bits/getextsrv) this doesn't add much. It boils down to minor syntax differences in how numbers are laid out in a grid. And the performance issue remains. Additionally, nothing in this spec requires that a local bitcoind be running. What stops someone from advertising just NODE_EXTENDED_SERVICES and nothing else? I don't think a generic service advertisement mechanism is a bad thing to have, by the way, just pointing out that nothing makes this more focused than service bits already are. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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, 2014 at 6:41 AM, Christian Decker wrote: > 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 parallel network, external to Bitcoin, could take over the > task of advertising external services. > > Regards, > Chris > > -- > Christian Decker > > > On Fri, Aug 8, 2014 at 11:26 AM, Wladimir wrote: >> >> 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 not? Does the port matter much? >> > >> > Yes. The services bits are for advertising services on the P2P >> > network. That's not open for discussion. >> >> It also wouldn't work. A bit is not enough to find an external service >> except in the naive case where the advertised service would have a >> fixed port. Not even bitcoind has a fixed port. So there needs to be a >> mechanism to find how to connect to the 'external service'. This is >> provided by the proposed extension. >> >> It would in principle be possible to advertise an extra service bit >> *in addition to* this one, to make it easier to find through the addr >> mechanism. But it would be confusing and IMO an abuse of P2P service >> bits. >> >> Wladimir >> >> >> -- >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 parallel network, external to Bitcoin, could take over the task of advertising external services. Regards, Chris -- Christian Decker On Fri, Aug 8, 2014 at 11:26 AM, Wladimir wrote: > 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 not? Does the port matter much? > > > > Yes. The services bits are for advertising services on the P2P > > network. That's not open for discussion. > > It also wouldn't work. A bit is not enough to find an external service > except in the naive case where the advertised service would have a > fixed port. Not even bitcoind has a fixed port. So there needs to be a > mechanism to find how to connect to the 'external service'. This is > provided by the proposed extension. > > It would in principle be possible to advertise an extra service bit > *in addition to* this one, to make it easier to find through the addr > mechanism. But it would be confusing and IMO an abuse of P2P service > bits. > > Wladimir > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 not? Does the port matter much? > > Yes. The services bits are for advertising services on the P2P > network. That's not open for discussion. It also wouldn't work. A bit is not enough to find an external service except in the naive case where the advertised service would have a fixed port. Not even bitcoind has a fixed port. So there needs to be a mechanism to find how to connect to the 'external service'. This is provided by the proposed extension. It would in principle be possible to advertise an extra service bit *in addition to* this one, to make it easier to find through the addr mechanism. But it would be confusing and IMO an abuse of P2P service bits. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 for advertising services on the P2P network. That's not open for discussion. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
> > 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 information, such as the port to connect on, for the > auxilary service. Yes, I understand what it does, but from a clients perspective what it means is if someone implements a useful service and exposes it this way you have to seek out, connect to and interrogate every possible server even if (say) only a handful actually provide it. The most there's >1 "ext service" the protocol becomes extremely slow, vs service bits where you can download addr packets and see which IPs are advertising which services. I don't see much reason to take a potentially large performance hit when there's a service advertisement mechanism that already works. What's wrong with the existing mechanism exactly? -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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 bits? 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. All the NODE_EXT_SERVICES bit does is advertise the P2P "getextsrv" command to get information, such as the port to connect on, for the auxilary service. Wladimir -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
> > 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 client TCP stack when it discovers the server doesn't know about the connection anymore? TLS without cert validation defeats the point, you can still be connected to a MITM at any point by anyone who can simply interrupt or corrupt the stream, forcing a reconnect. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] NODE_EXT_SERVICES and advertising related services
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? -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Miners MiTM
> > 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 infrastructure you can change certificates and keys without needing to update miners. Besides, when it comes to financial services SSL is essential, I'm kind of surprised it wasn't already used everywhere. I wouldn't use an online bank that didn't support SSL, I would see it as a a sign of serious problems. Heck I wouldn't even use webmail that didn't support SSL these days. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
