1 2016-05-12T00:00:28  <GitHub127> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/423ca302a3ee...69b3a6dd9d9a
  2 2016-05-12T00:00:28  <GitHub127> bitcoin/master 32114dd Wladimir J. van der Laan: bench: Add crypto hash benchmarks...
  3 2016-05-12T00:00:28  <GitHub127> bitcoin/master 69b3a6d Pieter Wuille: Merge #8039: bench: Add crypto hash benchmarks...
  4 2016-05-12T00:00:34  <phantomcircuit> wumpus, ^
  5 2016-05-12T00:00:41  <GitHub131> [bitcoin] sipa closed pull request #8039: bench: Add crypto hash benchmarks (master...2016_05_benchmark_sha256) https://github.com/bitcoin/bitcoin/pull/8039
  6 2016-05-12T00:02:39  *** alpalp has joined #bitcoin-core-dev
  7 2016-05-12T00:10:18  *** alpalp has quit IRC
  8 2016-05-12T00:10:30  *** alpalp has joined #bitcoin-core-dev
  9 2016-05-12T00:10:30  *** alpalp has joined #bitcoin-core-dev
 10 2016-05-12T00:19:41  *** kadoban has quit IRC
 11 2016-05-12T00:40:47  *** zooko has joined #bitcoin-core-dev
 12 2016-05-12T00:41:10  *** Ylbam has quit IRC
 13 2016-05-12T00:41:29  <gmaxwell> sipa: the xor-linked-list-ish trick in this is clever: http://www.cs.cmu.edu/~binfan/papers/login_cuckoofilter.pdf
 14 2016-05-12T00:59:11  *** Chris_Stewart_5 has quit IRC
 15 2016-05-12T01:00:07  *** kadoban has joined #bitcoin-core-dev
 16 2016-05-12T01:03:01  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 17 2016-05-12T01:09:51  *** donal has quit IRC
 18 2016-05-12T01:11:27  *** Chris_Stewart_5 has quit IRC
 19 2016-05-12T01:14:06  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 20 2016-05-12T01:35:04  *** dermoth_ has quit IRC
 21 2016-05-12T01:35:46  *** dermoth_ has joined #bitcoin-core-dev
 22 2016-05-12T01:37:49  *** alpalp has quit IRC
 23 2016-05-12T01:38:41  *** alpalp has joined #bitcoin-core-dev
 24 2016-05-12T01:38:53  *** alpalp has joined #bitcoin-core-dev
 25 2016-05-12T01:41:54  *** TomMc has quit IRC
 26 2016-05-12T01:54:01  *** Alopex has quit IRC
 27 2016-05-12T01:55:06  *** Alopex has joined #bitcoin-core-dev
 28 2016-05-12T02:12:58  *** belcher has quit IRC
 29 2016-05-12T02:13:55  *** Chris_Stewart_5 has quit IRC
 30 2016-05-12T02:33:31  *** alpalp has quit IRC
 31 2016-05-12T02:33:46  *** alpalp has joined #bitcoin-core-dev
 32 2016-05-12T02:37:09  *** grassass has joined #bitcoin-core-dev
 33 2016-05-12T02:43:02  *** grassass has quit IRC
 34 2016-05-12T02:47:05  *** TomMc has joined #bitcoin-core-dev
 35 2016-05-12T02:53:08  *** grassass has joined #bitcoin-core-dev
 36 2016-05-12T02:57:24  *** achow101 has quit IRC
 37 2016-05-12T02:57:37  *** TomMc has quit IRC
 38 2016-05-12T02:57:51  *** fengling has joined #bitcoin-core-dev
 39 2016-05-12T03:03:37  *** xiangfu has joined #bitcoin-core-dev
 40 2016-05-12T03:04:02  *** alpalp has quit IRC
 41 2016-05-12T03:08:29  *** mrkent has quit IRC
 42 2016-05-12T03:10:29  *** Giszmo has quit IRC
 43 2016-05-12T03:11:09  *** TomMc has joined #bitcoin-core-dev
 44 2016-05-12T03:32:02  *** Alopex has quit IRC
 45 2016-05-12T03:33:07  *** Alopex has joined #bitcoin-core-dev
 46 2016-05-12T03:45:40  *** CubicEarth has quit IRC
 47 2016-05-12T03:45:55  *** CubicEarth has joined #bitcoin-core-dev
 48 2016-05-12T04:07:02  *** TomMc has quit IRC
 49 2016-05-12T04:14:02  *** Alopex has quit IRC
 50 2016-05-12T04:15:07  *** Alopex has joined #bitcoin-core-dev
 51 2016-05-12T04:24:57  *** Cory has quit IRC
 52 2016-05-12T04:27:51  *** Cory has joined #bitcoin-core-dev
 53 2016-05-12T04:32:51  *** Cory has quit IRC
 54 2016-05-12T04:34:02  *** Alopex has quit IRC
 55 2016-05-12T04:35:07  *** Alopex has joined #bitcoin-core-dev
 56 2016-05-12T04:35:24  *** Pasha has joined #bitcoin-core-dev
 57 2016-05-12T04:42:18  *** Pasha is now known as Cory
 58 2016-05-12T04:49:06  *** xiangfu has quit IRC
 59 2016-05-12T04:52:01  *** Alopex has quit IRC
 60 2016-05-12T04:53:07  *** Alopex has joined #bitcoin-core-dev
 61 2016-05-12T04:56:04  *** earlest has quit IRC
 62 2016-05-12T04:57:51  *** gabridome has joined #bitcoin-core-dev
 63 2016-05-12T04:57:59  *** muuqwaul has joined #bitcoin-core-dev
 64 2016-05-12T05:08:01  *** Alopex has quit IRC
 65 2016-05-12T05:09:00  *** gill3s has joined #bitcoin-core-dev
 66 2016-05-12T05:09:06  *** Alopex has joined #bitcoin-core-dev
 67 2016-05-12T05:12:50  *** gabridome has left #bitcoin-core-dev
 68 2016-05-12T05:13:48  *** gabridome has joined #bitcoin-core-dev
 69 2016-05-12T05:14:40  *** xiangfu has joined #bitcoin-core-dev
 70 2016-05-12T05:22:18  *** gabridome has quit IRC
 71 2016-05-12T05:23:19  *** gabridome has joined #bitcoin-core-dev
 72 2016-05-12T05:28:59  *** gabridome has quit IRC
 73 2016-05-12T05:30:38  *** gabridome has joined #bitcoin-core-dev
 74 2016-05-12T05:42:17  *** fengling has quit IRC
 75 2016-05-12T05:43:25  *** gill3s has quit IRC
 76 2016-05-12T05:50:09  *** gill3s has joined #bitcoin-core-dev
 77 2016-05-12T05:52:01  *** gill3s has joined #bitcoin-core-dev
 78 2016-05-12T05:54:38  *** gabridome has quit IRC
 79 2016-05-12T05:59:43  *** gabridome has joined #bitcoin-core-dev
 80 2016-05-12T06:02:10  *** gill3s has quit IRC
 81 2016-05-12T06:05:28  *** gabridome has quit IRC
 82 2016-05-12T06:11:07  *** paveljanik has quit IRC
 83 2016-05-12T06:11:31  *** fengling has joined #bitcoin-core-dev
 84 2016-05-12T06:28:18  *** Ylbam has joined #bitcoin-core-dev
 85 2016-05-12T06:42:37  *** PaulCapestany has quit IRC
 86 2016-05-12T06:42:49  *** Squidicuz has quit IRC
 87 2016-05-12T06:43:15  *** Squidicuz has joined #bitcoin-core-dev
 88 2016-05-12T06:43:41  *** PaulCapestany has joined #bitcoin-core-dev
 89 2016-05-12T06:47:35  *** jtimon has quit IRC
 90 2016-05-12T06:48:38  <wumpus> jonasschnelli: but for the 1MB buffer the benchmark will get called more times, also flattening out variance
 91 2016-05-12T06:49:03  <wumpus> I also reasoned like you but forgot to take into account that the benchmarking framework automatically runs for a (approximate) fixed amount  of time
 92 2016-05-12T06:50:21  <wumpus> <Chris_Stewart_5> Is there a reason we don't have any logging inside of interpreter.cpp (or seemingly anything related to scripts)? <- for various reasons: it is inner-loop code, so logging would slow it down. Also it would be incredbily spammy. And further, any kind of logging complicates libconsensus initiatives by adding external dependencies
 93 2016-05-12T06:51:29  <wumpus> can anyone please benchmark this on an actual recent Intel processor? https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel
 94 2016-05-12T06:51:58  <wumpus> intel's 'fast' sha256 assembly implementations mostly turn out slower instead of faster here
 95 2016-05-12T06:52:00  <wumpus> but that's on AMD
 96 2016-05-12T06:52:36  <gmaxwell> doing do
 97 2016-05-12T06:52:37  <gmaxwell> er so
 98 2016-05-12T06:59:55  <gmaxwell> wumpus: this is on a haswell based xeon:
 99 2016-05-12T06:59:57  <gmaxwell> SHA256_avx,319,0.00344849,0.00346613,0.0034525
100 2016-05-12T06:59:57  <gmaxwell> SHA256_basic,191,0.00531399,0.00533286,0.00532052
101 2016-05-12T06:59:57  <gmaxwell> SHA256_rorx,351,0.00290081,0.00290608,0.002903
102 2016-05-12T06:59:57  <gmaxwell> SHA256_rorx_x8ms,351,0.0028524,0.00286806,0.0028543
103 2016-05-12T06:59:59  <gmaxwell> SHA256_sse4,319,0.00342679,0.00345755,0.003443
104 2016-05-12T07:00:35  *** xiangfu has quit IRC
105 2016-05-12T07:00:36  *** go1111111 has quit IRC
106 2016-05-12T07:00:51  *** xiangfu has joined #bitcoin-core-dev
107 2016-05-12T07:04:57  <gmaxwell> and a somewhat lower clocked broadwell-ep xeon:
108 2016-05-12T07:04:58  <gmaxwell> SHA256_avx,255,0.0039705,0.0040791,0.00397483
109 2016-05-12T07:04:59  <gmaxwell> SHA256_basic,175,0.00599706,0.00610304,0.00599851
110 2016-05-12T07:04:59  <gmaxwell> SHA256_rorx,319,0.00334549,0.00345182,0.00334802
111 2016-05-12T07:04:59  <gmaxwell> SHA256_rorx_x8ms,319,0.00328481,0.00339317,0.00328667
112 2016-05-12T07:05:01  <gmaxwell> SHA256_sse4,255,0.00395852,0.00404716,0.00396052
113 2016-05-12T07:07:24  *** gill3s has joined #bitcoin-core-dev
114 2016-05-12T07:11:23  *** AaronvanW has joined #bitcoin-core-dev
115 2016-05-12T07:13:14  *** go1111111 has joined #bitcoin-core-dev
116 2016-05-12T07:17:42  *** CubicEarth has quit IRC
117 2016-05-12T07:18:10  <jonasschnelli> What does "OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)" exactly mean? nFile=-1 looks after a undefined CDiskBlockPos?
118 2016-05-12T07:18:17  *** CubicEarth has joined #bitcoin-core-dev
119 2016-05-12T07:18:42  <jonasschnelli> I'd like to debug the corruption I've got on my AARCH
120 2016-05-12T07:20:36  *** BashCo has quit IRC
121 2016-05-12T07:32:30  *** paveljanik has joined #bitcoin-core-dev
122 2016-05-12T07:37:47  *** kadoban has quit IRC
123 2016-05-12T07:43:00  *** BashCo has joined #bitcoin-core-dev
124 2016-05-12T07:46:06  <jonasschnelli> wumpus: my results:
125 2016-05-12T07:46:09  <jonasschnelli> SHA1,703,0.00148028,0.00152859,0.0015024
126 2016-05-12T07:46:09  <jonasschnelli> SHA256_avx,415,0.00256598,0.00258584,0.0025782
127 2016-05-12T07:46:10  <jonasschnelli> SHA256_basic,287,0.00375891,0.00400322,0.00383578
128 2016-05-12T07:46:10  <jonasschnelli> SHA256_sse4,415,0.00255489,0.00261028,0.0025789
129 2016-05-12T07:46:10  <jonasschnelli> SHA512,415,0.00251514,0.00256588,0.00252959
130 2016-05-12T07:46:33  <jonasschnelli> Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz
131 2016-05-12T07:47:47  <jonasschnelli> bench results of master...
132 2016-05-12T07:47:48  <jonasschnelli> SHA1,703,0.00146294,0.00149019,0.00148072
133 2016-05-12T07:47:48  <jonasschnelli> SHA256,255,0.00396442,0.00401562,0.00398446
134 2016-05-12T07:47:48  <jonasschnelli> SHA512,415,0.00252354,0.0025878,0.00254187
135 2016-05-12T07:48:32  <jonasschnelli> Ah. I guess SHA256_basic is the non-tweaked one..
136 2016-05-12T07:49:04  <jonasschnelli> So... looks after a 150% performance increase on my xeon server
137 2016-05-12T07:49:23  <jonasschnelli> same on gmaxwell's results
138 2016-05-12T07:51:51  <gmaxwell> interesting that the only thing the avx seems to do is hurt performance on AMD. :)
139 2016-05-12T07:52:35  <gmaxwell> the rorx is somewhat faster though.
140 2016-05-12T07:54:46  <jonasschnelli> What about the Intel SHA extentension? I Guess sse4 is a different thing.
141 2016-05-12T07:54:51  <jonasschnelli> https://software.intel.com/en-us/articles/intel-sha-extensions
142 2016-05-12T07:56:15  <jonasschnelli> I have a Xeon E3 and it seems that intels sha extension is only built into E5 and E7 families.
143 2016-05-12T07:57:24  <gmaxwell> jonasschnelli: they don't exist yet.
144 2016-05-12T07:57:58  <gmaxwell> (they were announced for broadwell then quietly dropped, I assume because the silicon failed)
145 2016-05-12T07:58:17  <jonasschnelli> Also my "AArch64 Processor rev 4 (aarch64)" has Features	: fp asimd aes pmull sha1 sha2 crc32
146 2016-05-12T07:58:29  <jonasschnelli> mbedtls has some implementations for this: https://github.com/ARMmbed/mbedtls/pull/432/files
147 2016-05-12T08:02:38  <jonasschnelli> After this: https://github.com/CriticalBlue/mbedtls/wiki it could give a x5 performance boost for SHA256 on ARM with that extension
148 2016-05-12T08:02:46  *** molz has quit IRC
149 2016-05-12T08:12:54  <GitHub135> [bitcoin] jonasschnelli opened pull request #8046: [Qt][OSX] Fix Cmd-Q / Menu Quit shutdown on OSX (master...2016/05/fix_quit) https://github.com/bitcoin/bitcoin/pull/8046
150 2016-05-12T08:13:24  <wumpus> thanks for the benchmark results! and yeah re SHA extensions: I'm trying to target hardware that actually exist in the wild :)
151 2016-05-12T08:13:56  <wumpus> the AARCH64 sHA256 extension sounds reasonably interesting though, too bad Odroid C2 doesn't have it
152 2016-05-12T08:16:24  <jonasschnelli> Yes. Not really an important thing.
153 2016-05-12T08:16:49  <jonasschnelli> But enabling AVX should probably be something we should do.
154 2016-05-12T08:16:52  <jonasschnelli> wumpus: Is the implementation directly copied from intel?
155 2016-05-12T08:16:58  <wumpus> yes
156 2016-05-12T08:18:04  <jonasschnelli> 1.5* performance boost in sha256 for advance vector enabled processors should be something we should try to get in soon.
157 2016-05-12T08:18:49  *** gill3s has quit IRC
158 2016-05-12T08:18:53  <jonasschnelli> I guess Sandy and Ivy supports it.
159 2016-05-12T08:21:33  <wumpus> what you could try is see if it influences sync performance (a matter of adding CSHA256::SetImplementation(CSHA256::Impl::SSE4); in the inititalization)
160 2016-05-12T08:22:50  <gmaxwell> s/AVX/SSE4/
161 2016-05-12T08:23:18  <jonasschnelli> SSE4 is ~the same performance boost on my Xeon. But right. We should probably go for AVX
162 2016-05-12T08:23:25  <sipa> building
163 2016-05-12T08:23:54  <gmaxwell> jonasschnelli: AVX is no faster on anything we've tested on and it hurts performance on Wumpus' AMD chip.
164 2016-05-12T08:24:10  <jonasschnelli> gmaxwell: arg. Right. Mixed it up.
165 2016-05-12T08:24:14  <gmaxwell> :)
166 2016-05-12T08:24:24  <wumpus> yes, AVX seems useless
167 2016-05-12T08:24:56  <gmaxwell> BlueMatt: can you benchmark this on skylake?
168 2016-05-12T08:25:16  <sipa> SHA256_avx,255,0.00398244,0.00399226,0.00398497
169 2016-05-12T08:25:16  <sipa> SHA256_basic,175,0.00608169,0.00611341,0.00608469
170 2016-05-12T08:25:16  <sipa> SHA256_sse4,255,0.0039705,0.00398195,0.00397209
171 2016-05-12T08:25:17  <jonasschnelli> wumpus: so I just pass in a CSHA256::SetImplementation(CSHA256::Impl::SSE4) in init.cpp somewhere?
172 2016-05-12T08:25:37  *** gill3s has joined #bitcoin-core-dev
173 2016-05-12T08:25:43  <wumpus> jonasschnelli: yes, or alternatively change the default in src/crypto/sha256.cpp
174 2016-05-12T08:25:57  <wumpus> sipa: what processor?
175 2016-05-12T08:26:14  <sipa> Intel(R) Core(TM) i7-4800MQ, 2.6 GHz
176 2016-05-12T08:26:33  <wumpus> thanks
177 2016-05-12T08:27:02  <gmaxwell> sipa: thats another haswell.
178 2016-05-12T08:27:41  <sipa> ok
179 2016-05-12T08:28:38  <midnightmagic> I'm sure there's a reason for it, but is cpu detection and then dual codepaths, or even multiple-compile outputs not an option in the event a cpu family does benefit?
180 2016-05-12T08:29:24  <midnightmagic> or has a significant benefit to these features just not been found i guess
181 2016-05-12T08:29:29  <jonasschnelli> I could create a bench on a "2.6 GHz Intel Core i7" (guess this is Ivy Bridge) if it would be good to know.
182 2016-05-12T08:29:47  <wumpus> midnightmagic: runtime CPU detection is necessary to integrate this, yes
183 2016-05-12T08:30:06  *** Guyver2 has joined #bitcoin-core-dev
184 2016-05-12T08:30:08  <wumpus> (right now I don't bother as this is just a hack/experiment)
185 2016-05-12T08:30:24  *** Cheeseo has quit IRC
186 2016-05-12T08:30:53  *** Cheeseo has joined #bitcoin-core-dev
187 2016-05-12T08:30:53  *** Cheeseo has joined #bitcoin-core-dev
188 2016-05-12T08:30:53  <gmaxwell> midnightmagic: yes, it would be detected. But the test is important, e.g. it looks like we've learned not to use the AVX version even if supported.
189 2016-05-12T08:31:00  <wumpus> in any case it's nice that sse4 gives the best speedup; that's the most common
190 2016-05-12T08:31:38  * midnightmagic shakes fist at irritating icc dual code pathing which ((iirc) nullified it for commercial dev at prior employer
191 2016-05-12T08:33:31  <gmaxwell> well rorx was clearly faster in my benchmarks.
192 2016-05-12T08:33:59  <wumpus> but you actually have a cpu that supports it :)
193 2016-05-12T08:34:36  <wumpus> oh! you did post your results, I missed that
194 2016-05-12T08:34:56  <gmaxwell> I even highlit you. :)
195 2016-05-12T08:35:02  <midnightmagic> uh. I have a lemote laptop sitting next to me in a backpack. in the event someone might like me to use it for testing, I'd be cool with helping.
196 2016-05-12T08:35:44  <midnightmagic> (after I get it rebuilt)
197 2016-05-12T08:38:12  <gmaxwell> wumpus: so does sipa and jonasschnelli.
198 2016-05-12T08:38:39  <gmaxwell> They just didn't enable it.
199 2016-05-12T08:45:38  <gmaxwell> IIRC rorx was introduced with haswell so it's a couple arch generations old now and pretty widely spread. though I can't say if the modest performance increase is really worth it.
200 2016-05-12T08:50:27  <wumpus> ok added all of them to https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel
201 2016-05-12T08:51:04  <wumpus> agreed, at the least we should only select one of the rorx variants, they're so similar in performance
202 2016-05-12T08:51:37  <gmaxwell> sipa and jonasschnelli should test the rorx. (esp jonasschnelli since his chip is skylake)
203 2016-05-12T08:53:16  *** gill3s has quit IRC
204 2016-05-12T08:55:16  *** gill3s has joined #bitcoin-core-dev
205 2016-05-12T08:56:40  <jonasschnelli> A simple reindex comparison:
206 2016-05-12T08:57:01  <jonasschnelli> Reindex up to block 200'000:
207 2016-05-12T08:57:08  <jonasschnelli> SSE4: 389 seconds
208 2016-05-12T08:57:15  <jonasschnelli> master: 406 seconds
209 2016-05-12T08:58:04  <jonasschnelli> But I guess the SHA256 performance will be mostly "visible" during a synced state
210 2016-05-12T08:59:03  <wumpus> at least when larger blocks come into play it may be more indicative, up to 200,000 are mostly easy blocks IIRC
211 2016-05-12T08:59:10  <wumpus> but it's a noticable speedup that's good
212 2016-05-12T08:59:55  <jonasschnelli> here my bench with rorx:
213 2016-05-12T08:59:57  <jonasschnelli> SHA256_avx,351,0.00267656,0.00406031,0.00287071
214 2016-05-12T08:59:57  <jonasschnelli> SHA256_basic,191,0.00403945,0.00774813,0.00572075
215 2016-05-12T08:59:57  <jonasschnelli> SHA256_rorx,415,0.00223376,0.00340772,0.00260254
216 2016-05-12T08:59:57  <jonasschnelli> SHA256_rorx_x8ms,319,0.00224853,0.00372237,0.00329514
217 2016-05-12T08:59:57  <jonasschnelli> SHA256_sse4,255,0.00273502,0.00505805,0.00409666
218 2016-05-12T09:00:10  *** laurentmt has joined #bitcoin-core-dev
219 2016-05-12T09:01:48  *** laurentmt has quit IRC
220 2016-05-12T09:03:19  <wumpus> so sse4 139% rorx 173%
221 2016-05-12T09:04:25  <jonasschnelli> Looks like...
222 2016-05-12T09:05:02  *** gill3s has quit IRC
223 2016-05-12T09:06:19  <jonasschnelli> I try now to compare a full reindex with std sha against rorx.
224 2016-05-12T09:06:42  <wumpus> is this on the same Intel(R) Xeon(R) CPU E3-1275 v5 @ 3.60GHz?
225 2016-05-12T09:06:52  <jonasschnelli> Yes.
226 2016-05-12T09:07:14  <wumpus> the numbers are fairly different that's why I ask
227 2016-05-12T09:07:26  <jonasschnelli> Hmm...
228 2016-05-12T09:08:21  <jonasschnelli> sse4 is extremely different.. right.
229 2016-05-12T09:08:48  <jonasschnelli> Hmm.. maybe the reindex ran in the background... let me redo it.
230 2016-05-12T09:08:59  <wumpus> min and max differences are also huge; possibly the benchmark framework should ignore the first run to 'prime the cache'
231 2016-05-12T09:09:40  *** gill3s has joined #bitcoin-core-dev
232 2016-05-12T09:09:52  <wumpus> not that precise benchmarks are super-imporant here, it's clear that there is a win to using sse4/rorx
233 2016-05-12T09:10:06  <jonasschnelli> SHA1,703,0.00148106,0.00254279,0.00150908
234 2016-05-12T09:10:06  <jonasschnelli> SHA256_avx,415,0.00256918,0.00271057,0.00260393
235 2016-05-12T09:10:06  <jonasschnelli> SHA256_basic,287,0.00377643,0.00395856,0.00385546
236 2016-05-12T09:10:06  <jonasschnelli> SHA256_rorx,479,0.00214249,0.00227334,0.00217936
237 2016-05-12T09:10:06  <jonasschnelli> SHA256_rorx_x8ms,479,0.00212789,0.00233448,0.00219144
238 2016-05-12T09:10:06  <jonasschnelli> SHA256_sse4,383,0.00263,0.00277644,0.00266623
239 2016-05-12T09:10:06  <jonasschnelli> SHA512,415,0.00252406,0.00267003,0.0025598
240 2016-05-12T09:10:34  <wumpus> that looks better
241 2016-05-12T09:10:46  <jonasschnelli> Yes. The reindex was probably running in the background.
242 2016-05-12T09:11:08  <jonasschnelli> The latest bench was on a quite system (like the first ones without rorx i have posted)
243 2016-05-12T09:14:03  <wumpus> these are comparable: https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accel#intelr-xeonr-cpu-e3-1275-v5--360ghz
244 2016-05-12T09:16:54  *** gill3s has quit IRC
245 2016-05-12T09:25:43  *** gill3s has joined #bitcoin-core-dev
246 2016-05-12T09:31:04  *** xiangfu has quit IRC
247 2016-05-12T09:36:01  *** Ginnarr has joined #bitcoin-core-dev
248 2016-05-12T09:36:58  *** xiangfu has joined #bitcoin-core-dev
249 2016-05-12T09:45:53  <GitHub120> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/69b3a6dd9d9a...5b736ddaa1c1
250 2016-05-12T09:45:54  <GitHub120> bitcoin/master fad60b3 MarcoFalke: [qa] Fix bip9-softforks blockstore issue
251 2016-05-12T09:45:55  <GitHub120> bitcoin/master 5b736dd Wladimir J. van der Laan: Merge #8041: [qa] Fix bip9-softforks blockstore issue...
252 2016-05-12T09:46:05  <GitHub52> [bitcoin] laanwj closed pull request #8041: [qa] Fix bip9-softforks blockstore issue (master...Mf1604-qaBip9Blockstore) https://github.com/bitcoin/bitcoin/pull/8041
253 2016-05-12T09:46:30  <GitHub57> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5b736ddaa1c1...2efe38b8323c
254 2016-05-12T09:46:31  <GitHub57> bitcoin/master 3262316 Chirag Davé: fReopenDebugLog and fRequestShutdown should be type sig_atomic_t...
255 2016-05-12T09:46:33  <GitHub57> bitcoin/master 2efe38b Wladimir J. van der Laan: Merge #8004: signal handling: fReopenDebugLog and fRequestShutdown should be type sig_atomic_t...
256 2016-05-12T09:46:41  <GitHub29> [bitcoin] laanwj closed pull request #8004: signal handling: fReopenDebugLog and fRequestShutdown should be type sig_atomic_t (master...fix_signal_handler) https://github.com/bitcoin/bitcoin/pull/8004
257 2016-05-12T09:50:12  *** MarcoFalke_ has joined #bitcoin-core-dev
258 2016-05-12T09:52:23  *** slackircbridge has quit IRC
259 2016-05-12T09:53:37  *** slackircbridge has joined #bitcoin-core-dev
260 2016-05-12T09:56:41  <GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2efe38b8323c...7c8558da362f
261 2016-05-12T09:56:41  <GitHub124> bitcoin/master 8b0e497 Tyler Hardin: Qt: Add option to hide the system tray icon...
262 2016-05-12T09:56:42  <GitHub124> bitcoin/master 7c8558d Wladimir J. van der Laan: Merge #8006: Qt: Add option to disable the system tray icon...
263 2016-05-12T09:56:51  <GitHub140> [bitcoin] laanwj closed pull request #8006: Qt: Add option to disable the system tray icon (master...disable-tray) https://github.com/bitcoin/bitcoin/pull/8006
264 2016-05-12T10:01:19  *** gill3s has quit IRC
265 2016-05-12T10:08:06  *** gill3s has joined #bitcoin-core-dev
266 2016-05-12T10:13:15  <jonasschnelli> wumpus:do you have a tray icon menu on you Ubuntu?
267 2016-05-12T10:14:02  <wumpus> yes, but it's messed up (ends up in the lower left of my screen), a known (upstream) issue with qt5 and ubuntu 14.04, so I'm thankful for the option to disable it
268 2016-05-12T10:16:40  <wumpus> oh you mean if I can reproduce #8040 on ubuntu? I'll try
269 2016-05-12T10:18:27  <wumpus> no, I can't: the tray icon only appears after the main window shows
270 2016-05-12T10:19:04  <wumpus> it's not there during the splash screen
271 2016-05-12T10:19:28  <wumpus> this would be an issue if we had a "launcher icon menu"
272 2016-05-12T10:19:45  <wumpus> as the icon in the launcher appears as soon as the application loads
273 2016-05-12T10:20:05  <jonasschnelli> wumpus: check https://github.com/bitcoin/bitcoin/issues/8043
274 2016-05-12T10:20:10  <wumpus> then again that requires linking against ubuntu-specific libraries, so little chance
275 2016-05-12T10:20:15  <jonasschnelli> I have this issue in 14.04 and 16.04
276 2016-05-12T10:20:35  <MarcoFalke_> fedora core works fine
277 2016-05-12T10:20:49  <wumpus> hmm, no I never had that problem
278 2016-05-12T10:20:53  <MarcoFalke_> self-compiled, shows the tray icon after start
279 2016-05-12T10:21:45  <wumpus> I've had this issue: https://github.com/bitcoin/bitcoin/issues/4826 and this issue: https://github.com/bitcoin/bitcoin/issues/5260
280 2016-05-12T10:21:56  <wumpus> lots of fun with qt and the tray icon
281 2016-05-12T10:22:18  <wumpus> the former doesn't seem to happen anymore though, so I think it was fixed upstream
282 2016-05-12T10:22:51  <wumpus> the latter only happens with self-compiled bitcoin-qt against the system qt5, whichi s ancient
283 2016-05-12T10:23:12  <wumpus> (5.2.1)
284 2016-05-12T10:23:32  <wumpus> in any case not worrying. The missing menu is strange
285 2016-05-12T10:24:01  <wumpus> adding the hide tray icon option is a good start, maybe at some point in the future it should be the default, too much trouble with it
286 2016-05-12T10:30:58  *** gill3s has quit IRC
287 2016-05-12T10:31:48  <jonasschnelli> Yes. That's what I was thinking. Though, the menu itself can be helpful. But the global menu space problem and the issues we always see with the tray menu make me think so.
288 2016-05-12T10:32:29  *** fengling has quit IRC
289 2016-05-12T10:32:51  *** PaulCapestany has quit IRC
290 2016-05-12T10:32:56  *** fengling has joined #bitcoin-core-dev
291 2016-05-12T10:34:08  <wumpus> the right way to do this on ubuntu would be the 'launcher menu' route. But due to the practical concern with distributing GUI binaries on linux that'd only work, at most, for the ppa as that is custom-built for ubuntu
292 2016-05-12T10:34:10  *** PaulCapestany has joined #bitcoin-core-dev
293 2016-05-12T10:38:48  <wumpus> in any case I'll try on ubuntu 16.04 too and see if I can reproduce 8043
294 2016-05-12T10:42:36  *** fengling has quit IRC
295 2016-05-12T10:43:59  *** fengling has joined #bitcoin-core-dev
296 2016-05-12T10:53:07  <jonasschnelli> wumpus: thanks.
297 2016-05-12T11:01:12  *** achow101 has joined #bitcoin-core-dev
298 2016-05-12T11:14:26  <GitHub176> [bitcoin] MarcoFalke opened pull request #8047: [qa] test_framework: Set wait-timeout for bitcoind procs (master...Mf1605-qaUtilTimeout) https://github.com/bitcoin/bitcoin/pull/8047
299 2016-05-12T11:16:06  <GitHub130> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c8558da362f...169d379c9835
300 2016-05-12T11:16:06  <GitHub130> bitcoin/master 34ebceb Jonas Schnelli: [Qt][OSX] Fix Cmd-Q / Menu Quit shutdown on OSX
301 2016-05-12T11:16:07  <GitHub130> bitcoin/master 169d379 Jonas Schnelli: Merge #8046: [Qt][OSX] Fix Cmd-Q / Menu Quit shutdown on OSX...
302 2016-05-12T11:16:15  <GitHub15> [bitcoin] jonasschnelli closed pull request #8046: [Qt][OSX] Fix Cmd-Q / Menu Quit shutdown on OSX (master...2016/05/fix_quit) https://github.com/bitcoin/bitcoin/pull/8046
303 2016-05-12T11:17:55  *** MarcoFalke_ has quit IRC
304 2016-05-12T11:26:11  *** cryptapus has joined #bitcoin-core-dev
305 2016-05-12T11:26:11  *** cryptapus has joined #bitcoin-core-dev
306 2016-05-12T11:32:00  *** Ginnarr has quit IRC
307 2016-05-12T11:49:57  *** fengling has quit IRC
308 2016-05-12T11:50:29  *** gill3s has joined #bitcoin-core-dev
309 2016-05-12T11:51:22  *** molz has joined #bitcoin-core-dev
310 2016-05-12T11:52:42  <GitHub194> [bitcoin] laanwj opened pull request #8048: doc: Remove outdated qt4 install information from README.md (master...2016_05_doc_noqt4) https://github.com/bitcoin/bitcoin/pull/8048
311 2016-05-12T11:58:17  *** murch has joined #bitcoin-core-dev
312 2016-05-12T12:11:05  *** gill3s has quit IRC
313 2016-05-12T12:11:38  *** gill3s has joined #bitcoin-core-dev
314 2016-05-12T12:16:27  *** molz has quit IRC
315 2016-05-12T12:16:45  *** molz has joined #bitcoin-core-dev
316 2016-05-12T12:23:37  *** murch1 has joined #bitcoin-core-dev
317 2016-05-12T12:24:10  *** jtimon has joined #bitcoin-core-dev
318 2016-05-12T12:25:08  *** murch has quit IRC
319 2016-05-12T12:27:33  <GitHub159> [bitcoin] laanwj opened pull request #8049: Expose information on whether transaction relayed is enabled in `getnetwork` (master...2016_05_rpc_relaytxes) https://github.com/bitcoin/bitcoin/pull/8049
320 2016-05-12T12:28:07  <GitHub116> [bitcoin] laanwj closed pull request #7841: Expose information on whether transaction relayed is enabled in getnetwork (master...patch-2) https://github.com/bitcoin/bitcoin/pull/7841
321 2016-05-12T12:32:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
322 2016-05-12T12:43:47  *** xiangfu has quit IRC
323 2016-05-12T12:45:26  *** xiangfu has joined #bitcoin-core-dev
324 2016-05-12T13:07:41  *** gill3s has quit IRC
325 2016-05-12T13:08:18  *** gill3s has joined #bitcoin-core-dev
326 2016-05-12T13:10:13  *** CubicEarth has quit IRC
327 2016-05-12T13:10:28  *** CubicEarth has joined #bitcoin-core-dev
328 2016-05-12T13:11:43  *** CubicEarth has quit IRC
329 2016-05-12T13:12:17  *** CubicEarth has joined #bitcoin-core-dev
330 2016-05-12T13:20:22  *** CubicEarth has quit IRC
331 2016-05-12T13:20:35  *** CubicEarth has joined #bitcoin-core-dev
332 2016-05-12T13:37:53  *** Chris_Stewart_5 has quit IRC
333 2016-05-12T13:39:55  *** fengling has joined #bitcoin-core-dev
334 2016-05-12T13:40:30  *** TomMc has joined #bitcoin-core-dev
335 2016-05-12T13:41:47  *** zooko has quit IRC
336 2016-05-12T13:44:36  *** fengling has quit IRC
337 2016-05-12T13:47:39  *** CubicEarth has quit IRC
338 2016-05-12T13:48:15  *** CubicEarth has joined #bitcoin-core-dev
339 2016-05-12T13:50:05  <BlueMatt> gmaxwell: still need it benchmarked?
340 2016-05-12T13:50:32  <gmaxwell> BlueMatt: we got skylake numbers from jonasschnelli
341 2016-05-12T13:51:51  <BlueMatt> kk
342 2016-05-12T13:54:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
343 2016-05-12T13:59:11  *** BonyM has quit IRC
344 2016-05-12T13:59:58  *** gill3s has quit IRC
345 2016-05-12T14:01:50  *** BonyM has joined #bitcoin-core-dev
346 2016-05-12T14:02:00  *** MarcoFalke has joined #bitcoin-core-dev
347 2016-05-12T14:14:07  *** Giszmo has joined #bitcoin-core-dev
348 2016-05-12T14:28:53  <jonasschnelli> wumpus: benchmark results of full reindex up to height 400'000
349 2016-05-12T14:29:08  <jonasschnelli> master, std sha: 8'431 seconds
350 2016-05-12T14:29:13  <jonasschnelli> rorx: 7'836
351 2016-05-12T14:30:41  *** xiangfu has quit IRC
352 2016-05-12T14:35:36  *** xiangfu has joined #bitcoin-core-dev
353 2016-05-12T14:37:34  <instagibbs> jonasschnelli, what is this line doing? https://github.com/bitcoin/bitcoin/pull/8035/files#diff-fcc78df4b7178e5b09f83f38196fef8bR59
354 2016-05-12T14:37:39  <instagibbs> I suppose I don't get the serialization code well enough
355 2016-05-12T14:38:22  *** G1lius has joined #bitcoin-core-dev
356 2016-05-12T14:46:20  *** paveljanik has joined #bitcoin-core-dev
357 2016-05-12T14:48:37  *** laurentmt has joined #bitcoin-core-dev
358 2016-05-12T14:48:43  *** laurentmt has quit IRC
359 2016-05-12T14:52:38  *** Guyver2 has quit IRC
360 2016-05-12T14:59:21  *** CubicEarth has quit IRC
361 2016-05-12T14:59:33  *** CubicEarth has joined #bitcoin-core-dev
362 2016-05-12T15:09:16  *** MarcoFalke has quit IRC
363 2016-05-12T15:10:29  *** earlest has joined #bitcoin-core-dev
364 2016-05-12T15:13:34  *** muuqwaul has quit IRC
365 2016-05-12T15:15:16  <jonasschnelli> instagibbs: i think this line is not required. I guess I copied this from another class. Will have a look soon.
366 2016-05-12T15:15:21  *** zooko has joined #bitcoin-core-dev
367 2016-05-12T15:15:35  <instagibbs> ok, that's my only ? left. Thanks
368 2016-05-12T15:15:54  <luke-jr> it's doing something there
369 2016-05-12T15:16:07  <luke-jr> nVersion is the method param, not the class var
370 2016-05-12T15:16:17  <luke-jr> I think READWRITE uses it?
371 2016-05-12T15:16:37  <luke-jr> definitely needs better docs
372 2016-05-12T15:16:44  <instagibbs> ... what
373 2016-05-12T15:16:54  <luke-jr> +    inline void SerializationOp(Stream& s, Operation ser_action, int nType, int nVersion)
374 2016-05-12T15:16:55  <instagibbs> oh
375 2016-05-12T15:16:56  <instagibbs> right
376 2016-05-12T15:17:41  <luke-jr> I suggest renaming one of the nVersions
377 2016-05-12T15:17:48  <luke-jr> as-is, this is obfuscated code
378 2016-05-12T15:18:04  <instagibbs> agreed
379 2016-05-12T15:18:06  <jonasschnelli> Yes. Will rename it.
380 2016-05-12T15:18:35  <jonasschnelli> I think I took it 1:1 from CKeyMetadata
381 2016-05-12T15:21:18  *** zooko` has joined #bitcoin-core-dev
382 2016-05-12T15:22:04  *** zooko has quit IRC
383 2016-05-12T15:28:38  *** zooko`` has joined #bitcoin-core-dev
384 2016-05-12T15:30:07  *** zooko` has quit IRC
385 2016-05-12T15:30:33  *** BashCo has quit IRC
386 2016-05-12T15:31:12  *** BashCo has joined #bitcoin-core-dev
387 2016-05-12T15:35:19  *** BashCo has quit IRC
388 2016-05-12T15:43:55  *** fengling has joined #bitcoin-core-dev
389 2016-05-12T15:44:48  *** laurentmt has joined #bitcoin-core-dev
390 2016-05-12T15:47:56  *** fengling has quit IRC
391 2016-05-12T16:04:01  *** bysherper has joined #bitcoin-core-dev
392 2016-05-12T16:06:42  *** CubicEarth has quit IRC
393 2016-05-12T16:07:04  *** earlest has quit IRC
394 2016-05-12T16:10:15  *** zooko`` has quit IRC
395 2016-05-12T16:13:53  *** laurentmt has quit IRC
396 2016-05-12T16:23:48  *** xiangfu has quit IRC
397 2016-05-12T16:28:05  *** earlest has joined #bitcoin-core-dev
398 2016-05-12T16:31:04  *** bysherper has quit IRC
399 2016-05-12T16:35:03  *** Don_John has joined #bitcoin-core-dev
400 2016-05-12T16:44:42  *** fengling has joined #bitcoin-core-dev
401 2016-05-12T16:49:36  *** fengling has quit IRC
402 2016-05-12T16:58:13  *** zooko has joined #bitcoin-core-dev
403 2016-05-12T16:58:25  *** kadoban has joined #bitcoin-core-dev
404 2016-05-12T16:59:10  *** PRab_ has joined #bitcoin-core-dev
405 2016-05-12T17:01:52  *** G1lius has quit IRC
406 2016-05-12T17:02:41  *** cryptapus_ has joined #bitcoin-core-dev
407 2016-05-12T17:03:04  *** PRab has quit IRC
408 2016-05-12T17:03:12  *** PRab_ is now known as PRab
409 2016-05-12T17:04:44  *** PRab has quit IRC
410 2016-05-12T17:05:09  *** PRab has joined #bitcoin-core-dev
411 2016-05-12T17:05:30  *** cryptapus_ has quit IRC
412 2016-05-12T17:05:41  *** cryptapus_ has joined #bitcoin-core-dev
413 2016-05-12T17:05:42  *** cryptapus_ has joined #bitcoin-core-dev
414 2016-05-12T17:05:46  *** cryptapus has quit IRC
415 2016-05-12T17:06:52  *** PRab_ has joined #bitcoin-core-dev
416 2016-05-12T17:09:45  *** PRab has quit IRC
417 2016-05-12T17:09:54  *** PRab_ is now known as PRab
418 2016-05-12T17:11:42  *** PRab_ has joined #bitcoin-core-dev
419 2016-05-12T17:15:00  *** PRab_ is now known as PRab
420 2016-05-12T17:22:27  *** PRab has quit IRC
421 2016-05-12T17:27:37  *** TomMc has quit IRC
422 2016-05-12T17:28:54  *** BashCo has joined #bitcoin-core-dev
423 2016-05-12T17:41:07  *** TomMc has joined #bitcoin-core-dev
424 2016-05-12T17:42:08  *** cryptapus_ is now known as cryptapus
425 2016-05-12T17:55:27  *** jcorgan has joined #bitcoin-core-dev
426 2016-05-12T17:59:22  *** Guyver2 has joined #bitcoin-core-dev
427 2016-05-12T18:14:24  *** Chris_Stewart_5 has quit IRC
428 2016-05-12T18:17:27  <wumpus> jonasschnelli: nice, that's quite an improvement
429 2016-05-12T18:18:11  <jonasschnelli> wumpus: Yes. I guess most reindex work in ECDSA and not SHA. So yes. It's an impressive improvement.
430 2016-05-12T18:18:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
431 2016-05-12T18:18:24  <jonasschnelli> I guess during a synced state the improvements are even more visible.
432 2016-05-12T18:18:40  <jcorgan> are there still thursday weekly dev meetings here?
433 2016-05-12T18:18:46  <wumpus> yes
434 2016-05-12T18:18:47  <helo> yes
435 2016-05-12T18:19:10  <gmaxwell> not for another 45 minutes.
436 2016-05-12T18:19:17  <jcorgan> ah, off by an hour
437 2016-05-12T18:21:37  *** zooko has quit IRC
438 2016-05-12T18:38:41  *** kadoban has quit IRC
439 2016-05-12T18:40:01  *** droark has joined #bitcoin-core-dev
440 2016-05-12T18:41:43  <droark> Hi. Question about PR #7972. It adds a new file (qa/rpc-tests/create_cache.py) that creates a cache used, I assume, to assist with parallelizing the qa/rpc-tests code. I don't quite understand this. Can somebody help me out? TIA.
441 2016-05-12T18:43:45  *** bysherper has joined #bitcoin-core-dev
442 2016-05-12T18:44:00  <jonasschnelli> droark: You might need to ask MarcoFalke. But IIRC, you need to create the cache before you run the script in parallel because you run into the risk of different cache versions...
443 2016-05-12T18:44:23  <sdaftuar> jonasschnelli: droark: right, i assume it's to avoid having two jobs try to do it at the same time
444 2016-05-12T18:45:45  <droark> Sounds reasonable. What exactly is being cached, though? The results? The runtime environment for each instance? Something else?
445 2016-05-12T18:45:49  *** murch1 is now known as murch
446 2016-05-12T18:46:01  <sdaftuar> droark: it's a cached blockchain
447 2016-05-12T18:46:34  *** earlest has quit IRC
448 2016-05-12T18:46:37  <sdaftuar> take a look at initialize_chain in qa/rpc_tests/test_framework/util.py
449 2016-05-12T18:47:35  <droark> Ahhh. Thanks! I'll ping Marco and double check the code but it sounds right.
450 2016-05-12T18:47:52  *** fengling has joined #bitcoin-core-dev
451 2016-05-12T18:48:20  <lclc> Is anyone of the devs who are coming to Zurich arriving the day before (Thursday) ?
452 2016-05-12T18:48:40  <sipa> i'll be there on thursday evening
453 2016-05-12T18:49:48  <jcorgan> i get there thu evening as well
454 2016-05-12T18:49:49  <lclc> That doesn't surprise me :D   I'm asking because I'd like to organize a meetup the evening before so the community also has something from the event :)
455 2016-05-12T18:50:03  <jcorgan> well, 6pm at the airport
456 2016-05-12T18:51:14  <lclc> Would be cool if someone would give a talk - topic is up to you.   Our meetups are 30-110 people, free to attend, and recorded (www.bitcoinlectures.tv - YT Channel)
457 2016-05-12T18:51:41  *** laurentmt has joined #bitcoin-core-dev
458 2016-05-12T18:52:37  *** fengling has quit IRC
459 2016-05-12T19:00:16  <wumpus> I'm also arriving in zurich thursday evening
460 2016-05-12T19:00:20  <sdaftuar> meeting time?
461 2016-05-12T19:00:40  <wumpus> #meetingstart
462 2016-05-12T19:00:42  <petertodd> yup
463 2016-05-12T19:00:44  <wumpus> #startmeeting
464 2016-05-12T19:00:44  <lightningbot> Meeting started Thu May 12 19:00:44 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
465 2016-05-12T19:00:44  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
466 2016-05-12T19:01:12  <BlueMatt> topics?
467 2016-05-12T19:01:37  <wumpus> from last week:
468 2016-05-12T19:01:48  <wumpus> add a file bip-0009/assignments.md in the bips repository:  btcdrak made a pull for that
469 2016-05-12T19:02:05  <wumpus> discuss testnet activation date on bitcoin-dev mailing list
470 2016-05-12T19:02:15  <wumpus> ead bluematt's compact block bip
471 2016-05-12T19:02:19  <wumpus> +r
472 2016-05-12T19:02:33  *** jannes has quit IRC
473 2016-05-12T19:02:59  <wumpus> #link https://github.com/bitcoin/bips/pull/386
474 2016-05-12T19:03:30  <wumpus> any other topic proposals?
475 2016-05-12T19:03:31  <luke-jr> on that note, it'd be nice if people didn't ACK/NACK bips they are not a listed author of ;)
476 2016-05-12T19:04:14  <sipa> was segwit testnet discussed on the ml?
477 2016-05-12T19:04:19  <kanzure> luke-jr: please elaborate.
478 2016-05-12T19:04:25  <BlueMatt> re: compact block, got good feedback from a few, made some slight tweaks but need to finish tweaks in the coming days, so no need to discuss here, I think?
479 2016-05-12T19:05:06  <luke-jr> kanzure: when it comes to a BIP draft, the only ACK/NACK that matters is the Author(s); others posting ACK/NACK just makes me spend time looking at the Author header to confirm I need to ignore it
480 2016-05-12T19:05:12  <wumpus> well in the case of #386 I felt I had the right to give my opinion because I was one of the people to come up with the idea last meeting, even though I'm not listed as author
481 2016-05-12T19:05:28  <sipa> i guess the question is where BIPs are to be discussed
482 2016-05-12T19:05:38  <luke-jr> sipa: bitcoin-dev ML
483 2016-05-12T19:05:40  <sipa> and the idea is that that would be the mailinglist
484 2016-05-12T19:05:43  <sipa> but...
485 2016-05-12T19:05:56  <kanzure> luke-jr: wouldn't NACKs from non-authors still be useful? why should the authors be the only trusted source of updates ? i don't understand.
486 2016-05-12T19:06:17  <instagibbs> oh, the compact blocks got a bip#
487 2016-05-12T19:06:29  <paveljanik> I don't understand either. If the author dies in accident, we can no longer change the BIP? or what?
488 2016-05-12T19:06:30  <morcos> luke-jr: i'd suggest that you just come up with a way to distinguish.   for instance ACK/NACK shoudl be interpreted by the author and the author shoudl say Approved or Ready or something for your knowledge on when to merge
489 2016-05-12T19:06:31  <wumpus> I agree that ack/nack isn't very useful, in comparison to more detailed comments
490 2016-05-12T19:06:31  <kanzure> luke-jr: i'm willing to believe you're right but you need better reasons yo.
491 2016-05-12T19:06:36  *** laurentmt has quit IRC
492 2016-05-12T19:06:40  <petertodd> kanzure: if I were author of a BIP an ACK would give me confidence; a NACK could be useful criticism
493 2016-05-12T19:06:42  <sipa> paveljanik: an active BIP can't be modified anyway
494 2016-05-12T19:06:43  <kanzure> wumpus: right, sure.
495 2016-05-12T19:06:48  <luke-jr> kanzure: the BIP is a document by the Author(s). ideally, they should have exclusive merge access for changes, but GitHub doesn't support that
496 2016-05-12T19:06:54  <paveljanik> text clarification, etc...
497 2016-05-12T19:06:59  <kanzure> okay this is just trivial though, luke-jr isn't going to stop me from ACKing on BIPs i didn't author :)
498 2016-05-12T19:07:04  <morcos> sipa: in some cases it should be, if for instance the BIP wording is incorrect ala 34
499 2016-05-12T19:07:18  <luke-jr> paveljanik: BIP 1 technically allows me to reassign BIP Author in some cases IIRC
500 2016-05-12T19:07:18  <sipa> morcos: yeah - makes sense
501 2016-05-12T19:07:39  <jonasschnelli> We should also define a rule how we deal with links to implementations that have implemented the BIP.
502 2016-05-12T19:07:48  <sipa> jonasschnelli: yes
503 2016-05-12T19:07:53  <jonasschnelli> IMO we should not add any implementation links.
504 2016-05-12T19:07:58  <jonasschnelli> (expect of sample impl.)
505 2016-05-12T19:08:00  <wumpus> many bips have a list of implementations; what's wrong with that?
506 2016-05-12T19:08:08  <jonasschnelli> Its just noisy
507 2016-05-12T19:08:12  <sipa> wumpus: in BIP32 there are continuously pull requests to add links
508 2016-05-12T19:08:16  <gmaxwell> it gets flooded with spammy updates.
509 2016-05-12T19:08:17  <wumpus> I think it can be useful to have e.g. implementations in many languages
510 2016-05-12T19:08:18  <jonasschnelli> And we don't control the implementations I guess
511 2016-05-12T19:08:20  <sipa> wumpus: which imho function as nothing more than advertizement
512 2016-05-12T19:08:26  <kanzure> and then we have to moderate the additions
513 2016-05-12T19:08:27  <jonasschnelli> sipa: Yes!
514 2016-05-12T19:08:30  <gmaxwell> And if we're not looking at it, we're eventually going to get a malware example BIP32 impl. :)
515 2016-05-12T19:08:32  <wumpus> ok...
516 2016-05-12T19:08:34  <luke-jr> BIP 2 comments would be a nice place to list implementations, but that was controverisal
517 2016-05-12T19:09:07  <jonasschnelli> I could imaging more and more advertising like PR to come up in future.
518 2016-05-12T19:09:12  <wumpus> I think the requirement should at least be to point to the code
519 2016-05-12T19:09:15  <wumpus> not just the product
520 2016-05-12T19:09:15  <paveljanik> so what is the topic now? ;-)
521 2016-05-12T19:09:22  <wumpus> to prevent advertizement
522 2016-05-12T19:09:32  <kanzure> i think the topic was "feedback about compact block relay BIP things"
523 2016-05-12T19:09:50  <jonasschnelli> Which still intersects (a little bit)
524 2016-05-12T19:10:13  <jcorgan> it is useful, however, when reading a BIP, to at least get pointed to reference code, but it need not be every implementation that anyone wants to list thereafter
525 2016-05-12T19:10:20  <wumpus> I think the topic is how to handle BIP implementations, which is as good a topic as anything
526 2016-05-12T19:10:48  <wumpus> but then you get the fight about what is reference code and what is not
527 2016-05-12T19:10:58  <jonasschnelli> Links are always difficult. You need to check them... then what if a link diverges from the BIP specification?
528 2016-05-12T19:11:07  <jonasschnelli> Do we check it?
529 2016-05-12T19:11:08  <wumpus> in some cases it's clear if the BIP author wrote code themselves
530 2016-05-12T19:11:13  <kanzure> yeah another threat vector is someone selling their github account in the future
531 2016-05-12T19:11:17  <kanzure> and then a BIP links to someone's github
532 2016-05-12T19:11:21  <jonasschnelli> Yes. These are the link we should keep there...
533 2016-05-12T19:11:33  <jcorgan> or the BIP author themselves pick one or more...
534 2016-05-12T19:11:38  <gmaxwell> If it's upfront then we can trust the bip author and review process to have had some chance to verify it.
535 2016-05-12T19:11:42  <wumpus> yes, I'd say it's up to the BIP author
536 2016-05-12T19:11:46  <wumpus> like other changes to the BIP
537 2016-05-12T19:11:46  <kanzure> other problem is keeping track of upstream updates like security fixes, oops. anyway, this is a lot of work.
538 2016-05-12T19:11:57  <kanzure> we should include hashes of the reference source code, in the BIP text
539 2016-05-12T19:11:58  <luke-jr> maybe BIP PRs should be PGP signed
540 2016-05-12T19:12:03  <wumpus> this is not something that should be globally decided
541 2016-05-12T19:12:16  <gmaxwell> I could see the criteria being different for different BIPs.
542 2016-05-12T19:12:19  <jonasschnelli> wumpus: Yes. This makes sense.
543 2016-05-12T19:12:20  <kanzure> by hashing the source code we can at least have a way for readers to verify that the source code is still the part we meant to hyperlink to :)
544 2016-05-12T19:12:22  <wumpus> gmaxwell: exactly
545 2016-05-12T19:12:33  <wumpus> I mean the author of bip32 could say 'enough is enough'
546 2016-05-12T19:12:43  <jcorgan> er, link to a URL and commit hash?
547 2016-05-12T19:12:44  <wumpus> some other BIPs have far fewer implementations and the author may be happy to see one
548 2016-05-12T19:12:48  <gmaxwell> (unfortunately, it's BIP32 that gets 95% of this-- key generation is an especially awkward place for random found on the internet code)
549 2016-05-12T19:12:52  <petertodd> my BIP65 links to two separate demo repos that just give some sample code, which is probably something we can generally consider as acceptable (ignoring the issue of more complex implementations that aren't pure demos)
550 2016-05-12T19:13:09  <jonasschnelli> I like jcorgan idea to link to sourcecode-only with a commit hash
551 2016-05-12T19:13:16  <jonasschnelli> But kinda static.
552 2016-05-12T19:13:30  <wumpus> Itend to agree with that. Link to the actual code, not the product
553 2016-05-12T19:14:11  <wumpus> not 'blawallet implements bip32', no, *the code linked here shows how we implemented BIP32 in language Z*
554 2016-05-12T19:14:29  <sipa> wumpus: agree
555 2016-05-12T19:14:29  <luke-jr> +1
556 2016-05-12T19:14:33  <petertodd> wumpus: +1
557 2016-05-12T19:14:39  <paveljanik> yes
558 2016-05-12T19:14:43  <jonasschnelli> ack
559 2016-05-12T19:14:49  <wumpus> ok
560 2016-05-12T19:14:54  <kanzure> we should review existing bips for source code links that do not include a commit hash. branch names are not OK.
561 2016-05-12T19:15:01  <kanzure> i mean, branch names without a commit hash are not OK.
562 2016-05-12T19:15:01  <wumpus> other topics?
563 2016-05-12T19:15:38  <paveljanik> Revies Jonas' HD - #8035
564 2016-05-12T19:15:56  <jonasschnelli> I have a tiny topic proposal that is very into the impl. teretorry..
565 2016-05-12T19:16:02  <jonasschnelli> RPC long poll notifications
566 2016-05-12T19:16:07  <kanzure> have we received an overview from sipa yet about areas of segwit that he feels should be most thoroughly reviewed
567 2016-05-12T19:16:12  <sipa> kanzure: no, sorry
568 2016-05-12T19:16:22  <kanzure> can we get 10 volunteers to heckle sipa about this?
569 2016-05-12T19:16:23  <sipa> thanks for the reminder
570 2016-05-12T19:16:34  <wumpus> #action Revies Jonas' HD - #8035
571 2016-05-12T19:16:52  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8035 ... very simple and easy to review
572 2016-05-12T19:17:12  <paveljanik> jonasschnelli, can you add some after-merge TODO list there?
573 2016-05-12T19:17:18  <jonasschnelli> I'm happy to add some RPC tests...
574 2016-05-12T19:17:36  <jonasschnelli> There is no required after-merge PR... thats the nice thing.
575 2016-05-12T19:17:49  <jonasschnelli> But most important we should enable flexible bip32 keypath
576 2016-05-12T19:17:50  <paveljanik> import, dump... at least...
577 2016-05-12T19:17:52  <instagibbs> jonasschnelli, a bit hard to rpc test without import/dump? (perhaps offline discussion)
578 2016-05-12T19:18:18  <jonasschnelli> There are concerns with importing single keys into the bip32 wallet...
579 2016-05-12T19:18:32  <jonasschnelli> They would not be covered by "a old backup"
580 2016-05-12T19:18:44  <wumpus> but that's kind of obvious :)
581 2016-05-12T19:18:51  <btcdrak> maybe need a sweep feature.
582 2016-05-12T19:19:06  <wumpus> yes, a sweep feature would be nice
583 2016-05-12T19:19:09  <jonasschnelli> There are plenty of possible features...
584 2016-05-12T19:19:24  <jonasschnelli> But because of the lack of reviewers,.. we need babysteps
585 2016-05-12T19:19:28  <sipa> let's not discuss all possible features
586 2016-05-12T19:19:29  <luke-jr> sweep would be nice, but non-trivial (currently no way to iterate over the UTXO set I think)
587 2016-05-12T19:19:38  <sipa> just what is necessary to work and test
588 2016-05-12T19:19:38  <jonasschnelli> agree with sipa.
589 2016-05-12T19:19:46  <jonasschnelli> Just review and ack it! :P
590 2016-05-12T19:19:48  <luke-jr> so what about RPC longpoll?
591 2016-05-12T19:19:49  <wumpus> I agree
592 2016-05-12T19:19:58  <sipa> if import/export is necessary for testing, then maybe some functionality for that is warranted
593 2016-05-12T19:20:00  <wumpus> scope creep agian
594 2016-05-12T19:20:23  <instagibbs> well, it only came up due to testing
595 2016-05-12T19:21:10  <wumpus> luke-jr: https://github.com/bitcoin/bitcoin/pull/7949
596 2016-05-12T19:21:19  <jonasschnelli> RPC long poll would would allow remote GUI and remote wallet with a very easy setup. IMO it could allow third party developers to write simple remote GUIS, web-frontends, etc.
597 2016-05-12T19:22:07  <jonasschnelli> I would even say RPC long poll has more potential then ZMQ for core.
598 2016-05-12T19:22:10  <wumpus> I'm kind of divided on the notification thing to be honest - I'd prefer to stick to only one notification mechanism in bitcoin core (apart from the silly -Xnotify), and somehow zmq got a precedent there
599 2016-05-12T19:22:41  <luke-jr> calling pollnotifications myself seems like it would disrupt an application relying on it?
600 2016-05-12T19:22:45  <jonasschnelli> I also don't like multiple notification channels.
601 2016-05-12T19:22:49  <luke-jr> ie, we need channels
602 2016-05-12T19:22:56  <jonasschnelli> But how would you connect a remote GUI over the internet...
603 2016-05-12T19:23:03  <luke-jr> wumpus: zmq is crazy though :<
604 2016-05-12T19:23:16  <luke-jr> also note we already have longpolling
605 2016-05-12T19:23:17  <wumpus> yes it should definitely have multiple channels, the current code supports only one client
606 2016-05-12T19:23:27  <jonasschnelli> wumpus: no
607 2016-05-12T19:23:28  <wumpus> luke-jr: where were you to NACK zmq when it was added?
608 2016-05-12T19:23:33  <jcorgan> i'm happy to look at improving zmq
609 2016-05-12T19:23:34  <luke-jr> jonasschnelli: no RPC over internet ever :<
610 2016-05-12T19:23:35  <jonasschnelli> I have added support for <n> clients
611 2016-05-12T19:23:50  <luke-jr> wumpus: just because zmq is crazy doesn't mean optional ZMQ support should be excluded ..
612 2016-05-12T19:23:50  <jonasschnelli> RPC over internet over a reverse proxy is a wide use pratice.
613 2016-05-12T19:23:55  <wumpus> (I don't think zmq is necessarily crazy)
614 2016-05-12T19:24:04  <jtimon> sorry, what are the complaints with zmq? it is optional anyway
615 2016-05-12T19:24:18  <wumpus> jtimon: I'm not sure either, it seems to be fashionable to complain about it
616 2016-05-12T19:24:21  <luke-jr> jtimon: it's not optional if it is an excuse to exclude other systems
617 2016-05-12T19:24:32  <luke-jr> zmq breaks protocol compatibility for minor bumps
618 2016-05-12T19:24:34  <jonasschnelli> Working towards decoupling of the GUI and the wallet requires well defined channels/APIs
619 2016-05-12T19:24:39  <luke-jr> ie, 4.1 won't work with 4.0 right
620 2016-05-12T19:25:00  <jonasschnelli> ZMQ would require a tunnel (VPN, stunnel, etc.).
621 2016-05-12T19:25:06  <luke-jr> also see all the Elements functionary problems due to ZMQ
622 2016-05-12T19:25:14  <jcorgan> ZMQ 4.x is implementing CurveCP
623 2016-05-12T19:25:18  <jtimon> I think it's a wonderful tool I would like to use more (although maybe the fact that its creator rewrote it completely in nanomsg may indeed indicate that some parts of zmq have become too complex)
624 2016-05-12T19:25:20  <wumpus> zmq is basically only useful for local system, but so is RPC, it's not meant to be used over the internet
625 2016-05-12T19:25:45  <jcorgan> see comment about curvecp
626 2016-05-12T19:25:54  <wumpus> if you write tunneling for RPC - why not tunnel the notifications too?
627 2016-05-12T19:26:00  <jonasschnelli> I just think Core users would love to have a GUI/wallet-frontend that can run on a different machine.
628 2016-05-12T19:26:11  <jcorgan> http://curvezmq.org/
629 2016-05-12T19:26:16  <jtimon> wumpus: exactly, it's for your intranet or at most inside a vpn (although I haven't tried that myself)
630 2016-05-12T19:26:19  <luke-jr> jonasschnelli: yes, for years now that has been desirable
631 2016-05-12T19:26:25  <wumpus> jonasschnelli: I agree, but does that need RPC notifications?
632 2016-05-12T19:26:28  <jonasschnelli> wumpus: RPC does work extremly well in reverse-proxy mode.
633 2016-05-12T19:26:30  <wumpus> jonasschnelli: what would you use it for?
634 2016-05-12T19:26:46  <luke-jr> wumpus: right now it requires polling
635 2016-05-12T19:26:51  <wumpus> e.g. to get notification of transactions/blocks the P2P protocol works fine
636 2016-05-12T19:26:53  <jonasschnelli> Look at rtorrent or any other RPC daemon software.
637 2016-05-12T19:27:32  <jonasschnelli> Polling is extremely inefficient. Long polling would allow clients to get "realtime" events while not require any other dependencies...
638 2016-05-12T19:27:37  <jonasschnelli> And the code changes are tiny...
639 2016-05-12T19:27:37  <wumpus> yes, agreed jonasschnelli
640 2016-05-12T19:27:47  <wumpus> yes the code changes are tiny
641 2016-05-12T19:28:09  <jonasschnelli> You could setup a save and secure remote bitcoind with a single apache/nginx config.
642 2016-05-12T19:28:18  <wumpus> but I'm a bit afraid the same will happen as with REST, people will want to pile up things on top, and now for every notification people will want zmq and rpc longpull support
643 2016-05-12T19:28:19  <jonasschnelli> Now do the same with ZMQ notifications... :)
644 2016-05-12T19:28:47  <wumpus> just like people want every possible data item both through RPC and REST
645 2016-05-12T19:29:00  <sipa> well ZMQ/P2P are suboptimal to write a remote GUI, as you can't filter for just wallet transactions
646 2016-05-12T19:29:03  <wumpus> I believe thatthere is value to  keeping core limited to one interface
647 2016-05-12T19:29:07  <luke-jr> wumpus: I don't see why this is a problem
648 2016-05-12T19:29:10  <jonasschnelli> Yes. If i had a blank paper. I would drop ZMQ and REST in favor or RPC longpoll and the normal RPC.
649 2016-05-12T19:29:32  <jcorgan> longpoll does indeed solve some of my original motivation for adding ZMQ
650 2016-05-12T19:29:32  <sipa> jonasschnelli: i think you're biased because you're only thinking about one use case
651 2016-05-12T19:29:37  <wumpus> well my iniitial idea for notifications was also something like longpoll, or a streaming socket
652 2016-05-12T19:29:41  <wumpus> then a proxy from that to zmq
653 2016-05-12T19:29:44  <wumpus> but zmq was first
654 2016-05-12T19:30:05  <luke-jr> zmq is optional
655 2016-05-12T19:30:15  <luke-jr> someone shouldn't need to install zmq for notifications
656 2016-05-12T19:30:17  <jtimon> zmq's req/rep could replace both rpc and rest
657 2016-05-12T19:30:19  <jonasschnelli> There is one big advantage of RPC long polling...
658 2016-05-12T19:30:26  <jonasschnelli> you can have private notifications...
659 2016-05-12T19:30:31  <jonasschnelli> secured behind auth
660 2016-05-12T19:30:34  <wumpus> do we want private notifications?
661 2016-05-12T19:30:35  <jonasschnelli> Like a new relevant wallet tx comes in
662 2016-05-12T19:30:43  <sipa> wumpus: for a remote wallet gui you do
663 2016-05-12T19:30:52  <jonasschnelli> It would be on the same level then the RPC security...
664 2016-05-12T19:30:56  <jonasschnelli> just instead of poll you can have push
665 2016-05-12T19:31:06  <wumpus> connect a remote wallet GUI through RPC?
666 2016-05-12T19:31:10  <wumpus> wasn't RPC meant to be for local usage?
667 2016-05-12T19:31:15  <jonasschnelli> I would not add this over ZMQ because of the unknown risks
668 2016-05-12T19:31:20  <luke-jr> jonasschnelli: btw FYI https://en.bitcoin.it/wiki/Wallet_protocol
669 2016-05-12T19:31:32  <jonasschnelli> wumpus: that is an argument.
670 2016-05-12T19:31:33  <wumpus> I think the idea was to attach a *wallet*, not a wallet GUI
671 2016-05-12T19:31:47  <wumpus> the wallet needs to be split from the core
672 2016-05-12T19:31:58  <luke-jr> a wallet can be attached over p2p fine
673 2016-05-12T19:32:01  <jonasschnelli> Another solution would be to provide a tiny daemon that would interact between core <-> remote GUI/wallet.
674 2016-05-12T19:32:15  <wumpus> I'd prefer for core to handle semi-public data, then have a more restricted wallet
675 2016-05-12T19:32:17  <jonasschnelli> But that tiny daemon would speak RPC with the outside/internet.
676 2016-05-12T19:32:20  <luke-jr> ideally we should have node <-> wallet <-> GUI
677 2016-05-12T19:32:47  <wumpus> luke-jr: yes
678 2016-05-12T19:32:51  <jonasschnelli> luke-jr: But how would you see the communication channel between wallet <> GUI?
679 2016-05-12T19:32:57  <jcorgan> another motivation for adding ZMQ was to allow bitcoind to be a trusted "border gateway", that spoke P2P and consensus, and then stuff behind it would be very simple ZMQ-based software that didn't need to know all about those things
680 2016-05-12T19:33:02  <wumpus> but wallet<->GUI could be a competely different protocol than node<->wallet
681 2016-05-12T19:33:02  <jonasschnelli> Needs to be bidirect.
682 2016-05-12T19:33:07  <luke-jr> jonasschnelli: see wiki link; or something like what you're doing
683 2016-05-12T19:33:15  <jonasschnelli> node <> wallet is probably p2p?
684 2016-05-12T19:33:19  <sipa> yes
685 2016-05-12T19:33:21  <luke-jr> yes
686 2016-05-12T19:33:45  <morcos> node <-> wallet being p2p leaves a lot of missing pieces
687 2016-05-12T19:33:46  <wumpus> maybe authentiated P2P
688 2016-05-12T19:33:47  <morcos> fee estimation
689 2016-05-12T19:33:47  <jonasschnelli> But what direction do we want to go for <wallet> <-> <gui>?
690 2016-05-12T19:33:48  <wumpus> as you proposed
691 2016-05-12T19:33:55  <wumpus> with some private extensions
692 2016-05-12T19:33:59  <sipa> jonasschnelli: up to the wallet
693 2016-05-12T19:34:06  <morcos> mempool actions (eviction, how close to top of mempool, whether it was accepted)
694 2016-05-12T19:34:12  <jonasschnelli> morcos: fee estimations can be done with authentication/private extensions.
695 2016-05-12T19:34:14  <BlueMatt> ehh, lets not layer everything onto p2p extensions
696 2016-05-12T19:34:23  <luke-jr> jonasschnelli: XMPP! /s
697 2016-05-12T19:34:26  *** d4de has joined #bitcoin-core-dev
698 2016-05-12T19:34:38  <jtimon> why people want to remove zmq? I still don't undesrtand
699 2016-05-12T19:34:41  <jonasschnelli> sipa: That's why I propose RPC long poll (as a "wallet" feature). :)
700 2016-05-12T19:34:55  <sipa> jonasschnelli: i'm not sure our wallet should provide that
701 2016-05-12T19:35:01  <sipa> jonasschnelli: at least not at this stage
702 2016-05-12T19:35:02  <wumpus> BlueMatt: well if we have a autenticated+encryped P2P protocol, adding private extensions is attractive
703 2016-05-12T19:35:27  <wumpus> jtimon: I don't want to remove zmq. But I do think we should have one notification mechanism.
704 2016-05-12T19:35:39  <kanzure> notifications over zeromq would be nice
705 2016-05-12T19:35:42  <jtimon> wumpus: why not it be zmq?
706 2016-05-12T19:35:43  <luke-jr> jtimon: I just want to keep ZMQ as an optional feature, not necessary for this stuff
707 2016-05-12T19:35:55  <wumpus> jtimon: I don't want to amintain an endless pile-up of different external notification mechanisms
708 2016-05-12T19:36:08  <jonasschnelli> Yes. We don't want that.
709 2016-05-12T19:36:10  <jtimon> wumpus: ok, why not use ONLY zmq?
710 2016-05-12T19:36:10  <BlueMatt> wumpus: its quite attractive to shove everything into one monolithic protocol, indeed, but I do think there is a lot of value in splitting things out (though I wouldnt be upset if they were logically different code that just happened to have the same on-wire protocol or so)
711 2016-05-12T19:36:11  <jcorgan> jtimon: i agree that zmq req/rep and pub/sub could provide the entirety of needed interfaces to bitcoind, but that's an argument lost years ago :)
712 2016-05-12T19:36:23  <luke-jr> jtimon: then it's no longer optional
713 2016-05-12T19:36:24  <kanzure> unfortunately the simplest private notification stuff that the rest of the community would understand would be.... web hooks. :(
714 2016-05-12T19:36:39  <luke-jr> jcorgan: except ZMQ has no protocol compatibility
715 2016-05-12T19:36:44  <wumpus> websocket would work
716 2016-05-12T19:36:49  <morcos> wumpus: i think we can move towards deprecating some things that we view as redundant.  what we should do now though is decide what would work for a node <-> wallet communication protocol.  b/c that is something we defintiely want.
717 2016-05-12T19:36:56  <jtimon> luke-jr: ok, either we have 1, we remove zmq or we make it non-optional
718 2016-05-12T19:36:59  <luke-jr> wumpus: websocket doesn't define a protocol
719 2016-05-12T19:37:03  <wumpus> but just as well as longpoll
720 2016-05-12T19:37:08  <jonasschnelli> websockets have bad security
721 2016-05-12T19:37:24  <sipa> wumpus: i think it may be reasonable to say that zmq is for node notifications (which are unauthenticated) and longpoll for wallet notifications
722 2016-05-12T19:37:26  <luke-jr> jtimon: if we can only have 1, then IMO zmq can go
723 2016-05-12T19:37:30  <wumpus> morcos: what would you propose to deprecate?
724 2016-05-12T19:37:33  <jtimon> luke-jr: what do you mean by "protocol compatibility"?
725 2016-05-12T19:37:40  <luke-jr> jtimon: but I don't think we should limit to 1
726 2016-05-12T19:37:50  <wumpus> sipa: but what jonasschnelli wants is not wallet notifications
727 2016-05-12T19:37:51  <luke-jr> jtimon: ZMQ 4.0 can't talk to ZMQ 4.1
728 2016-05-12T19:37:53  <jtimon> luke-jr: and IMO, if we only want to have one, zmq should stay
729 2016-05-12T19:37:55  <sipa> wumpus: yes it is
730 2016-05-12T19:38:01  <wumpus> sipa: he wants the same stuff as is now offered over zmq
731 2016-05-12T19:38:08  <jonasschnelli> wumpus sipa: What i want is going toward wallet notifications
732 2016-05-12T19:38:11  <morcos> wumpus: well my argument is to first define the right way to do node <-> wallet and then do that (even if it means adding something) and then we can revisit and see what we have that is extraneous
733 2016-05-12T19:38:17  <jonasschnelli> But also notifications that could enable a remote GUI
734 2016-05-12T19:38:21  <sipa> i don't think so; nothing of what is offered over ZMQ is what you need for a remote wallet GUI
735 2016-05-12T19:38:21  <jonasschnelli> (mempool / peers, etc9
736 2016-05-12T19:38:38  <jonasschnelli> A Core node GUI on a smartphone....
737 2016-05-12T19:38:47  <jonasschnelli> Which can't work over ZMQ
738 2016-05-12T19:39:05  <sipa> i think we shouldn't discuss that in the current stage
739 2016-05-12T19:39:07  <jcorgan> of course it *could*
740 2016-05-12T19:39:15  <jcorgan> but not as it is written today
741 2016-05-12T19:39:25  <wumpus> jonasschnelli: how would you protect the RPC connection to the smartphone?
742 2016-05-12T19:39:26  <sipa> i don't want my bitcoin core full node software to be accessible by smartphones on the internet, i think
743 2016-05-12T19:39:29  <kanzure> jcorgan: how much difference?
744 2016-05-12T19:39:34  <wumpus> jonasschnelli: the same tunneling tool could route the notifications from zmq
745 2016-05-12T19:39:39  <jcorgan> zmq is a transport
746 2016-05-12T19:39:40  <jonasschnelli> wumpus: reverse proxy, SSL auth, mod_security
747 2016-05-12T19:39:44  <sipa> except the p2p protocol, which is must provide by necessarily
748 2016-05-12T19:39:49  <morcos> jonasschnelli: don't you think we shoudl concentrate on node <-> wallet now?  b/c then different people could build different wallet <-> gui protocols if we wanted.  our core responsiblity is the node
749 2016-05-12T19:39:57  <jcorgan> you have to define a protocol/serialization/encapsulation to run over it
750 2016-05-12T19:39:59  <luke-jr> jcorgan: except then you need to make sure your ZMQ lib versions match, which is just annoying
751 2016-05-12T19:40:15  <jcorgan> you can say that about dozens of other libs
752 2016-05-12T19:40:17  <jonasschnelli> morcos: I'm working on node <-> wallet. That's why I'm working on auth/enc. :)
753 2016-05-12T19:40:23  <jtimon> jonasschnelli: how can something "not work over ZMQ"? can't you proxy the messages through some other protocol outside of bitcoind once you get the zmq messages?
754 2016-05-12T19:40:35  <luke-jr> jcorgan: most protocols are compatible across lib versions
755 2016-05-12T19:40:37  <sipa> jtimon: because authentication
756 2016-05-12T19:40:37  <jonasschnelli> I don't want to talk SPV over unencrypted channels...
757 2016-05-12T19:40:49  <kanzure> unencrypted...?
758 2016-05-12T19:40:51  <jcorgan> anyway, if anyone wants to pursue making changes to the current zmq implementation, we can talk in zurich about it
759 2016-05-12T19:40:52  <wumpus> wellt he same protocol that offers RPC over the internet needs authentication too
760 2016-05-12T19:40:54  <jonasschnelli> jtimon: Sure can you. But can a normal user do that?
761 2016-05-12T19:40:57  <wumpus> you have exactly the same problem there
762 2016-05-12T19:41:25  <jonasschnelli> I just compared the requirements to setup a remote rtorrent GUI with a possible remote Core node GUI.
763 2016-05-12T19:41:46  <wumpus> in any case, I'm not strongly against longpoll RPC notifications
764 2016-05-12T19:41:52  <jtimon> jonasschnelli: well, what was your "normal user" using isntead of zmq?
765 2016-05-12T19:41:54  <jonasschnelli> And i feal that rpc long polls would result in a easy setup...
766 2016-05-12T19:42:14  <sipa> morcos, wumpus, jonasschnelli: i agree node <-> wallet is what we should be talking about first, and the apparent need to add private extensions is a sign of a deeper problem: an SPV wallet without trusted full node will be lacking in features
767 2016-05-12T19:42:22  <kanzure> easiest setup for non-core-developers is going to be web hooks :(
768 2016-05-12T19:42:36  <kanzure> not rpc
769 2016-05-12T19:42:50  <d4de> 0MQ supports GSSAPI and Curve auth, unencrypted?!
770 2016-05-12T19:42:54  <wumpus> and indeed, RPC longpoll can be supported without linking against external dependencies
771 2016-05-12T19:42:56  <morcos> sipa: good point, but maybe thats a separate problem to solve?
772 2016-05-12T19:42:57  <wumpus> which is an advantage
773 2016-05-12T19:42:59  <jonasschnelli> </rpc-long-poll-advertizing> I'm happy to keep the PR alive... I'll also try to work on a intermediate script that could -> ZMQ and does -> RPC
774 2016-05-12T19:43:17  <sipa> morcos: well if that problem is solved (unsure how...), maybe we don't need private extensions :)
775 2016-05-12T19:43:37  <sipa> jonasschnelli: you can't... ZMQ doesn't offer wallet-filtered events
776 2016-05-12T19:43:38  <morcos> yes, but it'll always be superior to some degree to have access to a trusted node
777 2016-05-12T19:43:44  <instagibbs> sipa, do you mean things like access to mempool, etc?
778 2016-05-12T19:43:49  <wumpus> at the least we should make a clear division about *what* should be offered over RPC longpoll and what over zmq and what over (theoretic) P2P extensions
779 2016-05-12T19:43:51  <sipa> instagibbs: yes, and fee estimation
780 2016-05-12T19:43:51  <morcos> so we shouldn't limit ourselves to things that you can't do without that
781 2016-05-12T19:43:52  <jonasschnelli> sipa: you still can talk RPC...
782 2016-05-12T19:43:57  <wumpus> so not everything ends up on all three
783 2016-05-12T19:44:07  <jonasschnelli> sipa: just the notifications need to be ZMQ to avoid polling..
784 2016-05-12T19:44:09  <instagibbs> even if you have access to full node over p2p, that doesn't get you that (maybe that's what you meant)
785 2016-05-12T19:44:28  <jonasschnelli> sipa: thats why I think adding long poll would not change the security aspect.
786 2016-05-12T19:44:42  <sipa> jonasschnelli: but you don't want to send a ZMQ event for every transaction over the wire... that would consume as much bandwidth as just the p2p protocol
787 2016-05-12T19:44:55  <wumpus> adding longpoll to RPC won't change any security aspect
788 2016-05-12T19:45:02  <luke-jr> more, since ZMQ is ASCII :P
789 2016-05-12T19:45:07  <sipa> luke-jr: wut?
790 2016-05-12T19:45:09  <kanzure> rpc thread count exhaustion might change a security aspect
791 2016-05-12T19:45:17  <wumpus> (except if it encourages opening up your RPC port to the internet)
792 2016-05-12T19:45:20  <jonasschnelli> sipa: Right. Long poll could then be extended to relevant wallet txes.
793 2016-05-12T19:45:25  *** d4de has quit IRC
794 2016-05-12T19:45:25  <wumpus> kanzure: you need user/pass for that, so only the owner can attack it
795 2016-05-12T19:45:37  <wumpus> kanzure: I would be against unauthenticated longpolls, that's for sure
796 2016-05-12T19:45:47  <luke-jr> sipa: at least the main protocol design (it transmits binary data as-is, IIRC)
797 2016-05-12T19:45:52  <wumpus> kanzure: and if you can authenticate you can do *much* worse things than hold up threads
798 2016-05-12T19:45:59  <jtimon> sipa: of course you can filter stuff with zmq, you can do anything with zmq, is "network complete"
799 2016-05-12T19:46:17  <jtimon> you may need more processes
800 2016-05-12T19:46:23  <sipa> jtimon: that's like saying that x86 asm is better than http, because it can do everything
801 2016-05-12T19:46:35  <jonasschnelli> Another + for RPC long poll: no dependencies...
802 2016-05-12T19:46:36  <sipa> jtimon: of course you can filter, but the filter would be too late
803 2016-05-12T19:46:41  <wumpus> so anyhow: I'd say continue your work jonasschnelli
804 2016-05-12T19:46:46  <jtimon> sipa: I really don't undesrtand what you claim can't be done with zmq
805 2016-05-12T19:46:46  <kanzure> my zeromq person just left the channel in a huff ("these people are retarded") hah...
806 2016-05-12T19:46:53  <jonasschnelli> wumpus: Okay.. I keep the PR warm.
807 2016-05-12T19:47:03  <luke-jr> again, we ALREADY have longpolling, so I don't see why make a big deal of it
808 2016-05-12T19:47:19  <jtimon> sipa: you want to filter by a set of addresses or something?
809 2016-05-12T19:47:19  <jonasschnelli> luke-jr: Yes. It's not a big deal...
810 2016-05-12T19:47:32  <sipa> jtimon: we don't want ZMQ to be authenticated, so it can't provide wallet-specific information, which means the ZMQ client will need to do the filtering
811 2016-05-12T19:47:40  <wumpus> people seem to have trouble to get zmq to work in practice, maybe if you can provide some easy examples for RPC longpolling then it will be the more popular way to do notifications soon
812 2016-05-12T19:47:42  <jonasschnelli> sipa: Agree
813 2016-05-12T19:47:49  <sipa> jtimon: which is duplicating logic, because that's something the wallet should do, not the gui
814 2016-05-12T19:47:58  <jonasschnelli> wumpus: Okay. I'll add some examples... good point!
815 2016-05-12T19:48:02  <wumpus> (I had so much trouble convincing joinmarket to use zmq notifications instead of wacky -notifyX scripts that I just gave u)
816 2016-05-12T19:48:11  <luke-jr> LP is really simple. just make a normal request and wait ☺
817 2016-05-12T19:48:15  <jonasschnelli> wumpus: hah .. yes. Another +1 for RPC long poll. :)
818 2016-05-12T19:48:27  <wumpus> maybe it's the extra dependency, maybe it's unfamiliarity, I don't know.
819 2016-05-12T19:48:31  <jonasschnelli> People will call exes on every transaction...
820 2016-05-12T19:48:37  <jtimon> sipa: oh, you don't want authenticated connections going through zmq processes...I don't undesrtand why, but ok, that seems to be the piece I was missing
821 2016-05-12T19:48:39  <sipa> jtimon: so yes, of course, you can do anything, if you reimplement the wallet in the client, but that was exactly what we were trying to avoid :)
822 2016-05-12T19:48:47  <gmaxwell> luke-jr: lots of things time out.
823 2016-05-12T19:48:58  <jonasschnelli> gmaxwell: time out doesnt matter
824 2016-05-12T19:48:58  <gmaxwell> this discussion seems ratholed.
825 2016-05-12T19:49:07  <jonasschnelli> Because you have a queue/state on the server
826 2016-05-12T19:49:14  *** fengling has joined #bitcoin-core-dev
827 2016-05-12T19:49:15  <wumpus> timeout doesn't matter with longpoll, you can just re-request
828 2016-05-12T19:49:19  <jtimon> sipa: no, I would just use some kind of authentication
829 2016-05-12T19:49:21  <kanzure> we need more user metric survey data about whehter rpc is really easy for folks. i think all the web app developers only know web hooks and HTTP.
830 2016-05-12T19:49:51  <wumpus> kanzure: moving away from JSON-RPC as the main RPC API is out of the question at this stage
831 2016-05-12T19:50:02  <wumpus> just too much software and libraries that assume it
832 2016-05-12T19:50:07  <sipa> are there other topics?
833 2016-05-12T19:50:20  <kanzure> er i did not mean to unintentionally advocate for moving away from json-rpc
834 2016-05-12T19:50:52  <wumpus> doesn't seem to be
835 2016-05-12T19:51:11  <wumpus> #endmeeting
836 2016-05-12T19:51:11  <lightningbot> Meeting ended Thu May 12 19:51:11 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
837 2016-05-12T19:51:11  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-12-19.00.html
838 2016-05-12T19:51:11  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-12-19.00.txt
839 2016-05-12T19:51:11  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-05-12-19.00.log.html
840 2016-05-12T19:51:54  <jcorgan> do we have any grand plans or even wishlists for zurich?
841 2016-05-12T19:52:06  <jtimon> kanzure: I did suggest replacing json-rpc with zmq json req/rep, but I knew very few people would consider it seriously
842 2016-05-12T19:52:18  <sipa> i'd like to talk about p2p encryption, segwit, signature aggregation, ...
843 2016-05-12T19:52:32  <jonasschnelli> Agree with sipa. We could also form groups to directly work on stuff.
844 2016-05-12T19:52:57  <sipa> but the overall goal should just be to facillitate improvements that are in the pipeline by meeting in face... whatever those improvements are
845 2016-05-12T19:52:59  <kanzure> i would like to do braindumps to get things written down
846 2016-05-12T19:53:18  <jonasschnelli> +1 for writing down things...
847 2016-05-12T19:53:22  <kanzure> i am good at this
848 2016-05-12T19:53:27  <jcorgan> suggest doing as much brainstorming/dumping in advance to not use precious F2F time
849 2016-05-12T19:53:55  <kanzure> would like to draw up list of too-often-unspoken proposals to write down more details about
850 2016-05-12T19:53:56  *** fengling has quit IRC
851 2016-05-12T19:54:09  <sipa> that'd be great
852 2016-05-12T19:54:14  <jonasschnelli> I think we should't feel too much pressure. The fact that we are meeting face to face alone is a value.
853 2016-05-12T19:54:22  <jcorgan> of course
854 2016-05-12T19:54:23  <sipa> agree
855 2016-05-12T19:54:37  <jonasschnelli> Even if there is no outcome. It would be a success.
856 2016-05-12T19:55:00  <kanzure> some feedback from d4de- he recommends that future bitcoin core meetings shoud have someone that more actively guides discussion, e.g. make things more explicit rather than implicit
857 2016-05-12T19:55:07  <wumpus> jtimon: right - there's no deep reason why zmq req/rep wouldn't work for the main RPC API, but it's .... unfamiliar for people, see my comment above about trying to get people to even use zmq for basic notifications
858 2016-05-12T19:55:14  <jcorgan> the face time is extremely valuable, just want to make the most of it
859 2016-05-12T19:55:17  <kanzure> jonasschnelli: gosh that sounds like one of those unreasonable metrics :) (kidding)
860 2016-05-12T19:55:34  <jonasschnelli> kanzure: It's called positiv thinking. :)
861 2016-05-12T19:55:35  <wumpus> kanzure: are you volunteering?
862 2016-05-12T19:56:01  <jcorgan> so if there are things that can be done ahead of time that don't necessarily need the f2f time, it would make sense to get it out of the way beforehand
863 2016-05-12T19:56:05  <kanzure> wumpus: for writing things down? yes. for brainstorming? sure... for meetings, i'll defer to our friendly neighborhod pointy-hair.
864 2016-05-12T19:56:06  <jonasschnelli> kanzure: I think wumpus is doing a fantastic job and you easly overmoderate on IRC.
865 2016-05-12T19:56:09  <gmaxwell> wumpus: execpt the no stable on the wire format, and no reliable delivery...
866 2016-05-12T19:56:43  <jonasschnelli> jcorgan: Agree. You could start a discussion on the bitcoin-core-dev ML?
867 2016-05-12T19:56:45  *** belcher has joined #bitcoin-core-dev
868 2016-05-12T19:56:48  <kanzure> jonasschnelli: i don't have enough context on many of these topics to correctly guide meetings. so it's not something you should be concerned about. heh.
869 2016-05-12T19:56:50  *** mrkent has joined #bitcoin-core-dev
870 2016-05-12T19:56:52  <wumpus> gmaxwell: I think you can have reliable delivry over zmq, just not in the way we use it
871 2016-05-12T19:56:53  <jtimon> wumpus: yeah, it seems people forgot about socket-like things
872 2016-05-12T19:57:10  <wumpus> jtimon: well it's a complete new API to learn
873 2016-05-12T19:57:40  <wumpus> jtimon: even if you already know normal socket programming, zmq is like a whole new alien landscape
874 2016-05-12T19:57:55  <jonasschnelli> jtimon: RPC long poll require no "real" dependencies, you just aim a http request and wait until you get response.
875 2016-05-12T19:58:02  <jcorgan> wumpus: jtimon: people don't seem to grok message based vs. function call based
876 2016-05-12T19:58:14  <kanzure> jonasschnelli: that can cause an unintentional DoS against yourself
877 2016-05-12T19:58:24  <jonasschnelli> kanzure: explain?
878 2016-05-12T19:58:31  <kanzure> rpc thread exhaustion, as mentioned above
879 2016-05-12T19:58:31  <jtimon> wumpus: I hadn't used sockets in ages and it was very easy to me (but as said I just use xreq/xrep, push/pull and pub/sub, no dealers or other stuff)
880 2016-05-12T19:58:32  <jcorgan> jonasschnelli: i'll make a suggestion on the ML then
881 2016-05-12T19:58:41  <jonasschnelli> jcorgan:+1
882 2016-05-12T19:59:02  <jonasschnelli> kanzure: no.. you only run the poll http request on a single thread...
883 2016-05-12T19:59:15  <jonasschnelli> Only one request in parallel.
884 2016-05-12T19:59:18  <kanzure> jonasschnelli: rpcthreads
885 2016-05-12T19:59:28  <jonasschnelli> But thats the serverside.
886 2016-05-12T19:59:35  <kanzure> yes.. that's still DoSing yourself.
887 2016-05-12T19:59:47  <kanzure> you're not enforcing one request in parallel
888 2016-05-12T19:59:56  <jtimon> wumpus: but apparently nanomsg simplifies things further removing the context and things like that
889 2016-05-12T20:00:01  <wumpus> in principle you don't even need a rpc thread open for a long-poller, if you'd use the event based http, but that's a topic for the far future
890 2016-05-12T20:00:10  <jonasschnelli> kanzure: sure. But that would not be different to the "normal" rpc calls?
891 2016-05-12T20:00:11  <kanzure> jtimon: in addition to nanomsg, look at nq
892 2016-05-12T20:00:24  *** Chris_Stewart_5 has quit IRC
893 2016-05-12T20:00:27  <kanzure> jonasschnelli: well, not many of them are meant to be open for a while
894 2016-05-12T20:00:43  <jtimon> kanzure: nq? do you have a link?
895 2016-05-12T20:00:44  <jonasschnelli> Sure. But you control them. Its secured behind auth.
896 2016-05-12T20:01:01  <jonasschnelli> kanzure: No strangers will connect to your RPC.
897 2016-05-12T20:01:08  <kanzure> jtimon: actually no :) i think this means i owe you BTC... hah.
898 2016-05-12T20:01:10  <wumpus> and if you need multiple long-pollers you can just increase the number of rpc threads anyhow, it's not like we need to support 1000 people in a chat
899 2016-05-12T20:01:19  <wumpus> no need to overdesign/overcomplicate
900 2016-05-12T20:01:20  <jonasschnelli> Indeed. :)
901 2016-05-12T20:01:46  <jtimon> jonasschnelli: you can have an http server with auth that connects "locally" (intranet) to stuff via zmq
902 2016-05-12T20:01:49  <kanzure> manual thread management, got it..
903 2016-05-12T20:02:01  <luke-jr> we're moving the dev meetings to the p2p network and using longpolling with bitcoin-cli to read the chat? :P
904 2016-05-12T20:02:12  <jtimon> jonasschnelli: but yeah, I guess that's one extra step you would be saving
905 2016-05-12T20:02:13  <jonasschnelli> jtimon: Yes. Sure. But why the roundtrip when you can have RPC long poll?
906 2016-05-12T20:02:15  <kanzure> we don't mention in our docs "don't connect to your bitcoin node from a thousand workers that listen for notifications"
907 2016-05-12T20:02:37  <jonasschnelli> jtimon: you don't need the ZMQ dependencies if you want to serve a push not. over http
908 2016-05-12T20:02:37  <wumpus> kanzure: some things are common sense, but feel free to add it explicitly
909 2016-05-12T20:03:04  <wumpus> kanzure: and for that, zmq is indeed more suited as it has one-to-many broadcast
910 2016-05-12T20:03:44  <jtimon> jonasschnelli: of course, strictly speaking "you don't need anything" to do anything, it's the "you can't do X using zmq" that nerves me
911 2016-05-12T20:04:30  <jonasschnelli> I think ZMQ is useful....
912 2016-05-12T20:04:35  <gmaxwell> jtimon: being excessively pedantic is not productive.
913 2016-05-12T20:04:39  <jonasschnelli> Its just pain in the ass to get a notification to a remote end.
914 2016-05-12T20:05:39  <jtimon> gmaxwell: sure, I was just misunderstanding some of the "you can't do this with zmq" claims, they were really just "you also need X" or similar things
915 2016-05-12T20:05:52  <jtimon> mistery solved
916 2016-05-12T20:06:43  * jonasschnelli needs rest and waves goodby...
917 2016-05-12T20:08:31  <jtimon> and I'm sorry for being so biased in favor of zmq whenever it's an option for anything, I guess it may equilibrate some other biases against it.
918 2016-05-12T20:10:09  *** cryptapus has quit IRC
919 2016-05-12T20:14:09  *** BashCo_ has joined #bitcoin-core-dev
920 2016-05-12T20:15:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
921 2016-05-12T20:16:50  *** BashCo has quit IRC
922 2016-05-12T20:17:51  <jcorgan> one suggestion--we seem to be going back and forth between different use cases and different means to accomplish them
923 2016-05-12T20:19:38  <jcorgan> i'd rather clarify what all the use cases are first, then see what technology best suits them, then see how that maps to what exists and what doesn't in the client
924 2016-05-12T20:21:42  <jcorgan> *best suits each of them
925 2016-05-12T20:25:44  <jtimon> jcorgan: that sounds very reasonable
926 2016-05-12T20:26:15  <jtimon> analysis first, arch/design decisions later
927 2016-05-12T20:34:37  *** droark has quit IRC
928 2016-05-12T20:46:15  *** kadoban has joined #bitcoin-core-dev
929 2016-05-12T20:47:23  *** kadoban has joined #bitcoin-core-dev
930 2016-05-12T20:52:00  *** cryptapus_afk is now known as cryptapus
931 2016-05-12T20:52:03  *** cryptapus is now known as cryptapus_afk
932 2016-05-12T20:52:06  *** cryptapus_afk is now known as cryptapus
933 2016-05-12T21:01:59  *** jcorgan has quit IRC
934 2016-05-12T21:12:05  *** kadoban has quit IRC
935 2016-05-12T21:12:32  *** kadoban has joined #bitcoin-core-dev
936 2016-05-12T21:17:33  *** kadoban has quit IRC
937 2016-05-12T21:19:02  *** kadoban has joined #bitcoin-core-dev
938 2016-05-12T21:36:46  *** d4de has joined #bitcoin-core-dev
939 2016-05-12T21:43:49  *** d4de has quit IRC
940 2016-05-12T21:44:09  *** d4de has joined #bitcoin-core-dev
941 2016-05-12T21:45:40  *** zooko has joined #bitcoin-core-dev
942 2016-05-12T21:52:06  *** fengling has joined #bitcoin-core-dev
943 2016-05-12T21:56:57  *** fengling has quit IRC
944 2016-05-12T22:00:26  *** AaronvanW has quit IRC
945 2016-05-12T22:03:25  *** mrkent has quit IRC
946 2016-05-12T22:03:32  *** cryptapus is now known as cryptapus_afk
947 2016-05-12T22:04:22  *** mrkent has joined #bitcoin-core-dev
948 2016-05-12T22:12:09  *** gabridome has joined #bitcoin-core-dev
949 2016-05-12T22:20:15  *** mrkent has quit IRC
950 2016-05-12T22:23:42  *** CubicEarth has joined #bitcoin-core-dev
951 2016-05-12T22:27:40  *** mrkent has joined #bitcoin-core-dev
952 2016-05-12T22:34:53  *** CubicEarth has quit IRC
953 2016-05-12T22:37:49  *** gabridome has quit IRC
954 2016-05-12T22:39:07  *** BashCo has joined #bitcoin-core-dev
955 2016-05-12T22:40:25  *** BashCo_ has quit IRC
956 2016-05-12T22:54:35  <BlueMatt> ugh, master is segfaulting trying to call rpc
957 2016-05-12T22:54:53  <sipa> BlueMatt: elaborate?
958 2016-05-12T22:54:59  <BlueMatt> gdb'ing
959 2016-05-12T22:55:07  <sipa> thanks
960 2016-05-12T22:55:08  <BlueMatt> but all i did was start and then try to call rpc :(
961 2016-05-12T22:57:00  <BlueMatt> oh, false alarm...custom change blew up
962 2016-05-12T22:57:04  <BlueMatt> sorry for the noise :/
963 2016-05-12T22:57:19  <BlueMatt> fucking 1-line change segfaults :(
964 2016-05-12T22:57:41  <sipa> we need a programming language with built-in reed-selomon code
965 2016-05-12T22:57:56  <sipa> so that the compiler can correct 1-line errors :p
966 2016-05-12T22:58:05  <BlueMatt> heh
967 2016-05-12T22:58:22  <gmaxwell> sipa: and updating the code means you need to read all of it?
968 2016-05-12T22:58:41  <sipa> gmaxwell: you mean you don't already do that?
969 2016-05-12T22:59:16  *** murch has quit IRC
970 2016-05-12T23:05:03  *** d4de has quit IRC
971 2016-05-12T23:07:34  *** PRab has joined #bitcoin-core-dev
972 2016-05-12T23:13:02  *** amiller has quit IRC
973 2016-05-12T23:17:43  *** Guest13955 has joined #bitcoin-core-dev
974 2016-05-12T23:22:37  *** Guyver2 has quit IRC
975 2016-05-12T23:23:12  *** aj has quit IRC
976 2016-05-12T23:24:49  *** wangchun has quit IRC
977 2016-05-12T23:24:55  *** wangchun has joined #bitcoin-core-dev
978 2016-05-12T23:30:36  *** aj has joined #bitcoin-core-dev
979 2016-05-12T23:45:18  *** zooko has quit IRC
980 2016-05-12T23:50:37  *** TomMc has quit IRC
981 2016-05-12T23:55:11  *** fengling has joined #bitcoin-core-dev
982 2016-05-12T23:55:44  *** belcher has quit IRC
983 2016-05-12T23:59:57  *** fengling has quit IRC