1 2017-07-13 00:42:01	0|jtimon|random data point: as of height 475560, it takes 157.7 GB of storage (using -txindex)
  2 2017-07-13 01:26:05	0|bitcoin-git|13bitcoin/06master 141e3a320 15practicalswift: Simplify "!foo || (foo && bar)" as "!foo || bar"
  3 2017-07-13 01:26:05	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/479afa0f8486...e4fcbf797ed3
  4 2017-07-13 01:26:06	0|bitcoin-git|13bitcoin/06master 14e4fcbf7 15Pieter Wuille: Merge #10780: Simplify "!foo || (foo && bar)" as "!foo || bar"...
  5 2017-07-13 01:26:36	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10780: Simplify "!foo || (foo && bar)" as "!foo || bar" (06master...06redundant-condition) 02https://github.com/bitcoin/bitcoin/pull/10780
  6 2017-07-13 07:21:46	0|bitcoin-git|13bitcoin/06master 1469a4339 15Lawrence Nahum: missing white space in function arg
  7 2017-07-13 07:21:46	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e4fcbf797ed3...7666250ffb4e
  8 2017-07-13 07:21:47	0|bitcoin-git|13bitcoin/06master 147666250 15Jonas Schnelli: Merge #10810: missing white space in function arg...
  9 2017-07-13 07:22:21	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #10810: missing white space in function arg (06master...06missing_white_space) 02https://github.com/bitcoin/bitcoin/pull/10810
 10 2017-07-13 07:27:24	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #10731: SanitizeString: Expand upon allowed characters in logging to include "!#%&*+=^{}~" (06master...06log_more_uacomment) 02https://github.com/bitcoin/bitcoin/pull/10731
 11 2017-07-13 07:28:15	0|luke-jr|jonasschnelli: how do we fix the current bug in Core then?
 12 2017-07-13 07:28:28	0|luke-jr|#10731 is a bug fix for a present issue
 13 2017-07-13 07:28:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/10731 | SanitizeString: Expand upon allowed characters in logging to include "!#%&*+=^{}~" by luke-jr · Pull Request #10731 · bitcoin/bitcoin · GitHub
 14 2017-07-13 07:46:41	0|bitcoin-git|[13bitcoin] 15jonasschnelli reopened pull request #10731: SanitizeString: Expand upon allowed characters in logging to include "!#%&*+=^{}~" (06master...06log_more_uacomment) 02https://github.com/bitcoin/bitcoin/pull/10731
 15 2017-07-13 07:50:27	0|jonasschnelli|luke-jr: Your description: "Current Core strips out the !, + and = characters used by Knots to indicate whether BIP148 enforcement is enabled."
 16 2017-07-13 07:50:50	0|jonasschnelli|luke-jr: Can you describe the bug more precise?
 17 2017-07-13 07:51:55	0|jonasschnelli|I fail to see the bug in Core
 18 2017-07-13 07:53:00	0|luke-jr|jonasschnelli: 2017-07-13 07:37:02 receive version message: /Satoshi:0.14.2(BIP148)/Knots:20170618/: version 70015…
 19 2017-07-13 07:53:17	0|luke-jr|jonasschnelli: Core logs this regardless of whether it's !BIP148= or +BIP148 or !BIP148
 20 2017-07-13 07:53:28	0|jonasschnelli|Well.. why is this a bug in core?
 21 2017-07-13 07:53:35	0|luke-jr|because they are all valid UA characters
 22 2017-07-13 07:53:46	0|jonasschnelli|Yes. But invalid log prints.
 23 2017-07-13 07:53:51	0|gmaxwell|because you just say they are valid?
 24 2017-07-13 07:53:57	0|gmaxwell|They were never printed before.
 25 2017-07-13 07:54:03	0|luke-jr|they don't violate BIP 14
 26 2017-07-13 07:54:06	0|jonasschnelli|It's a log...
 27 2017-07-13 07:54:09	0|luke-jr|jonasschnelli: why?
 28 2017-07-13 07:54:17	0|jonasschnelli|luke-jr: BIP 14 is not about a log file
 29 2017-07-13 07:54:21	0|luke-jr|there's no reason logs shouldn't have those characters. most do. Core does other places.
 30 2017-07-13 07:54:38	0|jonasschnelli|Yes. I'm happy if you fix it. But don't break the SanitizeString assumption
 31 2017-07-13 07:54:44	0|luke-jr|there are far worse characters also allowed in SanitizeString
 32 2017-07-13 07:54:48	0|gmaxwell|BIP14 seems to also allow \n  nul  and so on
 33 2017-07-13 07:54:57	0|gmaxwell|IOW: bip-14 is brain damaged
 34 2017-07-13 07:54:58	0|luke-jr|gmaxwell: those are sane to forbid
 35 2017-07-13 07:55:26	0|luke-jr|what if SanitizeString turns ! into \! ?
 36 2017-07-13 07:55:31	0|jonasschnelli|No
 37 2017-07-13 07:55:39	0|jonasschnelli|It's not escaping
 38 2017-07-13 07:55:42	0|jonasschnelli|Its sanitizing
 39 2017-07-13 07:55:49	0|gmaxwell|Characters that will screw up shell processing and potentially lead to XSS in URL also are sane to forbid.
 40 2017-07-13 07:55:58	0|luke-jr|gmaxwell: we already allow many of those
 41 2017-07-13 07:56:15	0|jonasschnelli|Then make it better but not worse?
 42 2017-07-13 07:56:17	0|gmaxwell|I am tempted to say we should change the printing to hex just as we do with other potentially malicious network input.
 43 2017-07-13 07:56:24	0|gmaxwell|already people spam advertisements via UAs.
 44 2017-07-13 07:56:44	0|luke-jr|jonasschnelli: it's not a reasonable expectation. it's a log file, not a database query.
 45 2017-07-13 07:56:57	0|luke-jr|what other log files forbid characters for such reasons?
 46 2017-07-13 07:57:03	0|gmaxwell|why are we even logging these strings?
 47 2017-07-13 07:57:04	0|jonasschnelli|luke-jr: I'm fine about chaging the log print.. but not SanitizeString
 48 2017-07-13 07:57:23	0|jonasschnelli|SanitizeString and the log file are conceptually two things.
 49 2017-07-13 07:57:30	0|luke-jr|why is it when wumpus submits a PR doing this, it gets only ACKs and merged; yet when I do, people dig up obscure reasons to argue against it?
 50 2017-07-13 07:57:49	0|gmaxwell|among other reasons, the privacy arguments we have for not logging IPs also applies, esp with so much diversity in stupid values people are setting in these strhings.
 51 2017-07-13 07:57:52	0|jonasschnelli|luke-jr: Can you refere to wumpus's PR?
 52 2017-07-13 07:58:15	0|luke-jr|https://github.com/bitcoin/bitcoin/pull/4983
 53 2017-07-13 07:58:41	0|luke-jr|‎[07:57:03] ‎<‎jonasschnelli‎>‎ luke-jr: I'm fine about chaging the log print.. but not SanitizeString <-- what do you mean by this?
 54 2017-07-13 07:59:06	0|gmaxwell|I didn't ack wumpus; but as far as yours went, because you included a bunch of red-flag characters that I've personally been burned by.
 55 2017-07-13 07:59:16	0|jonasschnelli|luke-jr: () wumpus, yours: !#%&*+=^{}~
 56 2017-07-13 07:59:53	0|gmaxwell|Again, why are we logging this in debug.log by default anyways?
 57 2017-07-13 08:00:00	0|gmaxwell|We do not log IPs for privacy reasons.
 58 2017-07-13 08:00:26	0|luke-jr|gmaxwell: I don't know an answer to that. This issue affects the GUI as well, though.
 59 2017-07-13 08:00:32	0|jonasschnelli|luke-jr: If you think those chars should be visible in the log, maybe find a way as gmaxwell mentioned via hex-representation of some partially-invalid (they turn to hex)...
 60 2017-07-13 08:00:52	0|gmaxwell|luke-jr: I think it's a lot less of a concern in the GUI.  I think your new characters are probably okay there.
 61 2017-07-13 08:01:04	0|jonasschnelli|GUI is isolated
 62 2017-07-13 08:01:09	0|luke-jr|so URL escape in debug log?
 63 2017-07-13 08:01:11	0|luke-jr|%xx
 64 2017-07-13 08:01:17	0|gmaxwell|jonasschnelli: % lets you escape arbritary characters for html/urls among other things.
 65 2017-07-13 08:01:29	0|gmaxwell|luke-jr: why not drop it from the debug log, and make the GUI more permissive?
 66 2017-07-13 08:01:51	0|luke-jr|gmaxwell: I de facto have a script parsing the debug log to analyse this
 67 2017-07-13 08:01:55	0|gmaxwell|though I question perhaps if we really should be showing these things in the gui.. not the characters, but third party sourced strings
 68 2017-07-13 08:02:02	0|jonasschnelli|gmaxwell, luke-jr: Hm.. yes. Maybe use the urlencode for the UA-string before printing to the log?
 69 2017-07-13 08:02:12	0|gmaxwell|UA:  DANGER YOUR WALLET HAS BEEN COMPROMISED GO TO HTTP://fixwallet.eu/ NOW
 70 2017-07-13 08:02:22	0|luke-jr|:|
 71 2017-07-13 08:02:37	0|jonasschnelli|I kinda agree with gmaxwell that BIP 14 is BD
 72 2017-07-13 08:02:54	0|jonasschnelli|The original idea was also to place a donation bitcoin address there... :/
 73 2017-07-13 08:02:59	0|sipa|gmaxwell: the .eu makes it totally legit
 74 2017-07-13 08:03:02	0|luke-jr|lol
 75 2017-07-13 08:03:08	0|jonasschnelli|hahaha
 76 2017-07-13 08:03:09	0|gmaxwell|UA: OFFICIAL BITCOIN NOTICE. BITCOIN HAS BEEN REPLACED BY ULTRACOIN BUY REPLACEMENT COINS AT BITCOIN.COM NOW
 77 2017-07-13 08:03:44	0|gmaxwell|I mean this is why we don't try to do any fancy decoding of data stuffed in transactions either... :)
 78 2017-07-13 08:04:12	0|sipa|let's print the hash of the UA; we do that for almost all data already anyway
 79 2017-07-13 08:04:14	0|gmaxwell|similar risks exist in logs.
 80 2017-07-13 08:04:18	0|luke-jr|I thought that was to discourage fancy encoding <.<
 81 2017-07-13 08:04:48	0|gmaxwell|luke-jr: well advertisments in UA is also bad (which some people have been doing)
 82 2017-07-13 08:05:04	0|gmaxwell|sipa: we display hex of many things too.
 83 2017-07-13 08:05:18	0|gmaxwell|hex can be decoded but it's not going to trick anyone.
 84 2017-07-13 08:05:19	0|luke-jr|gmaxwell: that's not clear to me. how is it bad?
 85 2017-07-13 08:05:41	0|gmaxwell|luke-jr: spin up lots of sybil nodes just to get people to see DRINK MORE OVALTINE.
 86 2017-07-13 08:05:49	0|luke-jr|hmm
 87 2017-07-13 08:06:00	0|luke-jr|but people *don't* see it that much
 88 2017-07-13 08:06:11	0|luke-jr|if they do, it's more often than not a website that doesn't care what we do here
 89 2017-07-13 08:06:23	0|gmaxwell|(and god forbid people use the malicious messages like I suggested above, which they'd see in optimally bad situations: when they're wondering if their node is working right)
 90 2017-07-13 08:06:38	0|gmaxwell|luke-jr: yea, thats those websites problems (actually a lot of them filter that stuff)
 91 2017-07-13 08:07:27	0|luke-jr|should I make SanitizeString do the %xx escaping, or have a new function for this?
 92 2017-07-13 08:07:33	0|gmaxwell|FWIW I protested the UAs to begin with. Just for the record. :P
 93 2017-07-13 08:08:30	0|gmaxwell|nothing good ever comes from strings in protocols.
 94 2017-07-13 08:09:29	0|luke-jr|I know a protocol that uses strings for commands
 95 2017-07-13 08:09:34	0|gmaxwell|as far as url escaping the logs, that solves some problems not others... e.g. I think it doesn't make them necessarily safe for shell processing.
 96 2017-07-13 08:09:35	0|luke-jr|… sortof XD
 97 2017-07-13 08:09:56	0|luke-jr|gmaxwell: ?
 98 2017-07-13 08:10:30	0|gmaxwell|or maybe it does. gah, part of my complaint is that these sorts of changes aren't worth the security review time.
 99 2017-07-13 08:11:36	0|gmaxwell|luke-jr: re wladimir adding ( and ) in 2014: at least those characters are specifically named in the BIP.
100 2017-07-13 08:11:59	0|gmaxwell|(they are also not ones that I've personally ever had bite me in data, I think)
101 2017-07-13 08:12:20	0|gmaxwell|where ! %  very much have.
102 2017-07-13 08:13:29	0|gmaxwell|Lets only allow the characters BIP14 specifically mentions. :P
103 2017-07-13 08:13:52	0|sipa|jonasschnelli: https://github.com/bitcoin/bitcoin/pull/10810#issuecomment-314993972 ?
104 2017-07-13 08:14:01	0|sipa|you're agreeing with a NACK, and then proceed to merge it?
105 2017-07-13 08:14:16	0|jonasschnelli|sipa: Yes
106 2017-07-13 08:14:17	0|sipa|(i have little opinion either way, just trying to follow what's happening)
107 2017-07-13 08:14:29	0|gmaxwell|luke-jr: also, FWIW, I can promise it wasn't because it was you that I protested... I was into writing my opposition before noticing it was you that was pring it.
108 2017-07-13 08:14:52	0|jonasschnelli|sipa: The best way to stop such PR is to merge them quickly. We can't close them.
109 2017-07-13 08:15:01	0|sipa|why not?
110 2017-07-13 08:15:23	0|jonasschnelli|Trolling and because it's an improvement (the space was missing there).
111 2017-07-13 08:15:33	0|jonasschnelli|Closing because it may slow us down is somehow weak?
112 2017-07-13 08:15:44	0|jonasschnelli|A quick merge seems to be the best path forward
113 2017-07-13 08:15:53	0|jonasschnelli|"get it out of the way" style
114 2017-07-13 08:18:13	0|gmaxwell|lets hope it didn't conflict any other PRs and cause needed rebasing.
115 2017-07-13 08:22:31	0|jonasschnelli|gmaxwell: I checked that and it shouldn't
116 2017-07-13 08:23:19	0|jonasschnelli|Maybe that something we can discuss in todays meeting. These typo-fix/add-spaced PRs need a clear strategy how to avoid them in the long run.
117 2017-07-13 08:23:25	0|jonasschnelli|Maybe the quick merge is not ideal then
118 2017-07-13 08:24:18	0|jonasschnelli|But if we want to close them (not merge them), then we should have a quick part in the PR guidlines
119 2017-07-13 08:24:50	0|sipa|> Do not submit patches solely to modify the style of existing code.
120 2017-07-13 08:25:09	0|sipa|-- https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#developer-notes
121 2017-07-13 08:26:50	0|jonasschnelli|Oh... I should read more.
122 2017-07-13 08:27:36	0|jonasschnelli|What about typo fixes?
123 2017-07-13 08:28:17	0|jonasschnelli|So yes. My quick merge was wrong.
124 2017-07-13 08:28:47	0|luke-jr|does #10731 look acceptable now?
125 2017-07-13 08:28:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/10731 | Escape rather than remove any printable characters in UAs by luke-jr · Pull Request #10731 · bitcoin/bitcoin · GitHub
126 2017-07-13 08:32:21	0|jonasschnelli|luke-jr: looks good. But I guess the PR description could be a bit better (going to be in git history)
127 2017-07-13 08:33:55	0|luke-jr|done
128 2017-07-13 08:35:24	0|luke-jr|insofar as UA phishing, how hard would it be to add a red exclamation mark icon next to the UA string with a tooltip warning the user it's not to be trusted?
129 2017-07-13 08:35:52	0|luke-jr|(otoh, maybe that would make the problem worse?)
130 2017-07-13 12:26:33	0|jonasschnelli|ryanofsky: I like your def __idiv__(self, relative_uri): approach
131 2017-07-13 12:26:41	0|jonasschnelli|Can you help me how I have to do this?
132 2017-07-13 13:08:55	0|bitcoin-git|[13bitcoin] 15ReneNyffenegger opened pull request #10814: Change type of op to agree with type of MAX_OPCODE. (06master...06MAX_OPCODE) 02https://github.com/bitcoin/bitcoin/pull/10814
133 2017-07-13 13:13:53	0|ryanofsky|jonasschnelli, does suggested code in https://github.com/bitcoin/bitcoin/pull/10650#discussion_r123484826 not work?
134 2017-07-13 13:14:38	0|ryanofsky|maybe it needs /v1/ string added
135 2017-07-13 13:14:58	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #10814: Change type of op to agree with type of MAX_OPCODE. (06master...06MAX_OPCODE) 02https://github.com/bitcoin/bitcoin/pull/10814
136 2017-07-13 13:18:34	0|ryanofsky|actually should probably be __truediv__ not idiv: https://docs.python.org/3/reference/datamodel.html?highlight=truediv#object.__truediv__
137 2017-07-13 13:41:54	0|jnewbery|jonasschnelli: what's the current status with 10814? Are you expecting to rebase/address feedback today?
138 2017-07-13 13:42:55	0|jnewbery|sorry, not 10814, 10650
139 2017-07-13 13:43:06	0|jnewbery|#10650
140 2017-07-13 13:43:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
141 2017-07-13 13:46:16	0|jonasschnelli|jnewbery, ryanofsky: working on a rebase of 10650 with add points adressed
142 2017-07-13 13:46:44	0|jonasschnelli|But git history is somehow fucked up... will fix soon
143 2017-07-13 13:47:00	0|jonasschnelli|So I pushed the just rebased version now
144 2017-07-13 13:47:19	0|jonasschnelli|Because the fixed has a strange history.. will fix soon
145 2017-07-13 13:47:34	0|jnewbery|anything I can do to help?
146 2017-07-13 13:50:15	0|jonasschnelli|jnewbery: no all good.
147 2017-07-13 14:01:28	0|instagibbs|morcos, displaying wallet name is still useful in case you have multiple wallets in same datadir and you've forgotten which one you loaded :)
148 2017-07-13 14:02:12	0|jonasschnelli|instagibbs you mean in getwalletinfo?
149 2017-07-13 14:02:32	0|instagibbs|yeah
150 2017-07-13 14:02:56	0|jonasschnelli|Yes. I think it's a must for getwalletinfo
151 2017-07-13 14:03:05	0|jonasschnelli|Its how users can be sure they interacting with the right wallet
152 2017-07-13 14:03:08	0|instagibbs|squinting at the hd key is the way I distinguish now
153 2017-07-13 14:03:23	0|jonasschnelli|yeah. that works too
154 2017-07-13 14:05:31	0|morcos|instagibbs: heh, i was joking about the listwallets feature.. but hopefully 10650 makes it!
155 2017-07-13 14:06:18	0|morcos|it lookes like #10706 could use one more ack, but it's close.  #10707 is then 2 simple commits on top of that.  But I'd like opinon on the second commit
156 2017-07-13 14:06:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/10706 | Improve wallet fee logic and fix GUI bugs by morcos · Pull Request #10706 · bitcoin/bitcoin · GitHub
157 2017-07-13 14:06:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/10707 | Better API for estimatesmartfee RPC by morcos · Pull Request #10707 · bitcoin/bitcoin · GitHub
158 2017-07-13 14:06:27	0|morcos|See this comment: https://github.com/bitcoin/bitcoin/pull/10707#issuecomment-314869251
159 2017-07-13 14:06:49	0|morcos|All this needs to go in before string freeze
160 2017-07-13 14:14:17	0|jonasschnelli|jnewbery or ryanofsky
161 2017-07-13 14:14:37	0|jonasschnelli|i could not get that authproxy endoint thing running
162 2017-07-13 14:15:00	0|jonasschnelli|I guess python doesnt like me...
163 2017-07-13 14:15:16	0|jonasschnelli|Anyone of you willing to provide a commit for 10650?
164 2017-07-13 14:21:31	0|jnewbery|jonasschnelli: I'll give it a go now
165 2017-07-13 14:21:47	0|jonasschnelli|perfect. thanks
166 2017-07-13 14:45:49	0|jnewbery|I've got authproxy working and written a test, but any requests to /v1/wallet/<wallet> get 404s
167 2017-07-13 14:46:01	0|jnewbery|I think because RegisterJSONEndpoint() isn't called anywhere?
168 2017-07-13 14:46:13	0|jnewbery|jonasschnelli ^
169 2017-07-13 14:55:14	0|jnewbery|ok, here you go: https://github.com/jnewbery/bitcoin/tree/multiwallet_test2
170 2017-07-13 14:55:58	0|jonasschnelli|jnewbery: Yes. The PR is currently not working
171 2017-07-13 14:56:52	0|jonasschnelli|jnewbery: which commit is relevant? I'd like to cherry pick (and keep you as the author)
172 2017-07-13 14:57:03	0|jnewbery|that is (your PR #10650) MINUS (the authproxy commit) PLUS (my PR #10604 rebased on top) PLUS (ryanofsky's suggested authproxy change) PLUS (a functional test for multiwallet endpoints) PLUS (a hack in httprpc.cpp to get the test to pass)
173 2017-07-13 14:57:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
174 2017-07-13 14:57:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/10604 | [wallet] [tests] Add listwallets RPC, include wallet name in `getwalletinfo` and add multiwallet test by jnewbery · Pull Request #10604 · bitcoin/bitcoin · GitHub
175 2017-07-13 14:57:42	0|jnewbery|4597818... is the authproxy commit
176 2017-07-13 14:59:03	0|jonasschnelli|jnewbery: Ah.. is was looking for that one: https://github.com/jnewbery/bitcoin/commit/4597818e43900dc07271773f544f47d1da6d635c
177 2017-07-13 14:59:27	0|jonasschnelli|Thanks.. will finish 10650 soon. best to do hand off for now (until I'll comment its rebased)
178 2017-07-13 14:59:34	0|jonasschnelli|*hands
179 2017-07-13 15:02:09	0|jnewbery|ok, ping me if you need anything else. It'd be great to get this ready for final review/merge before the meeting
180 2017-07-13 15:41:48	0|jonasschnelli|jnewbery with your AuthProxy thing I get also a 404
181 2017-07-13 15:42:00	0|jonasschnelli|But bitcoin-cli works.. so the endpoint must be registered
182 2017-07-13 15:43:17	0|jnewbery|can you push your latest branch and I'll test?
183 2017-07-13 15:43:52	0|jnewbery|suggest you tcpdump and compare the requests from bitcoin-cli and authproxy
184 2017-07-13 15:44:22	0|jonasschnelli|ah.. found!
185 2017-07-13 15:44:22	0|jonasschnelli|path='//v1/wallet/w0/'
186 2017-07-13 15:45:07	0|jonasschnelli|it should be AuthServiceProxy("{}{}" (for the __truediff__ op)
187 2017-07-13 15:47:28	0|ryanofsky|shouldn't you just write / "path" instead of / "/path"?
188 2017-07-13 15:48:11	0|jnewbery|ryanofsky: right. That's what's in the test I provided https://github.com/jnewbery/bitcoin/commit/53be2f334979f2cd979554fe81c4837ad02328cd
189 2017-07-13 15:48:24	0|jnewbery|doesn't matter either way, as long as you're consistent
190 2017-07-13 15:50:35	0|ryanofsky|/ "path" is more consistent with python path api
191 2017-07-13 15:59:00	0|jonasschnelli|jnewbery, ryanofsky: I just pushed the new version.. now its ready for a review
192 2017-07-13 15:59:57	0|jonasschnelli|I think usually its better to wait for a 2nd rebase until the author said its overhauled... :)
193 2017-07-13 16:00:10	0|jonasschnelli|But I guess Github sends those code-push mails.
194 2017-07-13 17:25:46	0|morcos|Can someone please remove 0.15 milestone from: #8501 and #10418  and add 0.15 milestone to: #10815
195 2017-07-13 17:25:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/8501 | Add mempool statistics collector by jonasschnelli · Pull Request #8501 · bitcoin/bitcoin · GitHub
196 2017-07-13 17:25:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/10418 | Need fee estimation migration for 0.15 · Issue #10418 · bitcoin/bitcoin · GitHub
197 2017-07-13 17:25:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/10815 | bitcoin-qt core dumps when bitcoin(d/-qt) is already running · Issue #10815 · bitcoin/bitcoin · GitHub
198 2017-07-13 17:26:22	0|morcos|Actually 10418 can just be closed, although it should be addressed in the release notes
199 2017-07-13 17:54:31	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #10816: Properly forbid -salvagewallet and -zapwallettxes for multi wallet. (06master...06multiwallet_parameters) 02https://github.com/bitcoin/bitcoin/pull/10816
200 2017-07-13 18:03:41	0|wumpus|10815 is crazy, when did that start to happen? I'm sure it was ok on 0.14 :/
201 2017-07-13 18:04:58	0|wumpus|we really need tests for the init sequence, it's too easy to mess it up
202 2017-07-13 18:06:49	0|morcos|wumpus: i don't know.. i've been noticing for a while now that occasionally i don't seem to be able to get RPC credentials..  what causes that aspect of the problem?
203 2017-07-13 18:07:12	0|morcos|don't know if those other cases were related to this problem, its kind of easy to miss the core dumps when you expect it to not start properly anyway
204 2017-07-13 18:09:46	0|morcos|by the way, general request for anyone who has open PR's please check whether your 0.15 milestone status is correct or not.  would be nice to focus on the right things and make sure we don't miss anything important.
205 2017-07-13 18:13:51	0|wumpus|well if it continues after not being able to lock the data directory it could do all kinds of things, such as deleting files that are used by the running instance
206 2017-07-13 18:14:31	0|sipa|it seems 0.15 will use around 1.4x less CPU for validation than 0.14.2 (with infinite dbcache, before assumevalid point)
207 2017-07-13 18:14:40	0|wumpus|great!
208 2017-07-13 18:15:41	0|sipa|and at the tip, it's probably even more due to tx validation cache
209 2017-07-13 18:18:09	0|sipa|wumpus: the whole type punning thing is complicated
210 2017-07-13 18:18:13	0|morcos|negative CPU usage sounds awesome!
211 2017-07-13 18:18:25	0|sipa|morcos: haha
212 2017-07-13 18:18:35	0|wumpus|sipa: I'm sometimes thinking about giving up on C++ completely, I really can't keep up anymore
213 2017-07-13 18:19:01	0|sipa|wumpus: in C11, type punning through a union is officially supported, and it's ambiguous in C99
214 2017-07-13 18:19:13	0|sipa|but in C++, there seems to be nothing in the standard to indicate that it is legal
215 2017-07-13 18:19:25	0|wumpus|everyone uses it though, we were all told to use it, after punning through a pointer was no longer allowed
216 2017-07-13 18:19:30	0|sipa|however, it's been supported in actual compilers since forever
217 2017-07-13 18:19:30	0|wumpus|now this is no longer allowed either?
218 2017-07-13 18:19:55	0|sipa|it was never allowed by standards, but in practice everyone used it, so compilers support it
219 2017-07-13 18:20:15	0|wumpus|so is this a question of language lawyering or a practical problem?
220 2017-07-13 18:20:34	0|sipa|in this PR, it's purely theoretical... i gave 3 reasons why it's not a problem :)
221 2017-07-13 18:20:46	0|wumpus|if everything supports it in practice and all code out there uses something, then it's very hard to argue avoiding it
222 2017-07-13 18:21:07	0|morcos|#10235 should be milestoned 0.15 but is ready for merge
223 2017-07-13 18:21:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/10235 | Track keypool entries as internal vs external in memory by TheBlueMatt · Pull Request #10235 · bitcoin/bitcoin · GitHub
224 2017-07-13 18:21:33	0|wumpus|unless there is an official way of doing it, of course, which is better, then we should move to that, but it's tiring
225 2017-07-13 18:21:45	0|wumpus|there's always something that is UB lately
226 2017-07-13 18:21:50	0|wumpus|c++ sucks
227 2017-07-13 18:21:56	0|sipa|wumpus: yes, you're always allowed to access a type's byte representation through a char pointer
228 2017-07-13 18:22:13	0|wumpus|but we don't want to access the type's byte representation
229 2017-07-13 18:22:43	0|wumpus|it was to initialize a pointer in a structure
230 2017-07-13 18:22:56	0|sipa|yes, but the wrong one :)
231 2017-07-13 18:22:58	0|wumpus|or do you want to use offset_of and clear the byte range?
232 2017-07-13 18:23:23	0|sipa|the compiler _incorrectly_ thinks that the indirect pointer may be used uninitialized
233 2017-07-13 18:23:54	0|sipa|this is not possible, the size field is used as a union tag
234 2017-07-13 18:24:10	0|wumpus|morcos: the problem in 10815 is that it does a shutdown, even though the init didn't complete
235 2017-07-13 18:24:12	0|sipa|we're trying to silence it by initializing that pointer, even though the other union field is the only one that's being used
236 2017-07-13 18:24:27	0|wumpus|morcos: so it shuts down the HTTP server, which deletes your authentication cookie etc, even though it was never started
237 2017-07-13 18:24:42	0|wumpus|sipa: bleh
238 2017-07-13 18:25:35	0|sipa|wumpus: forget i brought it up; there are plenty of reasons why it should be fine
239 2017-07-13 18:25:37	0|morcos|wumpus: and what causes core dump?
240 2017-07-13 18:26:05	0|wumpus|morcos:  g_signals.m_internals->BlockChecked.disconnect(boost::bind(&CValidationInterface::BlockChecked, pwalletIn, _1, _2));
241 2017-07-13 18:26:12	0|morcos|10799 can be tagged 0.15 too
242 2017-07-13 18:26:22	0|wumpus|morcos: probably disconnecting something that was never connected in the first place
243 2017-07-13 18:26:41	0|morcos|hmm.. that sucks
244 2017-07-13 18:28:11	0|morcos|while i have you, can i have your opinion on another RPC agument name change issue, this time all messed up solely by me:   https://github.com/bitcoin/bitcoin/pull/10707#issuecomment-314869251
245 2017-07-13 18:28:44	0|morcos|i don't want to miss string freeze, so just want to be sure we all agree on what the final API should look like so i can make sure commits are updated
246 2017-07-13 18:30:45	0|wumpus|morcos: sure, it's good to use a consistent name over multiple calls, if it is used for the same thing
247 2017-07-13 18:31:16	0|wumpus|and if it hasn't been in any release it's ok to change it
248 2017-07-13 18:31:25	0|morcos|yep only issue is the only one in stable release is using the wrong convention confTarget instead of conf_target.   make all the new ones wrong, or just allow that old one to stick around unchanged.
249 2017-07-13 18:31:35	0|wumpus|also the string freeze doesn't apply to RPC help or api, because it's not translated
250 2017-07-13 18:31:47	0|wumpus|it's just for GUI messages _(...) and tr(...)
251 2017-07-13 18:32:04	0|morcos|nblocks has been in release, but already changing estimatesmartfee anyway based on the unstable warning
252 2017-07-13 18:32:07	0|morcos|oh...
253 2017-07-13 18:32:18	0|morcos|whew, ok
254 2017-07-13 18:32:20	0|cfields|sipa: why not use aggregate initialization: prevector() : _size(0), _union{{}}
255 2017-07-13 18:32:25	0|cfields|or give the union a ctor?
256 2017-07-13 18:32:46	0|luke-jr|yeah, string freeze is to give translators time ;)
257 2017-07-13 18:33:00	0|sipa|cfields: oh?
258 2017-07-13 18:33:43	0|sipa|cfields: which field of the union does that initialize?
259 2017-07-13 18:33:51	0|cfields|sipa: the first
260 2017-07-13 18:34:35	0|sipa|cfields: go comment on the PR
261 2017-07-13 18:35:14	0|luke-jr|unions can have a ctor? :o
262 2017-07-13 18:35:51	0|sipa|luke-jr: yup, and other methods
263 2017-07-13 18:35:58	0|sipa|(but not virtual ones)
264 2017-07-13 18:36:00	0|cfields|sipa: sure. I'm not seeing the warning without the change, though.
265 2017-07-13 18:36:07	0|sipa|cfields: neither do it
266 2017-07-13 18:36:09	0|sipa|*do i
267 2017-07-13 18:48:46	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #10817: Add a discard_rate to avoid small change (06master...06discardmore) 02https://github.com/bitcoin/bitcoin/pull/10817
268 2017-07-13 18:49:21	0|morcos|gmaxwell: ^ probably too late, but was waiting on my other PR's to move forward, its still depending on 10706
269 2017-07-13 18:58:51	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10818: init: Keep track of whether data directory locked, don't cleanup if not (06master...062017_05_locked_datadir) 02https://github.com/bitcoin/bitcoin/pull/10818
270 2017-07-13 19:00:12	0|luke-jr|It is time.
271 2017-07-13 19:01:02	0|gmaxwell|Neat: luke-jr found a way to abuse the coinbase api to create a sybil resistant poll based on coinbases' KYC process: https://luke.dashjr.org/programs/kycpoll/answers.php
272 2017-07-13 19:01:20	0|petertodd|gmaxwell: nice
273 2017-07-13 19:01:29	0|achow101|meeting?
274 2017-07-13 19:01:35	0|gmaxwell|#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
275 2017-07-13 19:01:38	0|instagibbs|hi
276 2017-07-13 19:01:41	0|jonasschnelli|Hi
277 2017-07-13 19:01:41	0|lightningbot|Meeting started Thu Jul 13 19:01:40 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
278 2017-07-13 19:01:41	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
279 2017-07-13 19:01:41	0|wumpus|#startmeeting
280 2017-07-13 19:01:42	0|morcos|i'm here for 30 mins
281 2017-07-13 19:01:45	0|petertodd|hi
282 2017-07-13 19:01:52	0|luke-jr|I'm here until I pass out <.<
283 2017-07-13 19:01:59	0|jtimon|hi
284 2017-07-13 19:02:03	0|wumpus|proposed topics?
285 2017-07-13 19:02:04	0|paveljanik|hi
286 2017-07-13 19:02:20	0|achow101|possible topic: 0.15 feature freeze
287 2017-07-13 19:02:32	0|achow101|it's soon, july 16th
288 2017-07-13 19:02:40	0|cfields|hi
289 2017-07-13 19:02:44	0|jtimon|review begging as first topic ?
290 2017-07-13 19:02:49	0|wumpus|PSA: https://github.com/bitcoin/bitcoin/issues/9961, feature freeze is sunday (which is an awful day, it'll probably be monday in practice)
291 2017-07-13 19:03:20	0|wumpus|#topic high priority for review
292 2017-07-13 19:03:26	0|wumpus|#link https://github.com/bitcoin/bitcoin/projects/8
293 2017-07-13 19:03:33	0|achow101|everything marked as 0.15?
294 2017-07-13 19:03:37	0|achow101|:p
295 2017-07-13 19:03:51	0|luke-jr|we can delay the feature freeze to July 16th, 2018 to avoid a Sunday
296 2017-07-13 19:04:01	0|kanzure|hi.
297 2017-07-13 19:04:12	0|morcos|#10711 can be removed from high-priority as its not for 0.15
298 2017-07-13 19:04:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/10711 | [tests] Introduce TestNode by jnewbery · Pull Request #10711 · bitcoin/bitcoin · GitHub
299 2017-07-13 19:04:32	0|wumpus|agree with that jnewbery?
300 2017-07-13 19:04:39	0|morcos|Please add #10706 to high priority i guess, since the PR's it was depending on were merged
301 2017-07-13 19:04:41	0|gribble|https://github.com/bitcoin/bitcoin/issues/10706 | Improve wallet fee logic and fix GUI bugs by morcos · Pull Request #10706 · bitcoin/bitcoin · GitHub
302 2017-07-13 19:04:46	0|morcos|i think i asked him, but he stepped away
303 2017-07-13 19:04:57	0|jonasschnelli|I'm removing the 0.15 milestone from #10240 (will def. not make it)
304 2017-07-13 19:05:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
305 2017-07-13 19:05:05	0|sipa|jonasschnelli: no
306 2017-07-13 19:05:08	0|jtimon|since it seems #8498 cannot be priority for some reason that scapes me, what about #10757 from me ?
307 2017-07-13 19:05:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/8498 | Near-Bugfix: Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
308 2017-07-13 19:05:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
309 2017-07-13 19:05:15	0|jonasschnelli|sipa: you want that in?
310 2017-07-13 19:05:21	0|sipa|jonasschnelli: if we remove that from 0.15, we must revert the hd split
311 2017-07-13 19:05:29	0|wumpus|I tend to agree with achow101 - it's better to use the 0.15 tag now for high priority for review
312 2017-07-13 19:05:37	0|instagibbs|sipa, ?
313 2017-07-13 19:05:42	0|jonasschnelli|proposed topic then: Hd split / hd restore
314 2017-07-13 19:05:47	0|cfields|#9566 can be removed from 0.15
315 2017-07-13 19:05:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/9566 | threading: use std::chrono for timestamps by theuni · Pull Request #9566 · bitcoin/bitcoin · GitHub
316 2017-07-13 19:05:52	0|morcos|wumpus: i think its still helpful to distinguish between hope for 0.15 and really need
317 2017-07-13 19:06:01	0|wumpus|https://github.com/bitcoin/bitcoin/milestone/25
318 2017-07-13 19:06:21	0|gmaxwell|I think if we do not fix the restore we need to disable HD by default. The current situation can pretty easily lead to funds loss.
319 2017-07-13 19:06:32	0|morcos|but yes i also agree we need to clean up the 0.15 milestone list
320 2017-07-13 19:06:42	0|wumpus|cfields: bumped to 0.16
321 2017-07-13 19:06:51	0|cfields|thanks
322 2017-07-13 19:06:59	0|luke-jr|gmaxwell: that would be very confusing to users, since older versions have HD
323 2017-07-13 19:07:01	0|jnewbery|wumpus: yess please remove 10711
324 2017-07-13 19:07:12	0|jonasschnelli|I can work on the HD restrore. But It's pretty complex with pruning / encrypted wallets... the PR is already large and will get bigger...
325 2017-07-13 19:07:22	0|jonasschnelli|If there is enough review power, we can try for 0.15
326 2017-07-13 19:07:28	0|gmaxwell|E.g. just pick up a walled you'd previously saved, rescan won't move the keypool forward, and you'll end up missing transactions (then discarding wallets with money), and handing out addresses to people you already gave to other people and misattributing payments.
327 2017-07-13 19:07:29	0|jonasschnelli|I can have it overhauled by tuesday
328 2017-07-13 19:07:39	0|wumpus|jnewbery: done
329 2017-07-13 19:07:52	0|jonasschnelli|gmaxwell: Yeah.. is also true for all other wallets with gap limits of 5 (most do)
330 2017-07-13 19:07:59	0|jonasschnelli|We should def. do better
331 2017-07-13 19:08:01	0|luke-jr|can just the wallet-format-touching parts of HD restore be prioritised? eg, move out the actual restoring logic?
332 2017-07-13 19:08:22	0|sipa|jonasschnelli: this is not true for anything that automatically tops up the keypool
333 2017-07-13 19:08:29	0|jonasschnelli|What about just provide HD restore for non-pruning (to reduce the size)?
334 2017-07-13 19:08:44	0|jtimon|mhm, only #10652 in project 8...
335 2017-07-13 19:08:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
336 2017-07-13 19:09:06	0|jonasschnelli|sipa: most HD wallets in the wilde stop topping the window futher up if a gap of >5< keys where found
337 2017-07-13 19:09:16	0|sipa|jonasschnelli: yes
338 2017-07-13 19:09:20	0|gmaxwell|jonasschnelli: to that extent that thats true at least in other cases those wallets behaviors are well documented and the interfaces is built around them, they're also used almost exclusively for personal use, rather than industrial use... (and it's not completely true because if there isn't a long gap they do handling it right and we do not)
339 2017-07-13 19:09:21	0|sipa|jonasschnelli: but we don't top up at all
340 2017-07-13 19:09:39	0|jonasschnelli|sipa: Yes. Not saying that is better. :)
341 2017-07-13 19:09:48	0|sipa|jonasschnelli: and hd split makes it worse, because it risks reusing a key that was previously used as change as a payment address
342 2017-07-13 19:09:51	0|jonasschnelli|I just wanted to re-state the HD restore in general is a broken thing
343 2017-07-13 19:09:54	0|sipa|making you miss it as incoming payment
344 2017-07-13 19:10:00	0|jonasschnelli|So what should we do?
345 2017-07-13 19:10:03	0|sipa|fix it
346 2017-07-13 19:10:10	0|sipa|#10240 is a bug fix
347 2017-07-13 19:10:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
348 2017-07-13 19:10:14	0|jonasschnelli|Agree
349 2017-07-13 19:10:20	0|jonasschnelli|Okay. Then we have more time.. :)
350 2017-07-13 19:10:54	0|gmaxwell|Right now this is responsible for several serious bugs in our behavior, which regressed vs the past, and will predictable result in funds loss through several different vectors.  I don't see an easy workaround to prevent exposure-- I thought perhaps refusing to load a wallet if the tip doesn't match the chain tip, but thats too cumbersome and disruptive.
351 2017-07-13 19:10:58	0|jonasschnelli|Since we have great reviewers, .. I'm convinced we get it in
352 2017-07-13 19:11:09	0|morcos|10240 (when ready) is an example of something that should also be on high-priority...  it's going to take some review time and its important to get in  (in addition to 0.15 milestone)
353 2017-07-13 19:11:42	0|jonasschnelli|Okay. I though it not going to make it for 0.15 thats why I moved focus away.. but I see the issue now better
354 2017-07-13 19:11:50	0|jonasschnelli|*thought
355 2017-07-13 19:11:55	0|jnewbery|jonas: anything I can do to help for 10240? Would you like me to rebase it?
356 2017-07-13 19:12:03	0|wumpus|ok, will add 10240
357 2017-07-13 19:12:13	0|jonasschnelli|jnewbery: Please take over if you can
358 2017-07-13 19:12:16	0|sipa|jonasschnelli: rescanning beyond your pruning depth should already be an issue? what do we do in that case?
359 2017-07-13 19:12:22	0|jnewbery|sure. I'll take it
360 2017-07-13 19:12:22	0|morcos|achow101: what about the signrawtransaction splitting stuff, is that still aimed for 0.15?
361 2017-07-13 19:12:30	0|jonasschnelli|sipa: the PR halts validation
362 2017-07-13 19:12:35	0|gmaxwell|jnewbery: You are now my personal hero for the day.
363 2017-07-13 19:12:46	0|sipa|jonasschnelli: no, i mean right now
364 2017-07-13 19:12:54	0|sipa|what do we do if we try to rescan beyond the prune depth
365 2017-07-13 19:12:56	0|achow101|morcos: I'd like it to be. and the validateaddress stuff as that is related to #7965
366 2017-07-13 19:12:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub
367 2017-07-13 19:13:06	0|jonasschnelli|sipa: I don't know: :/
368 2017-07-13 19:13:17	0|jonasschnelli|I guess you get an expection
369 2017-07-13 19:13:46	0|sipa|so, i think pruning is not relevant for 10240
370 2017-07-13 19:13:57	0|gmaxwell|the rescan calls just say no if you try that.
371 2017-07-13 19:14:01	0|sipa|it's a problem right now if you rescan beyong the pruning depth, and it remains so
372 2017-07-13 19:14:27	0|jonasschnelli|A large part of 10240 is about haling the full node in pruning... dropping that would reduce the review workload
373 2017-07-13 19:15:22	0|jonasschnelli|So. Drop the pruning option from 10240?
374 2017-07-13 19:15:22	0|sipa|jonasschnelli: i think it should stop regardless of pruning
375 2017-07-13 19:15:31	0|sipa|it's crazy that your wallet would go out of sync with your node
376 2017-07-13 19:15:39	0|sipa|that's a totally unsupported state right now
377 2017-07-13 19:15:46	0|jonasschnelli|From the PR on encrypted wallets:
378 2017-07-13 19:15:46	0|jonasschnelli|Same as above, but, If we hit the gap limit with an encrypted wallet, we can't topup the keypool. In that case, we just pause the sync (not the node, only the wallet).
379 2017-07-13 19:15:55	0|sipa|maybe that can be enabled later, once the wallet is more independent from the node
380 2017-07-13 19:16:20	0|sipa|but i think 10240 should just stop sync entirely if your wallet is encrypted and the keypool runs out
381 2017-07-13 19:16:21	0|rhavar|Anyone familiar enough with constraint solving to help me out with this model? https://gist.github.com/RHavar/0710144c713033d42f8f443a99fefbb7
382 2017-07-13 19:16:26	0|jonasschnelli|sipa: well, if you use a backup wallet you have the same state
383 2017-07-13 19:16:29	0|sipa|rhavar: not now, meeting
384 2017-07-13 19:16:37	0|instagibbs|rhavar, ask again in 45 min :P
385 2017-07-13 19:16:41	0|sipa|jonasschnelli: at startup; not anymore after rescan
386 2017-07-13 19:16:52	0|sipa|during normal operation the wallet is always in sync with the node
387 2017-07-13 19:16:53	0|jonasschnelli|Yes. Thats true
388 2017-07-13 19:17:12	0|jonasschnelli|All that because of hardened derivation!
389 2017-07-13 19:17:28	0|sipa|it's also easy to avoid; using 10000 keys in the keypool
390 2017-07-13 19:17:37	0|gmaxwell|(indeed, which I also keep recommending)
391 2017-07-13 19:17:58	0|jonasschnelli|You don't avoid it, you just make the timespan for the possible impact smaller
392 2017-07-13 19:18:08	0|sipa|okay
393 2017-07-13 19:18:12	0|jonasschnelli|And 10000 is just inefficient
394 2017-07-13 19:18:42	0|sipa|well, i think all of that isn't the priority now
395 2017-07-13 19:18:59	0|jonasschnelli|What about only allowing non-hardened derivation for encrypted wallets and disable all pkey export calls?
396 2017-07-13 19:18:59	0|sipa|for 0.15, we need to have automatic marking of seen keys
397 2017-07-13 19:19:11	0|sipa|jonasschnelli: yes, i like that, but not 0.15
398 2017-07-13 19:19:35	0|jonasschnelli|Okay. jnewbery will focus on 10240 (he will rebase and overhaul I guess)
399 2017-07-13 19:19:48	0|gmaxwell|jonasschnelli: we have a program that requires >1GB ram, runs best with >8GB ram, that does hours of processing just to start up-- I don't think worrying about 320k of key material is a major concern.
400 2017-07-13 19:19:57	0|sipa|awesome; let's discuss further on the 10240 PR
401 2017-07-13 19:20:07	0|gmaxwell|(also 1000 works too, it 10k is really too much.)
402 2017-07-13 19:20:13	0|jonasschnelli|gmaxwell: should not be a concern. But it's still an inefficient fix for the problem we have
403 2017-07-13 19:20:26	0|jonasschnelli|sipa: ack. Thanks jnewbery
404 2017-07-13 19:20:53	0|gmaxwell|Inefficient compared to what?  Inefficient to taking away private key export? In efficient compared to even one moment of one users time?
405 2017-07-13 19:21:05	0|jnewbery|no problem. Topic suggestion: #10650
406 2017-07-13 19:21:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
407 2017-07-13 19:21:26	0|jonasschnelli|gmaxwell: Inefficient compared to support pub key derivation for encrypted keys or to topup the keypool on the fly
408 2017-07-13 19:21:54	0|gmaxwell|jonasschnelli: are you actively trying to sabotage the project?
409 2017-07-13 19:22:08	0|sipa|gmaxwell: please
410 2017-07-13 19:22:13	0|jonasschnelli|?
411 2017-07-13 19:22:23	0|sipa|jonasschnelli: there are good reasons to support hardened and unhardered derivation both; adding a feature is not a substitute for fixing a problem we have
412 2017-07-13 19:22:25	0|jonasschnelli|gmaxwell: was that a joke or a serious question?
413 2017-07-13 19:22:47	0|sipa|jonasschnelli: using non-hardened derivation implies you'll need to have a big keypool; it comes with that design choice
414 2017-07-13 19:23:20	0|gmaxwell|Sorry to be rude, but I am just gobsmacked about aruging that setting the keypool to be big "on the order of tens or hundreds of kilobytes" is opposed compared to this long saw about public derrivation; which we aren't doing for the wallet at least now.
415 2017-07-13 19:23:47	0|gmaxwell|So it seems to me like that you're intentionally in broken directions because you disagree with another decision.
416 2017-07-13 19:24:29	0|gmaxwell|er intentionally pushing in
417 2017-07-13 19:24:48	0|jonasschnelli|I though avoiding keypool with non-hardened derivation may be seen as a benefit for some of the users.. but it seems that i'm wrong. But at least it's not intentional sabotage
418 2017-07-13 19:24:50	0|morcos|let's move on from this at least duing the meeting, i think we all agree that the keypool can be bigger than 200 regardless of otehr chnages we make
419 2017-07-13 19:25:11	0|gmaxwell|Do we? it keeps getting argued against.
420 2017-07-13 19:25:23	0|morcos|thats why i ended it by saying we all agree. :)
421 2017-07-13 19:25:26	0|sipa|well, having non-hardened derivation with disabled key export is a perfectly fine _feature_ - but it's not usable for everyone (some people need key export), and for those users, we'll need to be able to deal with hardened derivation
422 2017-07-13 19:25:35	0|sipa|so let's do that
423 2017-07-13 19:25:37	0|sipa|next topic
424 2017-07-13 19:25:40	0|instagibbs|ack
425 2017-07-13 19:25:40	0|jtimon|NicolasDorier: how does #9728 interact with rescan ?
426 2017-07-13 19:25:41	0|jonasschnelli|Yes. Agree
427 2017-07-13 19:25:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/9728 | Can create Watch Only HD wallet with -hdwatchonly by NicolasDorier · Pull Request #9728 · bitcoin/bitcoin · GitHub
428 2017-07-13 19:25:57	0|instagibbs|jtimon, it doesn't do anything special for now
429 2017-07-13 19:26:13	0|instagibbs|same as hardened
430 2017-07-13 19:26:40	0|wumpus|other topics?
431 2017-07-13 19:26:53	0|morcos|jnewbery suggested 10650
432 2017-07-13 19:27:25	0|jnewbery|I think we're almost there with 10650. Only major sticking point is not having a default wallet when there are multiple wallets loaded
433 2017-07-13 19:27:26	0|jtimon|instagibbs: I see, so it kind of depends on #10240 ?
434 2017-07-13 19:27:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
435 2017-07-13 19:27:46	0|instagibbs|jtimon, we can chat offline about that after meeting
436 2017-07-13 19:27:54	0|wumpus|#topic Multiwallet: add RPC endpoint support
437 2017-07-13 19:28:00	0|jtimon|sure
438 2017-07-13 19:28:13	0|jonasschnelli|I just pushed the overhaule of 10650 that fixes the points reported by ryanofsky jnewbery and morcos
439 2017-07-13 19:28:16	0|jonasschnelli|*overhaul
440 2017-07-13 19:28:21	0|sipa|jonasschnelli: cool
441 2017-07-13 19:28:29	0|luke-jr|#10650
442 2017-07-13 19:28:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/10650 | Multiwallet: add RPC endpoint support by jonasschnelli · Pull Request #10650 · bitcoin/bitcoin · GitHub
443 2017-07-13 19:28:45	0|jnewbery|great! Will review
444 2017-07-13 19:28:50	0|jnewbery|thanks jonas
445 2017-07-13 19:29:06	0|wumpus|nice
446 2017-07-13 19:29:08	0|morcos|yes, excellent.  woo!
447 2017-07-13 19:29:22	0|luke-jr|I very much dislike passing wallet by name. That just makes the GUI side ugly
448 2017-07-13 19:29:42	0|jonasschnelli|luke-jr: you mean the selecting walltes by name?
449 2017-07-13 19:29:44	0|sipa|luke-jr: as opposed to what? (sorry, i'm not up to date)
450 2017-07-13 19:29:55	0|luke-jr|sipa: as opposed to passing a CWallet* on the JSONRPCRequest
451 2017-07-13 19:30:10	0|luke-jr|jonasschnelli: the GUI would have to go CWallet* -> string -> CWallet*
452 2017-07-13 19:30:10	0|sipa|that seems like something that's easy to change later
453 2017-07-13 19:30:14	0|luke-jr|and hope it matches the right one up
454 2017-07-13 19:30:23	0|luke-jr|sipa: I suppose, yes
455 2017-07-13 19:30:35	0|wumpus|yes, indeed, can we avoid long discussions about small details that don't matter for correctness?
456 2017-07-13 19:30:43	0|wumpus|we really want this in before the feature freeze
457 2017-07-13 19:30:47	0|wumpus|so let's be pracical about it
458 2017-07-13 19:30:49	0|gmaxwell|<3
459 2017-07-13 19:30:57	0|jonasschnelli|Yes. WalletID or similar can be done later.
460 2017-07-13 19:31:33	0|wumpus|yep
461 2017-07-13 19:32:13	0|jonasschnelli|One thing that is a bit cumbersome is that you have to remove the -wallet argument from bitcoin-cli when calling a non wallet command
462 2017-07-13 19:32:36	0|jonasschnelli|The endpoint node/wallet split is not very practical from the -cli use perspective
463 2017-07-13 19:32:42	0|wumpus|well it makes some sense
464 2017-07-13 19:32:46	0|luke-jr|hmm, bitcoin-cli reads bitcoin.conf, doesn't it? how does that interact? :/
465 2017-07-13 19:33:00	0|gmaxwell|then make the cli command handle that internally?
466 2017-07-13 19:33:18	0|gmaxwell|also, we can take some clunkyness with this expiremental feature in 0.15.
467 2017-07-13 19:33:22	0|jonasschnelli|gmaxwell: Yes. I though of that.
468 2017-07-13 19:33:24	0|gmaxwell|e.g. fix cli later.
469 2017-07-13 19:33:32	0|jonasschnelli|Yes. Sure.
470 2017-07-13 19:33:46	0|jonasschnelli|If you want to use multiwallet now, you need to add/remove -wallet when fiddling with -cli
471 2017-07-13 19:33:50	0|wumpus|IMO a clean separation between wallet and non wallet commands is good
472 2017-07-13 19:33:52	0|luke-jr|fixing cli could mean changing the -wallet= to something else
473 2017-07-13 19:33:55	0|wumpus|even if it seems cumbersome in the beginning
474 2017-07-13 19:34:04	0|luke-jr|jonasschnelli: how do yuo remove it, if it's in bitcoin.conf?
475 2017-07-13 19:34:09	0|instagibbs|luke-jr, yeah, something that means "use wallet" not "load wallet"
476 2017-07-13 19:34:13	0|jonasschnelli|Yes. Its good.
477 2017-07-13 19:34:15	0|jonasschnelli|luke-jr: ? I can't follow
478 2017-07-13 19:34:17	0|jtimon|bitcoin-cli calls with -wallet that don't need it could just ignore the extra argument and spit a warning somehwere or something?
479 2017-07-13 19:34:24	0|wumpus|I mean it'd be easy to put every non-wallet command on wallet endpoints as well, but that's something that is awfullly hard to change later
480 2017-07-13 19:34:31	0|luke-jr|jonasschnelli: typical multiwallet use case has wallet=abc.db \n wallet=def.db in bitcoin.conf
481 2017-07-13 19:34:36	0|sipa|jonasschnelli: there are a bunch of things that the wallet - even after separation - will need access to (like fee estimates, mempool, ...)... i think it's fine if those remain inside the v1/wallet API (and also accessible as node commands)
482 2017-07-13 19:34:38	0|jonasschnelli|wait.. that's actually a good point!
483 2017-07-13 19:34:43	0|luke-jr|jonasschnelli: bitcoin-cli will get these options too.
484 2017-07-13 19:34:55	0|jonasschnelli|Yes.. haven't tested that. :/
485 2017-07-13 19:35:14	0|luke-jr|instagibbs's -usewallet or similar seems like a good solution
486 2017-07-13 19:35:16	0|instagibbs|it likely takes the first wallet arg and uses that
487 2017-07-13 19:35:29	0|jonasschnelli|Yes. I think -usewallet is better
488 2017-07-13 19:35:41	0|sipa|so i think i may agree with having pretty much everything available through the wallet endpoint
489 2017-07-13 19:35:44	0|instagibbs|luke-jr, something like that, if it's not complicating something else
490 2017-07-13 19:35:48	0|sipa|(but not getinfo) *ducks*
491 2017-07-13 19:36:23	0|gmaxwell|It's an expiremental feature, API isn't table. The endpoint can be leaky for now.
492 2017-07-13 19:36:27	0|luke-jr|it's also easier to collapse args later than to split them, if we end up regretting it
493 2017-07-13 19:36:32	0|jonasschnelli|I guess we can leave it for now we just need to mark the /v1 *EXPERIMENTAL* in the release notes
494 2017-07-13 19:36:36	0|instagibbs|yes please
495 2017-07-13 19:36:42	0|sipa|ack
496 2017-07-13 19:36:45	0|gmaxwell|s/table/stable/
497 2017-07-13 19:37:04	0|gmaxwell|And I think the alternative is to not have it at all, which isn't preferable.
498 2017-07-13 19:37:06	0|wumpus|should do that anyway
499 2017-07-13 19:37:15	0|wumpus|absolutely
500 2017-07-13 19:37:42	0|wumpus|as long as it doesn't cause regressions for single-wallet mode
501 2017-07-13 19:38:13	0|wumpus|that would be unacceptable - but everything new is experimental
502 2017-07-13 19:38:55	0|sipa|agree
503 2017-07-13 19:39:26	0|jonasschnelli|I guess user feedback will also help us how to extend this further
504 2017-07-13 19:39:49	0|wumpus|indeed
505 2017-07-13 19:40:26	0|jonasschnelli|But once 10650 is in, we have finally usable multiwallet in Core! That's a big step.
506 2017-07-13 19:40:31	0|sipa|jonasschnelli: it is!
507 2017-07-13 19:40:45	0|jonasschnelli|And it wasn't the first try.
508 2017-07-13 19:41:20	0|wumpus|hehe multiwallet slipped so many releases it's a shame
509 2017-07-13 19:41:23	0|jtimon|yeah, is a nice feature to anounce in 0.15, even if as experimental
510 2017-07-13 19:42:18	0|sipa|just to repeat some other happy results briefly: my reindex-chainstate to 450k with infinity dbcache runs about 40% faster on master than on 0.14.2
511 2017-07-13 19:42:41	0|petertodd|sipa: what do you mean by "infinity dbcache"?
512 2017-07-13 19:42:42	0|jtimon|wow
513 2017-07-13 19:42:43	0|wumpus|which reminds me, someone should really write a release notes section about all the wonderful perf improvements in 0.15
514 2017-07-13 19:43:00	0|sipa|petertodd: dbcache sufficient for the entire utxo sets
515 2017-07-13 19:43:03	0|gmaxwell|wumpus: I've already been talking to drak about some blog posts and whatnot on it.
516 2017-07-13 19:43:06	0|wumpus|everything from crc instruction support in leveldb to the new and better database formats, to faster validation, etc
517 2017-07-13 19:43:22	0|petertodd|sipa: ah, cool!
518 2017-07-13 19:43:27	0|sipa|wumpus: don't forget tx validation caching; that's massive for performance at the tip
519 2017-07-13 19:43:32	0|instagibbs|^
520 2017-07-13 19:43:45	0|wumpus|sipa: +1
521 2017-07-13 19:43:47	0|sipa|(just somewhat harder to benchmark and give cool numbers for)
522 2017-07-13 19:44:30	0|sipa|petertodd: around 6-8GB in 0.15, in practice (and more in 0.14.2, due to the blowup at flushing time)
523 2017-07-13 19:44:48	0|petertodd|sipa: that's still pretty small fortunately :)
524 2017-07-13 19:45:07	0|gmaxwell|Was 2GB not that long ago.
525 2017-07-13 19:45:37	0|petertodd|gmaxwell: be interesting to know why UTXO growth has stopped temporarily...
526 2017-07-13 19:46:27	0|sipa|if you know, post it here: https://bitcoin.stackexchange.com/questions/56513/why-has-utxo-set-stopped-growing-since-2017-06-03
527 2017-07-13 19:46:30	0|instagibbs|(total size has been shrinking for a month now)
528 2017-07-13 19:47:14	0|petertodd|could easily be someone ran out of money for an attack, and is spending the coins again
529 2017-07-13 19:47:57	0|wumpus|#link https://bitcoin.stackexchange.com/questions/56513/why-has-utxo-set-stopped-growing-since-2017-06-03
530 2017-07-13 19:49:07	0|wumpus|any other topics?
531 2017-07-13 19:49:08	0|jtimon|many more possible explanations...
532 2017-07-13 19:49:25	0|luke-jr|maybe a reminder that Tokyo Core is in a few weeks
533 2017-07-13 19:50:21	0|instagibbs|2 weeks specifically
534 2017-07-13 19:50:55	0|luke-jr|https://coredev.tech/tokyo.html lots of unconfirmed invites still
535 2017-07-13 19:51:26	0|instagibbs|kind of a hike for those not already in area for other reasons
536 2017-07-13 19:51:30	0|jtimon|oh, missed that one, I guess I can confirm now I'm not attending
537 2017-07-13 19:51:30	0|wumpus|I'm not coming to tokyo core, but will be in the SF one in september
538 2017-07-13 19:51:41	0|sipa|wumpus: great!
539 2017-07-13 19:51:53	0|jonasschnelli|SF is pretty full booked..
540 2017-07-13 19:52:13	0|jonasschnelli|Not saying we running out of space, but >20 confirmed
541 2017-07-13 19:52:34	0|wumpus|sipa: you're coming too? great
542 2017-07-13 19:52:54	0|sipa|wumpus: yes, of course
543 2017-07-13 19:53:08	0|sipa|(i live nearby)
544 2017-07-13 19:53:11	0|achow101|do we have a location for the sf meetup?
545 2017-07-13 19:54:06	0|luke-jr|achow101: https://coredev.tech/nextmeeting.html
546 2017-07-13 19:54:08	0|wumpus|yes, but it's still possible it will change
547 2017-07-13 19:55:10	0|wumpus|depending on just how large the room needs to be I guess :-)
548 2017-07-13 19:55:29	0|instagibbs|will we finally activate segwit there? *ducks*
549 2017-07-13 19:55:40	0|rhavar|petertodd: the day it stopped growing is the day alphabay shut down
550 2017-07-13 19:55:52	0|luke-jr|instagibbs: it'll already be active by then
551 2017-07-13 19:56:01	0|achow101|luke-jr: hopefully
552 2017-07-13 19:56:03	0|petertodd|rhavar: interesting!
553 2017-07-13 19:56:13	0|instagibbs|rhavar, ? what date did it go down
554 2017-07-13 19:56:22	0|rhavar|the 3rd i think
555 2017-07-13 19:56:47	0|instagibbs|been holding/dropping since 3rd of June though
556 2017-07-13 19:56:59	0|instagibbs|might be contributing factor still..
557 2017-07-13 19:57:10	0|instagibbs|sorry, is meeting done
558 2017-07-13 19:57:11	0|rhavar|oh, sorry -- I'm a month off
559 2017-07-13 19:57:12	0|instagibbs|3 minutes
560 2017-07-13 19:57:25	0|rhavar|alphabay shut down the 3rd of july
561 2017-07-13 19:57:33	0|rhavar|and that question was 3rd of june
562 2017-07-13 19:57:52	0|instagibbs|my SWAG: I think internalizing customer transaction costs did the equiv of fees for exchange trading in China
563 2017-07-13 19:58:07	0|wumpus|seems time to end the meeting, speculation about the reason for the stop of utxo growth is interesting but not a bitcoin core meeting topic
564 2017-07-13 19:58:09	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-13-19.01.log.html
565 2017-07-13 19:58:09	0|lightningbot|Meeting ended Thu Jul 13 19:58:08 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
566 2017-07-13 19:58:09	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-13-19.01.html
567 2017-07-13 19:58:09	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-07-13-19.01.txt
568 2017-07-13 19:58:09	0|wumpus|#endmeeting
569 2017-07-13 19:58:50	0|rhavar|So anyway, anyone familiar with constraint solving (and minizinc in particular)? https://gist.github.com/RHavar/0710144c713033d42f8f443a99fefbb7
570 2017-07-13 19:59:02	0|rhavar|That model works, just give shit results
571 2017-07-13 19:59:12	0|sipa|in a previous life, i've used minizinc
572 2017-07-13 19:59:49	0|rhavar|Since the ideal solution is blindly obvious, can you can convince minizinc to pick it `constraint count_selected_optional_outputs = 1;`
573 2017-07-13 19:59:57	0|rhavar|But it doesn't find it on it's own
574 2017-07-13 20:00:14	0|rhavar|But it shows that the ideal solution doesn't violate any constraints (and has a lower cost than the one it picks)
575 2017-07-13 20:00:29	0|rhavar|I'm kind of wondering if the problem is just formatted in a stupid way or not
576 2017-07-13 20:01:55	0|rhavar|(in general, I can pretty much always out-perform that model by hand. Makes me think something is seriously fundamentally screwed up)
577 2017-07-13 20:01:57	0|jtimon|one could also argue that simply usage has been reduced in fear of a possible fork
578 2017-07-13 20:02:22	0|rhavar|I got like 10-15 emails yesterday from people freaking out after the bitcoin.org notice lolz ><
579 2017-07-13 20:04:15	0|rhavar|(which imo was reckless and alarmist. If they did enough mental gymnastics to convince themselves that bip148 would split the chain, they should have at least waited to be sure that segwit2x isn't going to activate in time)
580 2017-07-13 20:04:18	0|jtimon|I guess that further disproves the argument that "people that will support uasf already know about bip148 already know about it and already 'upgraded', waiting for bip149 won't result in more people or businesses on board"
581 2017-07-13 20:04:24	0|jtimon|sorry, getting offtopic...
582 2017-07-13 20:05:02	0|rhavar|For every 1 person who understands the technical details of forks and chain splits etc. there are 1000 who don't
583 2017-07-13 20:05:49	0|clarkmoody|rhavar I've done some constrained optimization stuff, but never with minizinc
584 2017-07-13 20:06:29	0|clarkmoody|I've found that you can make a constraint solver do anything you like depending on the objective function
585 2017-07-13 20:06:53	0|rhavar|If you can see why that model doesn't pick the obvious solution (the one you can force it to), I'd be happy to give you a $100 in bitcoin or something :P
586 2017-07-13 20:07:58	0|rhavar|(It's obviously really easy to hack it, so it picks the obvious solution. But i'm more interested to why it sucks in general, like if the problem is phrased badly or something)
587 2017-07-13 20:14:06	0|clarkmoody|Could you enumerate the combinations and print cost for each, then see where on the scale the solver is choosing? Like is it the worst, or near the best, etc?
588 2017-07-13 20:20:15	0|rhavar|Well in this simple example, it's the 2nd best solution or something
589 2017-07-13 20:20:34	0|rhavar|but considering it's a trivial example that you can do by hand in under a minute -- i think it's pretty embarrassing :P
590 2017-07-13 20:21:22	0|clarkmoody|I know the feeling :-)
591 2017-07-13 20:21:54	0|rhavar|There's also cases it say are not solvable, that are trivial  (pick all the inputs, for instance)
592 2017-07-13 20:22:16	0|rhavar|I actually have had some moderate success by splitting the model into two different problems (1 pick coins without change) and 1 pick coins always using change
593 2017-07-13 20:22:20	0|rhavar|and then compare which is better
594 2017-07-13 20:22:45	0|rhavar|But I feel like there must be something wrong at a more fundamental level if you need to do that
595 2017-07-13 20:32:18	0|jtimon|can someone close https://github.com/bitcoin/bitcoin/pull/10768 ? the author said it but for some reason didn't closed it himself
596 2017-07-13 20:32:57	0|jtimon|wait, #10714 didn't solved the warning...
597 2017-07-13 20:32:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/10714 | Avoid printing incorrect block indexing time due to uninitialized variable by practicalswift · Pull Request #10714 · bitcoin/bitcoin · GitHub
598 2017-07-13 20:38:59	0|jtimon|oh, yes, it does, sorry
599 2017-07-13 20:55:52	0|instagibbs|what could cause "no response from server"? It connects but gets no response?
600 2017-07-13 21:13:03	0|instagibbs|oh, likely my -cli not matching bitcoind (testing multiwallet endpoints)
601 2017-07-13 21:16:39	0|instagibbs|jonasschnelli, it seems I get "trapped" if I specify a wallet in my conf file, unable to use -cli to stop the node, complains that the call is trying to use a /node/ endpoint call
602 2017-07-13 21:17:05	0|instagibbs|so yeah we really need something other than "wallet" for -cli usage
603 2017-07-13 21:24:17	0|jtimon|do we have a list of new rpc calls so far for 0.15 ?
604 2017-07-13 22:32:21	0|bitcoin-git|[13bitcoin] 15promag opened pull request #10819: Fix uninitialized atomic variables (06master...062017-07-fix-unitialized-atomic) 02https://github.com/bitcoin/bitcoin/pull/10819
605 2017-07-13 22:52:46	0|promag|I got this output: Fee Calculation: Fee:4520 Bytes:226 Tgt:6 (requested 6) Reason:"Fallback fee" Decay 0.00000: Estimation: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out) Fail: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out)
606 2017-07-13 22:53:34	0|promag|buggy output right?
607 2017-07-13 23:44:01	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10820: Use cpuid intrinsics instead of asm code (06master...0620170717_cpuid) 02https://github.com/bitcoin/bitcoin/pull/10820