1 2017-11-09 11:18:58	0|luke-jr|I wonder if split HD should have had a 3rd category for refund addresses :x
  2 2017-11-09 12:13:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f7388e93d3dd...b5f9f025fef0
  3 2017-11-09 12:13:30	0|bitcoin-git|13bitcoin/06master 14b5f9f02 15Wladimir J. van der Laan: Merge #11552: Improve wallet-accounts test...
  4 2017-11-09 12:13:30	0|bitcoin-git|13bitcoin/06master 14bc9c0a7 15Russell Yanofsky: Improve wallet-accounts test...
  5 2017-11-09 12:14:02	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11552: Improve wallet-accounts test (06master...06pr/acctt) 02https://github.com/bitcoin/bitcoin/pull/11552
  6 2017-11-09 12:16:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b5f9f025fef0...0dec4cc30044
  7 2017-11-09 12:16:30	0|bitcoin-git|13bitcoin/06master 140dec4cc 15Wladimir J. van der Laan: Merge #11221: Refactor: simpler read...
  8 2017-11-09 12:16:30	0|bitcoin-git|13bitcoin/06master 149db9d62 15gnuser: Refactor: make the read function simpler
  9 2017-11-09 12:16:52	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11221: Refactor: simpler read (06master...06refactor-streams) 02https://github.com/bitcoin/bitcoin/pull/11221
 10 2017-11-09 12:17:29	0|bitcoin-git|13bitcoin/06master 1416be7dd 15Florian Schmaus: Improve bitcoind systemd service file...
 11 2017-11-09 12:17:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0dec4cc30044...331352f99f23
 12 2017-11-09 12:17:30	0|bitcoin-git|13bitcoin/06master 14331352f 15Wladimir J. van der Laan: Merge #10529: Improve bitcoind systemd service file...
 13 2017-11-09 12:17:44	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10529: Improve bitcoind systemd service file (06master...06systemd-service) 02https://github.com/bitcoin/bitcoin/pull/10529
 14 2017-11-09 12:33:08	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/331352f99f23...0ecc6305f464
 15 2017-11-09 12:33:09	0|bitcoin-git|13bitcoin/06master 147963335 15João Barbosa: Fix -disablewallet default value
 16 2017-11-09 12:33:09	0|bitcoin-git|13bitcoin/06master 14b411c2a 15João Barbosa: Improve -disablewallet parameter interaction
 17 2017-11-09 12:33:10	0|bitcoin-git|13bitcoin/06master 140ecc630 15Wladimir J. van der Laan: Merge #11594: Improve -disablewallet parameter interaction...
 18 2017-11-09 12:33:36	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11594: Improve -disablewallet parameter interaction (06master...062017-11-disable-wallet) 02https://github.com/bitcoin/bitcoin/pull/11594
 19 2017-11-09 12:39:17	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0ecc6305f464...ef3758d1ef73
 20 2017-11-09 12:39:18	0|bitcoin-git|13bitcoin/06master 14b109a1c 15practicalswift: Remove redundant nullptr checks before deallocation...
 21 2017-11-09 12:39:18	0|bitcoin-git|13bitcoin/06master 14ef3758d 15Wladimir J. van der Laan: Merge #10696: Remove redundant nullptr checks before deallocation...
 22 2017-11-09 12:39:32	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10696: Remove redundant nullptr checks before deallocation (06master...06delete-nullptr) 02https://github.com/bitcoin/bitcoin/pull/10696
 23 2017-11-09 12:49:11	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9716: [Net] Clarity TIMEOUT_INTERVAL constant meaning. (06master...062017-02-07-ping-timeout-interval) 02https://github.com/bitcoin/bitcoin/pull/9716
 24 2017-11-09 13:19:29	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10890: libbitcoinconsensus: Add version field to pkg-config info file (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10890
 25 2017-11-09 13:23:52	0|bitcoin-git|13bitcoin/06master 145a5e4e9 15Karl-Johan Alm: [wallet] Remove CTransaction&() helper conversion operator from wallet implementation.
 26 2017-11-09 13:23:52	0|bitcoin-git|13bitcoin/06master 1477ba4bf 15Wladimir J. van der Laan: Merge #10368: [wallet] Remove helper conversion operator from wallet...
 27 2017-11-09 13:23:52	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ef3758d1ef73...77ba4bf960d3
 28 2017-11-09 13:24:02	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10368: [wallet] Remove helper conversion operator from wallet (06master...06wallet-refactor-remove-ctrans-helper) 02https://github.com/bitcoin/bitcoin/pull/10368
 29 2017-11-09 14:20:43	0|bitcoin-git|13bitcoin/06master 146c4042a 15Eelis: Assert that CWallet::SyncMetaData finds oldest transaction....
 30 2017-11-09 14:20:43	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/77ba4bf960d3...99ec12666ba7
 31 2017-11-09 14:20:44	0|bitcoin-git|13bitcoin/06master 1499ec126 15Wladimir J. van der Laan: Merge #11074: Assert that CWallet::SyncMetaData finds oldest transaction....
 32 2017-11-09 14:21:09	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11074: Assert that CWallet::SyncMetaData finds oldest transaction. (06master...06syncassert) 02https://github.com/bitcoin/bitcoin/pull/11074
 33 2017-11-09 14:41:56	0|bitcoin-git|[13bitcoin] 15morcos closed pull request #9447: Allow 2 simultaneous block downloads (06master...06doubledownload) 02https://github.com/bitcoin/bitcoin/pull/9447
 34 2017-11-09 14:42:13	0|Drakon_|I'd like to provide a (feature) suggestion. Should I address at #bitcoin in order to do so?
 35 2017-11-09 14:43:32	0|luke-jr|sounds like a good place to start
 36 2017-11-09 14:45:44	0|wumpus|yes, this is not the place for feature suggestions, unless you're planning to implement it yourself and having questions about how to do so
 37 2017-11-09 14:51:39	0|Drakon_|This isn't my current intention, at least not at the moment. So where to address my suggestion?
 38 2017-11-09 14:54:34	0|wumpus|#bitcoin as suggested
 39 2017-11-09 14:57:27	0|Drakon_|Well sorry, but I'm a little bit confuse since you wrote "this is not the place for feature suggestions ..."
 40 2017-11-09 14:58:18	0|luke-jr|this isn't #bitcoin
 41 2017-11-09 14:58:46	0|Drakon_|Well sorry, I messed this up.
 42 2017-11-09 15:02:22	0|bitcoin-git|[13bitcoin] 15BitonicEelis opened pull request #11643: Remove dead store in secp256k1_ecmult_gen. (06master...06deadstore) 02https://github.com/bitcoin/bitcoin/pull/11643
 43 2017-11-09 15:07:32	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11643: Remove dead store in secp256k1_ecmult_gen. (06master...06deadstore) 02https://github.com/bitcoin/bitcoin/pull/11643
 44 2017-11-09 15:34:42	0|BlueMatt|cfields: re: #11562: I believe using high_resolution_clock is incorrect - seems like high_resolution_clock::is_steady is rarely true
 45 2017-11-09 15:34:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/11562 | bench: use std::chrono rather than gettimeofday by theuni · Pull Request #11562 · bitcoin/bitcoin · GitHub
 46 2017-11-09 15:35:12	0|BlueMatt|I mean or we can do something like this: https://gist.github.com/kballard/3549291#file-benchmark-hpp-L8
 47 2017-11-09 15:37:52	0|BlueMatt|cfields: we should be preferring steady_clock over high_resolution, I think, and then we can static_assert something about the resolution being at least microsecond or so...
 48 2017-11-09 15:39:12	0|BlueMatt|also, master dont build, yo
 49 2017-11-09 15:43:47	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11644: Fix qt build broken by 5a5e4e9 (06master...062017-11-fix-build) 02https://github.com/bitcoin/bitcoin/pull/11644
 50 2017-11-09 15:58:49	0|wumpus|BlueMatt: I also commented about that on the original PR
 51 2017-11-09 15:59:10	0|wumpus|apparently the steady clock is usually the same resolution as the high resolution clock
 52 2017-11-09 16:00:09	0|wumpus|this just handles the rare case where the high resolution clock is higher resolution (but not steady) in which case a higher resolution is probably preferred
 53 2017-11-09 16:00:13	0|BlueMatt|wumpus: indeed, but it seems nonsense to prefer high_resolution over steady *unless* their resolution is the same
 54 2017-11-09 16:00:27	0|BlueMatt|really? I mean its not like any of our runs require *that* much precision
 55 2017-11-09 16:00:37	0|wumpus|I don't think I agree on that, for benchmarks precision is always preferred
 56 2017-11-09 16:00:44	0|BlueMatt|microsecond is more than enough, even millisecond is probably fine especially after the next pr
 57 2017-11-09 16:01:14	0|wumpus|I mean the difference is that the steady clock isn't affected by time changes, but those should be rare anyhow right?
 58 2017-11-09 16:01:28	0|BlueMatt|but precision is nonsense if you're running ntp - the chance that your clock is running fast/slow randomly is not 0 and the gain you get from microsecond to something smaller is ~0
 59 2017-11-09 16:02:16	0|wumpus|running benchmarks on a system where the time is jumping crazy around sounds like a stupid idea to me
 60 2017-11-09 16:02:35	0|BlueMatt|most systems have ntpd, though....
 61 2017-11-09 16:02:44	0|BlueMatt|I think its like built-in to systemd or some batshit insane shit now
 62 2017-11-09 16:02:46	0|wumpus|ntp is supposed to increase time precision, not decrease it
 63 2017-11-09 16:03:26	0|wumpus|e.g. it explicitly doesn't do any large sudden corrections
 64 2017-11-09 16:03:54	0|BlueMatt|but it does corrections by making your clock run fast/slow when it detects your clock to be off (or your network path to have changed.....)
 65 2017-11-09 16:04:04	0|wumpus|that's the point, yes
 66 2017-11-09 16:04:53	0|MarcoFalke|I read that as a point for the steady_clock
 67 2017-11-09 16:05:15	0|Victorsueca|Came here to say it, but seems like you already noticed master is failing a lot lately
 68 2017-11-09 16:05:36	0|wumpus|Victorsueca: a lot?
 69 2017-11-09 16:05:44	0|BlueMatt|Victorsueca: usually master travis failures are cause travis will cancel a job if you push something new on top of it, so github shows them as failed
 70 2017-11-09 16:05:52	0|MarcoFalke|what do you mean? The tests?
 71 2017-11-09 16:05:55	0|BlueMatt|though master is actually failing right now, but its the first I've seen that in months
 72 2017-11-09 16:05:58	0|wumpus|these kind of merge conficts are incredibly rare
 73 2017-11-09 16:06:12	0|Victorsueca|BlueMatt: ahh that explains it
 74 2017-11-09 16:06:14	0|wumpus|currently testing BlueMatt's change
 75 2017-11-09 16:06:50	0|sipa|far better to have it fail to compile/test than have bugs
 76 2017-11-09 16:07:02	0|BlueMatt|Victorsueca: I often restart them cause I'm super ocd, though I should probably stop doing that cause it stops testing other things......
 77 2017-11-09 16:07:16	0|wumpus|absolutely
 78 2017-11-09 16:08:22	0|MarcoFalke|I mean we have a backlog anyway and that motivates people to compile and run locally
 79 2017-11-09 16:08:31	0|MarcoFalke|So I don't see huge issues with that
 80 2017-11-09 16:08:35	0|BlueMatt|yea, we almost always have a backlog during business hours :/
 81 2017-11-09 16:10:29	0|BlueMatt|wumpus: eg https://github.com/coreos/bugs/issues/391 which talks about how, yet again, systemd be breaking shit, in this case cause its timesyncd (which will now be default, I guess, on most hosts) is not accurate enough for ceph
 82 2017-11-09 16:10:47	0|wumpus|BlueMatt: yes thinking about it some more I agree with you
 83 2017-11-09 16:10:58	0|BlueMatt|given steady_clock usually has very good precision and the point of benchmarks is usually to figure out if things changed from one commit to another, not to compare between hosts, I think we should prefer that
 84 2017-11-09 16:13:51	0|wumpus|yes, indeed
 85 2017-11-09 16:14:08	0|BlueMatt|k, willfix
 86 2017-11-09 16:14:29	0|wumpus|it also simplifies the code if we always use the same clock
 87 2017-11-09 16:17:34	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/99ec12666ba7...045a80923419
 88 2017-11-09 16:17:35	0|bitcoin-git|13bitcoin/06master 14045a809 15Wladimir J. van der Laan: Merge #11644: Fix qt build broken by 5a5e4e9...
 89 2017-11-09 16:17:35	0|bitcoin-git|13bitcoin/06master 149e9e31a 15Matt Corallo: Fix qt build broken by 5a5e4e9
 90 2017-11-09 16:18:09	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11644: Fix qt build broken by 5a5e4e9 (06master...062017-11-fix-build) 02https://github.com/bitcoin/bitcoin/pull/11644
 91 2017-11-09 16:50:14	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #11646: Require a steady clock for bench with at least micro precision (06master...062017-11-11562-cleanups) 02https://github.com/bitcoin/bitcoin/pull/11646
 92 2017-11-09 17:12:19	0|BlueMatt|wumpus: hmmm, re: #11583 I kinda feel yucky adding a BCLog category that just means "ALWAYS log" - would you be ok with a #define function which does the LogPrint/LogPrintf call based on pnode->fInbound?
 93 2017-11-09 17:12:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/11583 | Do not make it trivial for inbound peers to generate log entries by TheBlueMatt · Pull Request #11583 · bitcoin/bitcoin · GitHub
 94 2017-11-09 17:13:46	0|wumpus|BlueMatt: I kind of like the idea of having a always-log category
 95 2017-11-09 17:14:08	0|wumpus|BlueMatt: it means LogPrintf could be defined in terms of it, and at some point only one log function would be needed anymore
 96 2017-11-09 17:14:36	0|wumpus|myself I always get confused between Logprint and Logprintf also because they are named so similarly
 97 2017-11-09 17:14:45	0|BlueMatt|true.....
 98 2017-11-09 17:14:58	0|BlueMatt|man i hate having a one-of-these-things-is-not-like-the-other enum :(
 99 2017-11-09 17:15:15	0|wumpus|well there is already a ::ALL
100 2017-11-09 17:15:39	0|BlueMatt|yea, but at least thats just defined to ~0
101 2017-11-09 17:15:41	0|wumpus|maybe we could use that as "log always"?
102 2017-11-09 17:16:17	0|wumpus|it doesn't really matter what it's defined to, just how it's handled :)
103 2017-11-09 17:16:20	0|BlueMatt|hmmmm, I thought about that briefly but decided I prefer an ::ALWAYS cause then you're even more confused....-debug=0 means ~0 still logs?
104 2017-11-09 17:16:31	0|BlueMatt|even though ~0 & 1 doesnt?
105 2017-11-09 17:16:39	0|BlueMatt|errr, ~0 ^ 1
106 2017-11-09 17:16:48	0|wumpus|hrm yeah
107 2017-11-09 17:17:11	0|wumpus|can't we just move those messages always to ::NET :-)
108 2017-11-09 17:17:12	0|BlueMatt|alright, I'll take a dive down the ::ALWAYS rabbit hole and see where I end up
109 2017-11-09 17:17:20	0|wumpus|that would remove this entire issue
110 2017-11-09 17:17:37	0|BlueMatt|I mean its nice to know when your outbound peers succeed in connecting
111 2017-11-09 17:17:38	0|wumpus|I mean they *are* net messages
112 2017-11-09 17:17:42	0|BlueMatt|I could add a second log for that
113 2017-11-09 17:17:51	0|wumpus|yes
114 2017-11-09 17:17:53	0|wumpus|maybe that's better
115 2017-11-09 17:18:02	0|BlueMatt|ok, fine, will table the ::ALWAYS discussion
116 2017-11-09 17:19:05	0|wumpus|the root issue really is that we confound log class and log priority
117 2017-11-09 17:19:37	0|wumpus|but I don't think we need to make logging perfect before merging your PR :)
118 2017-11-09 17:21:40	0|wumpus|but I agree with you that BCLog::ALWAYS is ugly
119 2017-11-09 17:22:09	0|wumpus|would prefer to add BCLog::ERROR BCLog::WARNING BCLog::DEBUG
120 2017-11-09 17:22:48	0|wumpus|then the log system would show messages based on a threshold
121 2017-11-09 17:23:11	0|wumpus|and it's not decided at the site of logigng whether something should always show
122 2017-11-09 17:23:24	0|BlueMatt|I mean I dunno, I kinda like the idea of logging based on subsystem, especially with rpc to turn them on and off - it lets you debug just the subsystem that is acting up
123 2017-11-09 17:23:34	0|wumpus|the subsystem should certainly stay
124 2017-11-09 17:23:35	0|BlueMatt|we could add both
125 2017-11-09 17:23:58	0|wumpus|common is to have a combination of both
126 2017-11-09 17:24:08	0|BlueMatt|that sounds overcomplex
127 2017-11-09 17:24:14	0|BlueMatt|but, eh...whatever
128 2017-11-09 17:24:23	0|wumpus|it's pretty much how it's done in all software
129 2017-11-09 17:24:25	0|BlueMatt|a discussion for when someone actually goes and writes the code to change it :p
130 2017-11-09 17:24:33	0|wumpus|so you can select by category or by priority
131 2017-11-09 17:25:11	0|wumpus|so this would be either a low priority or high priority net message based on incoming/outgoing
132 2017-11-09 17:26:41	0|wumpus|it also means that the log output can show the category, so you can grep for it later
133 2017-11-09 17:31:05	0|wumpus|(because all log messages will have a category, not just the debug priority ones)
134 2017-11-09 18:29:49	0|cfields|BlueMatt / wumpus: after thinking on it a bit, i agree with the clock change.
135 2017-11-09 18:41:29	0|wumpus|cfields: awesome
136 2017-11-09 18:45:06	0|Chris_Stewart_5|meeting in 15 right?
137 2017-11-09 18:46:57	0|wumpus|yes
138 2017-11-09 18:51:58	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/045a80923419...5e3f5e4f25b6
139 2017-11-09 18:51:59	0|bitcoin-git|13bitcoin/06master 142904e30 15John Newbery: [tests] Remove dead code from mininode.py...
140 2017-11-09 18:51:59	0|bitcoin-git|13bitcoin/06master 14c0b1274 15John Newbery: [tests] Remove support for bre-BIP31 ping messages...
141 2017-11-09 18:52:00	0|bitcoin-git|13bitcoin/06master 143858aab 15John Newbery: [tests] Remove support for p2p alert messages...
142 2017-11-09 18:52:28	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11638: [tests] Dead mininode code (06master...06dead_mininode_code) 02https://github.com/bitcoin/bitcoin/pull/11638
143 2017-11-09 18:57:28	0|promag|hi
144 2017-11-09 18:57:46	0|jonasschnelli|o/
145 2017-11-09 18:58:28	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5e3f5e4f25b6...1f4375f8e75f
146 2017-11-09 18:58:29	0|bitcoin-git|13bitcoin/06master 143788a84 15Matt Corallo: Do not send (potentially) invalid headers in response to getheaders...
147 2017-11-09 18:58:29	0|bitcoin-git|13bitcoin/06master 14725b79a 15Russell Yanofsky: [test] Verify node doesn't send headers that haven't been fully validated
148 2017-11-09 18:58:30	0|bitcoin-git|13bitcoin/06master 141f4375f 15Wladimir J. van der Laan: Merge #11580: Do not send (potentially) invalid headers in response to getheaders...
149 2017-11-09 18:58:54	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11580: Do not send (potentially) invalid headers in response to getheaders (06master...062017-10-getheaders-valid-only) 02https://github.com/bitcoin/bitcoin/pull/11580
150 2017-11-09 19:01:21	0|sipa|meetung?
151 2017-11-09 19:01:31	0|jonasschnelli|jup
152 2017-11-09 19:01:36	0|achow101|meeting
153 2017-11-09 19:02:19	0|lightningbot|Meeting started Thu Nov  9 19:02:18 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
154 2017-11-09 19:02:19	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
155 2017-11-09 19:02:19	0|wumpus|#startmeeting
156 2017-11-09 19:02:22	0|MarcoFalke|proposed short topic "Signing key for gitian executables"
157 2017-11-09 19:02:28	0|meshcollider|Hi
158 2017-11-09 19:02:32	0|achow101|hi
159 2017-11-09 19:02:35	0|Provoostenator|Hi
160 2017-11-09 19:02:35	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
161 2017-11-09 19:02:43	0|sdaftuar|oh hi
162 2017-11-09 19:02:51	0|cfields|hi
163 2017-11-09 19:02:53	0|morcos|hi
164 2017-11-09 19:03:05	0|wumpus|#topic 0.15.1
165 2017-11-09 19:03:06	0|instagibbs|hi
166 2017-11-09 19:03:14	0|morcos|Release!
167 2017-11-09 19:03:15	0|sdaftuar|does it work?
168 2017-11-09 19:03:16	0|wumpus|anyone had any bug reports regarding the rc?
169 2017-11-09 19:03:23	0|BlueMatt|Release!
170 2017-11-09 19:03:26	0|instagibbs|I have not seen any...
171 2017-11-09 19:03:34	0|MarcoFalke|release notes missing?
172 2017-11-09 19:03:39	0|wumpus|seems that was a short rc cycle then
173 2017-11-09 19:03:44	0|achow101|I haven't seen any, but I also don't know how many people are testing it out
174 2017-11-09 19:03:51	0|sipa|yes, i think we need a writeup on the P2P changes at least
175 2017-11-09 19:03:51	0|wumpus|MarcoFalke: no? I think we have them?
176 2017-11-09 19:03:58	0|meshcollider|MarcoFalke I wrote release notes and wumpus already merged
177 2017-11-09 19:04:04	0|MarcoFalke|great
178 2017-11-09 19:04:09	0|MarcoFalke|Tag and release?
179 2017-11-09 19:04:17	0|BlueMatt|there's no release notes on the p2p changes, I think
180 2017-11-09 19:04:19	0|BlueMatt|as sipa points out
181 2017-11-09 19:04:22	0|BlueMatt|though that may be fine
182 2017-11-09 19:04:22	0|morcos|yeah i think actually we might as well not release yet, there is no big rush now, so might as well see if any bugs pop up?
183 2017-11-09 19:04:22	0|sdaftuar|yes there are some
184 2017-11-09 19:04:29	0|cfields|i suspect many of the people who might've usually been testing rc1 got stuck dealing with drama instead :(
185 2017-11-09 19:04:33	0|wumpus|I don't think we should hold up a minor on release notes tbh, unless something really important is missing\
186 2017-11-09 19:05:22	0|luke-jr|morcos: I'm not sure we should drop our guard so easily
187 2017-11-09 19:05:24	0|achow101|morcos: there's still a possibility that some miner goes ahead and forks anyways
188 2017-11-09 19:05:29	0|BlueMatt|we can tag an rc2 with no changes to encourage testing :p
189 2017-11-09 19:05:30	0|wumpus|if it's ready we should just release and move on
190 2017-11-09 19:05:38	0|achow101|like these guys: https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000689.html
191 2017-11-09 19:05:40	0|BlueMatt|but, yea, I think we should release
192 2017-11-09 19:05:43	0|jonasschnelli|ack
193 2017-11-09 19:05:45	0|meshcollider|Hmm did I miss something? I thought I wrote up
194 2017-11-09 19:05:53	0|BlueMatt|even the idiots running a few hundred btc1 nodes may cause disruption and 15.1 can help
195 2017-11-09 19:05:56	0|luke-jr|achow101: in fact, at least one mining pool has announced they intend to
196 2017-11-09 19:06:10	0|meshcollider|ACK on release though, can just do 0.15.1.1 if it's got a bug ;)
197 2017-11-09 19:06:14	0|sdaftuar|lol
198 2017-11-09 19:06:15	0|wumpus|yes would be a waste if we get disruption anyway
199 2017-11-09 19:06:21	0|BlueMatt|meshcollider: god damn it
200 2017-11-09 19:06:24	0|wumpus|because some people fork anyway
201 2017-11-09 19:06:25	0|sipa|meshcollider: oh, i missed those notes!
202 2017-11-09 19:06:38	0|Provoostenator|This being Bitcoin, _someone_ is going to fork...
203 2017-11-09 19:06:42	0|wumpus|and we have a release ready but decide to delay it because 'no rush'
204 2017-11-09 19:06:43	0|morcos|ok ok..  i have no problem releasing
205 2017-11-09 19:06:51	0|luke-jr|meshcollider: if we make 0.15.2 another bugfix-only, we can do segwit wallet in 0.15.pi
206 2017-11-09 19:06:56	0|sdaftuar|release!
207 2017-11-09 19:07:00	0|kanzure|hi.
208 2017-11-09 19:07:00	0|wumpus|ok!
209 2017-11-09 19:07:02	0|BlueMatt|Relese!
210 2017-11-09 19:07:05	0|BlueMatt|e
211 2017-11-09 19:07:09	0|wumpus|#action release 0.15.1
212 2017-11-09 19:07:12	0|achow101|ack release
213 2017-11-09 19:07:18	0|wumpus|#topic HIgh priority for review
214 2017-11-09 19:07:33	0|wumpus|I think https://github.com/bitcoin/bitcoin/projects/8 is stale now
215 2017-11-09 19:08:03	0|achow101|so back to doing segwit wallet stuff?
216 2017-11-09 19:08:08	0|wumpus|the blockers were those that were already there before we started working on 0.15.1, so probably needs a update
217 2017-11-09 19:08:15	0|wumpus|achow101: yes
218 2017-11-09 19:08:26	0|wumpus|we should at least have segwit wallet in 0.16.0
219 2017-11-09 19:08:41	0|sipa|yes
220 2017-11-09 19:08:49	0|jonasschnelli|Yes. SW wallet support should be in projects/8
221 2017-11-09 19:08:54	0|morcos|sipa: did you ever write up that document?
222 2017-11-09 19:08:55	0|meshcollider|C.f. #11403
223 2017-11-09 19:08:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
224 2017-11-09 19:08:58	0|BlueMatt|speaking of segwit wallet......sipa where are we?
225 2017-11-09 19:09:02	0|sipa|no, sorry, distracted
226 2017-11-09 19:09:08	0|sipa|been thinking a lot about it though...
227 2017-11-09 19:09:13	0|morcos|i don't think i had any concerns about the last plan as i understood it.. but would be nice to sort of have it written out
228 2017-11-09 19:09:23	0|wumpus|added
229 2017-11-09 19:09:27	0|sipa|agree, i'll try to write things up today
230 2017-11-09 19:09:50	0|morcos|have we decided that barring bugs, the next release will be 0.16 with segwit wallet?
231 2017-11-09 19:09:52	0|achow101|is 11403 all that's left for segwit wallet? (besides the fact that it is the segwit wallet PR)
232 2017-11-09 19:10:02	0|morcos|and then the new and improved segwit wallet will be left for 0.1&?
233 2017-11-09 19:10:05	0|morcos|0.17
234 2017-11-09 19:10:06	0|sipa|achow101: there are some TODOs left
235 2017-11-09 19:10:21	0|wumpus|morcos: I think that's sensible
236 2017-11-09 19:10:22	0|sipa|morcos: i'm going to stop thinking in terms of specific releases
237 2017-11-09 19:10:26	0|jonasschnelli|morcos: makes sense
238 2017-11-09 19:10:32	0|wumpus|just do an early 0.16 release if it's finished early
239 2017-11-09 19:10:48	0|sipa|but short term, 11403 + its todos
240 2017-11-09 19:10:53	0|morcos|wumpus: yes thats what i mean.. ok good.
241 2017-11-09 19:10:53	0|wumpus|I'm kind of tired of holding off changes because backports to 0.15 need to be easier
242 2017-11-09 19:10:56	0|sipa|long term, rework ismine etc
243 2017-11-09 19:11:09	0|sipa|and release whatever is ready
244 2017-11-09 19:11:33	0|MarcoFalke|wumpus: Are we still doing a 0.15 with segwit wallet?
245 2017-11-09 19:11:50	0|wumpus|MarcoFalke: no, I don't think so (or at least that's what we discussed last meeting)
246 2017-11-09 19:11:53	0|cfields|ack 0.16 whenever segwit wallet is ready
247 2017-11-09 19:11:57	0|promag|sorry, multi wallet also for 0.16?
248 2017-11-09 19:12:05	0|sipa|multiwallet is in 0.15, no?
249 2017-11-09 19:12:10	0|meshcollider|Dynamic multiwallet?
250 2017-11-09 19:12:12	0|jonasschnelli|promag: if it's ready... you mean dynamic loading/unloading?
251 2017-11-09 19:12:18	0|promag|yes
252 2017-11-09 19:12:25	0|luke-jr|MarcoFalke: same plan, different versioning
253 2017-11-09 19:12:26	0|wumpus|if it's ready in time, sure
254 2017-11-09 19:12:27	0|jonasschnelli|promag: Should be possible
255 2017-11-09 19:12:37	0|wumpus|not going to hold it up on that though, if the explicit goal is segwit wallet
256 2017-11-09 19:12:45	0|promag|not project 8 thou?
257 2017-11-09 19:12:50	0|jonasschnelli|Indeed
258 2017-11-09 19:12:54	0|jonasschnelli|promag: it is there
259 2017-11-09 19:13:03	0|MarcoFalke|#action put segwit wallet in the next major release
260 2017-11-09 19:13:22	0|wumpus|yes, anything else for high priority for review?
261 2017-11-09 19:13:45	0|BlueMatt|#10286 :(
262 2017-11-09 19:13:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
263 2017-11-09 19:13:57	0|jonasschnelli|I'd like to see BIP159 in 0.16... but it's already in the HP list
264 2017-11-09 19:14:10	0|BlueMatt|jonasschnelli: needs rebase and I left you comments :p
265 2017-11-09 19:14:15	0|wumpus|10286 is already on there
266 2017-11-09 19:14:35	0|meshcollider|Any label stuff to replace accounts in there?
267 2017-11-09 19:14:36	0|sipa|bip159 would be nice, indeed
268 2017-11-09 19:14:38	0|jonasschnelli|BlueMatt: yes. Saw that.. will work on it asap
269 2017-11-09 19:15:23	0|promag|btw, I think it would be cool to have some diagram of the current thread model and what should be the ideal model
270 2017-11-09 19:15:37	0|wumpus|thread model?
271 2017-11-09 19:15:40	0|promag|I think BlueMatt has some things in mind
272 2017-11-09 19:15:58	0|jonasschnelli|I think promag means the general concurrency concept, right?
273 2017-11-09 19:16:05	0|promag|sure
274 2017-11-09 19:16:26	0|BlueMatt|promag: my model is CValidationInterface
275 2017-11-09 19:16:27	0|BlueMatt|:p
276 2017-11-09 19:16:33	0|promag|well BlueMatt keeps saying he wants to refactor in some way, but would be cool to actually "see" the big picture
277 2017-11-09 19:16:38	0|jonasschnelli|We move away from topics... MarcoFalke had a proposed topic
278 2017-11-09 19:16:44	0|BlueMatt|promag: CValidationInterface :p
279 2017-11-09 19:16:58	0|meshcollider|Signing keys for binaries?
280 2017-11-09 19:16:59	0|morcos|promag: +1
281 2017-11-09 19:17:33	0|jonasschnelli|[09:02:17]  <MarcoFalke>	proposed short topic "Signing key for gitian executables"
282 2017-11-09 19:17:39	0|wumpus|#topic Signing key for gitian executables (MarcoFalke)
283 2017-11-09 19:17:44	0|MarcoFalke|Background is that the current key expires Q1 2018, so we should come up with something for the 0.16 release. Someone had the idea to ask MIT to apply for a key, as individuals can not apply AFAICT.
284 2017-11-09 19:17:50	0|jonasschnelli|can you elaborate MarcoFalke?
285 2017-11-09 19:18:04	0|jonasschnelli|MarcoFalke: you mean the Apple/WINDOWS code signing keys?
286 2017-11-09 19:18:09	0|BlueMatt|MarcoFalke: there was some discussion of doing a split rsa key here.... gmaxwell around?
287 2017-11-09 19:18:12	0|MarcoFalke|jonasschnelli: jup
288 2017-11-09 19:18:13	0|luke-jr|would be good to have a key that is explicitly used for not only Core releases (eg, Knots too)
289 2017-11-09 19:18:16	0|jonasschnelli|Apple is still the Bitcoin Foundatiomn, right?
290 2017-11-09 19:18:24	0|gmaxwell|BlueMatt: I have code for mpc generation of rsa keys and signing.
291 2017-11-09 19:18:24	0|MarcoFalke|BlueMatt: That would require some more time?
292 2017-11-09 19:18:31	0|jonasschnelli|luke-jr: no, only Core
293 2017-11-09 19:18:35	0|luke-jr|jonasschnelli: why?
294 2017-11-09 19:18:41	0|cfields|yes, both are btcf atm
295 2017-11-09 19:18:43	0|BlueMatt|luke-jr: no
296 2017-11-09 19:18:50	0|gmaxwell|BlueMatt: (by I have, I mean it's on github, and I've used it... works fine)
297 2017-11-09 19:19:08	0|jonasschnelli|luke-jr: its about trust... I don't know if I would sign something I havev't reviewd
298 2017-11-09 19:19:32	0|cfields|gmaxwell: deals well with csr? I have no idea if that complicates things.
299 2017-11-09 19:19:56	0|achow101|the windows cert expires in 2019
300 2017-11-09 19:19:58	0|jonasschnelli|MarcoFalke: individuals can apply for keys (Apple and Windows)
301 2017-11-09 19:20:03	0|instagibbs|jonasschnelli, mmm not sure if gitian is about you "trusting" the binary, so much as it matches others'?
302 2017-11-09 19:20:03	0|jonasschnelli|But not sure if we should do individuals...
303 2017-11-09 19:20:07	0|gmaxwell|cfields: it deals with RSA numbers, someone would need to do the hacking to stuff the rsa number it generates into a CSR and whatnot.
304 2017-11-09 19:20:27	0|cfields|gmaxwell: ok
305 2017-11-09 19:20:49	0|luke-jr|jonasschnelli: I see it as dealing with backward OS policies that make it hard for users to run stuff.
306 2017-11-09 19:20:56	0|morcos|Does anyone think its best to just get BTCF to renew for now?
307 2017-11-09 19:21:02	0|gmaxwell|I think it's _really_ unfortunate to have any name except the project name on the binaries, causes a drama and stupidity.  There are still people that think the bitcoin foundation controls bitcoin just because of that existing cert. :(
308 2017-11-09 19:21:03	0|BlueMatt|todo: cfields creates an rsa # -> csr program :p
309 2017-11-09 19:21:03	0|wumpus|luke-jr: it basically is
310 2017-11-09 19:21:13	0|gmaxwell|morcos: thats the obvious thing to do.
311 2017-11-09 19:21:19	0|jonasschnelli|luke-jr: yes. But applying for you own key is maybe 300USD/year,.... so possible IMO
312 2017-11-09 19:21:34	0|BlueMatt|gmaxwell: so can I just legally change my name to Bitcoin Core, get a cert, and then change it back?
313 2017-11-09 19:21:35	0|BlueMatt|:p
314 2017-11-09 19:21:41	0|jonasschnelli|morcos: renaming with the APPLE Developer Portal is almost impossible
315 2017-11-09 19:21:44	0|achow101|BlueMatt: lol
316 2017-11-09 19:21:46	0|meshcollider|lol
317 2017-11-09 19:21:58	0|morcos|jonasschnelli: huh?
318 2017-11-09 19:21:59	0|jonasschnelli|changing name requires legal documents, etc.
319 2017-11-09 19:22:04	0|gmaxwell|BlueMatt: well the other option is that we just register a bitcoin core org someplace and have it get the key. But I wouldn't want to suggest that for a key that is expiring soon.
320 2017-11-09 19:22:12	0|jonasschnelli|It's all by approval basis through apple
321 2017-11-09 19:22:16	0|gmaxwell|it's not terribly hard, just requires a bit of money.
322 2017-11-09 19:22:20	0|jonasschnelli|you need a D.U.N.S number as well
323 2017-11-09 19:22:22	0|BlueMatt|I mean it doesnt take long to create an LLC that holds $0
324 2017-11-09 19:22:35	0|kanzure|would chaincode do it?
325 2017-11-09 19:22:45	0|jonasschnelli|But plase... don't set up an orga called "Bitcoin Core"
326 2017-11-09 19:22:58	0|meshcollider|Then bitcoin core really would be a company and you'd set off all the conspiracy theorists
327 2017-11-09 19:22:58	0|wumpus|jonasschnelli: agree
328 2017-11-09 19:22:59	0|gmaxwell|Bitcoin Core Code Signing Key inc.
329 2017-11-09 19:22:59	0|morcos|I'm happy to have an official Bitcoin Core org established if we want that, but it does seem like there are downsides to that
330 2017-11-09 19:23:08	0|wumpus|gmaxwell: yeah
331 2017-11-09 19:23:12	0|jonasschnelli|Id rather use an individual then ChainCodeLabs for it's own protection
332 2017-11-09 19:23:14	0|morcos|unless we specifically limited its purpose very narrowly
333 2017-11-09 19:23:19	0|cfields|ugh
334 2017-11-09 19:23:24	0|kanzure|yes if it's a "bitoin core org" then it should be named "bitcoin core code signing key holding only and nothing else, llc."
335 2017-11-09 19:23:24	0|luke-jr|wumpus: jonasschnelli: then I see no reason not to use a common key for both Core and Knots..
336 2017-11-09 19:23:25	0|wumpus|CoreSign
337 2017-11-09 19:23:41	0|jonasschnelli|I could provide my own personal APPL key...
338 2017-11-09 19:23:45	0|gmaxwell|Bitcoin Release signing key incorporated.
339 2017-11-09 19:23:47	0|achow101|BTW the apple key expires Jan 11 2018, Windows March 5 2019, so we would need to do this soon
340 2017-11-09 19:23:50	0|morcos|luke-jr: stop..  please bring up knots later .  it has nothing to do with the Core meeting
341 2017-11-09 19:23:57	0|jonasschnelli|(OSX only)
342 2017-11-09 19:24:12	0|jonasschnelli|heh
343 2017-11-09 19:24:18	0|gmaxwell|achow101: or just renew the apple one then, and continue on with doing something sensible.
344 2017-11-09 19:24:32	0|cfields|ok, in parallel to whatever else, I'll work on trying to get our current apple cert renewed
345 2017-11-09 19:24:42	0|wumpus|makes sense
346 2017-11-09 19:24:44	0|morcos|cfields: i think it makes most sense to do that.
347 2017-11-09 19:25:12	0|wumpus|any name would give conspiracy theories anyway, I don't really think it's so bad to have TBF as signing organization
348 2017-11-09 19:25:15	0|Provoostenator|Or Gitan Code Signing LLC, if other projects want their stuff signed too?
349 2017-11-09 19:25:20	0|gmaxwell|If someone wants to work on stuffing rsa numbers into CSRs, I can show them out to use the RSA MPC code (have to remember it myself first, but it's not hard)
350 2017-11-09 19:25:23	0|cfields|but i think we need a plan b. no clue if the resources/accounts/etc. are still live and available
351 2017-11-09 19:25:26	0|luke-jr|Provoostenator: good idea
352 2017-11-09 19:25:34	0|jonasschnelli|I kinda like the idea of a "Bitcoin Core Code Signing Assoc."
353 2017-11-09 19:25:37	0|cfields|gmaxwell: yes, i'd very very much like to do that
354 2017-11-09 19:25:42	0|cfields|so i'll volunteer for that
355 2017-11-09 19:25:50	0|achow101|do we really need code signed binaries though?
356 2017-11-09 19:25:56	0|cfields|tired of 10hr builds and signing on my damn laptop
357 2017-11-09 19:26:12	0|gmaxwell|wumpus: well at least TBF isn't any _new_ conspiracy theories... though it does kinda suck. :)
358 2017-11-09 19:26:20	0|cfields|achow101: yea. necessary evil, im afraid
359 2017-11-09 19:26:29	0|luke-jr|achow101: some variants of Mac and Windows won't let users run unsigned stuff or something like that
360 2017-11-09 19:26:34	0|wumpus|yes, otherwise all virus scanners will trigger on it and such
361 2017-11-09 19:26:38	0|achow101|luke-jr: well that's annoying
362 2017-11-09 19:26:50	0|Provoostenator|As an aside: has any one ever tried submitting to the Mac App Store?
363 2017-11-09 19:27:09	0|jonasschnelli|Provoostenator: no.. we won't
364 2017-11-09 19:27:36	0|jonasschnelli|This means the binaries are under APPLs control
365 2017-11-09 19:27:36	0|jonasschnelli|Would someone disagree on founding a "Bitcoin Core Code Signing Association" based in Switzerland?...
366 2017-11-09 19:27:45	0|jonasschnelli|(we could just try and also follow the path of renewing the current cert)
367 2017-11-09 19:27:50	0|wumpus|jonasschnelli: no, would be great
368 2017-11-09 19:27:59	0|luke-jr|jonasschnelli: "Gitian Code Signing" would be better as Provoostenator suggested
369 2017-11-09 19:28:06	0|gmaxwell|jonasschnelli: sounds fine to me, whatever is the path of least resistance.
370 2017-11-09 19:28:09	0|wumpus|luke-jr: I think that makes the scope too wide
371 2017-11-09 19:28:14	0|gmaxwell|I'd rather not introduce a new word 'gitian' to users.
372 2017-11-09 19:28:16	0|morcos|Let's please leave whatever we do focused on Bitcoin Core
373 2017-11-09 19:28:18	0|BlueMatt|it should probably have "Bitcoin Core" in the name
374 2017-11-09 19:28:26	0|BlueMatt|jonasschnelli: yes, please register, thanks!
375 2017-11-09 19:28:42	0|MarcoFalke|#action Register "Bitcoin Core Code Signing Association"
376 2017-11-09 19:28:45	0|luke-jr|BlueMatt: then you'll whine that it can't be shared
377 2017-11-09 19:28:52	0|wumpus|luke-jr: I don't personally have a problem with signing knots executables, but making it soo general means we'll have a bureaucracy about what to sign blabla, and btw devrandom owns the name gitian :)
378 2017-11-09 19:28:53	0|sipa|and then we'd apply for code signing keys under that association's name, using the MPC RSA scheme?
379 2017-11-09 19:28:54	0|meshcollider|jonasschnelli: sounds good to me
380 2017-11-09 19:29:05	0|jonasschnelli|Okay... I'll let that happen and register with apple
381 2017-11-09 19:29:06	0|sipa|(or at least eventually)
382 2017-11-09 19:29:13	0|Provoostenator|Decentralized Code Signers LLC?
383 2017-11-09 19:29:17	0|wumpus|sipa: yes, at least eventually
384 2017-11-09 19:29:18	0|BlueMatt|luke-jr: I object to it being shared, it is not *that* hard for you to get your own cert for your own project.....
385 2017-11-09 19:29:18	0|gmaxwell|sipa: yes, thats the idea.
386 2017-11-09 19:29:21	0|jonasschnelli|sipa: not sure it that is possible with apples key enrolling process
387 2017-11-09 19:29:28	0|BlueMatt|sipa: yes
388 2017-11-09 19:29:28	0|sipa|jonasschnelli: i don't see why not
389 2017-11-09 19:29:30	0|cfields|wumpus: exactly. The question to ask is: would we want btc1 signed with the same key?
390 2017-11-09 19:29:46	0|jonasschnelli|I'll focus on the legal association stuff maybe someone can try to look into the MPC RSA sheme with apple OSX signing keys
391 2017-11-09 19:29:46	0|sipa|jonasschnelli: assuming all the plumbing work is done
392 2017-11-09 19:29:47	0|wumpus|cfields: right, no we don't :)
393 2017-11-09 19:29:53	0|achow101|does anyone have a link to the rsa mpc thing?
394 2017-11-09 19:29:53	0|luke-jr|BlueMatt: it's a waste of money to a bad corp and a waste of time, at the very least
395 2017-11-09 19:29:55	0|gmaxwell|I wouldn't want any of us us wasting time helping with an adversarial project.
396 2017-11-09 19:29:58	0|morcos|Guys, if you are signing code, you are responsible for that code.  If we are signing it in the name of Bitcoin Core we are all taking responsibility.  Please let's limit this discussion to the code we all work on together
397 2017-11-09 19:30:09	0|Provoostenator|Makes sense
398 2017-11-09 19:30:14	0|sipa|well, in the MPC setting, the group of signers would be fixed
399 2017-11-09 19:30:18	0|morcos|someone can always separately create a more general entity to sign other projects, but thats not related to Core
400 2017-11-09 19:30:31	0|sipa|the project should be signing the things that group of signers is jointly interested in signing
401 2017-11-09 19:30:32	0|wumpus|yeah it's typical scope creep
402 2017-11-09 19:30:38	0|gmaxwell|achow101: I'll give you the link after the meeting.
403 2017-11-09 19:30:41	0|kanzure|or bike shedding on name
404 2017-11-09 19:30:43	0|cfields|gmaxwell: right. I was making the point that it would be impossible to draw the line unless core-specific.
405 2017-11-09 19:30:43	0|wumpus|let's sign the entire world :p
406 2017-11-09 19:30:46	0|achow101|gmaxwell: k, thanks
407 2017-11-09 19:31:15	0|MarcoFalke|Any other topics?
408 2017-11-09 19:31:22	0|BlueMatt|promag: CValidationInterface is where you learn things from consensus code (ie from CChainState after 10279 or validation.cpp otherwise) - its also where you learn about mempool things but I have a branch which comes after 10286 that splits the interface up between the two to differentiate a little bit....wrt threading, CValidationInterface listeners all move into the scheduler, which means you dont have any deadlocking issues since
409 2017-11-09 19:31:22	0|BlueMatt|they're all just called async, this is mostly complete in 10286, but cleaning up the remaining few isnt too hard...thats pretty much it, there's not much to it...net/net_processing is a different issue, and is mostly around moving things from CNode to CNodeState and disconnecting those two things being so closely joined, but the threading issues there are less of the primary concern (except for cs_main being too heavily shared between
410 2017-11-09 19:31:23	0|BlueMatt|net_processing for mapNodeState and everything else)
411 2017-11-09 19:31:29	0|gmaxwell|it is unfortunate that e.g. knots has an uphill time there, it's a barrier to entry that shouldn't exist. But it's also not one we created.
412 2017-11-09 19:31:38	0|luke-jr|cfields: except Knots and Core have the same developers
413 2017-11-09 19:31:39	0|wumpus|gmaxwell: I agree
414 2017-11-09 19:31:54	0|cfields|luke-jr: as does btc1...
415 2017-11-09 19:31:57	0|sipa|luke-jr: they don't have the same maintainers
416 2017-11-09 19:31:59	0|luke-jr|cfields: hardly
417 2017-11-09 19:32:36	0|sipa|i don't think everyone who is interested in signing off on core releases is interested in doing the same work for knots - and perhaps the other way around
418 2017-11-09 19:32:59	0|cfields|luke-jr: i hope it's clear that I'm not trying to lump you in with an adversarial fork. Just making the point that the distinction in terms of signing is hard to draw.
419 2017-11-09 19:33:00	0|luke-jr|"We Just Codesign Stuff We Want, LLC" XD
420 2017-11-09 19:33:15	0|cfields|luke-jr: that's my end goal, actually
421 2017-11-09 19:33:16	0|jonasschnelli|Indeed
422 2017-11-09 19:33:17	0|jonasschnelli|It's one entity luke-jr
423 2017-11-09 19:33:23	0|wumpus|well adversarial versus consensus-compatible is easy to draw
424 2017-11-09 19:33:25	0|gmaxwell|there is another issue, I'm pretty sure that apple will not grant a key to "I sign random shit LLC"
425 2017-11-09 19:33:36	0|jonasschnelli|You can found a "Knots Code Signing Assoc"
426 2017-11-09 19:33:37	0|promag|thanks BlueMatt, I'll read that in a bit
427 2017-11-09 19:33:38	0|cfields|to create a body like Let's Encrypt, which attests to the fact that code -> binary.
428 2017-11-09 19:34:04	0|wumpus|cfields: that would be awesome
429 2017-11-09 19:34:07	0|luke-jr|cfields: well, how to stop malware from using it?
430 2017-11-09 19:34:13	0|achow101|cfields: well that's a whole separate thing which we can join once it exists :)
431 2017-11-09 19:34:21	0|wumpus|but it's outside the scope of the bitcoin core project
432 2017-11-09 19:34:24	0|wumpus|any other topics?
433 2017-11-09 19:34:25	0|cfields|luke-jr: deterministic malware would have to be welcome, unfortunately
434 2017-11-09 19:34:52	0|luke-jr|that'd just get the key revoked
435 2017-11-09 19:34:56	0|gmaxwell|not like this stuff actually stops malware, snake oil security. alas.
436 2017-11-09 19:35:07	0|gmaxwell|in any case, a discussion for another time.
437 2017-11-09 19:36:11	0|wumpus|ok, no other topics
438 2017-11-09 19:36:20	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-09-19.02.log.html
439 2017-11-09 19:36:20	0|lightningbot|Meeting ended Thu Nov  9 19:36:19 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
440 2017-11-09 19:36:20	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-09-19.02.html
441 2017-11-09 19:36:20	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-11-09-19.02.txt
442 2017-11-09 19:36:20	0|wumpus|#endmeeting
443 2017-11-09 19:37:33	0|achow101|well that was short
444 2017-11-09 19:38:07	0|gmaxwell|achow101: the links are here https://github.com/kljensen/viff/blob/master/doc/applications.txt#L59
445 2017-11-09 19:38:28	0|wumpus|achow101: very efficient, can spent the rest of the time on reviewing high-priority PRs if you want :)
446 2017-11-09 19:39:20	0|promag|guys, what do you think about implicit sharing (or copy on write) for some structures, like cchain?
447 2017-11-09 19:39:28	0|meshcollider|jonasschnelli: Is it true that an LLC in Switzerland needs at least CHF 20,000 capital?
448 2017-11-09 19:39:41	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11647: 0.15: Backports (060.15...06Mf1711-0152backports) 02https://github.com/bitcoin/bitcoin/pull/11647
449 2017-11-09 19:39:49	0|wumpus|meshcollider: that's the case here in the netherlands
450 2017-11-09 19:40:02	0|gmaxwell|achow101: the key gen is really slow, but who cares... signing is fast.
451 2017-11-09 19:40:13	0|sipa|meshcollider: 3 BTC doesn't *sound* like much at all :p
452 2017-11-09 19:40:26	0|BlueMatt|if thats the case might as well just create a US LLC
453 2017-11-09 19:40:30	0|BlueMatt|cost is trivial
454 2017-11-09 19:40:34	0|gmaxwell|achow101: IIRC that implementation is setup for three parties, but it would be relatively straight forward to adjust it for more.
455 2017-11-09 19:40:36	0|jonasschnelli|meshcollider: 10k for a GmbH
456 2017-11-09 19:40:52	0|jonasschnelli|jonasschnelli: but we do an association.. which is almost free (maybe 1k)
457 2017-11-09 19:40:58	0|sipa|promag: cchain is pretty big
458 2017-11-09 19:41:01	0|meshcollider|Heh yeah sounds like quite a lot for a code signing only company
459 2017-11-09 19:41:06	0|BlueMatt|jonasschnelli: i believe us is like 50$
460 2017-11-09 19:41:45	0|promag|sipa: you don't have to copy everything
461 2017-11-09 19:41:46	0|BlueMatt|(but I think in most states yearly to file tax returns)
462 2017-11-09 19:42:11	0|achow101|gmaxwell: thanks. I'm going to try taking a look at it
463 2017-11-09 19:42:11	0|sipa|promag: not without introducing massive granularity
464 2017-11-09 19:42:24	0|jonasschnelli|BlueMatt: that's why people trust swiss companies more then US. :)
465 2017-11-09 19:42:46	0|BlueMatt|jonasschnelli: would you prefer I do something in .us?
466 2017-11-09 19:42:54	0|sipa|promag: if there is ever a point where concurrency is hurt by needing a consistent CChain, i think the solution is to stop using CChain for that purpose (CChain is just an optimized-for-seeking copy of CBlockIndex)
467 2017-11-09 19:43:05	0|jonasschnelli|For the simplest form of a registered non-single-person company, the GmbH, you need to deposit 10k and have liability (personal) for 20k
468 2017-11-09 19:43:11	0|jonasschnelli|BlueMatt: no.. please not US
469 2017-11-09 19:43:30	0|BlueMatt|I mean its not like the company will even hold the cert
470 2017-11-09 19:43:30	0|meshcollider|jonasschnelli is there any difference between an association and an LLC in terms of getting the certs
471 2017-11-09 19:43:36	0|BlueMatt|only exist as a legal entity to exist
472 2017-11-09 19:43:43	0|jonasschnelli|Or the association member may have troubles getting a US visa. :()
473 2017-11-09 19:43:58	0|BlueMatt|jonasschnelli: I presume there will be no "members"
474 2017-11-09 19:44:15	0|meshcollider|Or wumpus will be so he gets the cert?
475 2017-11-09 19:44:33	0|gmaxwell|the only concern about the entity is that it could get more certs but I don't think we care, since the fact that apple et. al. can issue as many as they want regardless.
476 2017-11-09 19:44:54	0|gmaxwell|meshcollider: we're hopefully going to use multiparty computation so no one person has the cert.'
477 2017-11-09 19:44:56	0|morcos|i think it makes sense for it to be jonas or someone not related to the Blockstream/Chaincode conspiracy who does this
478 2017-11-09 19:44:59	0|BlueMatt|gmaxwell: I'm gonna go out on a limb and bet that almost anyone would claim to be a representative of the company and apple would buy it
479 2017-11-09 19:45:18	0|jonasschnelli|BlueMatt: an official assiciation needs to have member
480 2017-11-09 19:45:20	0|jonasschnelli|(but only in the background)
481 2017-11-09 19:45:24	0|jonasschnelli|LLC is US imo
482 2017-11-09 19:45:49	0|cfields|my original suggestion was the DCI, but that got drowned out in the discussion
483 2017-11-09 19:45:51	0|gmaxwell|lol please, no more non-developers.
484 2017-11-09 19:45:55	0|BlueMatt|jonasschnelli: I mean ok, if you hate the idea of a us LLC, fine, I just figure its not worth wasting 1k on it, but....ok
485 2017-11-09 19:45:59	0|cfields|(also, i realize that everyone is just suggesting their own org :p )
486 2017-11-09 19:46:00	0|BlueMatt|gmaxwell: yea...that
487 2017-11-09 19:46:11	0|wumpus|cfields: DCI would be fine with me too
488 2017-11-09 19:46:15	0|sdaftuar|cfields: i am not suggesting my own org! :)
489 2017-11-09 19:46:19	0|luke-jr|cfields: everyone else is suggesting not-our-org it sounds like
490 2017-11-09 19:46:21	0|wumpus|cfields: this is just to have alternatives
491 2017-11-09 19:46:37	0|jonasschnelli|I'm not really familiar with US legal company/association constructs....
492 2017-11-09 19:47:02	0|BlueMatt|jonasschnelli: all that matters is its cheaper :p
493 2017-11-09 19:47:11	0|gmaxwell|I would rather not use DCI simply because we really have suffered from people using that stupid message as proof BCF controls bitcoin. I'd rather the name be more benign. (the "foo code signing" sort).
494 2017-11-09 19:47:20	0|jonasschnelli|DCI would be fine for me as well, though I prefer "Bitcoin Core Code Signing Assocation" over "DCI" (which is a private owned company) in the signing details
495 2017-11-09 19:47:20	0|promag|sipa: consider a long rpc call, it locks cs_main and replies a big json - how can it avoid the cs_main lock?
496 2017-11-09 19:47:48	0|wumpus|yes on the longer term having our own signing org would certainly be preferable, I agree
497 2017-11-09 19:47:52	0|gmaxwell|"Orginization which does not control Bitcoin. LLC"
498 2017-11-09 19:48:16	0|gmaxwell|yea, for a stopgap, whatever works. hopefully we can just.
499 2017-11-09 19:48:19	0|jonasschnelli|BlueMatt: I guess the 1000$ is for the lawyers setup,... I guess I would need the same for the LLC process (or someone needs to fill out the application form which then leads to lost 1000$ in development ressources)
500 2017-11-09 19:48:20	0|cfields|well, this may shortcut the discussion a bit...
501 2017-11-09 19:48:29	0|BlueMatt|ok, are there any remaining questions aside from "does jonasschnelli want to register it as a swiss org, or do we want someone in .us to spend the 35$ to make it happen here"
502 2017-11-09 19:48:29	0|wumpus|DCI sounds sufficiently neutral to me though
503 2017-11-09 19:48:55	0|cfields|from a quick glance, looks pretty possible that I can renew with the current cert
504 2017-11-09 19:49:03	0|achow101|who would be the named members/officers/whatever of said organization/association/llc
505 2017-11-09 19:49:03	0|gmaxwell|lol
506 2017-11-09 19:49:05	0|wumpus|cfields: nice!
507 2017-11-09 19:49:06	0|sipa|promag: accessing CBlockIndex entries does not require a lock to access most fields (as they are immutable)
508 2017-11-09 19:49:07	0|BlueMatt|jonasschnelli: the registration process for an org in the us can be pretty easily diy-d, especially if you're never going to *use* the org
509 2017-11-09 19:49:08	0|luke-jr|why does it need to be Core-specific? just a redundant waste of money and time to then get another one for Knots, when it could just as easily be a shared effort. sigh.
510 2017-11-09 19:49:18	0|BlueMatt|achow101: who cares?
511 2017-11-09 19:49:19	0|gmaxwell|achow101: we should create a UK org, you can name anyone you want as the officers.
512 2017-11-09 19:49:23	0|jonasschnelli|BlueMatt: let me first check the real costs here in CH
513 2017-11-09 19:49:23	0|jonasschnelli|I know it's basically free... but someone needs to do the paperwork...
514 2017-11-09 19:49:29	0|jonasschnelli|Which is the significant costs IMO
515 2017-11-09 19:49:34	0|gmaxwell|achow101: and the registrations are visible online. :P
516 2017-11-09 19:49:34	0|luke-jr|gmaxwell: even without their consent? XD
517 2017-11-09 19:49:35	0|jonasschnelli|Which *are
518 2017-11-09 19:49:37	0|gmaxwell|luke-jr: yes.
519 2017-11-09 19:49:37	0|meshcollider|BlueMatt does a US LLC need a bank account and everything?
520 2017-11-09 19:49:41	0|BlueMatt|meshcollider: no
521 2017-11-09 19:49:42	0|gmaxwell|meshcollider: no.
522 2017-11-09 19:49:43	0|BlueMatt|why would it?
523 2017-11-09 19:49:47	0|achow101|BlueMatt: people who want to look at the paperwork and then go "X controls bitcoin blarg" conspiracy
524 2017-11-09 19:49:58	0|meshcollider|Idk, some countries do dont they
525 2017-11-09 19:50:04	0|BlueMatt|all you have to do is file paperwork to create it, then file a tax return every year....some nominal cost to doing so, but IIRC 35$ for delaware
526 2017-11-09 19:50:05	0|luke-jr|gmaxwell: Satoshi Nakamoto, John Doe, Jane Doe, …
527 2017-11-09 19:50:10	0|gmaxwell|achow101: so e.g. we can list satoshi nakamoto, bill gates, donald trump...
528 2017-11-09 19:50:18	0|achow101|gmaxwell: lol
529 2017-11-09 19:50:18	0|BlueMatt|achow101: hence why its called "Code Signing, LLC" :p
530 2017-11-09 19:50:50	0|achow101|meshcollider: it varies in the us by state. IIRC it costs almost nothing to register an LLC. pay the fee and submit paperwork and thats just about it
531 2017-11-09 19:51:05	0|BlueMatt|yea, that ^
532 2017-11-09 19:51:25	0|meshcollider|Ok sweet as
533 2017-11-09 19:51:27	0|gmaxwell|it does take a bit of time.
534 2017-11-09 19:51:38	0|jonasschnelli|I guess an US LLC is always tied to an individual, a person who found/owns the LLC?
535 2017-11-09 19:51:49	0|achow101|jonasschnelli: yes
536 2017-11-09 19:51:59	0|meshcollider|According to cagi.ch, "The creation of an association does not entail any administrative cost."
537 2017-11-09 19:52:12	0|achow101|that person also has to file taxes for the llc every year. but for something that does nothing and makes no money, that shouldn't be a problem
538 2017-11-09 19:52:17	0|jonasschnelli|Where an association (in Switzerland at least) has no owner,... it just has members (which have different / exchangable roles)
539 2017-11-09 19:52:17	0|sipa|promag: so if you want consistent but just read-only access to CChain, you could ibstead just briefly lock main, get a copy of chainActive.Tip() pointer, unlock, and then use the resulting CBlockIndex without any locks
540 2017-11-09 19:52:41	0|luke-jr|jonasschnelli: does Apple definitely recognise it?
541 2017-11-09 19:52:46	0|meshcollider|Association in Switzerland sounds cleaner than LLC in us imo
542 2017-11-09 19:53:05	0|jonasschnelli|meshcollider: "costs" are a wide term... fill out paperwork/forms for 2-3 can have costs...
543 2017-11-09 19:53:15	0|sipa|promag: CBlockIndex has efficient Ancestor function yo query at any height... not quite as efficient as looking up in CChain, but probably sufficient for almost anything
544 2017-11-09 19:53:36	0|jonasschnelli|luke-jr: just checking... but I know other swiss Assocaitions having an App in the App store... so it should work
545 2017-11-09 19:53:49	0|promag|right, only lacks Next
546 2017-11-09 19:53:55	0|BlueMatt|jonasschnelli: I dont think we care about ownership here - it literally will not even hold the keys
547 2017-11-09 19:54:37	0|meshcollider|Jonasschnelli it also says "A Committee (comprising at least a president, a secretary, and a treasurer)." Not just members, irrelevant point though
548 2017-11-09 19:54:47	0|achow101|I guess the cost here is "how much money does someone need to pay for this thing to exist"
549 2017-11-09 19:55:05	0|jonasschnelli|A committee is required,.. yes. But it's flexible...
550 2017-11-09 19:55:19	0|jonasschnelli|achow101: + how much work does he need to spend
551 2017-11-09 19:55:19	0|meshcollider|Yep
552 2017-11-09 19:56:16	0|jonasschnelli|BlueMatt: The ownership can have some sideeffects... I personally don't want to be in a register with my Name tied to a company that have "Bitcoin" in it's name. For travel purposes...
553 2017-11-09 19:56:19	0|wumpus|wasn't it that you can put other companies as officers? :)
554 2017-11-09 19:56:31	0|wumpus|and create a recursive organization
555 2017-11-09 19:56:44	0|jonasschnelli|wumpus: I guess not for an association
556 2017-11-09 19:56:52	0|jonasschnelli|(for other companies that would work)
557 2017-11-09 19:57:06	0|jonasschnelli|although I may be wrong
558 2017-11-09 19:57:41	0|BlueMatt|jonasschnelli: heh, I'm not too worried, if they google any of us they'll find bitcoin faster than if they look at what companies we are connected to :p
559 2017-11-09 19:57:49	0|achow101|jonasschnelli: in the US, you could register in like Delaware where the business registrations are not public and can only be revealed by subpoena (or the like)
560 2017-11-09 19:58:16	0|wumpus|jonasschnelli: yes maybe that's only true in Panama :p
561 2017-11-09 19:58:40	0|wumpus|BlueMatt: I'm not really worried either, they know we're connected to the software project anyhow
562 2017-11-09 19:59:35	0|jonasschnelli|Yes... probably... though I'm always suprised how entering the country depends on the officers (and the little surface info he has) you have in front of you
563 2017-11-09 20:00:03	0|meshcollider|"LLCs in Delaware don’t file annual reports"
564 2017-11-09 20:00:46	0|wumpus|meshcollider: that's another popular location for shell companies right?
565 2017-11-09 20:01:09	0|jonasschnelli|However, next week i should have more bandwidth then 14.4kbds so I'll can check the details... and report in next weeks meeting
566 2017-11-09 20:01:19	0|meshcollider|I'd expect so, achow101 suggested it
567 2017-11-09 20:01:39	0|sipa|promag: but next is easy to implement as tip->Ancestor(prev->nHeight + 1) :)
568 2017-11-09 20:01:42	0|achow101|wumpus: a lot of big US companies are registered in delaware, e.g. Google
569 2017-11-09 20:01:45	0|luke-jr|TIL achow101 is well-known for suggesting shell company locations
570 2017-11-09 20:02:34	0|wumpus|luke-jr: hah
571 2017-11-09 20:02:47	0|achow101|there's also a few other states too
572 2017-11-09 20:02:56	0|sipa|unfortunately, someone would just need to know the information was suggested by achow101, to guess
573 2017-11-09 20:03:18	0|meshcollider|Sounds like delaware is good for avoiding lots of tax too, not that that matters here ;)
574 2017-11-09 20:03:23	0|achow101|luke-jr: well right now I'm taking a course about fraud and scams, and we came to the topic of shell companies and the panama papers recently :p
575 2017-11-09 20:03:59	0|luke-jr|i c
576 2017-11-09 20:04:34	0|meshcollider|Oh, "Delaware LLCs do not file annual reports; instead, LLCs in Delaware file annual taxes. The annual tax is a flat $300."
577 2017-11-09 20:06:27	0|promag|cya later
578 2017-11-09 20:12:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1f4375f8e75f...e6e3fc39518b
579 2017-11-09 20:12:33	0|bitcoin-git|13bitcoin/06master 14208fda6 15Jonas Schnelli: CCrypter: move relevant implementation out of the header
580 2017-11-09 20:12:33	0|bitcoin-git|13bitcoin/06master 143155fd2 15Jonas Schnelli: CKeystore: move relevant implementation out of the header
581 2017-11-09 20:12:34	0|bitcoin-git|13bitcoin/06master 14dd9bb25 15Jonas Schnelli: Fix code style in keystore.cpp/crypter.cpp
582 2017-11-09 20:12:59	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11272: CKeystore/CCrypter: move relevant implementation out of the header (06master...062017/09/wallet_refact) 02https://github.com/bitcoin/bitcoin/pull/11272
583 2017-11-09 20:20:53	0|bitcoin-git|13bitcoin/06master 14ab8e8b9 15practicalswift: Remove unused variables in shell scripts.
584 2017-11-09 20:20:53	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e6e3fc39518b...23e9074e0a36
585 2017-11-09 20:20:54	0|bitcoin-git|13bitcoin/06master 1423e9074 15Wladimir J. van der Laan: Merge #10771: Remove unused variables in shell scripts...
586 2017-11-09 20:21:13	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10771: Remove unused variables in shell scripts (06master...06unused-shell-variables) 02https://github.com/bitcoin/bitcoin/pull/10771
587 2017-11-09 20:25:57	0|wumpus|* [new tag]         v0.15.1 -> v0.15.1
588 2017-11-09 20:26:39	0|BlueMatt|!
589 2017-11-09 20:27:50	0|wumpus|congrats everyone on the 0.15.1 release :)
590 2017-11-09 20:34:27	0|achow101|yay!
591 2017-11-09 20:34:52	0|bitcoin-git|[13bitcoin] 15laanwj pushed 14 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/23e9074e0a36...5e9be169e430
592 2017-11-09 20:34:53	0|bitcoin-git|13bitcoin/06master 145a6f768 15practicalswift: Use unique_ptr for httpRPCTimerInterface (HTTPRPCTimerInterface)
593 2017-11-09 20:34:53	0|bitcoin-git|13bitcoin/06master 14860e912 15practicalswift: Use unique_ptr for pwalletMain (CWallet)
594 2017-11-09 20:34:54	0|bitcoin-git|13bitcoin/06master 14fa6d122 15practicalswift: Use unique_ptr:s for {fee,short,long}Stats (TxConfirmStats)
595 2017-11-09 20:35:12	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11043: Use std::unique_ptr (C++11) where possible (06master...06unique-pointers) 02https://github.com/bitcoin/bitcoin/pull/11043
596 2017-11-09 20:45:51	0|meshcollider|I'll write a release page for bitcoincore.org later if no one else does
597 2017-11-09 20:52:49	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11648: [tests] Add primitives.py (06master...06add_primitives_py) 02https://github.com/bitcoin/bitcoin/pull/11648
598 2017-11-09 20:53:44	0|RealM9|Hello, which paper wallet generator can be trusted?
599 2017-11-09 20:53:59	0|RealM9|(Asking it here, because i trust core devs)
600 2017-11-09 20:54:22	0|RealM9|Is bit address safe?
601 2017-11-09 20:57:53	0|aj|jonasschnelli: is there really a question about #8550 being qt only or having a non-qt stats collector? having non-qt access to info always seems better, at a minimum for tests and the like...
602 2017-11-09 20:57:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/8550 | [Qt] Add interactive mempool graph by jonasschnelli · Pull Request #8550 · bitcoin/bitcoin · GitHub
603 2017-11-09 21:05:18	0|wumpus|aj jonasschnelli I tend to agree, though getting things merged w/ the GUI tends to be easier than JSON API changes
604 2017-11-09 21:05:33	0|wumpus|in any case the end goal is to have both
605 2017-11-09 21:05:48	0|aj|wumpus: (loving watching all the commits going through today)
606 2017-11-09 21:06:23	0|wumpus|I really want the GUI interactive mempool graph in, because it is appealing to people
607 2017-11-09 21:07:01	0|wumpus|aj: yes, much progress today
608 2017-11-09 21:09:56	0|cfields|meshcollider: that reminds me, anyone else getting a cert issue for bitcoincore.org ?
609 2017-11-09 21:12:03	0|cfields|wumpus: and, looks like i was wrong about an easy cert renewal. going deeper now.
610 2017-11-09 21:13:45	0|aj|cfields: bitcoincore.org seems fine here (firefox sees a let's encrypt cert)
611 2017-11-09 21:14:25	0|wumpus|cfields: uh oh
612 2017-11-09 21:14:44	0|wumpus|aj: he means the code signing cert, web certs are much easier luckily
613 2017-11-09 21:14:51	0|cfields|aj: ah right, thanks for confirming
614 2017-11-09 21:15:10	0|cfields|wumpus: nah, i meant the site. forgot i had a dns hack in place
615 2017-11-09 21:15:12	0|cfields|damn you BlueMatt!
616 2017-11-09 21:15:15	0|wumpus|oh
617 2017-11-09 21:25:09	0|BlueMatt|cfields: lol, uhhhh, I have no idea what server you were accessing that had an old cert
618 2017-11-09 21:25:12	0|BlueMatt|thats...strange
619 2017-11-09 21:25:43	0|cfields|BlueMatt: it was pointed at bitcoin.org for some experiment
620 2017-11-09 21:25:49	0|BlueMatt|lolk
621 2017-11-09 21:26:31	0|cfields|no worries, all good now
622 2017-11-09 21:41:29	0|luke-jr|‎[21:06:22] ‎<‎wumpus‎>‎ I really want the GUI interactive mempool graph in, because it is appealing to people <-- it conflicts with its dependency nowadays :x
623 2017-11-09 21:41:41	0|luke-jr|although I have it in Knots with an older version of the dep
624 2017-11-09 21:46:41	0|gmaxwell|luke-jr: what dependency
625 2017-11-09 21:46:55	0|luke-jr|gmaxwell: the stats collection stuff
626 2017-11-09 21:49:58	0|aj|luke-jr: i did a rebase of the qt bit in a PR against jonas's repo fwiw, https://github.com/btc1/bitcoin/issues/140
627 2017-11-09 21:50:33	0|aj|luke-jr: (rebased on top of jonas's repo for the json bit)
628 2017-11-09 21:51:33	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11649: Revert "Remove unused variable in shell script" (06master...06Mf1711-revertRemove) 02https://github.com/bitcoin/bitcoin/pull/11649
629 2017-11-09 22:03:52	0|luke-jr|aj: did you link the wrong thing?
630 2017-11-09 22:05:42	0|bitcoin-git|13bitcoin/06master 14fa0025d 15MarcoFalke: Revert "Remove unused variable in shell script"...
631 2017-11-09 22:05:42	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5e9be169e430...c838283ecdfb
632 2017-11-09 22:05:43	0|bitcoin-git|13bitcoin/06master 14c838283 15MarcoFalke: Merge #11649: Revert "Remove unused variable in shell script"...
633 2017-11-09 22:06:13	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11649: Revert "Remove unused variable in shell script" (06master...06Mf1711-revertRemove) 02https://github.com/bitcoin/bitcoin/pull/11649
634 2017-11-09 22:09:57	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c838283ecdfb...6e4e98ee8ce2
635 2017-11-09 22:09:58	0|bitcoin-git|13bitcoin/06master 14487aff4 15Pieter Wuille: Check subtree consistency in Travis
636 2017-11-09 22:09:58	0|bitcoin-git|13bitcoin/06master 14e1d0cc2 15Pieter Wuille: Improve git-subtree-check.sh...
637 2017-11-09 22:09:59	0|bitcoin-git|13bitcoin/06master 146e4e98e 15MarcoFalke: Merge #11394: Perform a weaker subtree check in Travis...
638 2017-11-09 22:10:00	0|wumpus|MarcoFalke: huh, I'm 100% sure I checked all the variables
639 2017-11-09 22:10:16	0|wumpus|no match for $old in that script
640 2017-11-09 22:10:22	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11394: Perform a weaker subtree check in Travis (06master...06201709_travis_subtree) 02https://github.com/bitcoin/bitcoin/pull/11394
641 2017-11-09 22:10:28	0|MarcoFalke|wumpus: Not your fault :)
642 2017-11-09 22:10:55	0|MarcoFalke|It was only used in one of the sipa/bitcoin.git branches
643 2017-11-09 22:11:05	0|MarcoFalke|I guess you didn't check them
644 2017-11-09 22:11:20	0|sipa|hmm, did i miss something?
645 2017-11-09 22:11:20	0|wumpus|no, I checked our own repository only
646 2017-11-09 22:11:44	0|MarcoFalke|sipa: no
647 2017-11-09 22:11:54	0|MarcoFalke|all should be fine now
648 2017-11-09 22:13:31	0|wumpus|ok
649 2017-11-09 22:16:23	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11582: wallet: Restore -usehd=0 option (06master...06usehd) 02https://github.com/bitcoin/bitcoin/pull/11582
650 2017-11-09 22:22:06	0|aj|luke-jr: yes, yes i did. https://github.com/jonasschnelli/bitcoin/pull/9