1 2016-11-30 03:17:09	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9243: Clean up mapArgs and mapMultiArgs Usage (06master...062016-11-mapmultiargs) 02https://github.com/bitcoin/bitcoin/pull/9243
  2 2016-11-30 04:42:08	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9244: Trivial refactor: Remove extern keyword from function declarations (06master...06no-extern-funcdecl) 02https://github.com/bitcoin/bitcoin/pull/9244
  3 2016-11-30 06:45:41	0|luke-jr|http://arstechnica.com/security/2016/11/firefox-0day-used-against-tor-users-almost-identical-to-one-fbi-used-in-2013/
  4 2016-11-30 08:28:25	0|gmaxwell|oops #9233 contained a change to ctaes which should have been directed upstream (not like it really matters but the change will potentially get blown away with the next subrepo merge).
  5 2016-11-30 08:28:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/9233 | Fix some typos by fsb4000 · Pull Request #9233 · bitcoin/bitcoin · GitHub
  6 2016-11-30 08:30:10	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #9245: Drop IO priority to idle while reading blocks for getblock requests (06master...06ionice) 02https://github.com/bitcoin/bitcoin/pull/9245
  7 2016-11-30 08:40:47	0|jonasschnelli|wumpus: "Doesn't every wallet get its own database environment?" <--- wouldn't this require a "directory" per wallet?
  8 2016-11-30 08:43:06	0|wumpus|jonasschnelli: good point - I wasn't aware that there is a directory - database environment correspondence
  9 2016-11-30 08:44:33	0|luke-jr|wumpus: I put it in util.h cuz I'm not sure what the best way to add a conditional header to the makefiles is :x
 10 2016-11-30 08:44:49	0|wumpus|luke-jr: just add it unconditionally
 11 2016-11-30 08:44:52	0|luke-jr|I guess it wouldn't be conditional at this point
 12 2016-11-30 08:45:04	0|jonasschnelli|luke-jr: if BITCOIN_CORE_H+=?
 13 2016-11-30 08:45:06	0|wumpus|luke-jr: we do want this functionality for windows eventualy (though it's ok if you don't do thatin your pull)
 14 2016-11-30 08:45:18	0|luke-jr|jonasschnelli: yeah, but it's resolved earlier than it can be added cleanly
 15 2016-11-30 08:45:30	0|wumpus|it's better to not have conditional headers
 16 2016-11-30 08:45:33	0|wumpus|yes, it has
 17 2016-11-30 08:46:16	0|wumpus|in any case you should make at least the interface abstract, that the implementation is empty on windows for now is ok
 18 2016-11-30 08:46:37	0|luke-jr|it's pretty abstract right now?
 19 2016-11-30 08:46:49	0|wumpus|yes, but it wouldn't be if you make the header conditional
 20 2016-11-30 08:47:04	0|jonasschnelli|I think this should also work on OSX.
 21 2016-11-30 08:47:05	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #9246: Developer docs about existing subtrees. (06master...06devdocs_for_subtrees) 02https://github.com/bitcoin/bitcoin/pull/9246
 22 2016-11-30 08:47:31	0|gmaxwell|wumpus: yea, there is an enviroment/directory correspondance.
 23 2016-11-30 08:47:53	0|jonasschnelli|luke-jr: would this also affect filtered blocks?
 24 2016-11-30 08:48:03	0|jonasschnelli|heh
 25 2016-11-30 08:48:04	0|luke-jr|jonasschnelli: yes, that's intentional
 26 2016-11-30 08:48:22	0|wumpus|luke-jr: my comment was completely about code organization, if you make a util_prio.cpp, you should define the interface in util_prio.h, this makes it easier to find stuff :)
 27 2016-11-30 08:48:34	0|jonasschnelli|Yes. I though about an option to only prio down the filtere blocks (not the non-filtered).
 28 2016-11-30 08:48:47	0|wumpus|yes he is fast
 29 2016-11-30 08:49:01	0|luke-jr|hmm, other util files don't have an underscore; should I rename it?
 30 2016-11-30 08:49:12	0|wumpus|gmaxwell: bummer
 31 2016-11-30 08:49:44	0|wumpus|luke-jr: yes, would make sense for consistency
 32 2016-11-30 08:50:46	0|wumpus|jonasschnelli: well further options could be added later I suppose
 33 2016-11-30 08:51:17	0|luke-jr|along these lines, I was pondering adding DSCP flags at the network level too
 34 2016-11-30 08:51:22	0|luke-jr|but that seems invasive
 35 2016-11-30 08:51:54	0|wumpus|luke-jr: does libevent support that?
 36 2016-11-30 08:51:59	0|luke-jr|no idea :x
 37 2016-11-30 08:52:27	0|gmaxwell|luke-jr: actually doesn't usually help. ... turns out that lots of network gear ignores it and a lot of what doesn't will do terrible things like drop all the marked packets. :(
 38 2016-11-30 08:52:33	0|wumpus|I wouldn't recomment hacking on low level bits of the network code as it's going to be ripped out anyway
 39 2016-11-30 08:53:19	0|wumpus|do torrent clients use that?
 40 2016-11-30 08:53:21	0|luke-jr|gmaxwell: really? to try to survive with this DSL I have my router tagging everything differently :x
 41 2016-11-30 08:53:44	0|wumpus|or is it something you would usually define at the OS/firewall level?
 42 2016-11-30 08:53:51	0|luke-jr|my torrent client has a field for it, but it seems to be set to 0
 43 2016-11-30 08:54:23	0|gmaxwell|torrent mostly uses utp, a reliable transport constructed over UDP that has flow control management that is designed to be as unintrusive as possible... slow downs when it detects delay going up.
 44 2016-11-30 08:54:37	0|gmaxwell|And the use of UDP allows it to do hole punching, of course.
 45 2016-11-30 08:54:47	0|wumpus|interesting
 46 2016-11-30 08:55:34	0|wumpus|I had no idea bittorrent implemented its own bulk data transfer protocol on top of UDP
 47 2016-11-30 08:55:45	0|wumpus|thought it used udp just for negotiation and distributed hash tables and such
 48 2016-11-30 08:55:49	0|gmaxwell|I don't think any of the utp stuff is using DSCP, it could, but as I mentioned there are networks that respond poorly to it. (not that many, but enough that I've seen multiple pieces of software in the past deploy bits of tagging then either take it out or add more code to detect stupidity and adapt)
 49 2016-11-30 08:56:14	0|gmaxwell|yea, it's why ISPs mostly dropped the war on bittorrent. :P
 50 2016-11-30 08:56:25	0|gmaxwell|https://en.wikipedia.org/wiki/Micro_Transport_Protocol
 51 2016-11-30 08:57:33	0|wumpus|would be interesting to use something similar
 52 2016-11-30 08:58:00	0|jonasschnelli|Wasn't aware of uTP, very interesting.
 53 2016-11-30 08:58:07	0|gmaxwell|Yep. It's just a ... big project. I thought maybe after our networking is cleaner adding other transports might be easier.
 54 2016-11-30 09:00:27	0|wumpus|it's a big project though I guess if some of the implementation coudl be shared with some bittorrent implementation, it'd help - transferring historical blocks isn't that different from transferring other data
 55 2016-11-30 09:00:43	0|gmaxwell|(mostly interesting for block syncing, though the fact that it does hole punching is useful too. and of course, fibre has a udp based transport for blocks on the tip-- designed for an entirely different goal, latency minimization).
 56 2016-11-30 09:00:56	0|jonasschnelli|luke-jr: OSX: "checking for ioprio syscalls... no"
 57 2016-11-30 09:01:11	0|gmaxwell|wumpus: there is a libutp, I dunno about its quality.
 58 2016-11-30 09:01:35	0|jonasschnelli|luke-jr: But it should work on OSX AFAIK, others are also using it: https://github.com/daliworks/busybox-osx/blob/master/miscutils/ionice.c#L23
 59 2016-11-30 09:01:55	0|gmaxwell|wumpus: no the dump-data-over-tcp with many parallel connections is pretty unfriendly to other traffic on the network, tends to irritate users and ISPs.. :)
 60 2016-11-30 09:02:13	0|gmaxwell|and also doesn't traverse NAT without heroic efforts.
 61 2016-11-30 09:02:14	0|luke-jr|jonasschnelli: dunno how..
 62 2016-11-30 09:02:32	0|wumpus|jonasschnelli: can you check in config.log why?
 63 2016-11-30 09:03:30	0|wumpus|gmaxwell: true, though the main user of upnp seems to be torrent clients too - that put me on the wrong track, probably just as a fallback if the hole punching doesn't work
 64 2016-11-30 09:04:53	0|jonasschnelli|luke-jr, wumpus: conftest.cpp:61:21: error: use of undeclared identifier 'SYS_ioprio_get'
 65 2016-11-30 09:04:58	0|wumpus|jonasschnelli: oh wait it's actually directly calling syscalls, yea that won't work on anything but Linux. You probably need to just add a specific implementation for macosx
 66 2016-11-30 09:05:18	0|luke-jr|wumpus: BSD seems to use the same syscall macro though
 67 2016-11-30 09:05:26	0|luke-jr|jonasschnelli: maybe a new header needed?
 68 2016-11-30 09:05:36	0|wumpus|but the syscalls will be named differently and have a different interface
 69 2016-11-30 09:05:44	0|wumpus|certainly obscure ones like this
 70 2016-11-30 09:07:05	0|luke-jr|looks like this abstraction isn't going to work for Windows
 71 2016-11-30 09:07:26	0|luke-jr|it can only set threads low-priority for IO, CPU, and paging at the same time; or set IO alone per-fd
 72 2016-11-30 09:07:43	0|jonasschnelli|I'll have a look for OSX.
 73 2016-11-30 09:07:51	0|luke-jr|per-fd is probably ideal, but will require API changes
 74 2016-11-30 09:08:22	0|wumpus|per-fd is neat
 75 2016-11-30 09:08:48	0|gmaxwell|Per-fd is super neat.
 76 2016-11-30 09:09:22	0|gmaxwell|luke-jr: rather than IO-nicing it might be better to just rate limit responses.
 77 2016-11-30 09:10:15	0|luke-jr|that doesn't allow an idle PC to max out IO, nor an active PC to throttle it down further :x
 78 2016-11-30 09:14:57	0|wumpus|might be even better to do both
 79 2016-11-30 09:15:27	0|nsh|what's the proposal? block data restructuring or rethreading or something?
 80 2016-11-30 09:15:40	0|jonasschnelli|luke-jr: I guess oSX only has the general priority which affects the IO prio: https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/setpriority.2.html
 81 2016-11-30 09:15:41	0|wumpus|huh
 82 2016-11-30 09:16:00	0|wumpus|jonasschnelli: 'legacy' :-)
 83 2016-11-30 09:16:04	0|jonasschnelli|luke-jr: what about: https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/setiopolicy_np.3.html#//apple_ref/doc/man/3/setiopolicy_np?
 84 2016-11-30 09:16:13	0|jonasschnelli|setiopolicy_np seems stdc?
 85 2016-11-30 09:16:48	0|jonasschnelli|Probably a BSD thing
 86 2016-11-30 09:17:38	0|luke-jr|is it bad to have an empty .o file?
 87 2016-11-30 09:17:48	0|wumpus|luke-jr: nope
 88 2016-11-30 09:17:49	0|luke-jr|jonasschnelli: _np means non-portable
 89 2016-11-30 09:19:21	0|wumpus|well it certainly ain't stdc, if it'd be anything it'd be POSIX, but no, no such functions in posix. Posix threading has a general concept of priority but i/o specific is too new and fancy.
 90 2016-11-30 09:20:58	0|luke-jr|jonasschnelli: IOPOL_UTILITY sound about right?
 91 2016-11-30 09:21:23	0|jonasschnelli|Yes. That level would be desirtable.
 92 2016-11-30 09:21:32	0|jonasschnelli|But do we want all this custom platform specific code in our codebase?
 93 2016-11-30 09:21:41	0|jonasschnelli|I think its nice. I probably would go for it.
 94 2016-11-30 09:30:47	0|luke-jr|done I think
 95 2016-11-30 09:31:07	0|luke-jr|I was tempted to make it support platforms with BOTH ioprio and iopolicy, and retry the alternate if the first fails, but meh
 96 2016-11-30 11:45:43	0|bitcoin-git|13bitcoin/06master 147d3b627 15Wladimir J. van der Laan: torcontrol: Explicitly request RSA1024 private key...
 97 2016-11-30 11:45:43	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e56cf67e6b3f...56bee4986d11
 98 2016-11-30 11:45:44	0|bitcoin-git|13bitcoin/06master 1456bee49 15Wladimir J. van der Laan: Merge #9234: torcontrol: Explicitly request RSA1024 private key...
 99 2016-11-30 11:45:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9234: torcontrol: Explicitly request RSA1024 private key (06master...062016_11_torcontrol_key_ttpe) 02https://github.com/bitcoin/bitcoin/pull/9234
100 2016-11-30 11:51:49	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/94531b53509470e01dcbd90275577cb37a794fa8
101 2016-11-30 11:51:50	0|bitcoin-git|13bitcoin/060.13 1494531b5 15Wladimir J. van der Laan: torcontrol: Explicitly request RSA1024 private key...
102 2016-11-30 15:27:21	0|bitcoin-git|[13bitcoin] 15wodry opened pull request #9249: Improvement of documentation of command line parameter 'whitelist' (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/9249
103 2016-11-30 16:22:54	0|bitcoin-git|[13bitcoin] 15wodry opened pull request #9251: Improvement of documentation of command line parameter 'whitelist' (06master...06patch-3) 02https://github.com/bitcoin/bitcoin/pull/9251
104 2016-11-30 17:34:46	0|bitcoin-git|[13bitcoin] 15wodry closed pull request #9249: Improvement of documentation of command line parameter 'whitelist' (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/9249
105 2016-11-30 18:51:50	0|bobbytux|hello all
106 2016-11-30 18:57:14	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9252: Release cs_main before calling ProcessNewBlock (cmpctblock handling) (06master...06cb-lock) 02https://github.com/bitcoin/bitcoin/pull/9252