1 2017-06-22T00:06:19  *** chjj has joined #bitcoin-core-dev
  2 2017-06-22T00:11:49  <sipa> jonasschnelli: https://github.com/sipa/bitcoin/commits/progress
  3 2017-06-22T00:11:52  *** neel has joined #bitcoin-core-dev
  4 2017-06-22T00:12:34  <sipa> jonasschnelli: you were just returning from Upgrade without shutting down... no wonder you get a corruption :)
  5 2017-06-22T00:15:24  *** jamesob has joined #bitcoin-core-dev
  6 2017-06-22T00:16:10  *** unholymachine has quit IRC
  7 2017-06-22T00:16:26  *** unholymachine has joined #bitcoin-core-dev
  8 2017-06-22T00:16:33  *** neel has quit IRC
  9 2017-06-22T00:19:30  *** jamesob has quit IRC
 10 2017-06-22T00:44:21  *** Giszmo has joined #bitcoin-core-dev
 11 2017-06-22T01:02:35  *** Ylbam has quit IRC
 12 2017-06-22T01:10:07  *** goatpig has joined #bitcoin-core-dev
 13 2017-06-22T01:14:10  *** Dyaheon has quit IRC
 14 2017-06-22T01:16:08  *** Dyaheon has joined #bitcoin-core-dev
 15 2017-06-22T01:22:20  *** marcoagn1 has quit IRC
 16 2017-06-22T01:34:14  *** marcoagn1 has joined #bitcoin-core-dev
 17 2017-06-22T01:58:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 18 2017-06-22T01:59:17  *** neel has joined #bitcoin-core-dev
 19 2017-06-22T02:00:50  *** echonaut has quit IRC
 20 2017-06-22T02:01:03  *** echonaut3 has joined #bitcoin-core-dev
 21 2017-06-22T02:05:00  *** neel has quit IRC
 22 2017-06-22T02:13:48  *** Chris_Stewart_5 has quit IRC
 23 2017-06-22T02:28:34  *** dabura667 has joined #bitcoin-core-dev
 24 2017-06-22T02:29:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 25 2017-06-22T02:44:33  *** jamesob has joined #bitcoin-core-dev
 26 2017-06-22T03:26:37  *** nemgun has quit IRC
 27 2017-06-22T03:41:18  *** Chris_Stewart_5 has quit IRC
 28 2017-06-22T03:44:46  *** justan0theruser has joined #bitcoin-core-dev
 29 2017-06-22T03:45:16  *** justan0theruser has joined #bitcoin-core-dev
 30 2017-06-22T03:46:27  *** justanotheruser has quit IRC
 31 2017-06-22T04:11:59  *** imposter has joined #bitcoin-core-dev
 32 2017-06-22T04:23:18  *** marcoagn1 has quit IRC
 33 2017-06-22T04:34:46  *** marcoagn1 has joined #bitcoin-core-dev
 34 2017-06-22T04:39:26  *** randy-waterhouse has joined #bitcoin-core-dev
 35 2017-06-22T04:42:09  *** sogo has joined #bitcoin-core-dev
 36 2017-06-22T05:00:00  *** imposter has quit IRC
 37 2017-06-22T05:01:11  *** jamesob has quit IRC
 38 2017-06-22T05:01:44  *** jamesob has joined #bitcoin-core-dev
 39 2017-06-22T05:06:00  *** jamesob has quit IRC
 40 2017-06-22T05:10:54  *** sogo has quit IRC
 41 2017-06-22T05:26:33  *** randy-waterhouse has quit IRC
 42 2017-06-22T05:40:03  *** paveljanik has quit IRC
 43 2017-06-22T05:53:53  *** CubicEarth has joined #bitcoin-core-dev
 44 2017-06-22T05:57:12  *** Deadhand has quit IRC
 45 2017-06-22T05:58:02  *** Deadhand has joined #bitcoin-core-dev
 46 2017-06-22T06:02:45  <jonasschnelli> sipa: okay. I see. :/
 47 2017-06-22T06:22:46  *** CubicEarth has quit IRC
 48 2017-06-22T06:40:12  *** vicenteH has quit IRC
 49 2017-06-22T06:40:31  *** vicenteH has joined #bitcoin-core-dev
 50 2017-06-22T06:47:14  *** Ylbam has joined #bitcoin-core-dev
 51 2017-06-22T06:49:22  *** JackH has joined #bitcoin-core-dev
 52 2017-06-22T07:00:08  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10649: Make sure we only mine via the first wallet (master...2017/06/wallet_generate) https://github.com/bitcoin/bitcoin/pull/10649
 53 2017-06-22T07:01:10  *** neel has joined #bitcoin-core-dev
 54 2017-06-22T07:05:35  *** neel has quit IRC
 55 2017-06-22T07:16:07  *** neel has joined #bitcoin-core-dev
 56 2017-06-22T07:27:53  *** cheese_ has quit IRC
 57 2017-06-22T07:38:04  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #10650: Multiwallet: add RPC endpoint support (master...2017/06/wallet_rpc_endpoint) https://github.com/bitcoin/bitcoin/pull/10650
 58 2017-06-22T07:46:02  *** d9b4bef9 has quit IRC
 59 2017-06-22T07:47:07  *** d9b4bef9 has joined #bitcoin-core-dev
 60 2017-06-22T07:49:16  *** neel has quit IRC
 61 2017-06-22T07:51:28  *** neel has joined #bitcoin-core-dev
 62 2017-06-22T08:01:07  *** neel has quit IRC
 63 2017-06-22T08:23:19  *** ryanku___ has joined #bitcoin-core-dev
 64 2017-06-22T08:25:25  *** ryankung_ has joined #bitcoin-core-dev
 65 2017-06-22T08:28:19  *** ryanku___ has quit IRC
 66 2017-06-22T08:29:27  *** Guyver2 has joined #bitcoin-core-dev
 67 2017-06-22T08:34:27  *** ryankung_ has quit IRC
 68 2017-06-22T08:34:57  *** ryankun__ has joined #bitcoin-core-dev
 69 2017-06-22T08:39:11  *** ryankung_ has joined #bitcoin-core-dev
 70 2017-06-22T08:40:16  *** neel has joined #bitcoin-core-dev
 71 2017-06-22T08:41:38  *** neel has quit IRC
 72 2017-06-22T08:41:56  *** Dyaheon has quit IRC
 73 2017-06-22T08:42:46  *** Dyaheon has joined #bitcoin-core-dev
 74 2017-06-22T08:43:06  *** neel has joined #bitcoin-core-dev
 75 2017-06-22T08:53:31  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d083bd9b9c52...c68a9a69278a
 76 2017-06-22T08:53:32  <bitcoin-git> bitcoin/master 5555fa8 MarcoFalke: qa: Add stopatheight test
 77 2017-06-22T08:53:32  <bitcoin-git> bitcoin/master c68a9a6 MarcoFalke: Merge #10632: qa: Add stopatheight test...
 78 2017-06-22T08:54:03  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10632: qa: Add stopatheight test (master...Mf1706-qaStopAtHeight) https://github.com/bitcoin/bitcoin/pull/10632
 79 2017-06-22T09:01:14  *** riemann has joined #bitcoin-core-dev
 80 2017-06-22T09:09:04  *** timothy has joined #bitcoin-core-dev
 81 2017-06-22T09:18:31  *** neel has quit IRC
 82 2017-06-22T09:24:45  *** neel has joined #bitcoin-core-dev
 83 2017-06-22T09:25:05  *** arubi has quit IRC
 84 2017-06-22T09:25:13  *** neel has joined #bitcoin-core-dev
 85 2017-06-22T09:30:19  *** arubi has joined #bitcoin-core-dev
 86 2017-06-22T09:50:10  *** neel has quit IRC
 87 2017-06-22T09:51:42  *** neel has joined #bitcoin-core-dev
 88 2017-06-22T09:59:31  *** neel has quit IRC
 89 2017-06-22T10:02:46  *** neel has joined #bitcoin-core-dev
 90 2017-06-22T10:05:04  *** luke-jr has quit IRC
 91 2017-06-22T10:07:16  *** neel has quit IRC
 92 2017-06-22T10:10:48  *** neel has joined #bitcoin-core-dev
 93 2017-06-22T10:13:29  *** JackH has quit IRC
 94 2017-06-22T10:13:46  *** luke-jr has joined #bitcoin-core-dev
 95 2017-06-22T10:27:23  *** JackH has joined #bitcoin-core-dev
 96 2017-06-22T11:00:32  *** Dyaheon has quit IRC
 97 2017-06-22T11:03:56  *** Dyaheon has joined #bitcoin-core-dev
 98 2017-06-22T11:06:29  *** neel has quit IRC
 99 2017-06-22T11:12:04  *** ryankung_ has quit IRC
100 2017-06-22T11:21:49  *** laurentmt has joined #bitcoin-core-dev
101 2017-06-22T11:24:28  *** laurentmt has quit IRC
102 2017-06-22T11:46:05  *** Alina-malina has quit IRC
103 2017-06-22T12:01:50  *** Alina-malina has joined #bitcoin-core-dev
104 2017-06-22T12:05:40  *** JackH has quit IRC
105 2017-06-22T12:06:17  *** dabura667 has quit IRC
106 2017-06-22T12:07:40  *** neel has joined #bitcoin-core-dev
107 2017-06-22T12:08:22  *** riemann has quit IRC
108 2017-06-22T12:09:10  *** gill3s has joined #bitcoin-core-dev
109 2017-06-22T12:13:05  *** neel has quit IRC
110 2017-06-22T12:17:12  *** neel has joined #bitcoin-core-dev
111 2017-06-22T12:17:41  *** riemann has joined #bitcoin-core-dev
112 2017-06-22T12:25:17  *** gill3s has quit IRC
113 2017-06-22T12:32:17  *** Void_ has joined #bitcoin-core-dev
114 2017-06-22T12:39:25  *** marcoagn1 has quit IRC
115 2017-06-22T12:41:32  *** marcoagn1 has joined #bitcoin-core-dev
116 2017-06-22T12:44:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
117 2017-06-22T12:47:37  *** marcoagn1 has quit IRC
118 2017-06-22T12:51:06  *** marcoagn1 has joined #bitcoin-core-dev
119 2017-06-22T12:56:05  *** Void_ is now known as pvoid
120 2017-06-22T12:56:45  *** pvoid is now known as random
121 2017-06-22T13:04:33  *** neel has quit IRC
122 2017-06-22T13:04:34  *** laurentmt has joined #bitcoin-core-dev
123 2017-06-22T13:17:10  *** vicenteH` has joined #bitcoin-core-dev
124 2017-06-22T13:17:16  *** vicenteH has quit IRC
125 2017-06-22T13:29:01  *** neel_ has joined #bitcoin-core-dev
126 2017-06-22T13:32:00  *** ProfMac has quit IRC
127 2017-06-22T13:32:25  *** jannes has joined #bitcoin-core-dev
128 2017-06-22T13:44:45  *** Alina-malina has quit IRC
129 2017-06-22T13:44:46  *** Alina-malina has joined #bitcoin-core-dev
130 2017-06-22T13:53:25  *** Cheeseo has joined #bitcoin-core-dev
131 2017-06-22T13:53:33  *** laurentmt has quit IRC
132 2017-06-22T13:54:29  *** cheese_ has joined #bitcoin-core-dev
133 2017-06-22T13:57:50  *** Cheeseo has quit IRC
134 2017-06-22T14:03:00  *** Dyaheon has quit IRC
135 2017-06-22T14:05:12  *** Dyaheon has joined #bitcoin-core-dev
136 2017-06-22T14:11:57  *** Char0n has quit IRC
137 2017-06-22T14:12:04  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c68a9a69278a...1d991f6f18df
138 2017-06-22T14:12:04  <bitcoin-git> bitcoin/master 700d8d8 practicalswift: Remove obsolete _MSC_VER check...
139 2017-06-22T14:12:05  <bitcoin-git> bitcoin/master 1d991f6 Wladimir J. van der Laan: Merge #10642: Remove obsolete _MSC_VER check...
140 2017-06-22T14:12:49  <bitcoin-git> [bitcoin] laanwj closed pull request #10642: Remove obsolete _MSC_VER check (master...undefined-msc-ver) https://github.com/bitcoin/bitcoin/pull/10642
141 2017-06-22T14:21:00  *** To7 has joined #bitcoin-core-dev
142 2017-06-22T14:21:10  *** chjj has quit IRC
143 2017-06-22T14:26:48  *** morcos has quit IRC
144 2017-06-22T14:27:27  *** jnewbery_ has quit IRC
145 2017-06-22T14:27:30  *** sdaftuar has quit IRC
146 2017-06-22T14:27:44  *** zxzzt has quit IRC
147 2017-06-22T14:28:50  *** morcos has joined #bitcoin-core-dev
148 2017-06-22T14:29:19  *** zxzzt has joined #bitcoin-core-dev
149 2017-06-22T14:29:26  *** sdaftuar has joined #bitcoin-core-dev
150 2017-06-22T14:29:26  *** sdaftuar has joined #bitcoin-core-dev
151 2017-06-22T14:29:36  *** jnewbery has joined #bitcoin-core-dev
152 2017-06-22T14:31:06  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1d991f6f18df...8465b68985f4
153 2017-06-22T14:31:07  <bitcoin-git> bitcoin/master 2c3fc51 fanquake: [depends] expat 2.2.1
154 2017-06-22T14:31:07  <bitcoin-git> bitcoin/master 8465b68 Wladimir J. van der Laan: Merge #10628: [depends] expat 2.2.1...
155 2017-06-22T14:31:54  <bitcoin-git> [bitcoin] laanwj closed pull request #10628: [depends] expat 2.2.1 (master...expat-2-2-1) https://github.com/bitcoin/bitcoin/pull/10628
156 2017-06-22T14:32:40  *** Char0n has joined #bitcoin-core-dev
157 2017-06-22T14:33:46  <sdaftuar> sipa: i've finished my functional test for #10148 -- https://github.com/sdaftuar/bitcoin/tree/test-10148
158 2017-06-22T14:33:50  <gribble> https://github.com/bitcoin/bitcoin/issues/10148 | Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub
159 2017-06-22T14:47:12  *** neel_ has quit IRC
160 2017-06-22T14:49:05  *** neel has joined #bitcoin-core-dev
161 2017-06-22T14:57:00  *** riemann has quit IRC
162 2017-06-22T15:04:20  <bitcoin-git> [bitcoin] laanwj closed pull request #10541: Docs:  Update INSTALL.md to add link to build notes (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10541
163 2017-06-22T15:10:37  *** echonaut3 has quit IRC
164 2017-06-22T15:10:48  *** echonaut has joined #bitcoin-core-dev
165 2017-06-22T15:17:02  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8465b68985f4...87e69c2549c4
166 2017-06-22T15:17:02  <bitcoin-git> bitcoin/master e5c6168 Pavlos Antoniou: Fix instantiation and array accesses in class base_uint<BITS>...
167 2017-06-22T15:17:03  <bitcoin-git> bitcoin/master 87e69c2 Wladimir J. van der Laan: Merge #10530: Fix invalid instantiation and possibly unsafe accesses of array in class base_uint<BITS>...
168 2017-06-22T15:17:43  <bitcoin-git> [bitcoin] laanwj closed pull request #10530: Fix invalid instantiation and possibly unsafe accesses of array in class base_uint<BITS> (master...master) https://github.com/bitcoin/bitcoin/pull/10530
169 2017-06-22T15:20:07  *** rafalcpp has quit IRC
170 2017-06-22T15:20:53  *** rafalcpp has joined #bitcoin-core-dev
171 2017-06-22T15:31:02  *** neel has quit IRC
172 2017-06-22T15:37:41  *** neel has joined #bitcoin-core-dev
173 2017-06-22T15:39:52  *** neel has quit IRC
174 2017-06-22T15:43:14  *** laurentmt has joined #bitcoin-core-dev
175 2017-06-22T15:43:41  *** laurentmt has quit IRC
176 2017-06-22T15:44:04  <bitcoin-git> [bitcoin] laanwj closed pull request #8831: Replace CWalletDB::ReadKeyValue with CWallet::LoadKeyValue (master...2016-09-28-cwallet-loadkeyvalue) https://github.com/bitcoin/bitcoin/pull/8831
177 2017-06-22T15:44:53  *** Dizzle has joined #bitcoin-core-dev
178 2017-06-22T15:45:48  *** abpa has joined #bitcoin-core-dev
179 2017-06-22T15:46:25  *** arubi has quit IRC
180 2017-06-22T15:51:56  *** arubi has joined #bitcoin-core-dev
181 2017-06-22T15:57:41  *** neel has joined #bitcoin-core-dev
182 2017-06-22T16:01:23  *** laurentmt has joined #bitcoin-core-dev
183 2017-06-22T16:08:00  *** neel has quit IRC
184 2017-06-22T16:09:16  *** neel has joined #bitcoin-core-dev
185 2017-06-22T16:11:05  *** nelruk has joined #bitcoin-core-dev
186 2017-06-22T16:17:36  *** Guyver2_ has joined #bitcoin-core-dev
187 2017-06-22T16:19:57  *** def has joined #bitcoin-core-dev
188 2017-06-22T16:20:15  <earlz> Why is CheckTransaction in CheckBlock just a normal rejection and not a DoS rejection? Is there some valid case where CheckTransaction can fail and it not be a malicious actor?
189 2017-06-22T16:20:37  *** Guyver2 has quit IRC
190 2017-06-22T16:20:40  *** Guyver2_ is now known as Guyver2
191 2017-06-22T16:23:31  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/87e69c2549c4...209eef60a9ac
192 2017-06-22T16:23:31  <bitcoin-git> bitcoin/master 6171826 Alex Morcos: Don't create change at the dust limit, even if it means paying more than expected
193 2017-06-22T16:23:32  <bitcoin-git> bitcoin/master 209eef6 Wladimir J. van der Laan: Merge #9343: Don't create change at dust limit...
194 2017-06-22T16:23:41  <sipa> earlz: yes!
195 2017-06-22T16:23:43  <bitcoin-git> [bitcoin] laanwj closed pull request #9343: Don't create change at dust limit (master...noneconomicchange) https://github.com/bitcoin/bitcoin/pull/9343
196 2017-06-22T16:23:46  <sipa> soft forks
197 2017-06-22T16:24:03  <sipa> earlz: the peer may not be aware of a softfork that you are aware of
198 2017-06-22T16:25:13  <def> https://0x0.st/lFn.txt <- i can't get signrawtransaction to work, any ideas? i know this isn't a support channel but i'm becoming increasingly convinced that this might be a bug in bitcoin-qt
199 2017-06-22T16:33:29  *** nelruk has quit IRC
200 2017-06-22T16:34:00  <sipa> def: can you show the output you are trying to spend?
201 2017-06-22T16:35:43  <earlz> ah, didn't think about softforks
202 2017-06-22T16:35:48  *** CryptoAna has joined #bitcoin-core-dev
203 2017-06-22T16:38:44  *** nelruk has joined #bitcoin-core-dev
204 2017-06-22T16:38:53  *** neel has joined #bitcoin-core-dev
205 2017-06-22T16:39:40  *** neel has quit IRC
206 2017-06-22T16:43:23  *** CryptoAna has quit IRC
207 2017-06-22T16:46:05  *** nelruk has quit IRC
208 2017-06-22T16:50:24  *** nelruk has joined #bitcoin-core-dev
209 2017-06-22T16:54:59  *** nelruk has quit IRC
210 2017-06-22T17:00:28  *** timothy has quit IRC
211 2017-06-22T17:00:32  *** nelruk has joined #bitcoin-core-dev
212 2017-06-22T17:07:03  *** nelruk has quit IRC
213 2017-06-22T17:10:19  *** nelruk has joined #bitcoin-core-dev
214 2017-06-22T17:16:57  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/209eef60a9ac...ffce893982d9
215 2017-06-22T17:16:58  <bitcoin-git> bitcoin/master fd369d2 Kalle Alm: Switched httpserver.cpp to use RAII wrapped libevents.
216 2017-06-22T17:16:59  <bitcoin-git> bitcoin/master 1ae86ec Karl-Johan Alm: Changed event RAII helper functions to inline to deal with duplicate symbol linker errors.
217 2017-06-22T17:16:59  <bitcoin-git> bitcoin/master ffce893 Wladimir J. van der Laan: Merge #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents....
218 2017-06-22T17:17:08  <bitcoin-git> [bitcoin] laanwj closed pull request #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents. (master...raii-httpserver) https://github.com/bitcoin/bitcoin/pull/9517
219 2017-06-22T17:17:59  *** nelruk has quit IRC
220 2017-06-22T17:20:06  *** nelruk has joined #bitcoin-core-dev
221 2017-06-22T17:27:53  *** nelruk has quit IRC
222 2017-06-22T17:30:46  *** nelruk has joined #bitcoin-core-dev
223 2017-06-22T17:33:31  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ffce893982d9...b750b33c3cea
224 2017-06-22T17:33:31  <bitcoin-git> bitcoin/master 8d4dafd Andres G. Aragoneses: contrib/verifybinaries: allow filtering by platform...
225 2017-06-22T17:33:32  <bitcoin-git> bitcoin/master b750b33 Wladimir J. van der Laan: Merge #10276: contrib/verifybinaries: allow filtering by platform...
226 2017-06-22T17:33:51  <bitcoin-git> [bitcoin] laanwj closed pull request #10276: contrib/verifybinaries: allow filtering by platform (master...filterByPlatformInVerifySh) https://github.com/bitcoin/bitcoin/pull/10276
227 2017-06-22T17:46:19  *** gaf_ has quit IRC
228 2017-06-22T17:51:04  *** gaf_ has joined #bitcoin-core-dev
229 2017-06-22T17:54:59  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b750b33c3cea...01c4b143a87e
230 2017-06-22T17:54:59  <bitcoin-git> bitcoin/master cf68a48 Pieter Wuille: Deduplicate addrdb.cpp and use CHashWriter/Verifier
231 2017-06-22T17:55:00  <bitcoin-git> bitcoin/master 01c4b14 Wladimir J. van der Laan: Merge #10248: Rewrite addrdb with less duplication using CHashVerifier...
232 2017-06-22T17:55:24  <bitcoin-git> [bitcoin] laanwj closed pull request #10248: Rewrite addrdb with less duplication using CHashVerifier (master...chashverifier) https://github.com/bitcoin/bitcoin/pull/10248
233 2017-06-22T17:59:18  *** paveljanik has joined #bitcoin-core-dev
234 2017-06-22T18:04:51  *** SopaXorzTaker has joined #bitcoin-core-dev
235 2017-06-22T18:05:38  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10651: Verify binaries from bitcoincore.org and bitcoin.org (master...2017-06-verify-coreorg) https://github.com/bitcoin/bitcoin/pull/10651
236 2017-06-22T18:09:29  *** Dyaheon has quit IRC
237 2017-06-22T18:10:01  *** Dyaheon has joined #bitcoin-core-dev
238 2017-06-22T18:18:17  *** laurentmt has quit IRC
239 2017-06-22T18:18:28  *** def has left #bitcoin-core-dev
240 2017-06-22T18:19:07  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/01c4b143a87e...4bc853b50fd9
241 2017-06-22T18:19:08  <bitcoin-git> bitcoin/master 999923e MarcoFalke: [qa] util: Check return code after closing bitcoind proc...
242 2017-06-22T18:19:09  <bitcoin-git> bitcoin/master 4bc853b MarcoFalke: Merge #10636: [qa] util: Check return code after closing bitcoind proc...
243 2017-06-22T18:19:41  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10636: [qa] util: Check return code after closing bitcoind proc (master...Mf1706-qaTraceback) https://github.com/bitcoin/bitcoin/pull/10636
244 2017-06-22T18:25:29  *** eenoch has quit IRC
245 2017-06-22T18:25:38  *** bordeaux_facile has quit IRC
246 2017-06-22T18:32:33  *** bordeaux_facile has joined #bitcoin-core-dev
247 2017-06-22T18:41:27  *** nelsondcg has joined #bitcoin-core-dev
248 2017-06-22T18:42:50  *** nelruk has quit IRC
249 2017-06-22T18:44:28  *** mryandao has quit IRC
250 2017-06-22T18:44:57  *** mryandao has joined #bitcoin-core-dev
251 2017-06-22T18:44:57  *** mryandao has joined #bitcoin-core-dev
252 2017-06-22T18:46:57  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4bc853b50fd9...6bef7ca8bc6a
253 2017-06-22T18:46:58  <bitcoin-git> bitcoin/master 0a5a6b9 Dimitris Tsapakidis: Fixed multiple typos...
254 2017-06-22T18:46:58  <bitcoin-git> bitcoin/master 6bef7ca Wladimir J. van der Laan: Merge #10633: doc: Fix various typos...
255 2017-06-22T18:47:32  <bitcoin-git> [bitcoin] laanwj closed pull request #10633: doc: Fix various typos (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10633
256 2017-06-22T18:48:59  *** eenoch has joined #bitcoin-core-dev
257 2017-06-22T18:57:43  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/6bef7ca8bc6a...8c2098ad1209
258 2017-06-22T18:57:44  <bitcoin-git> bitcoin/master c8914b9 Andrew Chow: Have `make cov` optionally include branch coverage statistics...
259 2017-06-22T18:57:44  <bitcoin-git> bitcoin/master 405b86a Andrew Chow: Replace lcov -r commands with faster way...
260 2017-06-22T18:57:45  <bitcoin-git> bitcoin/master d5711f4 Andrew Chow: Filter subtrees and and benchmarks from coverage report...
261 2017-06-22T18:58:27  <bitcoin-git> [bitcoin] laanwj closed pull request #10565: [coverage] Remove subtrees and benchmarks from coverage report (master...lcov-remove-extra) https://github.com/bitcoin/bitcoin/pull/10565
262 2017-06-22T19:00:40  <BlueMatt> meeting?
263 2017-06-22T19:00:45  <wumpus> #startmeeting
264 2017-06-22T19:00:45  <lightningbot> Meeting started Thu Jun 22 19:00:45 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
265 2017-06-22T19:00:45  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
266 2017-06-22T19:00:52  <achow101> hi
267 2017-06-22T19:00:56  <jonasschnelli> hi
268 2017-06-22T19:00:58  <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
269 2017-06-22T19:01:05  <cfields> hi
270 2017-06-22T19:01:07  <wumpus> topics?
271 2017-06-22T19:01:16  <sipa> ohai
272 2017-06-22T19:01:46  <wumpus> #topic high priority for review
273 2017-06-22T19:01:47  *** jtimon has joined #bitcoin-core-dev
274 2017-06-22T19:01:48  <wumpus> #link https://github.com/bitcoin/bitcoin/projects/8
275 2017-06-22T19:02:10  <wumpus> any new ones?
276 2017-06-22T19:02:32  <BlueMatt> should i give up on #10179 (+ #10286)?
277 2017-06-22T19:02:35  <gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub
278 2017-06-22T19:02:36  <BlueMatt> at least for 15
279 2017-06-22T19:02:38  <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
280 2017-06-22T19:02:49  <sipa> BlueMatt: no
281 2017-06-22T19:02:51  <kanzure> hi.
282 2017-06-22T19:03:11  <BlueMatt> sipa: well i mean point being that is something that really needs to stew in master for a month (or more) before a release
283 2017-06-22T19:03:17  <BlueMatt> so its hitting up against the 15 deadline already
284 2017-06-22T19:03:22  <wumpus> why give up?
285 2017-06-22T19:03:28  <instagibbs> hi
286 2017-06-22T19:03:29  <BlueMatt> not a huge deal to push to 16
287 2017-06-22T19:03:44  <BlueMatt> because i dont want to ship 10286 right after merging it
288 2017-06-22T19:03:56  <BlueMatt> its a real not-gonna-see-the-issues-unless-its-in-master-for-a-month kinda thing :(
289 2017-06-22T19:04:26  <wumpus> that's about the risk - what would be the main gain for merging it for 0.15?
290 2017-06-22T19:04:46  <wumpus> eh it's already in high-priority for review category
291 2017-06-22T19:05:10  <wumpus> we can't bump it anything higher :p
292 2017-06-22T19:05:14  <BlueMatt> well im asking if we should drop it from high priority, unless we still think we can get both in pretty quick i think we should say we wont until its 16
293 2017-06-22T19:05:17  <jtimon> I would like review on #8498
294 2017-06-22T19:05:21  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
295 2017-06-22T19:05:56  <wumpus> ok, but I mean, what would we lose if we decide to drop it for 0.15. Is there something else would be prioritized before it?
296 2017-06-22T19:06:16  <wumpus> I don't think it collides with e.g. multiwallet
297 2017-06-22T19:06:18  *** ryanofsky_ is now known as ryanofsky
298 2017-06-22T19:06:27  <BlueMatt> just 10286 - the dont-really-block-on-wallet-for-block-connection thing
299 2017-06-22T19:06:42  <BlueMatt> its not itself a huge win, but iterative steps towards better disconnection
300 2017-06-22T19:06:46  <cfields> BlueMatt: I'll try to get through it today, I've put it off long enough :)
301 2017-06-22T19:06:54  <BlueMatt> i know ryanofsky wanted it for the separate-process-wallet stuff he was working on
302 2017-06-22T19:07:00  <sipa> BlueMatt: how about we re-assess it next week?
303 2017-06-22T19:07:06  <BlueMatt> ok, sounds good
304 2017-06-22T19:07:07  <jtimon> and #8994 too, not sure which one is more likely to get it
305 2017-06-22T19:07:07  <wumpus> looks like they're both getting reviews
306 2017-06-22T19:07:08  <sipa> and hope for review in the mean time
307 2017-06-22T19:07:10  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
308 2017-06-22T19:07:12  <wumpus> yeah...
309 2017-06-22T19:07:27  <ryanofsky> yeah i'd prefer 10286 not to be delayed for months
310 2017-06-22T19:07:41  *** SopaXorzTaker has quit IRC
311 2017-06-22T19:08:21  <jonasschnelli> #10286
312 2017-06-22T19:08:24  <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
313 2017-06-22T19:09:00  <wumpus> ok, any other topics?
314 2017-06-22T19:09:02  <jtimon> wumpus: well, maybe none of my prs should be in project 8, I don't know
315 2017-06-22T19:09:23  *** nel has joined #bitcoin-core-dev
316 2017-06-22T19:09:27  <phantomcircuit> pong
317 2017-06-22T19:09:28  <sipa> wumpus: coin selection / effective feerate / bnb
318 2017-06-22T19:09:31  <wumpus> jtimon: I'm not sure that one warrants extra priority pre-0.15
319 2017-06-22T19:09:32  <BlueMatt> random PSA: there is now a copy of binaries hosted on https://bitcoincore.org/bin as well as https://bitcoin.org/bin. This will be the new "official" download site (though the bitcoin.org folks said they were gonna keep their mirror up for those who are used to bitcoin.org to not have to hop to another site)
320 2017-06-22T19:10:05  <wumpus> sipa: that's one topic or three?
321 2017-06-22T19:10:10  <sipa> wumpus: one
322 2017-06-22T19:10:18  <wumpus> #topic coin selection / effective feerate / bnb
323 2017-06-22T19:10:41  <sipa> we have a number of open PRs (and one just merged I think) that interact with coin selection
324 2017-06-22T19:10:44  <jtimon> wumpus: egoistically for elements project, it would be very nice to have #8994 before 0.15 for next elements rebase (not that bitcoin should care)
325 2017-06-22T19:10:46  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
326 2017-06-22T19:11:23  <sipa> #10637 #10360 #10333
327 2017-06-22T19:11:24  <jtimon> regarding #8498 it's an optimization (perhaps again "not worth it", like #10339)
328 2017-06-22T19:11:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10360 | [WIP] [Wallet] Target effective value during transaction creation by instagibbs · Pull Request #10360 · bitcoin/bitcoin · GitHub
329 2017-06-22T19:11:27  <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
330 2017-06-22T19:11:29  <gribble> https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub
331 2017-06-22T19:11:30  <gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub
332 2017-06-22T19:11:32  <gribble> https://github.com/bitcoin/bitcoin/issues/10339 | Optimization: Calculate block hash less times by jtimon · Pull Request #10339 · bitcoin/bitcoin · GitHub
333 2017-06-22T19:11:59  <sipa> are instagibbs, achow101, ... here?
334 2017-06-22T19:12:02  <instagibbs> I'm not sure many are even close to merge.
335 2017-06-22T19:12:04  <instagibbs> yeah
336 2017-06-22T19:12:10  <sipa> i agree
337 2017-06-22T19:12:17  <achow101> i'm here
338 2017-06-22T19:12:18  *** nelsondcg has quit IRC
339 2017-06-22T19:12:18  <gmaxwell> Hellow meeting.
340 2017-06-22T19:12:18  <instagibbs> 10333 is closest, but needs more revision
341 2017-06-22T19:12:22  <sipa> but i think there are two approaches to follow here
342 2017-06-22T19:12:36  <wumpus> jtimon: I really think we should have #8994, but it seems to collide with a lot of other things
343 2017-06-22T19:12:39  <gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub
344 2017-06-22T19:13:14  <sipa> one is to aim for overhauling coin selection... which will take a long time, and probably should be merged early in a cycle, so not for 0.15
345 2017-06-22T19:13:27  <gmaxwell> 10333 needs to get in (in some form) because it's an important fix.
346 2017-06-22T19:13:46  <instagibbs> I can do suggested change that gmaxwell gave, which I noted.
347 2017-06-22T19:13:50  <sipa> another is to make changes that 1) fix existing bugs and 2) work as a preprocessing step (in the form "let's see if algorithm X finds a good solution... otherwise fallback to what exists"
348 2017-06-22T19:14:11  <wumpus> agree with doing coin selection changes early in a release cycle
349 2017-06-22T19:14:15  <sipa> if 10333 is considered a bug fix, perhaps it should be prioritized for 0.15?
350 2017-06-22T19:14:15  <jtimon> wumpus: I guess that will wait forever then, previous versions were closed because they "collided with mempool/fee stuff", like more than 1 year ago? I'm happy to help people do the trivial rebases for people if that's the problem
351 2017-06-22T19:14:34  <jtimon> anyway, topic changed...
352 2017-06-22T19:14:37  <gmaxwell> 10333 should do nothing other than prevent serious overpayment in some corner cases.
353 2017-06-22T19:14:44  <instagibbs> sipa, It's marked as such, but if people deem it higher priority I'll make it one
354 2017-06-22T19:15:05  <gmaxwell> (at least once it's twiddled some)
355 2017-06-22T19:15:38  <sipa> would 10333 + 10637  be reasonable to aim for in 0.15?
356 2017-06-22T19:15:43  <instagibbs> It needs rebasing likely due to recent dust change merge
357 2017-06-22T19:15:47  <instagibbs> #10637
358 2017-06-22T19:15:49  <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
359 2017-06-22T19:16:03  <wumpus> I don't think so
360 2017-06-22T19:16:22  <instagibbs> latter seems a stretch imo, as great as it would be.
361 2017-06-22T19:16:23  <wumpus> #10637 would be better for 0.16 IMO
362 2017-06-22T19:16:26  <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
363 2017-06-22T19:16:30  <sipa> to clarify, 10637 is just a preprocessing step that makes it much more likely to find a match without change, reducing UTXO set size
364 2017-06-22T19:16:32  <wumpus> the other one is already marked for 0.15
365 2017-06-22T19:16:37  <sipa> if it fails, it falls back to what we have
366 2017-06-22T19:16:46  <achow101> I don't think 10637 would be good for 0.15. I haven't entirely made sure that it doesn't do anything stupid
367 2017-06-22T19:16:52  <instagibbs> sipa, if the code is correct, sure, earlier it wasn't (I'd have to do lots of review to make sure)
368 2017-06-22T19:16:53  <sipa> ok
369 2017-06-22T19:16:58  <sipa> instagibbs: of course
370 2017-06-22T19:17:02  <gmaxwell> I am not in favor of takin total overhaul as a general strategy. The problem is that each logical change has a complex 'whole system impact' question connected to it, which is really hard to reasona about for "hay guies, I replaced the whole thing!"  So I would much rather see a series of 'obviously sane' changes followed by "I reworked it to make the code clearer with no substantive change in b
371 2017-06-22T19:17:05  <wumpus> achow101: agree, no need to hurry it just to make a release
372 2017-06-22T19:17:07  <instagibbs> it's a nasty web of code, not his fault, just a fact
373 2017-06-22T19:17:08  <gmaxwell> ehavior".
374 2017-06-22T19:17:36  <sipa> ok, so let's aim for all coin selection changes in 0.16
375 2017-06-22T19:17:39  <sipa> apart from bug fixes
376 2017-06-22T19:17:47  <wumpus> the problem is that at some point the code is so convoluted that no option remains but 'redesign the whole thing'
377 2017-06-22T19:17:58  <jtimon> yeah, I've been trying to do something like #8494 since at least   Jun 10, 2015, but I think actually earlier
378 2017-06-22T19:17:58  <gmaxwell> :( is it so late to the end of 0.15 that we're slipping things out of it?
379 2017-06-22T19:18:00  <gribble> https://github.com/bitcoin/bitcoin/issues/8494 | [init, wallet] ParameterInteraction() iff wallet enabled by MarcoFalke · Pull Request #8494 · bitcoin/bitcoin · GitHub
380 2017-06-22T19:18:07  <wumpus> most of that has been replaced by now, but the coin selection code is arguably some of that
381 2017-06-22T19:18:20  <sipa> gmaxwell: i wish you were right, but i believe at some point we'll need to bite the bullet
382 2017-06-22T19:18:38  <sipa> though a number of steps can be taken before that point
383 2017-06-22T19:18:41  <wumpus> gmaxwell: well it starts to be important, even now, to prioritize things
384 2017-06-22T19:18:50  <instagibbs> With BnB in place, lays decent groundwork for more extensions
385 2017-06-22T19:18:52  <gmaxwell> wumpus: will then we stay where we've been stuck for years then?  I think it improved a lot, changes we made in 0.14 cleaned up CreateTransaction a lot.
386 2017-06-22T19:19:30  <jtimon> gmaxwell: agree on that way of doing big refactors, that's the sanest way to review them at least
387 2017-06-22T19:19:32  <instagibbs> making sane change-making policy could come next
388 2017-06-22T19:19:45  <instagibbs> sane steps exist i think
389 2017-06-22T19:20:01  *** nelsondcg has joined #bitcoin-core-dev
390 2017-06-22T19:21:34  <gmaxwell> sipa: obviously it needs to be reworked, but I cannot review something that is just "here is replacement code that does everything subtly differently" against threats like "will this cause runaway upbidding" or "will this potentially cause the utxo set size to skyrocket relative to the current code" or "will this trash user privacy" (well hard do to worse than the current on that mark. :P).  But
391 2017-06-22T19:21:40  <gmaxwell>  I can review things like instagibbs's effective rate change against those criteria.
392 2017-06-22T19:22:17  <gmaxwell> I think it's important to seperate intentional behavioral changes from implementation structure.
393 2017-06-22T19:22:18  <jtimon> so why not try to get merged 10333 first which seems the simpler to review and then revisit the other 2 ?
394 2017-06-22T19:22:35  <gmaxwell> jtimon: instagibbs has changes he needs to make.
395 2017-06-22T19:22:40  <gmaxwell> And sure.
396 2017-06-22T19:22:43  * jtimon nods
397 2017-06-22T19:22:46  *** nel has quit IRC
398 2017-06-22T19:22:48  <sipa> gmaxwell: i'm worried about something like 10360 to cause unintended runaway behaviour due to some interaction as well
399 2017-06-22T19:22:49  <wumpus> jtimon: yes
400 2017-06-22T19:23:07  <sipa> gmaxwell: even if it looks perfectly fine by all metrics we considered
401 2017-06-22T19:23:17  <gmaxwell> Though if integrated correctly (not saying it is yet) 10637 is just a preprocessing stage that can't make things worse. (not saying that it's yet integrated correctly).
402 2017-06-22T19:23:30  <instagibbs> Action item is me incorporating suggestion to 10333 make more robust and beg for review again here
403 2017-06-22T19:23:46  <wumpus> so should we add 10333 to high priority for review?
404 2017-06-22T19:24:39  <achow101> imo, yes
405 2017-06-22T19:25:01  <gmaxwell> sipa: I don't think it looks fine, I think it fixes a flaw we depend on due to a ~total lack of other mechenisms to sweep txins.
406 2017-06-22T19:25:54  <sipa> gmaxwell: yes, but i can't reason about its total effect
407 2017-06-22T19:26:16  <gmaxwell> (it's easy to show that 10360 will abandon more txouts than current code; and also the current code will _create_ txouts that an immediate second run under that patch would not consider spending)
408 2017-06-22T19:26:17  <sipa> i like the change as such, but who knows what interaction we missed
409 2017-06-22T19:26:58  <sipa> anyway, probably a discussion for later
410 2017-06-22T19:26:58  <gmaxwell> So the only thing I don't know if the effect would be castrophic or just merely not perfect.
411 2017-06-22T19:27:11  <sipa> yes, i think 10333 should be prioritized
412 2017-06-22T19:27:17  <gmaxwell> ack on 10333.
413 2017-06-22T19:27:44  <wumpus> ok, added
414 2017-06-22T19:28:19  <gmaxwell> sipa: I think a simple invarient is that we must spend everything we create at least under more or less stationary conditions. Anything less leads to runaway utxo set growth (though perhaps slowly...).
415 2017-06-22T19:29:02  <gmaxwell> but thats a minimum and perhaps not sufficient. But still 10360 fails it.
416 2017-06-22T19:29:50  <gmaxwell> to be fair, it's not 10360's fault so much as that we only pass that criteria now due to bugs that 10360 fixes.
417 2017-06-22T19:30:31  <sipa> other topics?
418 2017-06-22T19:31:05  <cfields> quick topic suggestion: add "strongly discourage/forbit default function arguments" to the style guide?
419 2017-06-22T19:31:28  <luke-jr> cfields: eh, I don't think that's a good idea
420 2017-06-22T19:31:30  <wumpus> #topic  add "strongly discourage/forbit default function arguments" to the style guide
421 2017-06-22T19:31:31  <cfields> *forbid. forbitting would be too much :p
422 2017-06-22T19:31:32  <BlueMatt> not always
423 2017-06-22T19:31:37  <wumpus> f-orbitting
424 2017-06-22T19:31:47  <gmaxwell> default arguments are a footgun for sure, can we articluate where they are okay-- if they aren't forbidden?
425 2017-06-22T19:31:49  <sipa> f(ire from) orbit?
426 2017-06-22T19:31:52  <wumpus> no, I don't think that's a good rule in general either
427 2017-06-22T19:31:52  <luke-jr> the important thing should be making sure the behaviour doesn't change, when func signatures change
428 2017-06-22T19:31:57  <BlueMatt> if theres 20 arguments to the function or its a big many-callers function, maybe
429 2017-06-22T19:32:12  <cfields> gmaxwell: yes, i think that's the discussion I was looking for.
430 2017-06-22T19:32:24  <luke-jr> "if code calling it before compiles with the new signature, it must behave the same"
431 2017-06-22T19:32:25  <wumpus> if there's 20 arguments to a function there's something wrong in general
432 2017-06-22T19:32:30  <BlueMatt> but depends on where, eg I think https://github.com/bitcoin/bitcoin/pull/10179/commits/dd53c6f0a3f9fa34b0d8d0f6b9a3e4df51a3eda7 is probably fine
433 2017-06-22T19:32:31  <wumpus> please make a rule not to have 20 arguments please
434 2017-06-22T19:32:35  <wumpus> certainly not booleans :(
435 2017-06-22T19:32:39  <BlueMatt> (adds a default arg to CScheduler::schedule())
436 2017-06-22T19:32:44  <BlueMatt> wumpus: lol, yes, indeed
437 2017-06-22T19:32:48  <sipa> "It is strongly encouraged to have 19 arguments to functions."
438 2017-06-22T19:32:49  <wumpus> Foo(false, true, false, true, false, true, true)
439 2017-06-22T19:33:09  <BlueMatt> wumpus: you forgot the NULL for good measure which may or may not be a pointer :p
440 2017-06-22T19:33:16  <wumpus> BlueMatt: oh yes
441 2017-06-22T19:33:42  <wumpus> default arguments are mostly good for one thing: transitions without touching all the code
442 2017-06-22T19:33:43  <gmaxwell> I think the default arg is okay when going from 0 to 1 arguments to add a flag, for example.
443 2017-06-22T19:33:55  <sipa> well i think defaults arguments are often used to reduce code impact of a patch... adding an optional argument at the end (especially directly after a non-optional one, and with a type incompatible with the first optional one if any) is perfectly safe and can strongly reduce the amount of code touched
444 2017-06-22T19:34:13  <sipa> the same can be achieved by adding a fewer-arguments wrapper, though
445 2017-06-22T19:34:17  <wumpus> e.g. if you add an argument to a function that's called from 400 places, it's usually better to add a default argument, at least temporarily
446 2017-06-22T19:34:49  <wumpus> right. I think that's a valid use.
447 2017-06-22T19:34:58  <sipa> i like the approach of creating a new function (with more args, and perhaps even a different name), and changing the old one to be a wrapper around the new one
448 2017-06-22T19:35:07  <luke-jr> indeed, I have been rebasing the rescanblockchain RPC, and this is needed to minimise the conflicts
449 2017-06-22T19:35:18  <gmaxwell> The defaults lead to negative interactions with the fact that arguments aren't named.  I like sipa's suggestion.
450 2017-06-22T19:35:22  <wumpus> well if it has the same name there is no effective difference
451 2017-06-22T19:35:27  <luke-jr> (it adds an argument for a stop-scanning index)
452 2017-06-22T19:35:33  <BlueMatt> sipa: thats how you end up with AcceptToMemoryPoolWorker(tx, true, false, false, true, NULL, (default) false)
453 2017-06-22T19:35:34  <BlueMatt> :(
454 2017-06-22T19:35:36  *** justanotheruser has joined #bitcoin-core-dev
455 2017-06-22T19:35:46  <gmaxwell> wumpus: because when you make further additions to the arguments, you don't mess things up.
456 2017-06-22T19:35:52  <sipa> that wrapper approach also is more restrictive: it _just_ allows the exact old use case, and a new one - not a variety of combinations based on multiple optional args
457 2017-06-22T19:36:10  <wumpus> absent argument naming, I like enums better than booleans
458 2017-06-22T19:36:23  <wumpus> anyhow, no, I don't think we should add a general rule about this
459 2017-06-22T19:36:28  <gmaxwell> We had a near consensus fault in the main split as a result of something related to this. IIRC.
460 2017-06-22T19:36:29  <wumpus> just pay attention at reviews to the specific case
461 2017-06-22T19:36:49  * luke-jr wishes there was a tool to audit such changes for us
462 2017-06-22T19:36:49  <cfields> ok
463 2017-06-22T19:36:54  <wumpus> not everything has to be spelled out in the style guide, that just makes for laziness *we've checked all the checkboxes*
464 2017-06-22T19:37:05  <gmaxwell> right
465 2017-06-22T19:37:23  <sipa> also, i wish there was a sed-like took that understood our AST a bit better, so you could add a new argument to a function everywhere
466 2017-06-22T19:37:37  <sipa> but regexps are fundamentally not strong enough to do that :(
467 2017-06-22T19:37:42  <wumpus> if only c++ was easier to parse...
468 2017-06-22T19:37:52  <gmaxwell> though I still think sipa's suggestion is good: if you need to introduce an argument to a function called in many places, wrap it with something that provides the default. Then over time we change call sites to call the new function.
469 2017-06-22T19:37:54  <luke-jr> at least it's not Perl
470 2017-06-22T19:37:57  <wumpus> you can do things like that using python + clang, but it's pretty involved, and not fun
471 2017-06-22T19:37:59  *** justan0theruser has quit IRC
472 2017-06-22T19:38:07  *** jannes has quit IRC
473 2017-06-22T19:38:28  <jtimon> ack on strongly discouraging optional arguments, we have way too many and some are really stupid IMO (ehem, ehem #9717 )
474 2017-06-22T19:38:30  <gribble> https://github.com/bitcoin/bitcoin/issues/9717 | Pow: Remove fCheckPOW from CheckBlockHeader by jtimon · Pull Request #9717 · bitcoin/bitcoin · GitHub
475 2017-06-22T19:38:33  <gmaxwell> then we don't end up with function signatures that are full of a mix of default and non-default arguments.
476 2017-06-22T19:38:52  <wumpus> even if you have a c++ parser you get such a lot of information into your mutation function, so many cases to handle
477 2017-06-22T19:39:33  <wumpus> gmaxwell: I fully agree, just don't think it makes sense as a rule
478 2017-06-22T19:39:39  <gmaxwell> ACK
479 2017-06-22T19:40:08  <jtimon> you can also have simpler wrappers on functions with less parameters and "default values" instead of optional arguments
480 2017-06-22T19:40:22  <wumpus> yes
481 2017-06-22T19:40:31  <gmaxwell> yea, thats what sipa was just saying.
482 2017-06-22T19:40:33  <sipa> jtimon: that's what i was suggestion
483 2017-06-22T19:40:52  <jtimon> sipa: sorry, catching up...
484 2017-06-22T19:40:59  <wumpus> though the advantage of default arguments is that they're self-documenting in the function signature
485 2017-06-22T19:42:08  <wumpus> anyhow, more topics?
486 2017-06-22T19:42:13  *** justanotheruser has quit IRC
487 2017-06-22T19:42:22  <sipa> do we want to bring up multiwallet API again?
488 2017-06-22T19:42:25  <jonasschnelli> yes
489 2017-06-22T19:42:29  <gmaxwell> I don't think I've personally found that too useful except for functions with just a couple arguments with one or two simple flags.  FrobThing(&thing,FrobHarder=true).
490 2017-06-22T19:42:33  <wumpus> #topic multiwallet API
491 2017-06-22T19:42:39  <jonasschnelli> can we decide what we want to use? path or query string and or versioning?
492 2017-06-22T19:42:46  <wumpus> path
493 2017-06-22T19:42:49  <jonasschnelli> I think /v1/wallet/<walletid> seems ideal
494 2017-06-22T19:42:50  *** justanotheruser has joined #bitcoin-core-dev
495 2017-06-22T19:43:01  <gmaxwell> can we at least put a version in first?
496 2017-06-22T19:43:01  <wumpus> we've decided that last time, that wallet will be based on endpoints
497 2017-06-22T19:43:01  <luke-jr> query string <.<
498 2017-06-22T19:43:12  <jonasschnelli> gmaxwell: yes. See above
499 2017-06-22T19:43:19  <sipa> luke-jr: i've been thinking about the advantages and disadvantages of both
500 2017-06-22T19:43:23  <jonasschnelli> luke-jr: what advantages do you see with query strings?
501 2017-06-22T19:43:25  <wumpus> oh sure /v1/something is fine with me
502 2017-06-22T19:43:43  <luke-jr> jonasschnelli: it's not hacking the path into a parameter? it's extensible?
503 2017-06-22T19:43:45  <wumpus> if we can use /v1 as the general node endpoint hten
504 2017-06-22T19:43:54  <sipa> query string has the advantage that it's more flexible - there could be multiple things to direct the RPC, and they don't need to be in a hierarchical pattern
505 2017-06-22T19:43:57  <wumpus> and /v1/walletname for the wallet
506 2017-06-22T19:44:05  <wumpus> don't use query strings with POST
507 2017-06-22T19:44:06  <wumpus> just don't
508 2017-06-22T19:44:09  <jonasschnelli> luke-jr: you can still add a query string later if you need non-hirarichal inputs later
509 2017-06-22T19:44:10  <gmaxwell> path seems fine to me, so long as there is a version, but I'm clueless.  I do have some questions though.
510 2017-06-22T19:44:19  <jonasschnelli> what wumpus sais
511 2017-06-22T19:44:37  <wumpus> POST has always been used with the idea that the parameters are in the payload
512 2017-06-22T19:44:44  * luke-jr wants to hear the rest of sipa's thoughts. ☺
513 2017-06-22T19:44:46  <wumpus> POST should not have URI parameters
514 2017-06-22T19:44:48  <jonasschnelli> wumpus: exactly
515 2017-06-22T19:44:50  <ryanofsky> i think query strings are analogous to command line options, paths are analogous to positional command line arguments
516 2017-06-22T19:44:51  <sipa> however, most things that would go into the path/query string as well, can just become RPC arguments as well
517 2017-06-22T19:45:04  <wumpus> if you confuse them, it will be hard to use from some languages
518 2017-06-22T19:45:09  <sipa> i think that perhaps the wallet name is different, in that it's actually a different "module" you're sending it to
519 2017-06-22T19:45:18  <jonasschnelli> sipa: indeed... but the /wallet/ endpoint could have a different rpc server once
520 2017-06-22T19:45:22  <ryanofsky> options are better for non required things that tweak the current operation, arguments are better for required values that determine operation
521 2017-06-22T19:45:25  <gmaxwell> I think it's likely in the future that we'll support doing this "create transaction in wallet A but also able using coins from wallet B,C"-- seems clear to me how this could work in the GUI.  How could we RPC call that?
522 2017-06-22T19:45:31  <sipa> so i think my preference is path - and for things that don't fit in the normal hierarchical structure, use named RPC arguments
523 2017-06-22T19:45:39  <wumpus> oh no... not commands from multiple wallets
524 2017-06-22T19:45:58  <sipa> gmaxwell: ugh...
525 2017-06-22T19:45:59  <wumpus> can we at least agree on one object to apply commands too
526 2017-06-22T19:46:03  <luke-jr> BTW, did we consider a generic JSON-RPC "wallet" named param?
527 2017-06-22T19:46:08  <gmaxwell> it's not really 'from multiple wallets'.
528 2017-06-22T19:46:13  <sipa> luke-jr: i suggested that before, yes
529 2017-06-22T19:46:23  <wumpus> gmaxwell: in that case you should just use the raw transactions api
530 2017-06-22T19:46:35  <wumpus> you can listunspent on multiple wallets, then use thei r utxos
531 2017-06-22T19:46:36  <sipa> luke-jr: i'd be fine with it, except it's less compatible with a future change that moves it to a different process (which will necessarily have a new endpoint)
532 2017-06-22T19:46:45  <jonasschnelli> luke-jr: generic wallet named parameter seems fine. Is it mixable with the non-named parameter?
533 2017-06-22T19:46:51  <wumpus> no need to do some obscure voodoo calling a method on multiple objects on the same time
534 2017-06-22T19:46:54  <gmaxwell> in any case, without that you are forced to make idiotic pay wallet A from wallet B transactions just to make a large payment.  (or as wumpus notes, do something with raw transactions)
535 2017-06-22T19:46:55  <jonasschnelli> I guess we then would only allow wallet selecting with name bases params?
536 2017-06-22T19:46:57  <wumpus> that way madness lies
537 2017-06-22T19:47:06  <luke-jr> sipa: ah, right
538 2017-06-22T19:47:33  <sipa> so i think this guideline may help: arguments that select something that may in the future move to another process, should go into the path
539 2017-06-22T19:47:36  <gmaxwell> wumpus: fair enough that you wouldn't want to do a ?wallet=a&wallet=b  voodoo in any case there, so no interaction with this question.
540 2017-06-22T19:47:39  <sipa> other things should be RPC named args
541 2017-06-22T19:47:40  <jonasschnelli> I guess endpoints will also make process separation simpler
542 2017-06-22T19:47:47  <sipa> jonasschnelli: that's what i was saying
543 2017-06-22T19:48:10  <wumpus> sipa: +1
544 2017-06-22T19:48:19  <jonasschnelli> Okay. Lets then go for /v1/wallet/walletID for now
545 2017-06-22T19:48:27  <wumpus> yes
546 2017-06-22T19:48:30  <sipa> ack
547 2017-06-22T19:48:32  <luke-jr> v0? :P
548 2017-06-22T19:48:38  <jonasschnelli> WalletID is the wallet filename for now... not sure if this is a problem
549 2017-06-22T19:48:45  <sipa> luke-jr: v0 already exists :p
550 2017-06-22T19:48:47  <jonasschnelli> v0 is not what users are expecting..
551 2017-06-22T19:48:47  <wumpus> no, v1, v0 is what we had before :)
552 2017-06-22T19:48:54  <luke-jr> but this isn't changing the API
553 2017-06-22T19:49:03  <sipa> no, it's creating a new API
554 2017-06-22T19:49:04  <jonasschnelli> it's just a prevention for future api changes
555 2017-06-22T19:49:09  <wumpus> yes.
556 2017-06-22T19:49:12  <gmaxwell> adding /wallet/ is a new API.
557 2017-06-22T19:49:19  <gmaxwell> even though its a trivial one.
558 2017-06-22T19:49:32  <wumpus> I think it's good to add it just in case, we should be able to use /v1 as endpoint for non-wallet methods
559 2017-06-22T19:49:47  <luke-jr> oh, that's a point: how do we specify "no wallet"?
560 2017-06-22T19:49:47  <wumpus> and / for both wallet methos and non-wallet methods (wallet will use 'the default wallet')
561 2017-06-22T19:49:50  *** neel has joined #bitcoin-core-dev
562 2017-06-22T19:49:55  <jonasschnelli> Yes. /v1 should do the same / (selecting the default wallet)
563 2017-06-22T19:49:56  <gmaxwell> oh nice, though if we're going to do that, we need to ban wallet methods on /v1/  right away.
564 2017-06-22T19:50:03  <wumpus> gmaxwell: yes please
565 2017-06-22T19:50:09  <sipa> how about we also add /v1/node for all non-wallet RPCs?
566 2017-06-22T19:50:30  <wumpus>  /v1 should do away with wallet methods, / should have them for backward compat
567 2017-06-22T19:50:35  <sipa> yes
568 2017-06-22T19:50:36  <jonasschnelli> Wait, do we want to ban non wallet methods sent to /v1/wallet/?
569 2017-06-22T19:50:39  <jtimon> wumpus: why not use query string with POST? we do everything with POST in the rpc, there's no GET, perhaps a link I could read?
570 2017-06-22T19:50:41  <wumpus> jonasschnelli: yes
571 2017-06-22T19:50:43  <sipa> jonasschnelli: yes
572 2017-06-22T19:50:46  <gmaxwell> well we have node rpcs but we also have pure function rpcs.   though I don't know how good it is to bother callers with the fine details of how an rpc is implemented.
573 2017-06-22T19:50:49  <luke-jr> :|
574 2017-06-22T19:50:54  <jonasschnelli> Okay. That makes it a bit more complex. :)
575 2017-06-22T19:50:58  <jonasschnelli> And not user friendly.
576 2017-06-22T19:51:03  <jtimon> oh, the params after ?, right, sorry
577 2017-06-22T19:51:07  <sipa> jonasschnelli: how so?
578 2017-06-22T19:51:13  <instagibbs> we should just ban all calls, start fresh :P
579 2017-06-22T19:51:17  <luke-jr> sipa: can't just change the endpoint for existing software..
580 2017-06-22T19:51:22  <jonasschnelli> what about createrawtransaction?
581 2017-06-22T19:51:32  <sipa> luke-jr: then use the old API, which keeps working
582 2017-06-22T19:51:39  <luke-jr> sipa: then you can't select the wallet
583 2017-06-22T19:51:53  <wumpus> jonasschnelli: well... the methods thaat have both wallet and non-wallet functionality are obviously special here
584 2017-06-22T19:51:54  <jtimon> sipa: most things? all things I believe, even for GET
585 2017-06-22T19:51:55  <jonasschnelli> switch over to /wallet when you call fundrawtransaction and back to /node when using signrawtransactionwithkey?
586 2017-06-22T19:52:05  <wumpus> jonasschnelli: they could be on both, I don't care
587 2017-06-22T19:52:08  <gmaxwell> having them track that "x is a wallet rpc" vs "y is a node" rpc is already asking a lot.  and following this there should be something for pure rpcs that interact not with the node state or wallet. and so on.
588 2017-06-22T19:52:17  <gmaxwell> I guess I'm raising the same concern as jonasschnelli
589 2017-06-22T19:52:28  <wumpus> gmaxwell: it's a good preparation for beginning to split off the wallet though
590 2017-06-22T19:52:28  <sipa> i see there is a usability issue in doing so
591 2017-06-22T19:52:36  <jonasschnelli> Not sure if we can/should already seperate the calls in endpoints
592 2017-06-22T19:52:38  <wumpus> gmaxwell: when the wallet would be a separate process it also won't have the node methods
593 2017-06-22T19:52:57  <gmaxwell> Yes, and I think the wallet split is reasonable, I'm cautioning about what happens if you continue the logic.
594 2017-06-22T19:53:00  <jonasschnelli> Once we have process separation, then we would need it. Yes.
595 2017-06-22T19:53:02  <wumpus> also it's a bit starnge to have the same non-wallet methods aliased for every wallet
596 2017-06-22T19:53:05  <jonasschnelli> We could warn in the release notes.
597 2017-06-22T19:53:10  <wumpus> aliasing is usually a bad idea
598 2017-06-22T19:53:35  <luke-jr> I suppose if people want backward compatibility, they can just user per-username default wallets, and have multiple users
599 2017-06-22T19:53:55  <gmaxwell> Maybe there really are only three kinds:  Things that talk to the node, things that talk to a wallet (and maybe also a node),  and  things that are pure functions.
600 2017-06-22T19:54:03  <wumpus> what makes /v1/wallet/mywallet getnetworkinfo different from /v1/otherwallet netnetworkinfo
601 2017-06-22T19:54:13  <wumpus> none has anything to do with wallets
602 2017-06-22T19:54:20  <wumpus> gmaxwell: yes, those three kinds exist
603 2017-06-22T19:54:24  <jonasschnelli> Yes. Agree that it looks bad.
604 2017-06-22T19:54:31  <sipa> can you give an example of the middle one?
605 2017-06-22T19:54:41  <wumpus> gmaxwell: we've been trying to get rid of " things that talk to a wallet (and maybe also a node)"
606 2017-06-22T19:54:43  <sipa> oh, signrawtransaction needing UTXO access
607 2017-06-22T19:54:50  <jonasschnelli> hm... wumpus: not sure. The wallet could have it's own network rules in future
608 2017-06-22T19:54:52  <wumpus> sipa: getinfo
609 2017-06-22T19:55:00  <sipa> wumpus: i don't care about getinfo :)
610 2017-06-22T19:55:10  <gmaxwell> it's a little unfortunate to expose the three kinds to users though.  decoderawtransaction and createrawtransaction are pure, signrawtransaction is not.
611 2017-06-22T19:55:12  <wumpus> jonasschnelli: sure, then it could have a *different* getnetworkinfo
612 2017-06-22T19:55:31  <wumpus> sipa: there are more, I've listed them in some issue, let me see
613 2017-06-22T19:55:58  <jonasschnelli> I don't think it's wrong to have node calls in /v1/wallet/mywallet .. it allows us to – in theory – have different peering for different wallets. Also chaintips can be different.
614 2017-06-22T19:56:04  <wumpus> sipa: #7965
615 2017-06-22T19:56:05  <sipa> i think i'm fine with making v1 support all non-deprecated non-wallet RPCs as well
616 2017-06-22T19:56:06  <gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub
617 2017-06-22T19:56:08  <gmaxwell> I think a split on anything other than wallet vs non-wallet basically exposes implementation details to users.
618 2017-06-22T19:56:19  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10652: Small step towards demangling cs_main from CNodeState (master...2017-06-cnodestateaccessors-1) https://github.com/bitcoin/bitcoin/pull/10652
619 2017-06-22T19:56:23  <gmaxwell> jonasschnelli: those don't sound like very interesting things to accomplish. IMO.
620 2017-06-22T19:56:25  <luke-jr> I think we're adding too much complexity to make 0.15 :<
621 2017-06-22T19:56:48  <wumpus> "RPC still has some calls that vary depending on wallet support. We should split these up. This is the more annoying part as it will involve API changes. No non-wallet RPC call should make an assumption about "a wallet"."
622 2017-06-22T19:56:52  <sipa> can we please at least remove getinfo from v1?
623 2017-06-22T19:56:58  <BlueMatt> YES
624 2017-06-22T19:57:00  <wumpus> YES
625 2017-06-22T19:57:04  <gmaxwell> (and by wallet vs non-wallet, I mean a logical split where the address and transaction manipulating functions which are technically pure would still be wallet functions)
626 2017-06-22T19:57:25  <jonasschnelli> Okay. Should the call split be in the same PR that introduces the endpoint?
627 2017-06-22T19:57:35  <wumpus> jonasschnelli: not necessarily, small steps are fine
628 2017-06-22T19:57:38  <sipa> jonasschnelli: i don't care
629 2017-06-22T19:57:55  <jonasschnelli> I think it may get pretty big.
630 2017-06-22T19:57:58  <gmaxwell> we shouldn't ship a release with /v1/ though that has a lot of calls we intend to remove, however.
631 2017-06-22T19:57:58  <jonasschnelli> And ideally the endpoint is in 0.15 (otherwise multiwallet is not really useful)
632 2017-06-22T19:58:01  <wumpus> at this point it's better to make progress at all
633 2017-06-22T19:58:02  <luke-jr> let's get rid of BTC amounts while we're at it! :x
634 2017-06-22T19:58:04  <sipa> gmaxwell: agree
635 2017-06-22T19:58:26  <wumpus> gmaxwell: if it's in a release it means it needs to be /v2
636 2017-06-22T19:58:29  <sipa> jonasschnelli: we have time, i think
637 2017-06-22T19:58:31  <wumpus> gmaxwell: simple as that
638 2017-06-22T19:58:38  <gmaxwell> luke-jr: I'd like that but switching to integers could be a v2 thing too...
639 2017-06-22T19:58:44  <wumpus> sigh
640 2017-06-22T19:58:57  <sipa> wumpus: sure; but i think we can merge endpoints now, and do another PR before 0.15 to remove some of the unnecessary stuff from the wallet endpoints
641 2017-06-22T19:58:59  <gmaxwell> wumpus: well will we want to continue supporting v1 for a long time in th case?
642 2017-06-22T19:59:00  <jtimon> I would not apps anything in the uri, just /v1/wallet/ with {"wallet": "mywalley", "otherparam" : "other value"}
643 2017-06-22T19:59:30  <sipa> jtimon: the downside of that is that doesn't prepare downstream apps well for a future process split
644 2017-06-22T19:59:37  <jonasschnelli> jtimon: having it in the JSON layer would make process seperation harder...
645 2017-06-22T19:59:38  <wumpus> (sorry, just tired of the whole 'switching to integers' thing)
646 2017-06-22T19:59:55  <sipa> wumpus: i think the current solutions which accepts strings everywhere is perfectly fine
647 2017-06-22T20:00:01  <gmaxwell> wumpus: oh I thought other people wanted to do that, but the inability to change the api was holding it off.
648 2017-06-22T20:00:45  <sipa> PLOINK
649 2017-06-22T20:00:54  <jtimon> luke-jr: super ACK on finally moving from BTC to satoshi once and for all, but last time I tried I had to close the PR
650 2017-06-22T20:00:56  <luke-jr> sipa fell in the ocean?
651 2017-06-22T20:00:58  <instagibbs> that's dutch for "meeting over"
652 2017-06-22T20:00:59  <wumpus> gmaxwell:  I mean the problem is that JSON doesn't have integers
653 2017-06-22T20:01:02  <wumpus> #endmeeting
654 2017-06-22T20:01:02  <lightningbot> Meeting ended Thu Jun 22 20:01:02 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
655 2017-06-22T20:01:02  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.html
656 2017-06-22T20:01:02  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.txt
657 2017-06-22T20:01:02  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.log.html
658 2017-06-22T20:01:12  <sipa> instagibbs: indeed; clearly at least wumpus got it
659 2017-06-22T20:01:38  <gmaxwell> wumpus: yea, I thought the suggestion was integers in strings. sorry if I'm desynced there.
660 2017-06-22T20:01:43  <BlueMatt> sorry cfields, I didnt want to hold off on PRing #10652 anymore....I only started it last dec :p
661 2017-06-22T20:01:45  <gribble> https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub
662 2017-06-22T20:01:58  <luke-jr> JSON has Numbers, which can be integers just fine
663 2017-06-22T20:02:08  <wumpus> if only we used a *SANE* RPC mechanism that support uint64 values
664 2017-06-22T20:02:10  <jtimon> I see, the reason to have the wallet id in the uri is for processes, thanks
665 2017-06-22T20:02:12  <cfields> BlueMatt: np, great to see
666 2017-06-22T20:02:14  <sipa> wumpus: ASN.1
667 2017-06-22T20:02:20  <cfields> haha
668 2017-06-22T20:02:22  <wumpus> we'd haved save hours, no, days of discussion
669 2017-06-22T20:02:22  <gmaxwell> wumpus: the issue that its trying to address is that some json libraries coerse json numbers to 32-bit floats and other horrors and do corrupt our values.
670 2017-06-22T20:02:40  <jonasschnelli> cfields: interested if you know why I got again dependencies issues on travis only: https://travis-ci.org/bitcoin/bitcoin/jobs/245674276#L2089
671 2017-06-22T20:02:41  <gmaxwell> luke-jr: if you're willing to support proper handling of number we don't need to change anything-- current thing is fine.
672 2017-06-22T20:02:42  <wumpus> gmaxwell: we currently accept strings as BTC amounts
673 2017-06-22T20:02:56  <gmaxwell> wumpus: yes, but we don't return them.
674 2017-06-22T20:02:58  <luke-jr> gmaxwell: current thing confuses internals with externals
675 2017-06-22T20:03:48  <wumpus> ASN.1 hehe
676 2017-06-22T20:03:50  <jtimon> unrelated: I would add #9271 to project 6 (libconsensus), although I don't manage to fix the tests if I change the enums for the consensus part. Removing that last part doesn't feel right either
677 2017-06-22T20:03:51  <gribble> https://github.com/bitcoin/bitcoin/issues/9271 | Theres two types of flags: consensus and script by jtimon · Pull Request #9271 · bitcoin/bitcoin · GitHub
678 2017-06-22T20:04:11  <gmaxwell> I'm sorry for commenting. perhaps it would just be better addressed by offering an RPC that isn't json in the future.
679 2017-06-22T20:04:20  <cfields> jonasschnelli: will take a look
680 2017-06-22T20:04:24  <sipa> gmaxwell: XML?
681 2017-06-22T20:04:28  <jtimon> I gave up on verifyHeader, but not on verifyTx
682 2017-06-22T20:04:33  <jonasschnelli> cfields: thanks!
683 2017-06-22T20:04:38  <wumpus> gmaxwell: no, don't be sorry, I'm sorry for reacting so heavily to it, it's just that it's been discussed so many times, and every time it goes the same
684 2017-06-22T20:05:01  <jtimon> sipa: SOAP :p
685 2017-06-22T20:05:07  <luke-jr> wumpus: because we never change the API..
686 2017-06-22T20:05:15  <wumpus> some people want solution A, some want B, it never changes
687 2017-06-22T20:05:18  <gmaxwell> My skin crawls a bit about the big footgun json gives our callers here. :(  (though seems luke wasn't even concerned about that)
688 2017-06-22T20:05:32  <cfields> jonasschnelli: btw, I pinged you a few days ago for discussion about the policy change, but I guess I missed you. I suspect it's too late now to pester you about it for a min?
689 2017-06-22T20:05:45  <wumpus> two? three? years ago I had a PR open that allows, with a command line argument, to change the encoding of amounts to four different things
690 2017-06-22T20:05:50  <wumpus> both for accepting and returning
691 2017-06-22T20:06:00  <wumpus> but no, no one was interested
692 2017-06-22T20:06:05  <wumpus> we rather just keep discussing it
693 2017-06-22T20:06:49  <gmaxwell> changing the API from a commandline seems unsafe, however.  I think it came up here because we're doing api versions.
694 2017-06-22T20:06:55  <wumpus> yeah yeah...
695 2017-06-22T20:06:56  <wumpus> never mind
696 2017-06-22T20:07:32  <gmaxwell> (e.g. you set the commandline one way then run joinmarket that doesn't know about that, and Bad Things Happen (tm) ... though I apologize if your PR actually addressed that.)
697 2017-06-22T20:08:03  <wumpus> so, we could switch between just btc amount and "btc amount" and drop the integer variants, also fine with me
698 2017-06-22T20:08:13  * jtimon ended up in https://zeroc.com/products/ice when talking about rpc...remembers he used it for robots to talk to computers with more computing power
699 2017-06-22T20:08:43  <luke-jr> wumpus: that would just make the problem worse
700 2017-06-22T20:08:59  <wumpus> no way that's dangerous as it would just result in incompatible values that wouldn't be parsed instead of 10^8 blowup
701 2017-06-22T20:09:04  <wumpus> oh yeah of course it just makes things worse
702 2017-06-22T20:09:07  <wumpus> OF COURSE
703 2017-06-22T20:09:16  <gmaxwell> wumpus: Thats a good point
704 2017-06-22T20:09:59  <wumpus> jtimon: it's not just bitcoin, no one ever agrees about RPC mechanisms, ever, anywhere :)
705 2017-06-22T20:10:07  <luke-jr> lol
706 2017-06-22T20:10:25  <gmaxwell> actually what effective numeric value does "1.0000" have in javascript? (a string with a 1.00 in it)
707 2017-06-22T20:10:38  <wumpus> that's why hundreds different ones exist
708 2017-06-22T20:11:18  <wumpus> 1.0000 if you interpret it as number
709 2017-06-22T20:11:46  <jtimon> wumpus: right, I just remembered with gmaxwell comments what I had used i the past, I hated soap and liked ice
710 2017-06-22T20:11:56  <gmaxwell> okay, that looks vaguely safe. I was worring for a moment that it would be 0 or something.
711 2017-06-22T20:12:47  <wumpus> gmaxwell:   javascript:alert("1.0000"+0)
712 2017-06-22T20:13:20  <bitcoin-git> [bitcoin] achow101 closed pull request #10511: [Tests] Include branch coverage info in coverage test (master...lcov) https://github.com/bitcoin/bitcoin/pull/10511
713 2017-06-22T20:13:45  *** CubicEarth has joined #bitcoin-core-dev
714 2017-06-22T20:13:49  <gmaxwell> I don't know how anyone can stand programming in this language because "blart"+0 = "blart0"
715 2017-06-22T20:13:52  *** Dyaheon has quit IRC
716 2017-06-22T20:15:04  <sipa> gmaxwell: https://www.destroyallsoftware.com/talks/wat
717 2017-06-22T20:15:12  *** Dyaheon has joined #bitcoin-core-dev
718 2017-06-22T20:15:55  <wumpus> gmaxwell: I don't know either, it's just madness
719 2017-06-22T20:16:29  *** jtimon has quit IRC
720 2017-06-22T20:19:25  <wumpus> but yes, that probably means that changing a number to a string is going to result in funny results instead of errors immediately
721 2017-06-22T20:26:29  *** Giszmo has quit IRC
722 2017-06-22T20:27:56  *** Giszmo has joined #bitcoin-core-dev
723 2017-06-22T20:34:41  *** laurentmt has joined #bitcoin-core-dev
724 2017-06-22T20:34:54  *** laurentmt has quit IRC
725 2017-06-22T20:59:26  *** Chris_Stewart_5 has quit IRC
726 2017-06-22T21:12:37  *** nelsondcg has quit IRC
727 2017-06-22T21:34:23  *** laurentmt has joined #bitcoin-core-dev
728 2017-06-22T21:56:33  *** jtimon has joined #bitcoin-core-dev
729 2017-06-22T21:57:26  *** neel has quit IRC
730 2017-06-22T21:57:59  <sipa> Can I haz some review on https://github.com/bitcoin-core/leveldb/pull/2 ?
731 2017-06-22T22:05:42  *** belcher has joined #bitcoin-core-dev
732 2017-06-22T22:10:39  *** chjj has joined #bitcoin-core-dev
733 2017-06-22T22:12:35  *** neel has joined #bitcoin-core-dev
734 2017-06-22T22:18:58  *** Dyaheon has quit IRC
735 2017-06-22T22:20:18  *** Dyaheon has joined #bitcoin-core-dev
736 2017-06-22T22:26:01  *** Guyver2 has quit IRC
737 2017-06-22T22:27:21  <luke-jr> sipa: but I thought we all trusted you to do the LevelDB review? :P
738 2017-06-22T22:31:41  <sipa> luke-jr: not of my own code
739 2017-06-22T22:32:06  <luke-jr> oh, that's not just the version bump
740 2017-06-22T22:32:27  <wumpus> no, the version bump was already done
741 2017-06-22T22:32:47  *** neel has quit IRC
742 2017-06-22T22:33:46  <wumpus> this just moves the atomic pointer code
743 2017-06-22T22:34:19  <sipa> yes, it makes it prefer the c++11 native construct over the adhoc asm code
744 2017-06-22T22:37:38  *** chjj has quit IRC
745 2017-06-22T22:38:49  *** jtimon has quit IRC
746 2017-06-22T22:39:36  <wumpus> yep
747 2017-06-22T22:41:02  *** Dizzle has quit IRC
748 2017-06-22T22:45:03  <gmaxwell> sipa: unrelated to us reviewing it, but any feedback from upstream about it?
749 2017-06-22T22:45:13  <gmaxwell> I certantly feel much more comfortable using C++ atomics.
750 2017-06-22T22:46:23  <sipa> gmaxwell: it's even code from upstream
751 2017-06-22T22:46:34  <sipa> i just changed the priority of choosing one over another
752 2017-06-22T22:46:47  <sipa> not a single comment in the upstream github repo
753 2017-06-22T22:50:28  <profall> Can two different people mine to different accounts on the same node?
754 2017-06-22T22:52:59  <wumpus> since when can you mine on people?
755 2017-06-22T22:53:45  <profall> Sweat shop with people hashing with pen and paper
756 2017-06-22T22:54:15  <profall> ASIC, Miner, machine do-dad hashing thing. Want me to rephrase the statement?
757 2017-06-22T22:54:32  <sipa> what do accounts have to do with iy
758 2017-06-22T22:54:38  <sipa> what have nodes to do with it
759 2017-06-22T22:56:05  <wumpus> the question just makes no sense, also this is not the place to ask support questions, try #bitcoin
760 2017-06-22T22:56:21  <profall> If Miner #1 is mining to address ABC and Miner #2 is mining to address XZY. However, they have are using the same bitcoin core daemon.
761 2017-06-22T22:56:23  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
762 2017-06-22T22:56:25  <gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
763 2017-06-22T22:56:26  <profall> Alright, will ask there.
764 2017-06-22T22:57:50  <sipa> profall: bitcoin core is irrelevant in this question; all core does is provide a block template to mine from
765 2017-06-22T22:58:16  <sipa> it does not care what you do with that, where you make the payout go, or where you submit the solved block
766 2017-06-22T22:58:36  <profall> Alright, thank you sipa
767 2017-06-22T23:15:31  *** laurentmt has quit IRC
768 2017-06-22T23:25:11  *** RoyceX has joined #bitcoin-core-dev
769 2017-06-22T23:27:11  *** belcher has quit IRC
770 2017-06-22T23:28:30  *** cheese_ has quit IRC
771 2017-06-22T23:33:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
772 2017-06-22T23:41:22  *** Dyaheon has quit IRC
773 2017-06-22T23:42:16  *** midnightmagic has quit IRC
774 2017-06-22T23:42:43  *** spinza has quit IRC
775 2017-06-22T23:43:12  *** Dyaheon has joined #bitcoin-core-dev
776 2017-06-22T23:44:19  *** midnightmagic has joined #bitcoin-core-dev
777 2017-06-22T23:51:17  *** spinza has joined #bitcoin-core-dev
778 2017-06-22T23:54:55  <bitcoin-git> [bitcoin] ryanofsky opened pull request #10653: Simple, backwards compatible RPC multiwallet support (master...pr/multiparam) https://github.com/bitcoin/bitcoin/pull/10653
779 2017-06-22T23:55:23  <achow101> morcos: sdaftuar: what's the best way to get a long term fee rate (e.g. estimatesmartfee for 1008 blocks)? I need this for #10637.
780 2017-06-22T23:55:25  <gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub
781 2017-06-22T23:56:19  <achow101> right now I am doing this abomination: https://0bin.net/paste/aql1DfVmBRbaZ9ks#P+ZTH6yYhbb4X-+YeCrCU/Mmt85cjNpkBvlqFvxxHFZ since it seems that estimatesmartfee() will return a fee rate of 0 if the confirmation target is out of the data range
782 2017-06-22T23:57:07  <achow101> (getminimumfeerate in that snippet is a function that gets the fee rate with estimatesmartfee and then returns the max of that or the minrelayfee)
783 2017-06-22T23:58:41  *** cheese_ has joined #bitcoin-core-dev