1 2015-10-27 00:21:18 <rusty> make[3]: Entering directory '/home/rusty/devel/cvs/bitcoin/src/univalue'
  2 2015-10-27 00:21:20 <rusty> make[3]: Leaving directory '/home/rusty/devel/cvs/bitcoin/src/univalue'
  3 2015-10-27 00:21:20 <rusty> make[3]: *** No rule to make target 'libunivalue.la'.  Stop.
  4 2015-10-27 00:21:20 <rusty> Makefile:7350: recipe for target 'univalue/libunivalue.la' failed
  5 2015-10-27 00:21:43 <sipa> git clean -dfx
  6 2015-10-27 00:22:04 <rusty> sipa: thx...
  7 2015-10-27 00:22:39 <sipa> I am more worried about the fact that you seem to have checked out the Bitcoin Core source tree via CVS!
  8 2015-10-27 00:23:37 <rusty> sipa: heh... my "cvs" directory dates from about 20 years ago, for project source which used that fancy new online revision control system, rather than straight tarballs.
  9 2015-10-27 00:57:32 <rusty> CXXLD    bitcoind
 10 2015-10-27 00:57:33 <rusty> libbitcoin_server.a(libbitcoin_server_a-init.o): In function `CleanupBlockRevFiles()':
 11 2015-10-27 00:57:33 <rusty> /usr/include/boost/filesystem/path.hpp:140: undefined reference to `boost::filesystem::path_traits::dispatch(boost::filesystem::directory_entry const&, std::string&)'
 12 2015-10-27 01:01:05 <phantomcircuit> rusty, which version of boost?
 13 2015-10-27 01:01:17 <rusty> phantomcircuit: latest ubuntu, let me check...
 14 2015-10-27 01:02:03 <rusty> phantomcircuit: 1.58
 15 2015-10-27 01:10:53 <phantomcircuit> rusty, deprecated?
 16 2015-10-27 01:11:12 <rusty> phantomcircuit: sorry?
 17 2015-10-27 01:11:27 <phantomcircuit> any chance that call is deprecated?
 18 2015-10-27 01:12:07 <rusty> phantomcircuit: oh, there's more, that's just the first undefined.
 19 2015-10-27 01:12:47 <phantomcircuit> rusty, it looks like boost::filesystem has a version 2 and a version3
 20 2015-10-27 01:16:46 <rusty> phantomcircuit: ... I am trying to figure out why this has become my problem.
 21 2015-10-27 01:18:55 <rusty> phantomcircuit: let me try bisecting, see if I can figure out what happened.  I haven't built since upgrading to 15.10.
 22 2015-10-27 04:00:20 <acti0nman> about compliance best practices!
 23 2015-10-27 04:00:20 <acti0nman> Security Compliance is relevant to #bitcoin with all the bitoin stealing that's happening! Putting your Bitcoin Development Environment through PCI-DSS, FISMA/FEDRAMP, HIPAA, ISO 27001/2 will help you reduce security risk and increase trust/confidence in your product. Come join ##GRC. There are QSAs, Sysadmins, and Developers in ##GRC to help you throughout the security compliance process. ##GRC will answer your questions
 24 2015-10-27 04:01:01 <gmaxwell> acti0nman: Do they also help with spam?
 25 2015-10-27 04:02:52 <acti0nman> ##GRC is a budding channel, it needs help to grow. Security Compliance is relevant and important to Bitcoin customers, especially after Mt. Gox fell.
 26 2015-10-27 04:04:09 <gmaxwell> acti0nman: sounds more like trying to pull off victims to get compromised.
 27 2015-10-27 04:18:48 <jcorgan> If I Capitalize Everything I Say And Use Many Acronyms Will I Attain Security Compliance?
 28 2015-10-27 07:11:58 <wumpus> spam for security compliance... I... I don't know what to say
 29 2015-10-27 07:17:39 <Luke-Jr> lol
 30 2015-10-27 07:21:18 <gmaxwell> It causes me less dissonance to assume it's a con... "we'll /help/ you improve your security"... more comfortable than thinking that otherwise upstanding people think it's okay to spam like that.
 31 2015-10-27 07:25:56 <wumpus> yeah... either a con or "snakeoil security certifications, 3 a piece!"
 32 2015-10-27 10:07:25 <hardyred> Hey quick question, I am accessing bitcoind RPC interface on ubuntu and it crashes around 100 calls/second
 33 2015-10-27 10:07:33 <hardyred> I increased my swap space but it did not seem to do much
 34 2015-10-27 10:08:25 <hardyred> Anyone know any other things I should try to make it stay up for longer?
 35 2015-10-27 10:09:28 <wumpus> what kind of crash?
 36 2015-10-27 10:12:04 <hardyred> Not sure, it says bitcoind is still running but bitcoin-cli give me an error: couldn't connect to server, and RPC interface returns the error: [Error: Bitcoin Core JSON-RPC: host=127.0.0.1 port=18332: Request Error: connect EADDRNOTAVAIL]
 37 2015-10-27 10:12:50 <hardyred> Windows setup for bitcoind on same hardware reaches over 500 requests/second without any issues, not sure why it's crashing frequently on ubuntu
 38 2015-10-27 10:13:30 <wumpus> usually that means you have run out of ephermal ports for outgoing TCP connections
 39 2015-10-27 10:14:27 <wumpus> you can set a wider range in /proc/sys/net/ipv4/ip_local_port_range, but best is to use HTTP keepalive instead of opening a new connection for every command
 40 2015-10-27 10:15:57 <hardyred> Hmm ok
 41 2015-10-27 10:16:02 <wumpus> also: make sure that you are closing sockets after you don't need them anymore
 42 2015-10-27 10:16:33 <hardyred> I assume Windows was doing that automatically
 43 2015-10-27 10:16:44 <hardyred> considering the sheer difference between the two performances
 44 2015-10-27 10:17:57 <wumpus> well to name an example if you connect from some language with garbage collector, and rely on the GC to clean up old sockets, you'll run out of them if you accumulate too many before it runs. You need to close them manually after use.
 45 2015-10-27 10:18:38 <wumpus> so in that case it's happening automatically just not fast enough for this kind of 'DoS Attack' :)
 46 2015-10-27 10:19:52 <hardyred> Well let me try your suggestion and report the results, thank you :)
 47 2015-10-27 10:21:50 <hardyred> Well first I will try changing ip_local_port_range and see if I notice any difference
 48 2015-10-27 10:22:13 <hardyred> Right now my file lists 32768 61000
 49 2015-10-27 10:22:29 <hardyred> Should I just increase the upperbound limit and see if it works?
 50 2015-10-27 10:24:07 <hardyred> Or should I touch below 32768 since I believe < 1024 are reserved
 51 2015-10-27 10:25:21 <wumpus> 32768 61000 is already a huge range - I doubt increasin that will make any difference
 52 2015-10-27 10:26:06 <wumpus> that's 30k ports! I'd look at your client program and make sure it closes sockets first...
 53 2015-10-27 10:30:21 <hardyred> Client program in reference to program making JSON-RPC calls or bitcoind? (sorry for noob questions heh)
 54 2015-10-27 10:31:06 <wumpus> client = the program making calls
 55 2015-10-27 10:31:34 <wumpus> a local EADDRNOTAVAIL error can't be bitcoind's fault - the ports to connect *from* are exhausted
 56 2015-10-27 10:33:40 <hardyred> Well that's odd then, because it seems when that error shows up on my client
 57 2015-10-27 10:33:46 <hardyred> bitcoin-cli is unable to connect to server either
 58 2015-10-27 10:33:58 <wumpus> from the same host?
 59 2015-10-27 10:34:04 <hardyred> while before it can connect while the program is running, but once I receive the error it stops connecting
 60 2015-10-27 10:34:04 <hardyred> yes
 61 2015-10-27 10:34:13 <hardyred> But bitcoind is still running in processes
 62 2015-10-27 10:34:28 <wumpus> that makes sense, bitcoin-cli will suffer from the same problem, and be unable to create a port to connect from too
 63 2015-10-27 10:34:29 <hardyred> Well actually, checking again
 64 2015-10-27 10:34:40 <hardyred> It connects about 2 minutes later
 65 2015-10-27 10:34:41 <hardyred> oh
 66 2015-10-27 10:34:47 <wumpus> if another program took all the ephermal ports
 67 2015-10-27 10:35:01 <hardyred> Ah I am following you now
 68 2015-10-27 10:35:21 <wumpus> try running netstat -anp  when it happens, you'll get a very long list
 69 2015-10-27 10:35:29 <wumpus> 30k entries long ...
 70 2015-10-27 10:37:49 <hardyred> Oh jeez
 71 2015-10-27 10:37:57 <hardyred> Not sure if 30,000 exactly but it sure looked like it :o
 72 2015-10-27 10:38:24 <hardyred> Should have tried that earlier :/
 73 2015-10-27 12:03:27 <hardyred> wumpus: I had to make myself a quick breakfast
 74 2015-10-27 12:04:11 <hardyred> wumpus: but you were right, after I closed the socket following each request I did not run in to any more erros
 75 2015-10-27 12:04:13 <hardyred> errors*
 76 2015-10-27 12:04:15 <hardyred> thank you
 77 2015-10-27 12:07:16 <wumpus> great!
 78 2015-10-27 12:10:21 <hardyred> wumpus: your recommendation though is just to keep one keep-alive socket connection for all the requests right?
 79 2015-10-27 12:10:53 <wumpus> well, using keep-alive would probably be more efficient. If you've solved the problem and that's enough, you can stop here
 80 2015-10-27 12:11:19 <hardyred> wumpus: I like efficiency :p, I will keep it in mind
 81 2015-10-27 14:36:34 <yammq> are there any plans to port Bitcoin Core to C++11 ? Anyone working on this?
 82 2015-10-27 14:38:02 <bsm1175321> Have you tried just running it? g++ -std=c++11
 83 2015-10-27 14:38:49 <bsm1175321> I'm fairly certain the code will compile. What specifically are you proposing?
 84 2015-10-27 14:38:49 <Diablo-D3> bsm1175321: I think he means as in removing the boost dep
 85 2015-10-27 14:40:00 <sipa> yammq: as soon as we drop support for build systems that have too low c++11 support, we will start using c++11 features
 86 2015-10-27 14:40:32 <sipa> yammq: specifically, it means we need to support everything below gcc 4.8, whivh is still common in some older linix distros we support
 87 2015-10-27 14:41:16 <sipa> but we will be able to get rid of boost:;unordered_map, boost::thread, boost::mutex, boost::shared_ptr etc
 88 2015-10-27 14:41:24 <sipa> bu using their c++11 equivalents
 89 2015-10-27 14:42:07 <yammq> ok cool, guess Ubuntu 12.04 is a main blocker here
 90 2015-10-27 14:42:23 <yammq> bsm117532: Yes, I just tried, some errors
 91 2015-10-27 14:45:11 <yammq> sipa: is there a list of the supported Linux Distributions / Operating Systems somewhere?
 92 2015-10-27 14:49:33 <sipa> yammq: the release binaries are still built in a 12.04 ubuntu VM
 93 2015-10-27 14:49:38 <sipa> i think
 94 2015-10-27 14:55:00 <wumpus> 14.04 nowadays
 95 2015-10-27 14:55:31 <wumpus> if we need a newer gcc in gitian that's pretty much trivial, that's not what is holding it back
 96 2015-10-27 14:56:15 <bsm1175321> Do it.  Let's lambda and auto the shit out of this mess.
 97 2015-10-27 14:56:26 <wumpus> https://github.com/bitcoin/bitcoin/issues/6211
 98 2015-10-27 14:57:11 <wumpus> main problem is that some people want to compile bitcoind on older distributions that have older gccs, using (non-trivial) c++11 burns some bridges
 99 2015-10-27 14:58:20 <bsm1175321> Gavin says 0.13.  Seems like a good target.  Which means as soon as 0.12 is released, we could start using c++11 features on dev branches.
100 2015-10-27 14:58:24 <wumpus> so to be clear: it's not about our build system, it's about uncertainty about what minimum versions to support
101 2015-10-27 14:58:49 <wumpus> I'm ok with that
102 2015-10-27 15:00:55 <wumpus> sipa: oh you were right, we're indeed still using precise/12.04 in gitian, brainfart, thought we had upgraded
103 2015-10-27 15:01:10 <wumpus> anyhow that can be changed easily
104 2015-10-27 15:01:15 <bsm1175321> Thanks for bringing it up yammq, I'm going to start compiling with c++11 locally, see if any errors pop up.
105 2015-10-27 15:03:08 <wumpus> I think I was working on that once then I was interrupted with some issue and then another and then another and mental stack overflow happened
106 2015-10-27 15:09:21 <yammq> Thanks. Seems like there is a consensus regarding C++11 in the Github issue :)
107 2015-10-27 15:12:25 <bsm1175321> If you're really feeling ambitious, clang has a source-to-source c++11 conversion tool: http://clang.llvm.org/extra/clang-modernize.html
108 2015-10-27 15:12:30 <wumpus> dropping boost becomes realistic when full C++11 can be used we don't use boost asio anymore, we don't use spirit anymore, what remains is some data structures (like unordered_map) that exist in C++11, as well as threading/synchronization (of which most can be handled by C++11).  The only lib that has no clear c++11 relpacement is boost::filesystem
109 2015-10-27 15:14:12 <wumpus> https://en.wikipedia.org/wiki/C%2B%2B17 c++17 on the other hand... :-)
110 2015-10-27 15:16:23 <bsm1175321> Because having language features change out from under you is fun! ;-)
111 2015-10-27 15:18:37 <wumpus> well if it slowly helps change c++ into a safer, less frustrating language I'm all for it
112 2015-10-27 15:19:10 <bsm1175321> Is reimplementing bitcoin in python still an option?  ;-)
113 2015-10-27 15:19:18 <wumpus> it helps it stays relevant in a changing world
114 2015-10-27 15:22:04 <wumpus> haha, of course it is. I do most (ad hoc) testing using pynode and python-bitcoinlib. Using those and libconsensus it should be possible to make a consensus-conforming node implementation.
115 2015-10-27 15:30:36 <bsm1175321> Just compiled with c++11.  A few warnings are a few "std::auto_ptr is deprecated", "unrecognized command line option -Wno-self-assign", biggest problem is that rpcserver.cpp doesn't compile due to some problems with std::map.  Doesn't look too hard to fix.  (All other sources including qt and tests compile)
116 2015-10-27 15:31:47 <bsm1175321> I'll make a PR for that...
117 2015-10-27 15:35:15 <wumpus> problems with std::map?
118 2015-10-27 15:36:37 <bsm1175321> compile error: https://gist.github.com/mcelrath/cb02daaadbd0b01d9677
119 2015-10-27 15:38:58 <wumpus> looks like that needs an explicit boost::shared_ptr<>() to wrap the pointer now
120 2015-10-27 15:40:05 <bsm1175321> Will try
121 2015-10-27 15:40:21 <morcos> One other thing we need now before we can get rid of boost is a multi-index implementation
122 2015-10-27 15:40:36 <wumpus> morcos:  good point
123 2015-10-27 15:40:41 <morcos> this seems like this conversation is in the wrong channel though
124 2015-10-27 15:40:50 <wumpus> it is
125 2015-10-27 15:42:35 <zooko``> What channel is it appropriate for?
126 2015-10-27 15:43:33 <wumpus> #bitcoin-core-dev
127 2015-10-27 15:44:04 <zooko> Thanks, wumpus
128 2015-10-27 16:00:21 <frank1e> hey all
129 2015-10-27 16:00:28 <frank1e> still living =) didn't forget you guys
130 2015-10-27 16:06:58 <wumpus> hey
131 2015-10-27 17:41:51 <kroko> Hi, it seems like the GetHashesPerSec RPC is removed, is there any alternative method to get information about the mining performance?
132 2015-10-27 17:42:32 <sipa> kroko: for all practical purposes, you may assume the hashing performance is 0 :)
133 2015-10-27 17:42:45 <kroko> sipa: :D
134 2015-10-27 17:43:10 <kroko> sipa: I like lottery :)
135 2015-10-27 17:43:55 <kroko> sipa: I was interested just to see how bad it actually performs ... I like exact numbers.
136 2015-10-27 17:44:47 <kroko> sipa: I wounder why they kept the setgenerate true then in the first place, if there is no way to check the performance
137 2015-10-27 17:49:06 <sipa> ;;genrate 20
138 2015-10-27 17:49:08 <gribble> The expected generation output, at 20.0 Mhps, given difficulty of 60883825480.1, is 1.65202009718e-07 BTC per day and 6.88341707157e-09 BTC per hour.
139 2015-10-27 17:49:31 <sipa> kroko: about that much with a high end pc
140 2015-10-27 17:49:46 <sipa> ;;help
141 2015-10-27 17:49:47 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
142 2015-10-27 17:50:26 <sipa> ;;calc 0.0000001652 * 365 * 300
143 2015-10-27 17:50:27 <gribble> 0.0180894
144 2015-10-27 17:50:38 <sipa> about that many dollars per year
145 2015-10-27 17:51:50 <kroko> sipa: Ok, thanks :) I'll settle with this information then :)
146 2015-10-27 17:52:56 <sipa> kroko: maybe more interesting:
147 2015-10-27 17:53:15 <gribble> Error: '1y' is not a valid positive integer.
148 2015-10-27 17:53:15 <sipa> ;;genprob 20 1y
149 2015-10-27 17:53:21 <sipa> ;;gentime 20
150 2015-10-27 17:53:22 <gribble> The average time to generate a block at 20.0 Mhps, given difficulty of 60883825480.1, is 414602 years, 21 weeks, 1 day, 3 hours, 29 minutes, and 43 seconds
151 2015-10-27 17:54:06 <sipa> ;;genprob 20 30500000
152 2015-10-27 17:54:07 <gribble> The probability to generate a block at 20.0 Mhps within 50 weeks, 3 days, 0 hours, 13 minutes, and 20 seconds, given difficulty of 60883825480.1, is 2.33274643724e-06
153 2015-10-27 17:54:20 <sipa> lotteries have much better odds usually
154 2015-10-27 17:57:38 <forge_> sitting with a cup on the street will bring better income with these chances
155 2015-10-27 18:00:05 <kroko> sipa: thanks again. I agree that hoping to win a block is pretty futile on regular high end PC. As I already own a cup, so I'll use it as my hardware :D But I can't understand why they removed this option, when hash generation can still be enabled via the client. If I understand it correctly, people using the specialized hardware also use specialised mining software, not bitcoin core.
156 2015-10-27 18:03:33 <sipa> kroko: the option is still there for testnet and regtest, so it can used in tests that need to generate an own chain
157 2015-10-27 18:05:02 <kroko> sipa: ahh ok, that makes sense
158 2015-10-27 23:13:33 <Luke-Jr> why was this one rejected? https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/attachments/20151027/3bd0a0af/attachment.mht
159 2015-10-27 23:30:46 <Luke-Jr> rusty: ^