1 2016-10-03 05:58:06	0|GitHub64|13bitcoin/06master 141c80386 15Wladimir J. van der Laan: rpc: Generate auth cookie in hex instead of base64...
  2 2016-10-03 05:58:06	0|GitHub64|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6013c73b3312...6f3ef551fa0f
  3 2016-10-03 05:58:07	0|GitHub64|13bitcoin/06master 146f3ef55 15Wladimir J. van der Laan: Merge #8858: rpc: Generate auth cookie in hex instead of base64...
  4 2016-10-03 05:58:21	0|GitHub183|[13bitcoin] 15laanwj closed pull request #8858: rpc: Generate auth cookie in hex instead of base64 (06master...062016_10_01_moar_cookies) 02https://github.com/bitcoin/bitcoin/pull/8858
  5 2016-10-03 05:58:52	0|gmaxwell|"Error: -daemon is not supported on this operating system"
  6 2016-10-03 05:59:28	0|gmaxwell|wumpus: I am guessing that I shouldn't be seeing that on debian testing... and that I probably need to autogen.
  7 2016-10-03 05:59:50	0|gmaxwell|(checks)
  8 2016-10-03 05:59:53	0|gmaxwell|So I expect we're likely to get reports... :P
  9 2016-10-03 06:16:45	0|wumpus|gmaxwell: hah, already preempted that days ago: https://github.com/bitcoin/bitcoin/pull/8813#issuecomment-250788185 :)
 10 2016-10-03 06:29:56	0|gmaxwell|wumpus: comfirmed, autogen/configure fixed.
 11 2016-10-03 06:30:24	0|gmaxwell|Perhaps when we add these ifdefs we should set them up so if nothing is set at all we #error  with a reconfigure you knucklehead? :P
 12 2016-10-03 06:32:49	0|wumpus|that wouldn't be a bad idea, actually
 13 2016-10-03 06:33:34	0|wumpus|that same path would trigger for people building without HAVE_CONFIG_H, e.g. people trying to build with custom-rolled build systems, such as adding everyting into a MSVC project
 14 2016-10-03 06:34:00	0|wumpus|currently one'd get a whole slew of unrealistic defaults (although the windows one would work out)
 15 2016-10-03 06:34:16	0|wumpus|would fork out for HAVE_DAEMON I mean. Not for other config.h options
 16 2016-10-03 06:35:53	0|gmaxwell|libsecp256k1 does this.
 17 2016-10-03 06:45:32	0|GitHub182|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6f3ef551fa0f...eafc5f4fae52
 18 2016-10-03 06:45:33	0|GitHub182|13bitcoin/06master 142ca7faa 15MarcoFalke: Squashed 'src/univalue/' changes from daf1285..16a1f7f...
 19 2016-10-03 06:45:33	0|GitHub182|13bitcoin/06master 14e757115 15MarcoFalke: Merge commit '2ca7faab4205822b06dc2ab2bbda0a9a70fce7e0' into HEAD
 20 2016-10-03 06:45:34	0|GitHub182|13bitcoin/06master 14eafc5f4 15Wladimir J. van der Laan: Merge #8863: univalue: Pull subtree...
 21 2016-10-03 06:45:47	0|GitHub123|[13bitcoin] 15laanwj closed pull request #8863: univalue: Pull subtree (06master...06Mf1610-univalue) 02https://github.com/bitcoin/bitcoin/pull/8863
 22 2016-10-03 06:51:45	0|wumpus|jonasschnelli: looks like your testnet DNS seed is failing again
 23 2016-10-03 06:52:55	0|wumpus|if it keeps running and reporting to logs but not serving requests it seems a deeper issue
 24 2016-10-03 07:02:28	0|gmaxwell|"connections": 124,
 25 2016-10-03 07:02:54	0|gmaxwell|thats not good.
 26 2016-10-03 07:03:22	0|wumpus|time for the ban hammer?
 27 2016-10-03 07:03:57	0|gmaxwell|yea, looks like that amazon spy thing is back.. on new IPs.
 28 2016-10-03 07:04:15	0|luke-jr|they seem to have given up on me still
 29 2016-10-03 07:04:17	0|wumpus|arghh
 30 2016-10-03 07:05:57	0|wumpus|https://github.com/bitcoin/bitcoin/issues/8864 we just have to add a targeting mark to them and it'd be a fun whack-a-mole minigame
 31 2016-10-03 07:06:08	0|gmaxwell|hm. rm my debuglog and kill -HUP appears to have not freed the disk space. (on 0.13.x back a few weeks)
 32 2016-10-03 07:07:01	0|wumpus|if not the debug log, what is using your disk space?
 33 2016-10-03 07:07:35	0|gmaxwell|I mean, I had a 20gb debug.log, and 2gb free. Deleted the log. kill -HUP the daemon.. still 2gb free.
 34 2016-10-03 07:07:35	0|wumpus|oh or is it still holding a reference to the deleted file
 35 2016-10-03 07:07:38	0|gmaxwell|that.
 36 2016-10-03 07:08:06	0|wumpus|there's probably some lsof trick to get rid of that
 37 2016-10-03 07:09:01	0|wumpus|it indicates that there is some fd leak
 38 2016-10-03 07:09:11	0|gmaxwell|yea, actually I can probably figure out which thread it is.
 39 2016-10-03 07:09:47	0|wumpus|yes and then you can find the fd in /proc and trunacte it
 40 2016-10-03 07:19:07	0|gmaxwell|wumpus: false alarm here, had another process holding it.
 41 2016-10-03 08:04:26	0|da2ce7|hello, I have a build error on macOS; bitcoin/master:  https://paste.fedoraproject.org/442517/75481833/
 42 2016-10-03 08:04:40	0|da2ce7|./autogen.sh ; ./configure ; make -j8
 43 2016-10-03 08:08:59	0|da2ce7|macOS sierra: 10.12 (16A323)
 44 2016-10-03 08:13:27	0|GitHub76|13bitcoin/06master 14fa7c35c 15MarcoFalke: [qa] util: Move wait_bitcoinds() into stop_nodes()
 45 2016-10-03 08:13:27	0|GitHub76|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/eafc5f4fae52...76f3c02fb01a
 46 2016-10-03 08:13:28	0|GitHub76|13bitcoin/06master 1476f3c02 15MarcoFalke: Merge #8860: [qa] util: Move wait_bitcoinds() into stop_nodes()...
 47 2016-10-03 08:13:41	0|GitHub108|[13bitcoin] 15MarcoFalke closed pull request #8860: [qa] util: Move wait_bitcoinds() into stop_nodes() (06master...06Mf1610-qaUtilWait) 02https://github.com/bitcoin/bitcoin/pull/8860
 48 2016-10-03 08:16:40	0|wumpus|da2ce7: that looks non-trivial, better to open an issue I think
 49 2016-10-03 08:20:30	0|wumpus|you may be the first trying to build this on 10.12
 50 2016-10-03 08:39:38	0|wumpus|gah, every time I try to respond to jtimon's PMs he's offline
 51 2016-10-03 08:42:54	0|wumpus|and he should be in the same timezone. At least geographically.
 52 2016-10-03 09:04:15	0|GitHub47|[13bitcoin] 15MarcoFalke opened pull request #8866: [0.13] Backports (060.13...06Mf1610-013backp) 02https://github.com/bitcoin/bitcoin/pull/8866
 53 2016-10-03 09:09:28	0|btcdrak|wumpus: he is on Telegram reliably.
 54 2016-10-03 09:10:08	0|wumpus|I really dislike using my phone to chat. But I'll consider it
 55 2016-10-03 09:11:34	0|wumpus|if only all those zillions of new phone chat programs had an IRC interface, or, even a publically documented API
 56 2016-10-03 09:13:11	0|btcdrak|wumpus: you can use https://web.telegram.org
 57 2016-10-03 09:13:23	0|wumpus|its the same silly mess as in the 90's with icq, msn, aol etc all over again, until programs like pidgin came along
 58 2016-10-03 09:13:42	0|btcdrak|fully agree. it's annoying.
 59 2016-10-03 09:14:13	0|kinlo|wumpus: bitlbee with libpurple can act as a gateway between telegram and irc.  I have my telegram contacts just in my ircclient like all others
 60 2016-10-03 09:29:57	0|wumpus|kinlo: there's a libpurple backend for telegram? that's awesome. Hadn't expected so, for some reason, usually those things try very hard to be closed down to third-party applications.
 61 2016-10-03 09:30:43	0|wumpus|btcdrak: nice, web is preferable to phone at least :)
 62 2016-10-03 09:31:18	0|sipa|all my contacts are hangouts or irc, both work fine in bitlbee
 63 2016-10-03 09:31:32	0|kinlo|wumpus: telegram is afaik an "open standard", not a good one, but they are not closed minded like whatsapp
 64 2016-10-03 09:31:34	0|sipa|eh, irc doesn't even need bitlbee
 65 2016-10-03 09:32:03	0|wumpus|you're lucky. Some of mine insist on whatsapp, others on signal, others on telegram, others on skype, others on ricochet, ...
 66 2016-10-03 09:32:23	0|sipa|never heard about ricochet
 67 2016-10-03 09:32:42	0|kinlo|whatsapp is a bitch, dont assume you'll be able to handle that w/o official client, but telegram, skype, ricochet all have bitlbee options afaik
 68 2016-10-03 09:32:50	0|sipa|oh, i have signal too, but only with people i can reach in other ways
 69 2016-10-03 09:33:39	0|wumpus|ricochet is chat over tor hidden services, it's an open source protocol, however I don't think e.g. libpurple integrates it
 70 2016-10-03 10:22:17	0|da2ce7|wumpus: thank you, I've created an issue: https://github.com/bitcoin/bitcoin/issues/8869
 71 2016-10-03 12:05:51	0|wumpus|cfields_: did you know that ssh is set up to pass through LC_* environment variables by default on debian and derivatives? I never knew, just found out with a weird issue. I guess gitian already takes this into account.
 72 2016-10-03 12:13:09	0|achow101|what are these nodes with 52.x IPs?
 73 2016-10-03 12:14:02	0|wumpus|achow101: no one knows, guesses range from spy nodes to a (slow) DoS
 74 2016-10-03 12:15:15	0|wumpus|it's starting to look more and more like a DoS with the sheer number of connections opened, though opening all those connections could also be a way to deceive the trickle logic
 75 2016-10-03 12:15:44	0|wumpus|(and hence spy more effectively. I've never seen a spy that was so conspicious though...)
 76 2016-10-03 12:17:17	0|sipa|seems those stopped connecting to me
 77 2016-10-03 12:18:18	0|achow101|have you tried iptables to block those connections? I am about to do that.
 78 2016-10-03 12:19:20	0|luke-jr|I suspect a human is watching us and filtering out our IPs when they figure out who we are
 79 2016-10-03 12:19:48	0|wumpus|there's a topic on btctalk about it here: https://bitcointalk.org/index.php?topic=1478418.0
 80 2016-10-03 12:20:34	0|wumpus|achow101: yes you can use iptables based blocking, or bitcoind's ban functionality, getting rid of them is quite easy
 81 2016-10-03 12:23:35	0|wumpus|otherwise they leech quite some bandwith. "inv": 383977 * 45 connections, in 3 hours on one of my nodes
 82 2016-10-03 12:24:54	0|wumpus|if it's a DoS it's a sneaky kind of DoS because they don't have to send you data, they don't send anything besides pong,verack and version, but they can just wait for you to send them tons of invs
 83 2016-10-03 12:25:40	0|sipa|damn, since last thursday i've uploaded 250 GB worth of blocks
 84 2016-10-03 12:26:21	0|wumpus|wow
 85 2016-10-03 12:27:09	0|sipa|.. or my statistics patch is wrong
 86 2016-10-03 12:27:42	0|wumpus|luke-jr: it's very possible for their operators to listen in here, yes
 87 2016-10-03 12:28:11	0|sipa|or just notice they're getting banned and stop trying
 88 2016-10-03 12:30:16	0|achow101|those are all Amazon IPs so we could report them to Amazon and see if they will stop them
 89 2016-10-03 12:30:30	0|wumpus|yes, we should.
 90 2016-10-03 12:30:59	0|wumpus|I've been too lazy to report them up to now, but we certainly should, there more people do the better
 91 2016-10-03 12:32:02	0|wumpus|apparently they all suddenly reconnected about 300-400 seconds ago
 92 2016-10-03 12:35:42	0|sipa|here as well
 93 2016-10-03 12:36:21	0|wumpus|they're as conspicious as one can get, either this is some extremely unethical research project, or a troll action explicitly set up to provoke a response
 94 2016-10-03 12:37:53	0|sipa|about half my bandwidth goes to blocks up to depth 35000
 95 2016-10-03 12:40:13	0|sipa|a quarter goes to blocks up to depth 5200
 96 2016-10-03 12:40:25	0|wumpus|well with two service bits it could in principle support three ranges, maybe that would be another threshold
 97 2016-10-03 12:41:04	0|sipa|one eight goes to blocks up to depth 300
 98 2016-10-03 12:41:26	0|sipa|next week or so i'll make some graphs
 99 2016-10-03 12:41:43	0|wumpus|yes it would be interesting to see this plotted out
100 2016-10-03 13:21:05	0|GitHub138|[13bitcoin] 15luke-jr closed pull request #8386: mining: Optimise for typical mining use with blockmaxsize (06master...06blockmaxsize_opti) 02https://github.com/bitcoin/bitcoin/pull/8386
101 2016-10-03 13:25:26	0|btcdrak|[segwitcb] https://github.com/bitcoin/bitcoin/pull/8393 was updated. needs final review (segwitcb)
102 2016-10-03 13:26:23	0|btcdrak|also please review https://github.com/bitcoin/bitcoin/pull/8499 regarding segwit policy limits
103 2016-10-03 13:26:32	0|GitHub157|13bitcoin/06master 143450c18 15Jorge Timón: Globals: Decouple GetConfigFile and ReadConfigFile from global mapArgs
104 2016-10-03 13:26:32	0|GitHub157|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/76f3c02fb01a...a7e5cbb209d4
105 2016-10-03 13:26:33	0|GitHub157|13bitcoin/06master 14a7e5cbb 15Wladimir J. van der Laan: Merge #8856: Globals: Decouple GetConfigFile and ReadConfigFile from global mapArgs...
106 2016-10-03 13:26:47	0|GitHub100|[13bitcoin] 15laanwj closed pull request #8856: Globals: Decouple GetConfigFile and ReadConfigFile from global mapArgs (06master...060.13-globals-utils-configfile) 02https://github.com/bitcoin/bitcoin/pull/8856
107 2016-10-03 14:41:21	0|GitHub54|[13bitcoin] 15czzarr opened pull request #8870: Add p2sh segwit options to bitcoin tx (06master...06add-p2sh-segwit-options-to-bitcoin-tx) 02https://github.com/bitcoin/bitcoin/pull/8870
108 2016-10-03 14:52:33	0|GitHub95|[13bitcoin] 15czzarr closed pull request #8870: Add p2sh segwit options to bitcoin tx (06master...06add-p2sh-segwit-options-to-bitcoin-tx) 02https://github.com/bitcoin/bitcoin/pull/8870
109 2016-10-03 15:29:04	0|BlueMatt|sipa: re: https://github.com/bitcoin/bitcoin/pull/8393#discussion_r81563418 is there anything stopping us from switching GetFetchFlags to just return (LocalServices() & NODE_WITNESS) && State(pfrom->GetId())->fHaveWitness instead of checking IsWitnessEnabled?
110 2016-10-03 15:29:10	0|BlueMatt|or is that a big change to fix that small bug?
111 2016-10-03 15:34:22	0|sipa|that looks safe to me
112 2016-10-03 15:34:41	0|sipa|i'm unable to fix things now... just spilled coffee over my laptop
113 2016-10-03 15:37:33	0|Chris_Stewart_5|What file(s) does the logic reside to maintain the utxo set in Bitcoin Core?
114 2016-10-03 15:41:48	0|sipa|$DATADIR/chainstate/*
115 2016-10-03 15:41:54	0|sipa|ah, the logic
116 2016-10-03 15:41:59	0|sipa|coins.h/cpp
117 2016-10-03 15:42:01	0|sipa|and main
118 2016-10-03 15:47:53	0|sipa|BlueMatt: but that change will cause some logic to switch immediately in .13.1 rather than only after segwit activates
119 2016-10-03 15:47:57	0|sipa|maybe that's safer
120 2016-10-03 15:48:01	0|sipa|i can't check now
121 2016-10-03 15:49:50	0|BlueMatt|sipa: I'm aware its not a trivial change, indeed
122 2016-10-03 15:54:33	0|sipa|BlueMatt: i think in general that it's fine to switch things based on segwit being defined rather than active
123 2016-10-03 15:54:51	0|sipa|as it will expose problems with relay earlier, and not all at once on the network
124 2016-10-03 15:56:27	0|BlueMatt|sipa: ok, I'll open a pr that does just that since it would be weird to have that in a compact block-related pr
125 2016-10-03 15:57:57	0|BlueMatt|fwiw, a brief glance indicates this same bug might exist in INV processing
126 2016-10-03 16:07:08	0|sipa|BlueMatt: we should have made inv-based announcements obsolete for cb and/or segwit
127 2016-10-03 16:07:35	0|BlueMatt|sipa: yea, I was just looking at that code, I really dont like it
128 2016-10-03 16:07:56	0|BlueMatt|sipa: i really want to rip out the request there and only respond with getheaders, but too late for 0.13.1
129 2016-10-03 16:08:11	0|sipa|agree
130 2016-10-03 16:08:23	0|sipa|(both on ripping it out, and it being too late)
131 2016-10-03 17:04:57	0|GitHub49|[13bitcoin] 15TheBlueMatt opened pull request #8871: Make GetFetchFlags always request witness objects from witness peers (06master...06fetchflags) 02https://github.com/bitcoin/bitcoin/pull/8871
132 2016-10-03 17:08:45	0|gmaxwell|Anyone know who 66.180.32.186:18333 (testnet) is?
133 2016-10-03 18:11:17	0|BlueMatt|roasbeef: ping
134 2016-10-03 18:11:23	0|BlueMatt|roasbeef: does btcd do sendheaders announcements?
135 2016-10-03 18:24:50	0|Chris_Stewart_5|Is there a BIP for the serialization/unserialization for coins.h?
136 2016-10-03 18:26:15	0|gmaxwell|no, bips are for interoperability. the internal encoding is purely internal and could change freely from version to version.
137 2016-10-03 18:36:20	0|roasbeef|BlueMatt: yeah, although we don't fully utilize the new feature when receiving (only if we're still in checkpoint sync realm do we fetch blocks immedately from headers)
138 2016-10-03 18:40:58	0|GitHub86|[13bitcoin] 15TheBlueMatt opened pull request #8872: Remove block-request logic from INV message processing (06master...06fetchflags2) 02https://github.com/bitcoin/bitcoin/pull/8872
139 2016-10-03 18:41:04	0|BlueMatt|roasbeef: just asking in the context of https://github.com/bitcoin/bitcoin/pull/8872 ie can bitcoin core stop requesting directly on INVs and only request on headers messages
140 2016-10-03 18:41:14	0|BlueMatt|sdaftuar: noticed another reason why this is good "Finally, this removes the one place we MarkBlockAsInFlight (ie will forcibly store the block on disk in AcceptBlock) without having seen the header first."
141 2016-10-03 18:41:45	0|sipa|ah, good
142 2016-10-03 18:45:53	0|Chris_Stewart_5|Thanks for the explanation gmaxwell
143 2016-10-03 18:45:58	0|gmaxwell|Np.
144 2016-10-03 18:46:39	0|gmaxwell|What remaining OpenSSL dependencies do we have in bitcoind?  I am aware of the RNG, though its now far less critical due to the just in time urandom usage for key generation.
145 2016-10-03 18:47:32	0|gmaxwell|and tests.
146 2016-10-03 18:48:13	0|sipa|i believe that is the only openssl dependency for bitcoind
147 2016-10-03 18:49:25	0|roasbeef|BlueMatt: gotcha, yeah that change should be fine from btcd's PoV
148 2016-10-03 19:09:04	0|instagibbs|isn't it used for payment protocol?
149 2016-10-03 19:09:15	0|instagibbs|or is that extra-bitcoind(i dont know that stuff)
150 2016-10-03 19:09:23	0|sipa|bitcoind does not support the payment protocol
151 2016-10-03 19:09:32	0|sipa|it's only in qt
152 2016-10-03 19:09:36	0|instagibbs|kk
153 2016-10-03 19:09:45	0|gmaxwell|yea my bitcoind qualification was intentional.
154 2016-10-03 19:23:01	0|GitHub48|[13bitcoin] 15ryanofsky opened pull request #8873: Add microbenchmarks to profile more code paths. (06master...06issue-7883-benchmarks) 02https://github.com/bitcoin/bitcoin/pull/8873
155 2016-10-03 22:36:41	0|meowzus|could someone tell me an easy way to start contributing towards the project?
156 2016-10-03 22:42:58	0|luke-jr|meowzus: strictly easy, or as a good first stepping stone?
157 2016-10-03 22:43:16	0|meowzus|good first stepping stone most probably
158 2016-10-03 22:43:36	0|achow101|report bugs
159 2016-10-03 22:44:28	0|meowzus|i meant in terms of getting my hands with with developing
160 2016-10-03 22:44:37	0|sipa|what experience do you have?
161 2016-10-03 22:46:16	0|meowzus|just general development skills, used to do app development in silicon valley
162 2016-10-03 22:46:22	0|meowzus|looking to get into blockchain dev
163 2016-10-03 22:46:28	0|sipa|do you know c++?
164 2016-10-03 22:46:50	0|meowzus|yeah
165 2016-10-03 22:48:00	0|achow101|meowzus: you can review open PRs
166 2016-10-03 22:48:03	0|luke-jr|meowzus: write new unit tests
167 2016-10-03 22:48:09	0|luke-jr|review is also helpful, yes
168 2016-10-03 22:48:21	0|sipa|luke-jr: that's a really boring task if you don't know what about
169 2016-10-03 22:48:55	0|luke-jr|sipa: perhaps, but boring and easy tend to overlap a lot, and tests and review help one learn the codebase well
170 2016-10-03 22:48:55	0|sipa|meowzus: i suggest looking at the issue tracker (https://github.com/bitcoin/bitcoin/issues) and filtering for things with the 'easy' label
171 2016-10-03 22:50:21	0|meowzus|sipa: "Easy to implement" right?
172 2016-10-03 22:50:44	0|meowzus|luke-jr: how do i find out what unit tests are needed?
173 2016-10-03 22:52:57	0|luke-jr|meowzus: can either look over what exists already, or break things at random until something doesn't get detected
174 2016-10-03 22:53:10	0|meowzus|haha i see
175 2016-10-03 22:53:32	0|luke-jr|note some are in qa/rpc-tests/, some in src/tests/ and some in src/qt/tests/
176 2016-10-03 22:53:48	0|meowzus|cool
177 2016-10-03 23:01:43	0|sipa|luke-jr: i generally believe that good unit tests require a thorough understanding of the behaviour that is being tested
178 2016-10-03 23:02:04	0|sipa|though it is true that it may help getting used to the codebase
179 2016-10-03 23:02:07	0|luke-jr|sipa: yes, I agree
180 2016-10-03 23:02:17	0|luke-jr|that's part of learning the codebase IMO
181 2016-10-03 23:52:23	0|achow101|None of the context menu stuff for peers seems to be working for me