1 2014-11-28 00:35:57 <sipa> wumpus, gavinandresen: i just finished a patch for libsecp256k1 which allows it to compile (even for verification) without any dependencies at all
  2 2014-11-28 00:41:04 <Luke-Jr> sipa: same performance?
  3 2014-11-28 00:41:14 <sipa> no
  4 2014-11-28 00:41:32 <sipa> see benchmarks here: https://github.com/bitcoin/secp256k1/pull/119
  5 2014-11-28 00:44:15 <sipa> and the resulting stripped .so file is 47088 bytes :)
  6 2014-11-28 00:49:11 <sipa> (though some of the benchmarks were compiled with -O3, and the latest changes may have had a 0.5%-1% performance degradation)
  7 2014-11-28 06:02:36 <earlz> so, what's up with transaction "7a438de42d601864aead3efec71e07ae97a20b74cd36da2bf4489c77f5bde03e" on testnet
  8 2014-11-28 06:03:00 <earlz> `getrawtransaction txid 1` output just gives [error] for the script part
  9 2014-11-28 06:21:48 <op_null> earlz: "scriptPubKey": "238:1:01"
 10 2014-11-28 06:22:22 <earlz> that doesn'thelp :/
 11 2014-11-28 06:23:39 <op_null> I can't answer you for why, but that does indeed lead to "[error]" in decoderawtransaction
 12 2014-11-28 06:28:17 <op_null> not even sure where the [error] string is coming from, so probably one for somebody else to solve
 13 2014-11-28 06:39:31 <gmaxwell> earlz: whats the question?
 14 2014-11-28 06:40:27 <gmaxwell> the hex is 01, which doesn't deseralize to anything... basically the script is one byte long, and that one byte says to push the non-existing next byte onto the stack.
 15 2014-11-28 06:40:36 <gmaxwell> so the disassembler just reports error.
 16 2014-11-28 06:41:41 <op_null> gmaxwell: bitcoin-ruby prints that out as "238:1:01", wonder where they're getting that from.
 17 2014-11-28 06:42:35 <gmaxwell> the moon?
 18 2014-11-28 06:48:57 <earlz> lol
 19 2014-11-28 07:35:26 <wumpus> sipa: very cool! we should switch to that at least for now (can rediscuss whether it makes sense to use libgmp when verification using secp256k1 lands)
 20 2014-11-28 07:37:56 <wumpus> well at least whether to use libgmp for the gitian builds; apart from that it's just a developer-overridable default
 21 2014-11-28 07:46:12 <jonasschnelli> how does a serialized <vector> look like in memory? [size(int64_t)][data.1][data.2][data.X]?
 22 2014-11-28 07:49:17 <Luke-Jr> jonasschnelli: platform/implementation dependent..
 23 2014-11-28 07:50:25 <jonasschnelli> hm... i just saw in a bip (Bip64) protocol definition a data-type <vector>. So i think it can't be platform dependant.
 24 2014-11-28 07:56:08 <wumpus> no, the serialization format is not (or should not be) platform dependent
 25 2014-11-28 07:56:44 <wumpus> (the only case where it is is if you run bitcoind on a bigendian system)
 26 2014-11-28 07:56:45 <gmaxwell> jonasschnelli: "Each outpoint is serialized in the same way it is in a tx message"
 27 2014-11-28 07:57:28 <gmaxwell> wumpus: wires crossed, sounded like jonasschnelli was asking what a stl vector looked like in memory, which is platform and implementation dependant. (answer: there is a lot of overhead)
 28 2014-11-28 07:59:05 <jonasschnelli> maxwell thanks! "Read first than ask". Sorry for that. And yes. my question was a bit generic..
 29 2014-11-28 07:59:37 <wumpus> oh indeed, for STL you can't assume anything, it specifies an API not an implementation
 30 2014-11-28 08:00:08 <jonasschnelli> but i was looking for the bitcoin protocol like serialization. I just saw in serialize.h the template for vector...
 31 2014-11-28 08:34:59 <Luke-Jr> wumpus: any major merges left before 0.10 branches?
 32 2014-11-28 08:35:17 <Luke-Jr> (is now a good time to rebase things?)
 33 2014-11-28 08:35:57 <Luke-Jr> oh. core/ rename not merged yet, better wait.
 34 2014-11-28 08:42:11 <wumpus> Luke-Jr: deterministic signing, mostly
 35 2014-11-28 08:42:32 <wumpus> and #5387, but that's cosmetic only
 36 2014-11-28 08:43:43 <Luke-Jr> probably should wait on 5387 too
 37 2014-11-28 08:44:17 <wumpus> it's always painful
 38 2014-11-28 08:46:24 <wumpus> apart from that there's always a lot of last minute should-we-include-this-or-not bugfixes and small improvements
 39 2014-11-28 08:46:59 <Luke-Jr> yeah, but usually those merge cleanly ;)
 40 2014-11-28 08:49:06 <wumpus> well it's quite possible to run the formatting tool on both sides of the merge to create a new diff
 41 2014-11-28 08:49:19 <wumpus> if only my clang-format behaved the same as sipa's clang-format
 42 2014-11-28 08:49:23 <wumpus> :D
 43 2014-11-28 08:50:11 <wumpus> the differences between different versions of that tool do complicate our plan
 44 2014-11-28 08:51:03 <Luke-Jr> :/
 45 2014-11-28 08:53:09 <wumpus> we could just set some 'golden' version of clang-format and have everyone that runs it use that, but every obstacle you put up to running it makes it less likely that this will be maintained over time
 46 2014-11-28 08:54:46 <Luke-Jr> I don't care much since the format chosen sucks - as long as it isn't breaking merges regularly ;p
 47 2014-11-28 08:54:51 <wumpus> (and I'd just hate to see regions of the code flip/flop due to different versions of the formatter)
 48 2014-11-28 08:56:31 <wumpus> the idea, like any standard, is to just settle down on *something* so we can leave discussions about it behind and be more productive in more important areas
 49 2014-11-28 08:56:47 <wumpus> of course you, or someone else, will think the chosen settings suck.
 50 2014-11-28 08:56:50 <gmaxwell> I wonder if we should ask the clang folks about formater stability?  I wish it were some small and self contained software and then we could just standarize on it forever.
 51 2014-11-28 08:57:21 <gmaxwell> If no one thinks your format sucks, it must not be described particularly clearly.
 52 2014-11-28 08:57:22 <Luke-Jr> wumpus: I know, hence I'm not complaining about it :p
 53 2014-11-28 08:57:35 <wumpus> gmaxwell: indeed, but the inherent difficulty of handling C++ code makes this specialized to compiler-level-complexity code, I'm afraid
 54 2014-11-28 08:58:06 <wumpus> this is the whole reason that this ends up as clang-format, and not some silly python script that we can include in contrib/devtools
 55 2014-11-28 09:16:36 <wumpus> but yes, asking them about formatter stability makes sense
 56 2014-11-28 09:27:19 <wumpus> re: #5316, I'd like 'setmocktime' to the hidden category as well
 57 2014-11-28 09:27:37 <wumpus> s/to/in
 58 2014-11-28 09:27:55 <gmaxwell> Yea, agreed.
 59 2014-11-28 09:28:05 <gmaxwell> another foot gun
 60 2014-11-28 09:28:22 <gmaxwell> but a good testing tool.
 61 2014-11-28 09:30:04 <Luke-Jr> importprivkey as well then?
 62 2014-11-28 09:31:19 <wumpus> unfortunately it's too late for that, people know to find that one anyhow
 63 2014-11-28 09:39:05 <sipa> wumpus: does 3
 64 2014-11-28 09:39:18 <sipa> .5 work for you as for me?
 65 2014-11-28 09:39:54 <sipa> i expect that 3.6 just added more options, and the defaultfor one differs from what 3.5 did
 66 2014-11-28 09:43:22 <sipa> wumpus: if the clang changes are not reproducible, i shouldn't do them imho; the only reason to automate rather than use as a policy is that they can be frequently done with easy review
 67 2014-11-28 09:43:52 <sipa> of a one-time thing we can still do the compare-deterministic binaries thing
 68 2014-11-28 09:45:06 <wumpus> sipa: going to try, I have clang 3.4 installed as well as 3.6 but not 3.5 :)
 69 2014-11-28 09:46:21 <wumpus> whoa that's easy - clang-format-3.5 is actually a distro package now on ubuntu 14.04
 70 2014-11-28 09:46:45 <Luke-Jr> that's not a good sign XD
 71 2014-11-28 09:48:20 <wumpus> noooooooo - it reports as "Ubuntu clang-format version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)", but doesn't work with our .clang-format file
 72 2014-11-28 09:48:58 <wumpus> YAML:6:35: error: invalid boolean (line is AllowShortFunctionsOnASingleLine: All)
 73 2014-11-28 09:49:36 <wumpus> so 3.5 result is not necessarily reproducible on 3.5 either
 74 2014-11-28 09:56:31 <Luke-Jr> 
ACTION hopes we at the very least won't hold up 0.10 for this :x

 75 2014-11-28 09:56:40 <jonasschnelli> :)
 76 2014-11-28 09:58:03 <wumpus> I also think this should be postponed until a time that clang-format is more stable, if that ever happens
 77 2014-11-28 10:02:11 <wumpus> no, the hold-up for 0.10 at the moment is deterministic signing, as well as the REST interface which was merged last-minute and seemingly hasn't settled down yet
 78 2014-11-28 10:04:38 <wumpus> to me it looks like the testcases for deterministic signing are sufficient, what I'm not convinced of is that the new crypto code was reviewed thoroughly enough yet
 79 2014-11-28 10:04:48 <gmaxwell> does the rest interface also work without heroic work against the old patches that replace the json library?
 80 2014-11-28 10:05:20 <wumpus> ideally the REST interface shouldn't mess with JSON at all
 81 2014-11-28 10:05:57 <jonasschnelli> the rest interfaces uses blockToJSON() and TxToJSON() from rpc
 82 2014-11-28 10:06:18 <jonasschnelli> so no extra JSON stack in rest.cpp
 83 2014-11-28 10:06:46 <Luke-Jr> 
ACTION idly ponders if REST uses the same HTTP server as JSON-RPC

 84 2014-11-28 10:06:48 <wumpus> see my post here https://github.com/bitcoin/bitcoin/pull/5326#issuecomment-64179650 and the one after it
 85 2014-11-28 10:06:56 <jonasschnelli> does travis also runs the rpc tests (qa/pull-tester)?
 86 2014-11-28 10:07:04 <wumpus> tl;dr; using the RPC getblock format for the REST interface makes little sense
 87 2014-11-28 10:07:45 <wumpus> jonasschnelli: it runs ./qa/pull-tester/rpc-tests.sh, which runs some of the RPC tests
 88 2014-11-28 10:08:10 <wumpus> Luke-Jr: yes, we only have one HTTP server
 89 2014-11-28 10:08:20 <wumpus> *only* one HTTP server!
 90 2014-11-28 10:08:22 <Luke-Jr> hm
 91 2014-11-28 10:08:29 <Luke-Jr> that means the REST interface needs to be trusted
 92 2014-11-28 10:08:45 <Luke-Jr> in which case.. we might as well use the auth and we're back to JSON-RPC? :/
 93 2014-11-28 10:08:49 <jonasschnelli> wumpus: yes. the getblock json output could be better. but maybe thats something after 0.10?
 94 2014-11-28 10:08:58 <wumpus> let's merge more, we'd love to maintain all of them
 95 2014-11-28 10:09:39 <wumpus> Luke-Jr: it's unauthenticated, that's the only difference
 96 2014-11-28 10:09:43 <jonasschnelli> i think jeffs idea of the unauth. REST interface is also to support mikehs getutxo thing...
 97 2014-11-28 10:10:08 <paveljanik> depends/apache-httpd? ;-)
 98 2014-11-28 10:10:10 <wumpus> the REST interface is for public, read-only data. The goal is*NOT* to replace the control functionality of RPC, or the wallet commands, etc...
 99 2014-11-28 10:10:21 <jonasschnelli> so it then should be unauth. to give another "channel" next to the p2p
100 2014-11-28 10:10:33 <wumpus> paveljanik: ;-)
101 2014-11-28 10:10:38 <jonasschnelli> paveljanik apache is not involved here.
102 2014-11-28 10:10:59 <jonasschnelli> but if people runs this public, they should do a reverse proxy with apache and mod_security, etc.
103 2014-11-28 10:11:02 <wumpus> jonasschnelli: hence the smiley
104 2014-11-28 10:11:08 <paveljanik> yup
105 2014-11-28 10:11:27 <wumpus> jonasschnelli: yes it's good to put it behind a proxy/cache
106 2014-11-28 10:11:35 <wumpus> jonasschnelli: *if* you want to run it publically
107 2014-11-28 10:12:01 <jonasschnelli> wumpus: did anyone test-attacks the bitcoind http server, with a security-framework?
108 2014-11-28 10:12:14 <wumpus> please don't expose bitcoind's http server directly to the internet :-(
109 2014-11-28 10:12:27 <wumpus> jonasschnelli: I don't think so.
110 2014-11-28 10:13:11 <wumpus> jonasschnelli: it's not really urgent, hardening the P2P code against say possible DoS attacks wouuld have a much higher priority
111 2014-11-28 10:13:22 <Luke-Jr> wumpus: it's unauthenticated, but you have to trust users to not lock your connections..
112 2014-11-28 10:13:22 <op_null> jonasschnelli: please please please don't expose your RPC server to the internet
113 2014-11-28 10:13:41 <wumpus> Luke-Jr: so do you trust your users not to do that?
114 2014-11-28 10:13:55 <Luke-Jr> wumpus: if I did, I'd just give them the user/pass for RPC :P
115 2014-11-28 10:14:27 <wumpus> Luke-Jr: many 12-year old kids among them with a slowloris client? :P
116 2014-11-28 10:15:00 <Luke-Jr> wumpus: my point was just that this interface is no better than JSON-RPC, since you need to trust the user and we already have that with JSON-RPC
117 2014-11-28 10:15:01 <wumpus> Luke-Jr: well they are different levels of trust, the RPC pass allows shutting down your server and other things
118 2014-11-28 10:15:16 <sipa> same trust, higher convenience
119 2014-11-28 10:15:17 <sipa> that's all
120 2014-11-28 10:15:19 <Luke-Jr> REST does too! just lock up every connection, same effect
121 2014-11-28 10:15:32 <sipa> well, at least REST can't steal your coins
122 2014-11-28 10:15:33 <wumpus> Luke-Jr: well you could mess up some internal state as well using debug commands!
123 2014-11-28 10:15:39 <Luke-Jr> XD
124 2014-11-28 10:15:51 <wumpus> hah, that too
125 2014-11-28 10:15:57 <Luke-Jr> sipa: I sure hope nobody plans to expose this with a *wallet*
126 2014-11-28 10:19:57 <jonasschnelli> but why we have a REST interface when nobody expose it to the internet? See jeffs original post https://bitcointalk.org/index.php?topic=260701.0 shouldn't we tell uses how to run it in a secure way (behind reverse proxy mod_security)?
127 2014-11-28 10:20:28 <wumpus> Luke-Jr: you'd be surprised, a few days ago someone was arguing agressively against me against isolation, because servers are too expensive :')
128 2014-11-28 10:20:32 <jonasschnelli> RPC is clear. Not public. But the REST thing could give a side-channel of public blockchain infomation
129 2014-11-28 10:21:09 <Luke-Jr> wumpus: O.O
130 2014-11-28 10:22:28 <wumpus> jonasschnelli: well somebody could expose it to the internet, just be careful (ie as said, put it behind a squid or apache that vets the URLs and does caching)
131 2014-11-28 10:23:53 <gmaxwell> jonasschnelli: that interface is not ready to be exposed to the internet; I don't believe anyone has fuzz tested it (for example), and I think it's likely it wouldn't survive it... and it's also probably a DOS vector.
132 2014-11-28 10:23:55 <Luke-Jr> has anyone tested it behind a proxy? I imagine they'd keep the connection open and kill it
133 2014-11-28 10:23:58 <wumpus> indeed the point of REST is to make that easier by having a well-defined, stateless URL mapping
134 2014-11-28 10:24:17 <gmaxwell> But if the alternative is removing it; having it in as a not yet done thing is preferable IMO.
135 2014-11-28 10:25:12 <wumpus> another point of having a well-defined, small API is that other clients that are better hardened could implement the same interface
136 2014-11-28 10:25:42 <sipa> i see the REST api as something to expose to other services that run locally
137 2014-11-28 10:25:52 <wumpus> gmaxwell: indeed it's a work in progress
138 2014-11-28 10:26:02 <wumpus> we're certainly not going to work this all out before 0.10.
139 2014-11-28 10:27:00 <wumpus> Luke-Jr: with a smart http proxy that'd not be possible
140 2014-11-28 10:28:32 <wumpus> sipa: that's something it's indeed useful for already
141 2014-11-28 10:28:53 <sipa> as RPC right now only offers JSON, which may be unnecessary complication and overhead
142 2014-11-28 10:29:08 <sipa> however, for that use case, adding authentication shouldn't be much of a burden
143 2014-11-28 11:44:16 <jonasschnelli> regarding REST API:
144 2014-11-28 11:45:54 <jonasschnelli> the current state is IMO not satisfactory. I see 3 options...
145 2014-11-28 11:47:04 <jonasschnelli> 1. say that REST is meant local connections, so only allowing 127.0.0.1 and/or adding auth. default would be the logical step (but this is might be against the original plan o jgarzik) otherwise might see many port 80 responding with REST on the nodes
146 2014-11-28 11:47:26 <jonasschnelli> 2. harden http server with sploit-and-fix (very hard till impossible to implement, certainly not for 0.10)
147 2014-11-28 11:47:40 <jonasschnelli> 3. remove rest until it has a clear strategy where to go
148 2014-11-28 11:48:13 <gmaxwell> I don't think there is any ambiguity in strategy. This is not intended as a public interface exposed to the general internet. We have one of those, the p2p port.
149 2014-11-28 11:48:29 <gmaxwell> We're not going to be making arbritary bitcoin nodes acting as https servers to the general internet.
150 2014-11-28 11:49:42 <jonasschnelli> but reading jgarziks post ("Such an API would essentially provide a decentralized block explorer capability, enabling easy external access to transaction/address/block indices that we maintain.")...
151 2014-11-28 11:49:52 <gmaxwell> regardless of how hardened the interface is. Thats not the point for the interface. It's just another interface available to the operator of the node, and the lack of authentication is a major feature since auth configuration is a primary stumbling block for users.
152 2014-11-28 11:49:55 <jonasschnelli> does that more mean for a private decentralized net?
153 2014-11-28 11:50:37 <gmaxwell> jonasschnelli: he means for the user of the daemon themselves. Not for the general public (and the varrious indexes needed to do block explorerish like things are expensive to maintain and not on by default in any case)
154 2014-11-28 11:51:44 <jonasschnelli> so you just see the benefit in more-easy-to-access (no auth) then the RPC?
155 2014-11-28 11:52:21 <gmaxwell> yes.
156 2014-11-28 11:52:41 <jonasschnelli> regarding: https://github.com/bitcoin/bitcoin/pull/5326#issuecomment-64195797
157 2014-11-28 11:53:30 <jonasschnelli> the logical step could be adding @mikehearn's "getutxos" patch... how would that make sense having this on your private node?
158 2014-11-28 11:54:08 <gmaxwell> To serve to your own software.
159 2014-11-28 11:56:02 <jonasschnelli> okay. then this is more clear to me now. But would't it than make sense to just allow connections from 127.0.0.1 (maybe configurable)?
160 2014-11-28 11:58:30 <wumpus> that's already the case, RPC binds by default only on 127.0.0.1
161 2014-11-28 12:02:35 <jonasschnelli> okay. now i understand...
162 2014-11-28 12:02:43 <jonasschnelli> thanks and sorry for the confusion.
163 2014-11-28 12:03:36 <wumpus> you can extend it to say, a local network, with -rpcallowip
164 2014-11-28 12:09:59 <wumpus> it's indeed just an alternative way to query the node's state, I'm still not convinced it wouldn't have been beter as an external script
165 2014-11-28 12:11:27 <jonasschnelli> wumpus, i also don't see the point of adding another way to query only if the benefit it working around the auth... or is there more benefit?
166 2014-11-28 12:11:55 <wumpus> I've been trying hard to move away from the "bitcoind is a monolithic one-stop shop for all your bitcoin-related functionality" mindset
167 2014-11-28 12:12:38 <wumpus> but anyhow, it's pretty much separate from the rest of the code and easier to use than RPC, so maybe it will see some good uses
168 2014-11-28 12:13:08 <gmaxwell> wumpus: would be pretty easy to spin it into another process forked from bitcoind.
169 2014-11-28 12:13:19 <wumpus> gmaxwell: it doesn't need to be forked from bitcoind
170 2014-11-28 12:13:22 <gmaxwell> while breaking no compatiblity at all.
171 2014-11-28 12:13:28 <wumpus> just a separate process, a separate application
172 2014-11-28 12:13:54 <gmaxwell> no, it doesn't but if bitcoind doesn't launch it, would have higher administrative overhead... which I see is most of the advantages.
173 2014-11-28 12:14:18 <gmaxwell> Actually just us automatically creating auth credentials would be a world of good. walking people through setting up rpc credentials is a pita.
174 2014-11-28 12:15:14 <wumpus> it already creates auth credentials and prints how to use them?
175 2014-11-28 12:15:46 <DanMAbraham> gmaxwell: quick pm :P
176 2014-11-28 12:16:58 <gmaxwell> wumpus: yes, but then you must do sophicated technodweeb things like edit files.
177 2014-11-28 12:17:17 <wumpus> well arguably if you can't do that you aren't supposed to be messing around with this stuff at all
178 2014-11-28 12:18:00 <gmaxwell> well: task  "I want to use p2pool, or dustbegone, or andytoshi's coinjoin client"  most complicated step is enabling the rpc for your wallet. Which is a bit unfortunate.
179 2014-11-28 12:19:15 <wumpus> complicated?
180 2014-11-28 12:19:54 <gmaxwell> for joe-windows / mac osx / linux gui user navigating the file system and editing a text file is daunting compared to clicking.
181 2014-11-28 12:20:16 <gmaxwell> (also, they seem to like to make their rpcpassword a crappy password even after being given the automatic advice)
182 2014-11-28 12:20:32 <Luke-Jr> +1 to auto-configuring RPC :P
183 2014-11-28 12:20:48 <Luke-Jr> (it makes solo mining more plug-and-play too..)
184 2014-11-28 12:23:22 <wumpus> anyhow we already write the advice, creating a bitcoin.conf with those contents if it doesn't exist wouldn't be much more involved
185 2014-11-28 12:26:04 <wumpus> an even more fool proof option would be to use something like Tor's CookieAuthentication, which writes an authentication token to a file at each startup, and applciations that want to access it need access to that file.. the user won't even see the authentication token, even less be able to change it to something dumb
186 2014-11-28 12:26:28 <gmaxwell> Luke-Jr: for mining, I'd still like to have it eventually available on an unauthentcated port to the local network.
187 2014-11-28 12:27:06 <gmaxwell> wumpus: well thats effectively what we have if we use the recommendataion, save for the every startup part.   I'd like that.
188 2014-11-28 12:28:23 <wumpus> gmaxwell: the thing is that you're writing to a user configuration file, which isn't very nice, but if you just create it if it doesn't exist (and have write access to its directory) it's acceptable IMO
189 2014-11-28 12:29:16 <wumpus> but in general daemons shouldn't write to their configuration file, ideally they shouldn't even be able to
190 2014-11-28 12:29:41 <gmaxwell> maybe we could support two auth options:  auth via persistant rpcpassword, or auth (with a different username) via a rpccookie.  If there is no config file, we create one with rpccookie=1  and also create a rpccookie file at ever startup.
191 2014-11-28 12:30:21 <wumpus> sounds good to me
192 2014-11-28 19:59:06 <RobDude> Hi all - I hope this is okay to ask here.  I have a freeware desktop application with about 2,000 users per day.  I was wondering how difficult/profitable it would be to include bitcoin mining software along with my app.  When people run my app, they'd also donate some % of their CPU to mining for me.  Can anyone tell me if it would be feasible to set that up / what a ballpark figure would be for revenue
193 2014-11-28 20:01:49 <sturles> Completely unprofitable.
194 2014-11-28 20:02:00 <sturles> Just a lot of work an no revenue.
195 2014-11-28 20:03:03 <RobDude> Thanks.  I kind of expected as much, given that I haven't seen other applications doing it
196 2014-11-28 20:03:59 <sipa> all PCs in the world together would maybe be a few % of the hashing powere
197 2014-11-28 20:04:05 <sturles> CPUs aren't useful for mining anymore.  Haven't been for years.
198 2014-11-28 20:04:39 <sipa> ;;genrate 40000
199 2014-11-28 20:04:47 <gribble> The expected generation output, at 40000.0 Mhps, given difficulty of 40300030327.9, is 0.000499162419819 BTC per day and 2.07984341591e-05 BTC per hour.
200 2014-11-28 20:05:54 <sipa> so $0.2 per day, with 2000 PCs
201 2014-11-28 20:08:59 <RobDude> Thanks sipa.  It sounds like it's not worth the effort.  Plus, I have a feeling users wouldn't really like the sound of it
202 2014-11-28 23:17:11 <op_null> that's interesting.
203 2014-11-28 23:17:29 <op_null> 5.196.64.92 is advertising itself as a bitcoin node on serveral thousand ports.
204 2014-11-28 23:23:29 <op_null> they seem valid, at least I can handshake with them just fine.
205 2014-11-28 23:27:00 <op_null> right. they're sniffer ports. they act like /Satoshi:0.9.3/ but don't relay anything back to those who connect to them. well that's pretty obnoxious.