1 2015-07-19 00:20:56 <freewil> BlueMatt: were you aware that the builds for precise and lucid failed for the PPA?
 2 2015-07-19 01:13:20 <BlueMatt> freewil: no, only lucid failed
 3 2015-07-19 01:13:28 <BlueMatt> also, all arm builds
 4 2015-07-19 01:13:32 <BlueMatt> but those never worked
 5 2015-07-19 01:14:38 <gmaxwell> any idea why the arm builds are failing? Obviously bitcoin core runs fine on arm...
 6 2015-07-19 01:14:49 <freewil> BlueMatt: also precise
 7 2015-07-19 01:15:50 <freewil> https://i.imgur.com/b8eXHkp.png
 8 2015-07-19 01:16:56 <BlueMatt> oh, yea, oops, yea, lucid didnt fail because lucid cant be built anymore on launchpad
 9 2015-07-19 01:16:57 <BlueMatt> its eol
10 2015-07-19 01:16:59 <BlueMatt> precise failed
11 2015-07-19 01:18:00 <BlueMatt> specifically, precise failed because it has boost1.48 for everything except chrono
12 2015-07-19 01:18:03 <BlueMatt> for some unexplained reason
13 2015-07-19 01:19:54 <BlueMatt> where the package name is wrong
14 2015-07-19 01:20:12 <BlueMatt> gmaxwell: nope make check times out
15 2015-07-19 01:20:42 <BlueMatt> after segfaulting, it just hangs or so
16 2015-07-19 01:20:44 <BlueMatt> something like that
17 2015-07-19 08:11:51 <pgokeeffe> I’m interested in the application of functional programming in the Bitcoin space.
18 2015-07-19 08:11:59 <pgokeeffe> Already aware of #haskoin.
19 2015-07-19 08:13:14 <pgokeeffe> Seems like there would be reliability advantages of using something like Haskell to implement things like Bitcoin core.
20 2015-07-19 08:13:21 <pgokeeffe> What are the downsides?
21 2015-07-19 08:14:03 <pgokeeffe> For one, performance would probably require complex tuning.
22 2015-07-19 08:14:39 <Luke-Jr> you basically include the entire programming language implementation in the consensus protocol
23 2015-07-19 08:14:46 <pgokeeffe> Would anyone argue that there would be a security downside? I’d mostly argue that  would be an upside for Haskell.
24 2015-07-19 08:14:54 <Luke-Jr> which is likely a LOT of code, and unlikely to guarantee consensus compatibility
25 2015-07-19 08:15:28 <Luke-Jr> so you would probably need to fork the Haskell compiler and maintain it yourself
26 2015-07-19 08:15:34 <pgokeeffe> Luke-jr: Yes. From this point forward, very difficult to migratre consensus code to another toolchain.
27 2015-07-19 08:16:03 <pgokeeffe> Or fix the version of Haskell compiler being used.
28 2015-07-19 08:16:07 <Luke-Jr> pgokeeffe: I'm just talking about if you were to start a new altcoin from scratch - maintaining compatibility would be insanely difficutl
29 2015-07-19 08:16:27 <Luke-Jr> you can't really fix Haskell compiler versions
30 2015-07-19 08:16:30 <pgokeeffe> How is this managed with C++ and current Bitcoin Core?
31 2015-07-19 08:16:31 <Luke-Jr> they break ABI often
32 2015-07-19 08:16:42 <Luke-Jr> C++ is much more low-level than Haskell
33 2015-07-19 08:17:08 <pgokeeffe> So more predictable effects from compiler changes?
34 2015-07-19 08:18:16 <pgokeeffe> Would love some way to have a Proof of Consensus, but I think Turing might have something to say about that.
35 2015-07-19 08:19:29 <pgokeeffe> Something like this: http://cacr.uwaterloo.ca/~ajmeneze/anotherlook/ but for consensus, which I suspect would be harder still.
36 2015-07-19 08:22:11 <pgokeeffe> What’s say we leave consensus aside (put it in its own libconsensus) and consider other Bitcoin Core code. Now what are the downsides of functional programming here?
37 2015-07-19 08:24:32 <gmaxwell> --> ##programmingdebates or something.
38 2015-07-19 08:28:04 <Luke-Jr> pgokeeffe: then it's just a boring language preference choice, as gmaxwell hints ;)
39 2015-07-19 08:28:47 <pgokeeffe> gmaxmell: suitably chastened, thank you. I’m after a forum where I can ask this in a Bitcoin context. Would love core dev comment, but without you folks on critical, low bandwidth channel
40 2015-07-19 08:29:11 <pgokeeffe> bothering you folks*
41 2015-07-19 08:31:20 <gmaxwell> pgokeeffe: yea, sorry-- it's an interesting subject, everyone has opinions, etc etc. :)
42 2015-07-19 08:33:00 <pgokeeffe> gmaxwell: new in here, so just learning the ropes of what topics make sense where
43 2015-07-19 13:10:24 <BW^-> https://github.com/bitcoin/secp256k1 compilation crashes on OpenBSD 5.7.
44 2015-07-19 13:11:10 <BW^-> https://pastebin.mozilla.org/8839935
45 2015-07-19 13:11:12 <BW^-> crash log.
46 2015-07-19 13:13:03 <BW^-> wait.. but does it compile anyhow.. lessee
47 2015-07-19 13:13:31 <BW^-> "Makefile.am:83: `%'-style pattern rules are a GNU make extension" hmm
48 2015-07-19 13:13:41 <BW^-> is it trying to use "make" instead of "gmake".
49 2015-07-19 13:23:41 <billotronic> !balance
50 2015-07-19 13:23:41 <gribble> (balance <an alias, 1 argument>) -- Alias for "calc [web fetch http://blockchain.info/q/addressbalance/$1]/100000000".
51 2015-07-19 17:54:34 <English-> hey folks.... using the bitcoin json rpc api, what's the best way of calculating TPS, just counting the number of tx's in the mempool?
52 2015-07-19 17:54:53 <English-> or is this info available another way?
53 2015-07-19 17:55:22 <Luke-Jr> English-: define TPS
54 2015-07-19 17:55:45 <English-> transactions per second
55 2015-07-19 17:56:06 <Luke-Jr> bitcoind doesn't know how many transactions per second - most are off-chain
56 2015-07-19 17:56:16 <sipa> English-: getmempoolinfo will tell you how many transactions are in the mempool
57 2015-07-19 17:56:43 <English-> ok, great, thanks
58 2015-07-19 17:56:50 <Luke-Jr> and potential-blockchain-transactions per second is not really a meaningful number
59 2015-07-19 17:56:58 <sipa> but that won't tell you the number of transactions per second
60 2015-07-19 17:57:05 <sipa> as not all of them make it into the blockchain
61 2015-07-19 17:57:25 <sipa> you can use getblock to find the number of transactions in every block
62 2015-07-19 17:58:06 <English-> I guess then, I was looking to find a real time stat of transactions received by a node, from the network
63 2015-07-19 17:58:21 <Luke-Jr> pretty sure bitcoind doesn't keep count of that
64 2015-07-19 17:58:40 <Luke-Jr> no point, as the number is meaningless
65 2015-07-19 17:58:46 <sipa> grep the logfile, and set -debug=mempool :)
66 2015-07-19 17:58:50 <Luke-Jr> the GUI's debug window IIRC says bytes/sec though
67 2015-07-19 17:58:51 <English-> not from what I have seen, getting the delta of the tx's in the mempool seems to be the only way
68 2015-07-19 17:59:18 <English-> and then allow for drop as a new block is found
69 2015-07-19 17:59:50 <Luke-Jr> but again, this is not useful information to have/get; so not sure what you're trying to accomplish
70 2015-07-19 18:00:13 <English-> just something to graph over time.... :)
71 2015-07-19 18:00:30 <English-> that's it really :)
72 2015-07-19 18:06:00 <English-> thanks for the info guys, much appreciated, laters :)
73 2015-07-19 20:43:44 <dgenr8> sipa: no janitor thread, nifty