1 2015-07-02 00:29:31 <boxmein> ohai, if I wanted to develop apps that did stuff based on bitcoin movements, but at the same time would not want to download the thirty-gigabyte blockchain, how would I go about it
 2 2015-07-02 00:29:41 <boxmein> as a lot of libraries depend on bitcoind, is there a "thin bitcoind"
 3 2015-07-02 00:32:29 <phantomcircuit> boxmein, #bitcoin
 4 2015-07-02 00:32:43 <phantomcircuit> this channel is for development of bitcoin core software, not bitcoin software in general
 5 2015-07-02 00:33:33 <boxmein> whoops D:
 6 2015-07-02 00:34:27 <gmaxwell> TD-Linux: yea, bad idea. :P (care to be maximally multithread incompatible? :P )
 7 2015-07-02 00:53:59 <TD-Linux> gmaxwell, I'm trying to decide how to go forward with the static context patch
 8 2015-07-02 00:56:58 <gmaxwell> my impression is just to leave the init and all alone, and just make that table static. but you really ought to get sipa's opinion, join #secp256k1
 9 2015-07-02 11:38:58 <fanquake> wumpus You probably want to merge https://github.com/bitcoin/bips/pull/166
10 2015-07-02 11:41:04 <wumpus> looking
11 2015-07-02 13:17:00 <jonasschnelli> hearn: you need to add ipgroups.h to src/Makefile.am
12 2015-07-02 13:17:08 <jonasschnelli> you only added the implementation file (.cpp)
13 2015-07-02 13:17:32 <jonasschnelli> probably at line 101
14 2015-07-02 13:22:54 <altnode> @jonasschnelli I saw did you some work on banned peers. Do the setban/listbanned and clearbanned work with you?
15 2015-07-02 13:23:24 <jonasschnelli> altnode: yeah. They work fine... just compile the master branch and test it yourself.
16 2015-07-02 13:23:30 <altnode> tried them on 0.10.2 and get this error: {"code":-32601,"message":"Method not found"}
17 2015-07-02 13:23:41 <jonasschnelli> nope. will be in 0.12
18 2015-07-02 13:23:50 <jonasschnelli> Also not in 0.11 (which will be released soon).
19 2015-07-02 13:24:13 <jonasschnelli> If you want to test it you can use a nightlybuild
20 2015-07-02 13:24:15 <altnode> oh sorry, missed that
21 2015-07-02 13:24:29 <altnode> thanks
22 2015-07-02 14:37:56 <petertodd> hey everyone, mind running 'host testnet-seed.bitcoin.petertodd.org' and telling me if you get any errors?
23 2015-07-02 14:38:24 <petertodd> I think I fixed a long-standing issue with sipa's bitcoin-seeder not working with some ISPs: https://github.com/sipa/bitcoin-seeder/pull/27
24 2015-07-02 14:38:55 <helo> petertodd: looks good here. 23 ipv4 responses, and 13 ipv6.
25 2015-07-02 14:39:30 <petertodd> ok, so if it looks good, now try 'host rbf-seed.tbtc.petertodd.org'
26 2015-07-02 14:39:57 <petertodd> the second one isn't upgraded yet, so if your ISP is affected you should get something like 'Host rbf-seed.tbtc.petertodd.org not found: 2(SERVFAIL)'
27 2015-07-02 14:40:24 <helo> yep, that error exactly
28 2015-07-02 14:40:47 <petertodd> great! what ISP/country if you mind sharing?
29 2015-07-02 14:43:14 <helo> in the US - cox, and also a vps at serverpronto (Infolink Global Corporation)
30 2015-07-02 14:43:49 <petertodd> helo: thanks! google's 8.8.8.8/8.8.4.4 nameservers appear to have the same behavior too
31 2015-07-02 14:45:23 <harding> petertodd: I get identical results to helo on Comcast NJ, USA.  On a Linode in Newark NJ, I get the same results for testnet-seed but for rbf-seed I get a single IPv4 address.
32 2015-07-02 14:46:02 <petertodd> harding: cool, your ISP probably ignores the issue then
33 2015-07-02 14:46:32 <leakypat> petertodd: this will be used automatically by an RBF node ?
34 2015-07-02 14:47:22 <petertodd> leakypat: well, it's one of the seeds, so it'll be one source of many for IP addresses; for SPV though it's probably more useful if you're using bitcoinj's strategy of relying totally on seed nodes
35 2015-07-02 14:47:55 <petertodd> leakypat: the full-RBF patch does preferential peering, so even without the RBF seeds it will eventually find some RBF peers and then stay connected to them
36 2015-07-02 15:01:33 <jtimon> mhmm, is there wa way to make #define CBaseChainParams\:\:MAIN "main" work? the "::" are forcing me to use static const attribute of CBaseChainParams instead of the precompiler...
37 2015-07-02 15:01:48 <jtimon> s/attribute/attributes
38 2015-07-02 15:03:27 <jtimon> nevermind http://stackoverflow.com/a/369524
39 2015-07-02 15:07:28 <leakypat> petertodd: yes, I noticed it finding one or two on testnet. Btw I have my ant miner s5 arriving on Friday so will get some RBF hashing power on testnet
40 2015-07-02 15:08:13 <petertodd> leakypat: great!
41 2015-07-02 15:11:20 <jtimon> petertodd you ported bip66 back to 0.8, right?
42 2015-07-02 15:12:09 <petertodd> jtimon: I certainly didn't; sipa might have
43 2015-07-02 15:12:19 <petertodd> jtimon: we did backport bip66 to 0.9.5
44 2015-07-02 15:13:00 <jtimon> petertodd: ok, thanks, 0.9 may be the oldest one, let me check
45 2015-07-02 15:15:19 <jtimon> oh, no, indeed sipa did backport it to 0.8
46 2015-07-02 15:54:47 <hearn> jonasschnelli: why does it build for me? different autotools version or something?
47 2015-07-02 15:55:56 <jonasschnelli> hearn: hmm.. it shouldn't. But you probably did add the header to your local makefile.
48 2015-07-02 15:56:08 <hearn> i don't recall editing any makefiles directly.
49 2015-07-02 15:56:09 <jonasschnelli> or your toolchain detect it based on your filesys
50 2015-07-02 15:56:16 <hearn> hm possibly. maybe it's a clang thing.
51 2015-07-02 15:56:25 <jonasschnelli> But it need to be in src/Makefile.am anyways.
52 2015-07-02 15:58:22 <hearn> i'll add it
53 2015-07-02 16:04:14 <cfields> hearn: only the files listed in the makefiles are included in the source tarballs. That's to prevent source releases from including straggler files from some dev's working dir
54 2015-07-02 16:04:31 <cfields> travis creates a source tarball, extracts it, then builds from it. That ensures that all files are properly listed
55 2015-07-02 16:07:24 <hearn> i see
56 2015-07-02 18:04:01 <fanquake> wumpus can close #4219
57 2015-07-02 18:06:22 <fanquake> Wondered why my sigs hadn't been merged. Realised I didn't even create the pull..
58 2015-07-02 18:31:14 <jonasschnelli> wumpus: regarding CSubNet::CSubNet(const CNetAddr &addr, bool fAllowLookup) are you sure we can leave out the `LookupHost()`?
59 2015-07-02 18:31:52 <jonasschnelli> it would change all current ban option (RPC and node missbehaving)
60 2015-07-02 18:32:57 <jonasschnelli> ah... i see, we do the lockup in the CNetAddr::CNetAddr contr.
61 2015-07-02 18:33:01 <jonasschnelli> constructor
62 2015-07-02 18:33:28 <cfields> jonasschnelli: if it helps, the first part of my net refactor removes the lookups from all of those containers
63 2015-07-02 18:33:34 <cfields> i could go ahead and PR that part if it'd help you
64 2015-07-02 18:34:20 <jonasschnelli> cfields: nice. But i think we almost are done with #6310... lets try to get this merged... removing the lockups can follow.
65 2015-07-02 18:34:29 <cfields> ok
66 2015-07-02 19:25:01 <andytoshi> does anyone here run kcov on the libsecp256k1 ./tests binary? i last did this a few weeks ago and it has stopped working mysteriously
67 2015-07-02 19:25:18 <andytoshi> do i need specific cflags or ./configure options or something?
68 2015-07-02 19:25:42 <gmaxwell> andytoshi: it needs the prof cflags.
69 2015-07-02 19:26:13 <gmaxwell> oh, kcov not gcov!
70 2015-07-02 19:26:15 <gmaxwell> no clue.
71 2015-07-02 19:26:24 <gmaxwell> andytoshi: ah I bet the use of O3 is whats breaking it.
72 2015-07-02 19:26:30 <andytoshi> i'll try the prof cflags .. but i don't think so
73 2015-07-02 19:27:03 <andytoshi> that might be it. it says "???" even for "Command run" which i don't recall ever encountering before, i think it used to just have 0/0 on everything if i ran it wrong
74 2015-07-02 19:27:19 <andytoshi> :/ what an irritating tool
75 2015-07-02 19:27:40 <gmaxwell> andytoshi: yea, no, kcov doesn't need special instrumention I think; I'd guess if it stopped it would be the switch to O3 by default that broke it.
76 2015-07-02 19:28:45 <andytoshi> hmm, nope, with O0 it's still broken
77 2015-07-02 19:29:19 <andytoshi> i've got a <defunct> tests binary in my process list, and i've upgraded my kernel, could be either of those i suppose
78 2015-07-02 19:31:49 <andytoshi> with debug on it says `Can't find breakpoint at 0x7ffff79f7a89`, i'll bet that defunct process broke something
79 2015-07-02 19:42:38 <andytoshi> ugh, i'm an idiot, the kcov output requires javascript to be populated
80 2015-07-02 20:00:39 <jonasschnelli> oops: travis failing on master... https://travis-ci.org/bitcoin/bitcoin
81 2015-07-02 20:03:08 <jonasschnelli> Nevermind. I think the travis icon on https://github.com/bitcoin/bitcoin is wrong.
82 2015-07-02 20:49:17 <gmaxwell> I estimate a 4.47% probablity that BIP66 activates 73 blocks from now. FWIW.
83 2015-07-02 20:50:49 <gmaxwell> (in the last 288 blocks v2 is 4.166%, minimum number of additional v3 blocks to trigger activation is 73, (1-4.166%)^73 = 4.47%)
84 2015-07-02 21:18:01 <cfields> jonasschnelli: no, looks like it's failing
85 2015-07-02 21:18:40 <cfields> looks like 5881 did it
86 2015-07-02 21:31:40 <cfields> wumpus: hehe, you beat me to it :)
87 2015-07-02 21:31:47 <cfields> still compiling master here
88 2015-07-02 21:47:55 <michagogo> gmaxwell: didn't it already activate?
89 2015-07-02 21:48:01 <michagogo> Or do you mean lock in?
90 2015-07-02 21:56:14 <phantomcircuit> michagogo, the 75% threshold was passed, so blocks which have v3 enforce the rule, blocks which are v2 dont and are valid until the 95% threshold
91 2015-07-02 21:56:34 <michagogo> phantomcircuit: right
92 2015-07-02 21:58:15 <gmaxwell> michagogo: yes, thought it was clear from the context.
93 2015-07-02 21:59:02 <michagogo> gmaxwell: btw, does that account for whether the blocks falling off the end are v2 or v3?
94 2015-07-02 21:59:18 <gmaxwell> yes.
95 2015-07-02 21:59:55 <gmaxwell> at the time I spoke the minimum number of additional v3 block added to the tip to make the rule lock in was 73.  It's that many because most falling out are v3.
96 2015-07-02 22:00:59 <gmaxwell> failing to account for that you'd get a stupid number like "6 blocks required to lock in" :)
97 2015-07-02 23:21:08 <petertodd> wumpus: thanks for merging getblockheader, I've put it to "good" use already "optimizing" some two year old code of mine: https://github.com/petertodd/unholynames
98 2015-07-02 23:34:50 <Luke-Jr> wumpus: propose 6177 for 0.11 if there's another RC