1 2016-11-16T00:05:21  *** fengling has quit IRC
  2 2016-11-16T00:19:24  <thrasher`> thanks wumpus & sdaftuar :)
  3 2016-11-16T00:27:38  *** Giszmo has joined #bitcoin-core-dev
  4 2016-11-16T00:40:15  *** btcdrak has joined #bitcoin-core-dev
  5 2016-11-16T00:48:34  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  6 2016-11-16T01:25:08  *** fengling has joined #bitcoin-core-dev
  7 2016-11-16T02:02:38  *** Ylbam has quit IRC
  8 2016-11-16T02:23:46  *** Giszmo has quit IRC
  9 2016-11-16T03:16:19  *** LeMiner2 has joined #bitcoin-core-dev
 10 2016-11-16T03:17:24  *** DigiByteDev has joined #bitcoin-core-dev
 11 2016-11-16T03:18:40  *** jtimon has quit IRC
 12 2016-11-16T03:18:40  *** LeMiner has quit IRC
 13 2016-11-16T03:18:40  *** LeMiner2 is now known as LeMiner
 14 2016-11-16T03:20:22  *** DigiByteDev_ has joined #bitcoin-core-dev
 15 2016-11-16T03:20:30  *** Chris_Stewart_5 has quit IRC
 16 2016-11-16T03:22:45  *** DigiByteDev has quit IRC
 17 2016-11-16T03:22:45  *** DigiByteDev_ is now known as DigiByteDev
 18 2016-11-16T03:27:06  *** Alopex has quit IRC
 19 2016-11-16T03:28:11  *** Alopex has joined #bitcoin-core-dev
 20 2016-11-16T03:37:20  *** DigiByteDev has quit IRC
 21 2016-11-16T03:56:58  *** JackH has quit IRC
 22 2016-11-16T04:04:24  *** DigiByteDev has joined #bitcoin-core-dev
 23 2016-11-16T04:29:06  *** Alopex has quit IRC
 24 2016-11-16T04:29:54  *** fengling has quit IRC
 25 2016-11-16T04:30:11  *** Alopex has joined #bitcoin-core-dev
 26 2016-11-16T04:39:44  *** DigiByteDev has quit IRC
 27 2016-11-16T04:41:16  *** Alopex has quit IRC
 28 2016-11-16T04:42:22  *** Alopex has joined #bitcoin-core-dev
 29 2016-11-16T05:07:07  *** Alopex has quit IRC
 30 2016-11-16T05:08:12  *** Alopex has joined #bitcoin-core-dev
 31 2016-11-16T05:09:46  *** arowser has quit IRC
 32 2016-11-16T05:11:11  *** arowser has joined #bitcoin-core-dev
 33 2016-11-16T05:17:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 34 2016-11-16T05:20:32  *** arowser has quit IRC
 35 2016-11-16T05:21:11  *** Alopex has quit IRC
 36 2016-11-16T05:21:54  *** arowser has joined #bitcoin-core-dev
 37 2016-11-16T05:22:17  *** Alopex has joined #bitcoin-core-dev
 38 2016-11-16T05:25:17  *** xiangfu has quit IRC
 39 2016-11-16T05:25:33  *** xiangfu has joined #bitcoin-core-dev
 40 2016-11-16T05:30:07  *** arowser has quit IRC
 41 2016-11-16T05:30:35  *** fengling has joined #bitcoin-core-dev
 42 2016-11-16T05:31:33  *** arowser has joined #bitcoin-core-dev
 43 2016-11-16T05:38:02  *** btcdrak has quit IRC
 44 2016-11-16T05:38:11  *** Alopex has quit IRC
 45 2016-11-16T05:39:17  *** Alopex has joined #bitcoin-core-dev
 46 2016-11-16T05:47:53  <achow101> do any of the rpcs return how many blocks have signalled support for a soft fork?
 47 2016-11-16T05:48:11  <sipa> getblockchaininfo
 48 2016-11-16T05:48:18  <sipa> though i'm not sure it supports bip9
 49 2016-11-16T05:48:23  *** DigiByteDev has joined #bitcoin-core-dev
 50 2016-11-16T05:48:57  <achow101> it only gives a "since" block, not actual counts
 51 2016-11-16T05:53:54  *** DigiByteDev has quit IRC
 52 2016-11-16T06:07:07  *** Alopex has quit IRC
 53 2016-11-16T06:08:12  *** Alopex has joined #bitcoin-core-dev
 54 2016-11-16T06:08:24  *** DigiByteDev has joined #bitcoin-core-dev
 55 2016-11-16T06:17:59  <sipa> achow101: http://bitcoin.sipa.be/ver9-10k.png
 56 2016-11-16T06:18:20  <sipa> it's not counted exactly according to consensus
 57 2016-11-16T06:21:24  *** wolfspraul has quit IRC
 58 2016-11-16T06:22:17  *** wolfspraul has joined #bitcoin-core-dev
 59 2016-11-16T06:27:25  *** DigiByteDev has quit IRC
 60 2016-11-16T07:08:01  *** btcdrak has joined #bitcoin-core-dev
 61 2016-11-16T07:09:01  *** fengling has quit IRC
 62 2016-11-16T07:14:01  *** fengling has joined #bitcoin-core-dev
 63 2016-11-16T07:15:33  *** justan0theruser has joined #bitcoin-core-dev
 64 2016-11-16T07:18:17  *** justanotheruser has quit IRC
 65 2016-11-16T07:35:20  *** jannes has joined #bitcoin-core-dev
 66 2016-11-16T07:45:28  *** paveljanik has quit IRC
 67 2016-11-16T08:03:21  * luke-jr cowers in fear of the new Bitcoin Core configure that yells at you :P
 68 2016-11-16T08:15:09  <wumpus> bitcoin: where even the configure scripts yell at you
 69 2016-11-16T08:17:36  *** Ylbam has joined #bitcoin-core-dev
 70 2016-11-16T08:19:24  <wumpus> you think the build system is agressive? We'll introduce you to some of our community members :p
 71 2016-11-16T08:21:34  <sipa> we have this guy called Travis who continuously yells at very active developers
 72 2016-11-16T08:22:13  <wumpus> which reminds me, there is this guy called 'Coveralls' in some projects, maybe we should invite him too
 73 2016-11-16T08:22:16  <luke-jr> lol
 74 2016-11-16T08:22:49  <wumpus> I do think he's a bit on the spammy side tho, like our old pulltester
 75 2016-11-16T08:23:27  * jonasschnelli likes Coveralls
 76 2016-11-16T08:24:18  <jonasschnelli> It someone encourages contributors to write more tests (even if coverage does not prove correctness)
 77 2016-11-16T08:27:06  <wumpus> yeah coverage is especially good in languages such as python where many typos and such are only found by executing some code
 78 2016-11-16T08:27:22  <gmaxwell> speaking of yelling, would people be opposed to me adding a ifdef check so that if daemon is not either defined or failed to be detected the compiler errors out?  I keep running into not-supported-on-your-OS when switching between master and 0.13. :) That fact that it completes the build and only fails at runtime is annoying (esp because the build takes a long time on my laptop)
 79 2016-11-16T08:27:45  <wumpus> though it helps for C too I guess, having coverage in the first place is essential for complete tests, just not sufficient
 80 2016-11-16T08:28:15  <gmaxwell> C++ makes smart coverage harder because all the boilerplate stuff often adds unreachable code. :(
 81 2016-11-16T08:29:02  <wumpus> gmaxwell: no problem
 82 2016-11-16T08:29:31  <wumpus> though you *really* should make a habit of re-running autogen when changing branches
 83 2016-11-16T08:30:16  * wumpus has different repo checkouts for different major versions to avoid problems like that
 84 2016-11-16T08:30:33  <wumpus> also saved me from committing a patch against the wrong branch at least once :)
 85 2016-11-16T08:31:02  <gmaxwell> libsecp256k1's tests are something like 99.2% line coverage, 95.3% branch coverage. ... a few branches can't be reached without solving intractable crypto problems. alas. :(
 86 2016-11-16T08:31:26  <gmaxwell> wumpus: I figure if it keeps hitting me it will hit random users who find it more surprising. :)
 87 2016-11-16T08:32:39  <wumpus> I wish autoconf would just yell if your generated files are out of date with the build system files
 88 2016-11-16T08:32:47  <jonasschnelli> For C: high coverage together with a CI valgrind memleak check is desirable IMO
 89 2016-11-16T08:33:10  <wumpus> and fuzzing, of course
 90 2016-11-16T08:33:30  <wumpus> gmaxwell: anyhow, no problem with adding that, it'd also catch problems with people forgetting to include configure.h
 91 2016-11-16T08:33:37  <gmaxwell> memleak? seldom have memleaks in interesting code. Valgrind's undefined behavior checking, OTOH. Is super great. :)
 92 2016-11-16T08:33:46  <gmaxwell> wumpus: thanks okay, I'll do so.
 93 2016-11-16T08:34:20  *** DigiByteDev has joined #bitcoin-core-dev
 94 2016-11-16T08:34:56  <gmaxwell> for bitcoin I do think we need DRD run on it more often, it's just a bit frustrating because its so slow.
 95 2016-11-16T08:35:32  <wumpus> at least make sure you run valgrind against the optimized executable not the -O0 debugging one :-)
 96 2016-11-16T08:36:51  <sipa> http://bitcoin.sipa.be/ver9-10k.png
 97 2016-11-16T08:36:54  <wumpus> but yes valgrind is slow in any case, though it's surprisingly fast if you realize what it does in the background, converting executed code blocks to VEX and back to machine instructions on the fly
 98 2016-11-16T08:37:08  <gmaxwell> yes, it's amazing.
 99 2016-11-16T08:37:10  <sipa> (-ever, -50k, -2k also exist)
100 2016-11-16T08:37:53  <wumpus> sipa: nice!
101 2016-11-16T08:39:06  <TD-Linux> sipa, having them on the index page would also be nice :)
102 2016-11-16T08:39:25  <gmaxwell> there is an index page?
103 2016-11-16T08:39:37  <sipa> TD-Linux: that would involve loading my html knowledge back from swap space
104 2016-11-16T08:40:19  <sipa> gmaxwell: http://bitcoin.sipa.be
105 2016-11-16T08:41:05  <sipa> did we cross 2 exahash/s?
106 2016-11-16T08:41:59  <jonasschnelli> sipa: come one! s/hash rate</a></li>/hash rate</a></li><li class="hilight"><a accesskey="h" href="http://bitcoin.sipa.be/ver9-10k.png">ver9-10k</a></li>/
107 2016-11-16T08:42:24  <jonasschnelli> *come on :-)
108 2016-11-16T08:42:27  <sipa> jonasschnelli: i'll want a separate page with thumbnails and stuffs
109 2016-11-16T08:42:37  <wumpus> yes I was about to say, someone has got to have that knowledge in their ready memory and could provide a patch
110 2016-11-16T08:42:55  *** CubicEarth has joined #bitcoin-core-dev
111 2016-11-16T08:43:06  <sipa> https://github.com/sipa/bitcoin-stats
112 2016-11-16T08:43:15  <jonasschnelli> Yeah. Migrate the non-pngs html stuff to bitcoincore.org
113 2016-11-16T08:43:45  <wumpus> not me though, my html knowledge is in the 2000-2004 archive in deep storage
114 2016-11-16T08:43:45  <jonasschnelli> Yeah. Perl. How did I missed this.
115 2016-11-16T08:44:07  <sipa> also C
116 2016-11-16T08:44:10  <sipa> and bash
117 2016-11-16T08:44:19  <sipa> and bash that generates gnuplot
118 2016-11-16T08:46:15  <sipa> ;;nethash
119 2016-11-16T08:46:16  <gribble> 2049301157.56
120 2016-11-16T08:50:46  <CubicEarth> 13.1, Ubuntu.... my client is passing transaction data, synced several dozen blocks on startup, but then stalled for almost 10 minutes before downloading the most recent blocks. Is it just that none of the connected peers were providing the blocks it needed?  Or is it something else?
121 2016-11-16T08:51:27  <sipa> how many blocks do you have in total?
122 2016-11-16T08:51:47  <CubicEarth> I synced it this morning, so it was only about 10 hours behind... then it stalled at about 6 hours behind
123 2016-11-16T08:52:15  <CubicEarth> chewed though the first 4 or 5 hours in 30 seconds
124 2016-11-16T08:52:49  <sipa> if you had an abnormal shutdown before, that's normal
125 2016-11-16T08:53:02  *** droark has quit IRC
126 2016-11-16T08:53:04  <sipa> well, not normal, but known
127 2016-11-16T08:53:48  <CubicEarth> interesting.  Would just one abnormal shutdown ever be enough?  The most recent one was normal (so far as I could tell)
128 2016-11-16T08:54:00  <sipa> just the last one
129 2016-11-16T08:54:14  <sipa> it was busy processing the blocks it had on disk but not applied to the database, and does that in the background while connecting to other peers, ignoring their block announcements
130 2016-11-16T08:54:19  <sipa> s/was/would be/
131 2016-11-16T08:54:35  <gmaxwell> an unclean shutdown will delay the initial headers fetch?
132 2016-11-16T08:55:07  <sipa> no, it will cause skipping it
133 2016-11-16T08:55:10  <sipa> we should fix that
134 2016-11-16T08:59:42  <CubicEarth> I wasn't looking at cpu usage... but in the debug window the current number of blocks was not advancing either. I thought the 'current number of blocks' displayed the total that had been validated and added to the chain. Does it actually count them before they are fully processed and appended?
135 2016-11-16T09:01:47  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6eeac6e30d65...918ea16dc08d
136 2016-11-16T09:01:48  <bitcoin-git> bitcoin/master 70266e9 Cory Fields: build: fix qt5.7 build under macOS...
137 2016-11-16T09:01:48  <bitcoin-git> bitcoin/master 918ea16 Wladimir J. van der Laan: Merge #9169: build: fix qt5.7 build under macOS...
138 2016-11-16T09:02:03  <bitcoin-git> [bitcoin] laanwj closed pull request #9169: build: fix qt5.7 build under macOS (master...fix-objcxx-std) https://github.com/bitcoin/bitcoin/pull/9169
139 2016-11-16T09:02:41  <sipa> CubicEarth: no
140 2016-11-16T09:03:12  <sipa> CubicEarth: my theory is that your node downloaded a number of blocks, and stored them on disk, but didn't apply them to the main chain before crashing
141 2016-11-16T09:03:32  <sipa> after restarting, it noticed those blocks, and applied them immediately in the background
142 2016-11-16T09:04:46  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/918ea16dc08d...4333b1c4ea74
143 2016-11-16T09:04:46  <bitcoin-git> bitcoin/master fa80ef8 MarcoFalke: [qa] proxy_test: Calculate hardcoded port numbers instead
144 2016-11-16T09:04:47  <bitcoin-git> bitcoin/master 4333b1c Wladimir J. van der Laan: Merge #9151: [qa] proxy_test: Calculate hardcoded port numbers...
145 2016-11-16T09:05:01  <bitcoin-git> [bitcoin] laanwj closed pull request #9151: [qa] proxy_test: Calculate hardcoded port numbers (master...Mf1611-qaPort) https://github.com/bitcoin/bitcoin/pull/9151
146 2016-11-16T09:07:02  <CubicEarth> I'll watch cpu utilization next time I boot my node... I think this pattern of stalling has been happening often.
147 2016-11-16T09:07:28  <gmaxwell> CubicEarth: do you use p2pool by any chance?
148 2016-11-16T09:08:00  <CubicEarth> gmaxwell: No. I'm not mining.
149 2016-11-16T09:08:23  <gmaxwell> okay, p2pool often ends up gobbling the initial headers sync attempt for me.
150 2016-11-16T09:10:20  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4333b1c4ea74...62af16463833
151 2016-11-16T09:10:20  <bitcoin-git> bitcoin/master 079142b Jonas Schnelli: fNetworkActive is not protected by a lock, use an atomic
152 2016-11-16T09:10:21  <bitcoin-git> bitcoin/master 62af164 Wladimir J. van der Laan: Merge #9131: fNetworkActive is not protected by a lock, use an atomic...
153 2016-11-16T09:10:30  <bitcoin-git> [bitcoin] laanwj closed pull request #9131: fNetworkActive is not protected by a lock, use an atomic (master...2016/11/net_toggle) https://github.com/bitcoin/bitcoin/pull/9131
154 2016-11-16T09:12:04  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/62af16463833...434e683f7be6
155 2016-11-16T09:12:04  <bitcoin-git> bitcoin/master 79f755d Alex Morcos: Unset fImporting for loading mempool
156 2016-11-16T09:12:05  <bitcoin-git> bitcoin/master 434e683 Wladimir J. van der Laan: Merge #9133: Unset fImporting for loading mempool...
157 2016-11-16T09:12:19  <bitcoin-git> [bitcoin] laanwj closed pull request #9133: Unset fImporting for loading mempool (master...noImportLoadMempool) https://github.com/bitcoin/bitcoin/pull/9133
158 2016-11-16T09:17:57  <CubicEarth> separate question: does anyone know about a standard for multi-sig interoperability? Something so that wallets from different providers could talk to each other?
159 2016-11-16T09:25:37  <wumpus> CubicEarth: this is not a channel for general bitcoin related questions, please use #bitcoin
160 2016-11-16T09:28:09  <wumpus> I know of no such standard, though.
161 2016-11-16T09:28:35  <CubicEarth> wumpus: ok.  thanks.
162 2016-11-16T09:30:49  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9171: Introduce out-of-band block requests (master...2016/11/spv_step_1) https://github.com/bitcoin/bitcoin/pull/9171
163 2016-11-16T09:33:51  <wumpus> jonasschnelli: what is 'out of band' about out-of-band block requests? don't you mean something like 'asynchronous'?
164 2016-11-16T09:34:29  <jonasschnelli> wumpus: not sure if its the right term. But with out-of-band, I mean not-in-the-IBD-sequence...
165 2016-11-16T09:34:31  <wumpus> jonasschnelli: (just a question about terminology, I haven't seen 'out of band' used a lot except for some weird network protocols)
166 2016-11-16T09:34:42  <gmaxwell> I had the same thought, fwiw.
167 2016-11-16T09:35:03  <jonasschnelli> I see. Any better wordings?
168 2016-11-16T09:35:10  <jonasschnelli> Asynchronous is probably also not ideal.
169 2016-11-16T09:35:22  <jonasschnelli> Independent-block-requests?
170 2016-11-16T09:35:37  *** Victorsueca has quit IRC
171 2016-11-16T09:35:43  <jonasschnelli> prioritized-block-downloads?
172 2016-11-16T09:35:55  *** DigiByteDev has quit IRC
173 2016-11-16T09:35:56  <gmaxwell> "Third distinct block downloading mechenism" :P   I would have called it 'unordered block fetching' perhaps.
174 2016-11-16T09:36:01  <jonasschnelli> Though, its not always a download
175 2016-11-16T09:36:15  <jonasschnelli> I like "unordered block fetching"
176 2016-11-16T09:36:43  <gmaxwell> even that is confusing since the normal fetch isn't in strict order. :)
177 2016-11-16T09:37:03  <jonasschnelli> Indeed...
178 2016-11-16T09:37:16  <jonasschnelli> Seems to be hard to nail it in two or three words.
179 2016-11-16T09:37:23  <wumpus> so this provides a separate interface to block downloading
180 2016-11-16T09:37:27  *** Victorsueca has joined #bitcoin-core-dev
181 2016-11-16T09:37:43  <jonasschnelli> wumpus: not really,.. it still uses the internal block download mechanism
182 2016-11-16T09:38:00  <jonasschnelli> It just priories individual blocks.
183 2016-11-16T09:38:43  <wumpus> yes it uses the same mechanism, but provides an interface that that other parts of the software (not directly associated to validation) can use
184 2016-11-16T09:38:45  <jonasschnelli> And you have certainty that all these requested blocks get passed through the signals in the correct order
185 2016-11-16T09:39:05  <gmaxwell> Block on Demand.
186 2016-11-16T09:39:25  <jonasschnelli> Blocks on Demand?
187 2016-11-16T09:39:42  <jonasschnelli> Otherwise people think this blocks something. :P
188 2016-11-16T09:39:56  <gmaxwell> My node has hot and cold running blocks.
189 2016-11-16T09:40:05  <jonasschnelli> heh
190 2016-11-16T09:46:50  *** gielbier has joined #bitcoin-core-dev
191 2016-11-16T09:48:48  *** arowser has quit IRC
192 2016-11-16T09:49:55  <jonasschnelli> Someone mentioned auxiliary-block-requests?
193 2016-11-16T09:50:10  <wumpus> sgtm
194 2016-11-16T09:50:14  *** arowser has joined #bitcoin-core-dev
195 2016-11-16T09:52:08  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/434e683f7be6...0a6d48d9ed60
196 2016-11-16T09:52:08  <bitcoin-git> bitcoin/master 307acdd mrbandrews: [qa] add assert_raises_message to check specific error message
197 2016-11-16T09:52:09  <bitcoin-git> bitcoin/master 0a6d48d MarcoFalke: Merge #9168: [qa] add assert_raises_message to check specific error message...
198 2016-11-16T09:52:22  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9168: [qa] add assert_raises_message to check specific error message (master...ba-assert-raises) https://github.com/bitcoin/bitcoin/pull/9168
199 2016-11-16T09:52:41  <bitcoin-git> [bitcoin] laanwj closed pull request #8747: [rpc] Fix transaction size comments and RPC help text. (master...rpc_comments) https://github.com/bitcoin/bitcoin/pull/8747
200 2016-11-16T09:56:08  *** MarcoFalke has joined #bitcoin-core-dev
201 2016-11-16T09:56:47  *** DigiByteDev has joined #bitcoin-core-dev
202 2016-11-16T10:06:23  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0a6d48d9ed60...cb2ed300a89e
203 2016-11-16T10:06:23  <bitcoin-git> bitcoin/master 07ede5d Brian Deery: update comments for tx weight
204 2016-11-16T10:06:24  <bitcoin-git> bitcoin/master cb2ed30 MarcoFalke: Merge #9155: [trivial] update comments for tx weight...
205 2016-11-16T10:06:40  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9155: [trivial] update comments for tx weight (master...master) https://github.com/bitcoin/bitcoin/pull/9155
206 2016-11-16T10:24:42  *** gielbier has quit IRC
207 2016-11-16T10:25:55  *** DigiByteDev has quit IRC
208 2016-11-16T10:30:07  *** DigiByteDev has joined #bitcoin-core-dev
209 2016-11-16T10:33:57  <bitcoin-git> [bitcoin] laanwj opened pull request #9172: Resurrect pstratem's "Simple fuzzing framework" (master...2016_11_fuzzing_framework) https://github.com/bitcoin/bitcoin/pull/9172
210 2016-11-16T10:35:03  *** DigiByteDev has quit IRC
211 2016-11-16T10:50:55  *** BLTS has joined #bitcoin-core-dev
212 2016-11-16T10:51:48  <BLTS> Hi all, I need to outsource a BTC payment and validation program!
213 2016-11-16T10:52:26  <jonasschnelli> BLTS: what do you mean with outsource?
214 2016-11-16T10:55:29  <BLTS> I need to pay someone to help develop a BTC payment and verification software
215 2016-11-16T10:56:02  <BLTS> jonasschnelli  I need to pay someone to help develop a BTC payment and verification software
216 2016-11-16T10:56:27  <jonasschnelli> BLTS: maybe #bitcoin or #bitcoin-dev but not #bitcoin-core-dev I guess
217 2016-11-16T10:57:06  <BLTS> thank you
218 2016-11-16T10:58:11  *** BLTS has quit IRC
219 2016-11-16T11:08:14  *** cryptapus_afk has quit IRC
220 2016-11-16T11:08:46  *** CubicEarth has quit IRC
221 2016-11-16T11:09:38  <wumpus> travis is having issues
222 2016-11-16T11:10:48  <wumpus> (nothing we can help, it doesn't even manage apt-get)
223 2016-11-16T11:19:58  <wumpus> phantomcircuit: do you happen to have your directory of AFL inputs for #7940 somewhere?
224 2016-11-16T11:20:00  <gribble> https://github.com/bitcoin/bitcoin/issues/7940 | [WIP] Fuzzing framework by pstratem · Pull Request #7940 · bitcoin/bitcoin · GitHub
225 2016-11-16T11:20:24  *** CubicEarth has joined #bitcoin-core-dev
226 2016-11-16T11:22:23  <MarcoFalke> !m travis
227 2016-11-16T11:22:23  <[b__b]> You're doing good work, travis!
228 2016-11-16T11:22:24  <gribble> Error: "m" is not a valid command.
229 2016-11-16T11:24:55  *** cryptapus_afk has joined #bitcoin-core-dev
230 2016-11-16T11:25:22  <MarcoFalke> seems to work, now
231 2016-11-16T11:33:36  *** atroxes has quit IRC
232 2016-11-16T11:34:42  *** CubicEarth has quit IRC
233 2016-11-16T11:42:11  *** atroxes has joined #bitcoin-core-dev
234 2016-11-16T11:55:29  *** arowser has quit IRC
235 2016-11-16T11:57:32  *** arowser has joined #bitcoin-core-dev
236 2016-11-16T12:12:39  *** MarcoFalke has left #bitcoin-core-dev
237 2016-11-16T12:14:18  *** rabidus has quit IRC
238 2016-11-16T12:14:26  *** rabidus has joined #bitcoin-core-dev
239 2016-11-16T12:21:34  *** arowser has quit IRC
240 2016-11-16T12:23:09  *** arowser has joined #bitcoin-core-dev
241 2016-11-16T12:29:45  *** cryptapus has joined #bitcoin-core-dev
242 2016-11-16T12:30:11  *** cryptapus has joined #bitcoin-core-dev
243 2016-11-16T12:30:11  *** cryptapus has joined #bitcoin-core-dev
244 2016-11-16T12:33:23  *** cryptapus has quit IRC
245 2016-11-16T12:35:12  *** CubicEarth has joined #bitcoin-core-dev
246 2016-11-16T12:35:19  *** cryptapus has joined #bitcoin-core-dev
247 2016-11-16T12:35:19  *** cryptapus has joined #bitcoin-core-dev
248 2016-11-16T12:39:59  *** CubicEarth has quit IRC
249 2016-11-16T12:54:13  <jonasschnelli> wumpus: yes. I encountered the travis issue on other repos too
250 2016-11-16T13:10:12  <luke-jr> sigh, looks like Travis is totally broken
251 2016-11-16T13:14:35  <wumpus> yep.
252 2016-11-16T13:36:30  *** CubicEarth has joined #bitcoin-core-dev
253 2016-11-16T13:41:12  *** CubicEarth has quit IRC
254 2016-11-16T13:45:09  <jonasschnelli> Hmm... utf8 in not mandatory for JSON.. right?
255 2016-11-16T13:45:26  <jonasschnelli> RFC 4627 does state: "JSON text SHALL be encoded in Unicode.  The default encoding is
256 2016-11-16T13:45:27  <jonasschnelli>    UTF-8."?
257 2016-11-16T13:54:44  <luke-jr> I thought it was.. :x
258 2016-11-16T14:00:09  *** MarcoFalke has joined #bitcoin-core-dev
259 2016-11-16T14:08:52  *** Giszmo has joined #bitcoin-core-dev
260 2016-11-16T14:10:47  <wumpus> yes, utf-8 is mandatory for JSON
261 2016-11-16T14:11:20  <wumpus> and that is how everyone uses it. We're not going to support non-UTF-8 JSON in bitcoin core.
262 2016-11-16T14:17:16  <wumpus> I'm 99% sure that the non-utf8 data he managed to get into the wallet database in #9166 is from the wx GUI, not from any JSON client
263 2016-11-16T14:17:17  <gribble> https://github.com/bitcoin/bitcoin/issues/9166 | listtransactions returns invalid JSON when comment contain non-UTF8 special chars · Issue #9166 · bitcoin/bitcoin · GitHub
264 2016-11-16T14:18:14  <wumpus> qt handles everything as UTF-8, but the wx GUI did not, the stable wx (at that point) didn't even support unicode IIRC
265 2016-11-16T14:18:35  <timothy> who still uses wx?
266 2016-11-16T14:18:53  <wumpus> no one,but wallets grandfathered in from that time still exist
267 2016-11-16T14:28:12  <jonasschnelli> A fix would be to add a UTF8 filter at the deserialization of an CAccountingEntry
268 2016-11-16T14:28:37  <jonasschnelli> Somewhere here: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.h#L524
269 2016-11-16T14:28:48  <jonasschnelli> But not going to do this. It's just not worth...
270 2016-11-16T14:29:44  <wumpus> I understand. THis is better handled on a per-case basis probably
271 2016-11-16T14:30:41  <luke-jr> wumpus: wxBitcoin didn't support the stable wx, and required unicode XD
272 2016-11-16T14:30:49  *** Guyver2 has joined #bitcoin-core-dev
273 2016-11-16T14:31:06  <wumpus> luke-jr: ok. No clue then how he managed then :)
274 2016-11-16T14:31:24  <luke-jr> did the RPC really prohibit it?
275 2016-11-16T14:31:49  <wumpus> no, but no one uses JSON without unicode, the sane languages prohibit it
276 2016-11-16T14:31:56  <luke-jr> CLI?
277 2016-11-16T14:32:16  <wumpus> isn't cli usually unicode too?
278 2016-11-16T14:32:28  <luke-jr> not always
279 2016-11-16T14:32:49  <wumpus> no, not always, so it's possible, it'll just be very rare on all accounts
280 2016-11-16T14:33:14  <luke-jr> I think it's more commonly non-Unicode outside the English-speaking area
281 2016-11-16T14:33:24  <luke-jr> or was until some years ago
282 2016-11-16T14:33:46  <luke-jr> but nobody else has reported a problem.. so maybe not
283 2016-11-16T14:34:00  <wumpus> we're not talking about the 90's here
284 2016-11-16T14:34:31  <wumpus> or original VT-100 terminals or whatnot :) bitcoin isn't that old
285 2016-11-16T14:35:03  <wumpus> but yes it'll obviously be more common outside ENglish-speaking areas
286 2016-11-16T14:37:04  *** CubicEarth has joined #bitcoin-core-dev
287 2016-11-16T14:38:27  <jonasschnelli> I located the "issue" in the code.
288 2016-11-16T14:38:42  <jonasschnelli> Its in univalue_read.cpp
289 2016-11-16T14:38:49  <jonasschnelli> Univalue can't handle non UTF8
290 2016-11-16T14:38:56  <jonasschnelli> (even if its allowed by the JSON RFC)
291 2016-11-16T14:39:05  <wumpus> that's fine, we don't want it to
292 2016-11-16T14:39:08  <jonasschnelli> the read() function will resturn false
293 2016-11-16T14:39:13  <jonasschnelli> Yes. We don't want this
294 2016-11-16T14:40:25  <wumpus> univalue, as well as bitcoind, will acquire lots of cruft if you want full character set handling. We don't need that as no one uses JSON that way. E.g. the "JSON is a minefield" tests assume the JSON parser strictly checks UTF-8
295 2016-11-16T14:41:45  <wumpus> (neither did any of the previous JSON libraries that we used, but they didn't do any input validation, which is quite a bad thing)
296 2016-11-16T14:41:55  *** CubicEarth has quit IRC
297 2016-11-16T14:49:41  *** paveljanik has joined #bitcoin-core-dev
298 2016-11-16T14:49:41  *** paveljanik has joined #bitcoin-core-dev
299 2016-11-16T14:51:30  *** cysm has quit IRC
300 2016-11-16T15:03:46  <bitcoin-git> [bitcoin] laanwj reopened pull request #8747: [rpc] Fix transaction size comments and RPC help text. (master...rpc_comments) https://github.com/bitcoin/bitcoin/pull/8747
301 2016-11-16T15:11:38  <bitcoin-git> [bitcoin] demodun opened pull request #9173: demo (master...master) https://github.com/bitcoin/bitcoin/pull/9173
302 2016-11-16T15:12:23  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9173: demo (master...master) https://github.com/bitcoin/bitcoin/pull/9173
303 2016-11-16T15:15:15  *** cysm has joined #bitcoin-core-dev
304 2016-11-16T15:37:58  *** CubicEarth has joined #bitcoin-core-dev
305 2016-11-16T15:38:02  *** btcdrak has quit IRC
306 2016-11-16T15:43:15  *** CubicEarth has quit IRC
307 2016-11-16T15:43:56  <cfields> morcos: ping. gentle reminder about the prevector bench.
308 2016-11-16T15:44:02  <instagibbs> in what situations would ENABLE_WALLET be defined but pwalletMain be null? Or any other combination.
309 2016-11-16T15:45:11  <cfields> instagibbs: ./configure --enable-wallet && ./bitcoind --disablewallet
310 2016-11-16T15:45:12  <cfields> (i think)
311 2016-11-16T15:45:32  <instagibbs> cfields, ah that seems likely. Thanks!
312 2016-11-16T15:46:05  *** jtimon has joined #bitcoin-core-dev
313 2016-11-16T16:20:57  *** PaulCapestany has quit IRC
314 2016-11-16T16:26:30  *** btcdrak has joined #bitcoin-core-dev
315 2016-11-16T16:27:15  *** PaulCapestany has joined #bitcoin-core-dev
316 2016-11-16T16:43:52  *** cryptapus_afk has quit IRC
317 2016-11-16T17:01:27  *** paveljanik has quit IRC
318 2016-11-16T17:02:13  *** cysm has quit IRC
319 2016-11-16T17:02:39  *** cryptapus_afk has joined #bitcoin-core-dev
320 2016-11-16T17:02:39  *** cryptapus_afk has joined #bitcoin-core-dev
321 2016-11-16T17:04:53  *** paveljanik has joined #bitcoin-core-dev
322 2016-11-16T17:04:54  *** paveljanik has joined #bitcoin-core-dev
323 2016-11-16T17:28:08  *** jannes has quit IRC
324 2016-11-16T17:31:22  *** cysm has joined #bitcoin-core-dev
325 2016-11-16T17:31:42  *** cryptapus_afk has quit IRC
326 2016-11-16T17:40:31  *** CubicEarth has joined #bitcoin-core-dev
327 2016-11-16T17:45:09  *** CubicEarth has quit IRC
328 2016-11-16T17:51:04  *** CubicEarth has joined #bitcoin-core-dev
329 2016-11-16T17:55:35  *** cryptapus_afk has joined #bitcoin-core-dev
330 2016-11-16T17:55:38  *** cryptapus_afk has joined #bitcoin-core-dev
331 2016-11-16T18:12:19  *** abpa has joined #bitcoin-core-dev
332 2016-11-16T18:22:54  *** Chris_Stewart_5 has quit IRC
333 2016-11-16T18:26:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
334 2016-11-16T18:35:42  *** cryptapus_afk has quit IRC
335 2016-11-16T18:35:44  *** bsm1175321 has quit IRC
336 2016-11-16T18:37:58  *** bsm1175321 has joined #bitcoin-core-dev
337 2016-11-16T18:46:24  *** cryptapus_afk has joined #bitcoin-core-dev
338 2016-11-16T18:46:24  *** cryptapus_afk has joined #bitcoin-core-dev
339 2016-11-16T18:48:01  *** BonyM1 has quit IRC
340 2016-11-16T18:50:16  *** laurentmt has joined #bitcoin-core-dev
341 2016-11-16T18:55:16  *** laurentmt has quit IRC
342 2016-11-16T19:03:12  *** BonyM1 has joined #bitcoin-core-dev
343 2016-11-16T19:18:12  *** theymos has joined #bitcoin-core-dev
344 2016-11-16T19:19:30  <theymos> fyi, some apparently-popular antivirus is flagging Bitcoin Core 0.13.1: https://www.virustotal.com/en/file/c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419/analysis/
345 2016-11-16T19:34:24  <arubi> "Additional information" -> "VirusTotal metadata" -> "File names" -> "KMS V.1.2.3.exe"
346 2016-11-16T19:34:27  <arubi> weird.
347 2016-11-16T19:50:35  *** Guest84529 has joined #bitcoin-core-dev
348 2016-11-16T19:52:44  *** Guest84529 is now known as roidster
349 2016-11-16T19:58:08  <morcos> cfields: sorry, will have to wait a bit longer.   my initial results seem to show that maybe its a little bit of an improvement, but that the previous branch was a more significant improvement
350 2016-11-16T19:58:20  <morcos> so i'd like to run longer tests to get rid of the noise...
351 2016-11-16T19:59:30  <cfields> morcos: ok, np. thanks for testing
352 2016-11-16T20:00:16  <cfields> morcos: i suppose it's possible that all of the changes just slowly added up to a noticeable speedup. I figured it was more likely that there was a single silver bullet.
353 2016-11-16T20:01:45  <gmaxwell> btcdrak: any interest in trying to get that spurrious AV warning fixed?
354 2016-11-16T20:03:48  <Victorsueca> theymos: Baidu lol
355 2016-11-16T20:04:04  <Victorsueca> isn't that a Chinese page?
356 2016-11-16T20:04:41  <Victorsueca> would bet Chinese government is behind that
357 2016-11-16T20:08:29  *** CubicEarth has quit IRC
358 2016-11-16T20:16:34  <morcos> cfields: yeah i'll keep running tests, but actually when i tried your old branch, i accidentally did it without the removal of the CScript copy constructor (b/c i didn't want to use the Transaction stuff in that second commit)
359 2016-11-16T20:17:16  <morcos> once i re-removed the CScript copy contructor from the copy-move branch, its clearly much faster than the prevector-move branch
360 2016-11-16T20:19:43  <cfields> morcos: interesting, that points to the speedup coming from less time copying
361 2016-11-16T20:19:56  <btcdrak> gmaxwell: a job for a native chinese speaker I think.
362 2016-11-16T20:19:57  <cfields> which is strange, because last i looked, there were very few of those copies
363 2016-11-16T20:21:35  <cfields> morcos: hmm, though i suppose it could also come from construction/destruction. prevector as-is is pretty heavy on those
364 2016-11-16T20:22:34  <cfields> grr, i should just bite the bullet and do a quick specialization of prevector for unsigned char. It should be simple enough.
365 2016-11-16T20:23:21  *** roidster has quit IRC
366 2016-11-16T20:26:07  *** arubi_ has joined #bitcoin-core-dev
367 2016-11-16T20:27:21  *** arubi_ has left #bitcoin-core-dev
368 2016-11-16T20:30:32  <sipa> cfields: can't use use a my_is_trivially_copyable predicate class instead, and define it just manually for char for old compilers, and use std::is_trivially_copyable for new ones?
369 2016-11-16T20:30:45  *** jtimon has quit IRC
370 2016-11-16T20:31:55  <cfields> sipa: yes, but i'm pretty sure it could be sped up substantially if written specifically for packed bytes
371 2016-11-16T20:33:15  <cfields> sipa: for ex, no alignment concerns
372 2016-11-16T20:34:35  <gmaxwell> maybe time would be better spent working on flat transactions (which rrequires finishing making them immutable first)?
373 2016-11-16T20:35:45  <cfields> flat transactions?
374 2016-11-16T20:36:05  <sipa> cfields: one malloc
375 2016-11-16T20:36:37  <cfields> oh, accessing serialized fields on the fly, or so?
376 2016-11-16T20:37:04  <gmaxwell> doesn't have to be (and probably shouldn't be) in the seralized form we use on the wire.
377 2016-11-16T20:37:55  <cfields> right, you mentioned this the other day
378 2016-11-16T20:40:34  <cfields> gmaxwell: you mentioned you'd doodled some notes about a possible format. Happen to have those around?
379 2016-11-16T20:42:24  <gmaxwell> Well what I was working on is on the other side, improved serialization for disk and network that is more compact.
380 2016-11-16T20:43:14  <gmaxwell> For use in memory, one would have no varints, for example, just just character arrays and primitive types, and a set of pointers to allow random access to every field even though some parts are variable length.
381 2016-11-16T20:44:39  <sipa> doesn't sound hard
382 2016-11-16T20:45:00  <sipa> concatenate all scripts into a single byte array, and have (begin_ptr, size) tuples to refer to them
383 2016-11-16T20:45:34  <sipa> we'd need to modify the script interpreter to no longer use CScript anymore (which seems trivial, it doesn't need any of CScript's representation - even iteration is done byte by byte)
384 2016-11-16T20:45:35  <gmaxwell> no, but it needs transaction to be immutable though.. since you can't make changes that would change the size or count of any scripts.
385 2016-11-16T20:45:44  <sipa> of course
386 2016-11-16T20:46:18  *** NielsvG has quit IRC
387 2016-11-16T20:46:27  <gmaxwell> for the more effficent disk/wire format what I'd written up was https://people.xiph.org/~greg/compacted_txn.txt  though one thing it doesn't achieve, which would be nice though I don't know if its realistic, is a very fast procedure to decide how much memory would be needed for a flat in memory rep... which would facilitate some later optimizations.
388 2016-11-16T20:49:47  *** NielsvG has joined #bitcoin-core-dev
389 2016-11-16T20:49:47  *** NielsvG has joined #bitcoin-core-dev
390 2016-11-16T20:50:05  <cfields> thanks, will take a look
391 2016-11-16T20:51:33  <Chris_Stewart_5> Why does this test fail for EVAL_FALSE and not WITNESS_PROGRAM_MISMATCH? https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json#L1257
392 2016-11-16T20:51:34  <cfields> yes, i suppose in any scheme where all scripts are cat'd in memory, there'd be no need for something like prevector
393 2016-11-16T20:55:04  <sipa> cfields: sure there is. prevector's primary benefit is in CCoins
394 2016-11-16T20:57:29  <gmaxwell> but thats why I suggested that flattening transactions may be a better time investment than expanding prevector's use in transactions. I think with transaction const there is no reason to not flatten it all the way except that a lot of code may need to be adjusted to twiddle how accesses work. (Though perhaps enough C++ magic could keep the interface almost identical-- beyond my pay grade).  Not
395 2016-11-16T20:57:35  <gmaxwell>  that prevector isn't useful, but just for const transactions its a half-step.
396 2016-11-16T20:59:59  <cfields> sipa: i figured CCoins would use some similar monster allocation structure and indicies. But I suppose you'd run into crazy fragmentation issues quickly
397 2016-11-16T21:00:21  <cfields> *indices
398 2016-11-16T21:00:27  <sipa> cfields: for CCoins i want to move to a per-output model instead of per-tx
399 2016-11-16T21:02:32  *** cryptapus has quit IRC
400 2016-11-16T21:06:15  <sipa> Chris_Stewart_5: because 6e340b9cffb37a989ca544e6bb780a2c78901d3fb33738768511a30617afa01d is the hash of OP_0 (0x00) and not of OP_TRUE (0x51)
401 2016-11-16T21:06:42  <sipa> Chris_Stewart_5: so it's a perfectly valid p2wsh output, for the OP_FALSE witness script (which is unspendable)
402 2016-11-16T21:07:20  <cfields> makes sense, though admittedly i'm not very familiar with that code.
403 2016-11-16T21:07:50  <sipa> cfields: it needs design, implementation, and benchmarking
404 2016-11-16T21:08:37  <sipa> it's not trivial to do, but the current system has an ugly O(n^2) behaviour, where a transaction with n outputs needs O(n) database writes (one for each spend) each of size O(n) (because all unspent outputs are rewritten every time)
405 2016-11-16T21:09:18  <cfields> ah, i see
406 2016-11-16T21:09:29  *** theymos has left #bitcoin-core-dev
407 2016-11-16T21:09:47  <sipa> the easiest solution is storing height/coinbaseness in each output
408 2016-11-16T21:09:52  <sipa> and txid
409 2016-11-16T21:09:57  <sipa> but that's a lot of duplication
410 2016-11-16T21:10:52  <sipa> though leveldb does deduplication of identical prefixes in the database
411 2016-11-16T21:11:18  <sipa> an alternative is a txid->{height,coinbase,id} map, with id a short sequentially-assigned local id
412 2016-11-16T21:11:28  <sipa> and then use (id,index)->{utxo} map for the utxos
413 2016-11-16T21:11:33  <sipa> but that's an extra indirection
414 2016-11-16T21:16:52  <cfields> well the first potentially brings a nice read speedup, no? Since the outputs are then somewhat sorted by hotness
415 2016-11-16T21:17:54  <sipa> leveldb sorts by key
416 2016-11-16T21:18:39  <sipa> and the way we're using leveldb i think hardly results in actual levels
417 2016-11-16T21:18:50  <sipa> the batches are so large we always trigger compactions
418 2016-11-16T21:19:05  <cfields> heh
419 2016-11-16T21:20:30  <Chris_Stewart_5> sipa: Thanks for the help, mistakenly assumed it was still HASH160(SHA256()), is there a reason it is only 1 SHA256()?
420 2016-11-16T21:21:45  <sipa> Chris_Stewart_5: yes, 160 bits is too little
421 2016-11-16T21:22:09  <sipa> (it's too little for P2SH as well, but we weren't aware of the collision attack against it at the time)
422 2016-11-16T21:22:46  <Chris_Stewart_5> sipa: Is it a HF to change P2SH to a SHA256?
423 2016-11-16T21:23:24  <sipa> Chris_Stewart_5: of course
424 2016-11-16T21:24:48  <sipa> when done naively, at least
425 2016-11-16T21:24:59  <sipa> just defining something new P2SH-like could be done
426 2016-11-16T21:25:11  <sipa> ... but that's essentially what P2WSH is
427 2016-11-16T21:26:45  *** ryanofsky has quit IRC
428 2016-11-16T21:28:50  <Chris_Stewart_5> and with a versioning system now we can totally redefine the semantics of any witness scripts between versions, correct?
429 2016-11-16T21:28:53  *** ryanofsky has joined #bitcoin-core-dev
430 2016-11-16T21:29:24  <sipa> yes
431 2016-11-16T21:29:37  *** ryanofsky has quit IRC
432 2016-11-16T21:30:08  *** ryanofsky has joined #bitcoin-core-dev
433 2016-11-16T21:30:26  <sipa> Chris_Stewart_5: my answer was wrong. any interpretation for "changing P2SH to SHA256" i can come up with would be a soft fork
434 2016-11-16T21:30:36  <sipa> it would however also break any existing p2sh users
435 2016-11-16T21:31:25  <Chris_Stewart_5> sipa: Isn't the P2SH flag a required flag at this point in script? Would it have to do with redefining the IsScriptHash function?
436 2016-11-16T21:32:13  <sipa> that's an implementation detail
437 2016-11-16T21:33:36  <sipa> you can just add an IsScriptHash2 function, and add a new flag that assigns sha256-p2sh behaviour to IsScriptHash2, and outlaws any older IsScriptHash results
438 2016-11-16T21:34:02  <Chris_Stewart_5> Why would you need to outlaw?
439 2016-11-16T21:34:19  <sipa> because that's how i interpret 'moving to sha256' :)
440 2016-11-16T21:34:26  <Chris_Stewart_5> ahhh ok
441 2016-11-16T21:34:37  <sipa> if you would have said 'adding p2sh-sha256 feature', yes :)
442 2016-11-16T21:34:47  <sipa> but that's pretty much what p2wsh is... in a better way
443 2016-11-16T21:35:07  <Chris_Stewart_5> ... but I want to make p2sh great again. I'll see myself out.
444 2016-11-16T21:36:44  *** arubi has quit IRC
445 2016-11-16T21:36:55  <sipa> hahaha
446 2016-11-16T21:39:31  *** arubi has joined #bitcoin-core-dev
447 2016-11-16T21:46:23  *** arubi has quit IRC
448 2016-11-16T21:47:44  *** arubi has joined #bitcoin-core-dev
449 2016-11-16T22:31:39  *** roidster has joined #bitcoin-core-dev
450 2016-11-16T22:36:45  *** MarcoFalke has left #bitcoin-core-dev
451 2016-11-16T22:40:05  *** nabu has joined #bitcoin-core-dev
452 2016-11-16T22:52:48  *** nabu has quit IRC
453 2016-11-16T23:13:41  *** droark has joined #bitcoin-core-dev
454 2016-11-16T23:15:49  *** Guyver2 has quit IRC
455 2016-11-16T23:20:58  *** jtimon has joined #bitcoin-core-dev
456 2016-11-16T23:25:44  *** To7 has joined #bitcoin-core-dev
457 2016-11-16T23:26:04  *** shangzhou has joined #bitcoin-core-dev
458 2016-11-16T23:26:33  *** aalex has quit IRC
459 2016-11-16T23:58:02  *** btcdrak has quit IRC