1 2016-05-09T00:15:32  *** alpalp has joined #bitcoin-core-dev
  2 2016-05-09T00:15:32  *** alpalp has joined #bitcoin-core-dev
  3 2016-05-09T00:16:21  *** Guyver2 has quit IRC
  4 2016-05-09T00:23:32  *** raedah1 has joined #bitcoin-core-dev
  5 2016-05-09T00:26:17  *** raedah has quit IRC
  6 2016-05-09T00:34:17  *** alpalp has quit IRC
  7 2016-05-09T00:34:34  *** alpalp has joined #bitcoin-core-dev
  8 2016-05-09T00:40:22  *** raedah has joined #bitcoin-core-dev
  9 2016-05-09T00:51:10  *** Ylbam has quit IRC
 10 2016-05-09T01:00:52  *** raedah1 has joined #bitcoin-core-dev
 11 2016-05-09T01:01:26  *** raedah1 has quit IRC
 12 2016-05-09T01:01:52  *** raedah1 has joined #bitcoin-core-dev
 13 2016-05-09T01:04:29  *** raedah has quit IRC
 14 2016-05-09T01:05:12  *** belcher has quit IRC
 15 2016-05-09T01:08:40  *** baldur has joined #bitcoin-core-dev
 16 2016-05-09T01:09:22  *** raedah1 is now known as raedah
 17 2016-05-09T01:12:14  <Chris_Stewart_5> Is there an easy way to see the serialization for a transaction inside of CTransactionSignatureSerializer (not just the hash)?
 18 2016-05-09T01:17:09  <sipa> replace it with a CDataStream :)
 19 2016-05-09T01:20:45  <phantomcircuit> is there any reason not to encrypt the wallet by default with a null master key?
 20 2016-05-09T01:20:46  <GitHub22> [bitcoin] pstratem opened pull request #8025: Increase DEFAULT_KEYPOOL_SIZE to 10000. (master...2016-05-08-wallet-defaults) https://github.com/bitcoin/bitcoin/pull/8025
 21 2016-05-09T01:23:35  <Chris_Stewart_5> thank you so much sipa. I spent much more time than I would like to admit trying to figure that out :-)
 22 2016-05-09T01:29:20  <phantomcircuit> BlueMatt, ^
 23 2016-05-09T01:43:29  *** GAit has quit IRC
 24 2016-05-09T01:43:34  <sipa> phantomcircuit: backward compatibility at the time
 25 2016-05-09T01:43:42  <sipa> not really an argument anymore :)
 26 2016-05-09T01:43:47  <phantomcircuit> k
 27 2016-05-09T02:00:01  *** Alopex has quit IRC
 28 2016-05-09T02:01:06  *** Alopex has joined #bitcoin-core-dev
 29 2016-05-09T02:01:42  *** BashCo_ has joined #bitcoin-core-dev
 30 2016-05-09T02:03:44  *** BashCo has quit IRC
 31 2016-05-09T02:14:04  *** alpalp has quit IRC
 32 2016-05-09T02:54:01  *** Alopex has quit IRC
 33 2016-05-09T02:55:07  *** Alopex has joined #bitcoin-core-dev
 34 2016-05-09T02:57:27  *** molz has quit IRC
 35 2016-05-09T03:04:08  *** BashCo has joined #bitcoin-core-dev
 36 2016-05-09T03:05:44  *** BashCo_ has quit IRC
 37 2016-05-09T03:40:32  *** fengling has joined #bitcoin-core-dev
 38 2016-05-09T03:46:38  <GitHub177> [bitcoin] pstratem opened pull request #8026:  [WIP] Wallet: Cache CWalletDB pointer in CWallet to improve performance (master...2016-05-08-wallet-speed) https://github.com/bitcoin/bitcoin/pull/8026
 39 2016-05-09T03:59:20  *** Chris_Stewart_5 has quit IRC
 40 2016-05-09T04:05:58  *** moli has joined #bitcoin-core-dev
 41 2016-05-09T04:24:01  *** Alopex has quit IRC
 42 2016-05-09T04:25:07  *** Alopex has joined #bitcoin-core-dev
 43 2016-05-09T04:48:34  *** kadoban has joined #bitcoin-core-dev
 44 2016-05-09T04:50:02  *** Alopex has quit IRC
 45 2016-05-09T04:51:07  *** Alopex has joined #bitcoin-core-dev
 46 2016-05-09T04:55:50  *** fengling_ has joined #bitcoin-core-dev
 47 2016-05-09T04:55:56  *** fengling has quit IRC
 48 2016-05-09T05:02:00  *** BashCo_ has joined #bitcoin-core-dev
 49 2016-05-09T05:04:20  *** BashCo has quit IRC
 50 2016-05-09T05:06:02  *** Alopex has quit IRC
 51 2016-05-09T05:07:07  *** Alopex has joined #bitcoin-core-dev
 52 2016-05-09T05:08:48  *** Don_John has joined #bitcoin-core-dev
 53 2016-05-09T05:22:57  *** fengling_ has quit IRC
 54 2016-05-09T05:23:01  *** Alopex has quit IRC
 55 2016-05-09T05:24:07  *** Alopex has joined #bitcoin-core-dev
 56 2016-05-09T05:31:38  *** kadoban has quit IRC
 57 2016-05-09T05:39:01  *** Alopex has quit IRC
 58 2016-05-09T05:40:07  *** Alopex has joined #bitcoin-core-dev
 59 2016-05-09T05:45:21  *** gill3s has joined #bitcoin-core-dev
 60 2016-05-09T05:45:21  *** gill3s has joined #bitcoin-core-dev
 61 2016-05-09T05:54:29  *** gill3s has quit IRC
 62 2016-05-09T05:55:01  *** Alopex has quit IRC
 63 2016-05-09T05:55:58  *** fengling_ has joined #bitcoin-core-dev
 64 2016-05-09T05:56:06  *** Alopex has joined #bitcoin-core-dev
 65 2016-05-09T06:26:34  *** xiangfu has joined #bitcoin-core-dev
 66 2016-05-09T06:38:20  *** Ylbam has joined #bitcoin-core-dev
 67 2016-05-09T06:42:54  *** BashCo_ has quit IRC
 68 2016-05-09T06:45:57  *** fengling_ has quit IRC
 69 2016-05-09T06:47:40  <phantomcircuit> sipa, btw i just had a ccache failure working on #8026
 70 2016-05-09T06:52:47  <paveljanik> ccache failure?
 71 2016-05-09T06:52:56  <GitHub143> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/fbd84788e676...f17032f70328
 72 2016-05-09T06:52:57  <GitHub143> bitcoin/master aa62b68 Pieter Wuille: Benchmark rolling bloom filter
 73 2016-05-09T06:52:57  <GitHub143> bitcoin/master 1953c40 Pieter Wuille: More efficient bitsliced rolling Bloom filter...
 74 2016-05-09T06:52:58  <GitHub143> bitcoin/master f17032f Wladimir J. van der Laan: Merge #7934: Improve rolling bloom filter performance and benchmark...
 75 2016-05-09T06:53:06  <GitHub9> [bitcoin] laanwj closed pull request #7934: Improve rolling bloom filter performance and benchmark (master...benchrollingbloom) https://github.com/bitcoin/bitcoin/pull/7934
 76 2016-05-09T06:54:09  *** assder has joined #bitcoin-core-dev
 77 2016-05-09T06:55:21  *** murch has joined #bitcoin-core-dev
 78 2016-05-09T06:57:02  <phantomcircuit> paveljanik, wallet.cpp was being compiled incorrectly
 79 2016-05-09T06:57:15  <phantomcircuit> (or rather was compiling when it shouldn't have been)
 80 2016-05-09T06:57:19  <phantomcircuit> ccache -C
 81 2016-05-09T06:57:25  <phantomcircuit> and the issue disappeared
 82 2016-05-09T06:57:43  <paveljanik> strange
 83 2016-05-09T06:57:54  <paveljanik> never seen such issue with ccache...
 84 2016-05-09T06:58:17  <phantomcircuit> haven't seen that kind of problem with it in... well yeah ever
 85 2016-05-09T07:01:37  *** fengling_ has joined #bitcoin-core-dev
 86 2016-05-09T07:02:24  *** gill3s has joined #bitcoin-core-dev
 87 2016-05-09T07:21:17  <GitHub6> [bitcoin] pstratem opened pull request #8028: Fix insanity of CWalletDB::WriteTx and CWalletTx::WriteToDisk (master...2016-05-09-cwalletdb-writetx) https://github.com/bitcoin/bitcoin/pull/8028
 88 2016-05-09T07:28:30  *** BashCo has joined #bitcoin-core-dev
 89 2016-05-09T07:38:25  *** gevs has quit IRC
 90 2016-05-09T07:38:45  *** BashCo has quit IRC
 91 2016-05-09T07:39:34  *** BashCo has joined #bitcoin-core-dev
 92 2016-05-09T07:51:35  *** gevs has joined #bitcoin-core-dev
 93 2016-05-09T07:54:33  *** BashCo has quit IRC
 94 2016-05-09T07:57:50  *** Guyver2 has joined #bitcoin-core-dev
 95 2016-05-09T08:02:52  *** BashCo has joined #bitcoin-core-dev
 96 2016-05-09T08:04:20  *** gill3s has quit IRC
 97 2016-05-09T08:06:20  *** xiangfu has quit IRC
 98 2016-05-09T08:06:53  <phantomcircuit> i like how the trivial patch to change keypool size has tons of activity
 99 2016-05-09T08:06:54  <phantomcircuit> :P
100 2016-05-09T08:07:13  *** gill3s has joined #bitcoin-core-dev
101 2016-05-09T08:08:56  *** xiangfu has joined #bitcoin-core-dev
102 2016-05-09T08:11:31  <paveljanik> phantomcircuit, you are not the first though. MAX_BLOCK_SIZE...
103 2016-05-09T08:14:10  <jonasschnelli> :)
104 2016-05-09T08:15:31  <phantomcircuit> ha
105 2016-05-09T08:15:40  <phantomcircuit> now i just need someone to review 8028
106 2016-05-09T08:15:44  <phantomcircuit> it's almost as trivial
107 2016-05-09T08:15:52  * phantomcircuit looks at jonasschnelli 
108 2016-05-09T08:19:59  * jonasschnelli will look at 8028
109 2016-05-09T08:20:25  <jonasschnelli> I never liked the wtx.WriteToDisk()
110 2016-05-09T08:20:39  *** AaronvanW has joined #bitcoin-core-dev
111 2016-05-09T08:20:40  *** AaronvanW has joined #bitcoin-core-dev
112 2016-05-09T08:21:02  *** BashCo_ has joined #bitcoin-core-dev
113 2016-05-09T08:22:39  <gmaxwell> BlueMatt: I think pieter told you that your compact block recovery should request the txn when there is a collision.  You should also have the recovery check the orphan pool for txn.
114 2016-05-09T08:22:58  *** BashCo has quit IRC
115 2016-05-09T08:23:33  *** gill3s has quit IRC
116 2016-05-09T08:30:17  *** MarcoFalke has joined #bitcoin-core-dev
117 2016-05-09T08:30:46  *** gill3s has joined #bitcoin-core-dev
118 2016-05-09T08:30:52  <MarcoFalke> jonasschnelli, 8018 looks good. Mind to address the nit?
119 2016-05-09T08:31:21  <jonasschnelli> MarcoFalke: yes. Will do in a couple of hours. Need to finish the open work before I can checkout the branch. :)
120 2016-05-09T08:31:54  <MarcoFalke> sure, take your time.
121 2016-05-09T08:32:07  * sipa casually mentions git-worktree, which allows checking out two branches simultaneously
122 2016-05-09T08:35:21  <wumpus> git-worktree is great, it requires a pretty new git though, unfortunately
123 2016-05-09T08:35:32  <jonasschnelli> hmm... I probably should check this.
124 2016-05-09T08:35:45  <jonasschnelli> I have also multiple working copies to switch between work
125 2016-05-09T08:35:54  <wumpus> yes I simply have mulitple clones now
126 2016-05-09T08:35:59  <jonasschnelli> But loosing focus means loosing productivity. :)
127 2016-05-09T08:36:22  <wumpus> will switch to git-worktree when I upgrade more widely to ubuntu 16.04
128 2016-05-09T08:36:33  <sipa> jonasschnelli: you need to upgrade your brain to a multicore one
129 2016-05-09T08:36:45  <jonasschnelli> haha... I already run on 8 cores!
130 2016-05-09T08:36:53  <sipa> wumpus: no problems with ubuntu 16.04 here
131 2016-05-09T08:37:16  <jonasschnelli> core-dev organizing, Pine64/Odroid installation, hardware wallet work, libbtc and managing a familiy... :)
132 2016-05-09T08:37:19  <wumpus> sipa: no problems here either, but there is no supported upgrade path from 14.04 to 16.04 yet
133 2016-05-09T08:37:32  <sipa> upgrading worked fine here
134 2016-05-09T08:37:54  <wumpus> so all my 16.04 installations are either upgraded from 15.10 or new ones
135 2016-05-09T08:38:01  <GitHub105> [bitcoin] fanquake opened pull request #8029: [Doc] Simplify OS X build notes (master...osx-build-notes) https://github.com/bitcoin/bitcoin/pull/8029
136 2016-05-09T08:38:13  <sipa> i used do-release-upgrade -d
137 2016-05-09T08:38:20  <gmaxwell> Hurray for the multiple clone workflow!
138 2016-05-09T08:38:23  <gmaxwell> join us
139 2016-05-09T08:39:30  <wumpus> well what Ubuntu says is that "14.04 LTS to LTS upgrades will be enabled with the 16.04.1 LTS point release, in approximately 3 months time.". I think it's the safer option. I can wait 3 months for that anyhow :)
140 2016-05-09T08:39:48  *** xiangfu has quit IRC
141 2016-05-09T08:41:14  <sipa> wumpus: ha, i didn't bother to look that up and just used the dev upgrade... it has always worked fine in the past :)
142 2016-05-09T08:41:27  <sipa> and if it fails, it's not like reinstalling is a disaster
143 2016-05-09T08:41:37  * sipa zZzZ
144 2016-05-09T08:42:34  <wumpus> heh :)
145 2016-05-09T08:43:19  <wumpus> I've had very mixed experiences with upgrading, usually it goes fine, but I've also had it crash during upgrade once, or apparently upgrade fine that have an avalanche of errors at the next start
146 2016-05-09T08:46:14  *** MarcoFalke has quit IRC
147 2016-05-09T08:50:45  *** Ginnarr has joined #bitcoin-core-dev
148 2016-05-09T08:53:45  *** xiangfu has joined #bitcoin-core-dev
149 2016-05-09T08:58:39  *** xiangfu has quit IRC
150 2016-05-09T08:59:11  <wumpus> worst upgrade experience I ever had was with slackware, a bug in a documentation(!) package upgrader caused a rm -rf /, when I was wondering why it was taking so long it was nearly too late. These days I keep good backups.
151 2016-05-09T09:00:01  <gmaxwell> wumpus: there have been a couple of those incidents over the years.
152 2016-05-09T09:04:19  <wumpus> ouch
153 2016-05-09T09:06:08  <gmaxwell> one of the popular linux music players ("amarok"?) had a system("rm -rf "||unquoted_file_name); for when you told it to delete a file...
154 2016-05-09T09:06:43  <gmaxwell> better not delete "dance / greatesthits.mp3"
155 2016-05-09T09:07:32  <kinlo> sigh, what's wrong with a call to unlink() ?  why do ppl call the shell so much
156 2016-05-09T09:08:11  <wumpus> yes, seems absurd to use the shell for that. Usage of system() is usually a code stink
157 2016-05-09T09:08:46  *** G1lius has joined #bitcoin-core-dev
158 2016-05-09T09:13:43  *** xiangfu has joined #bitcoin-core-dev
159 2016-05-09T09:18:55  *** xiangfu has quit IRC
160 2016-05-09T09:24:37  *** fengling_ has quit IRC
161 2016-05-09T09:29:07  *** fengling__ has joined #bitcoin-core-dev
162 2016-05-09T09:30:44  *** spudowiar has joined #bitcoin-core-dev
163 2016-05-09T09:38:08  <jonasschnelli> can the cache-sizes be changed during runtime?
164 2016-05-09T09:38:13  <jonasschnelli> Things like nCoinCacheUsage
165 2016-05-09T09:49:29  <wumpus> no
166 2016-05-09T09:49:50  <wumpus> (I don't think there's any deep reason for that not being possible though)
167 2016-05-09T09:50:18  <wumpus> at least the size of the coin cache could be trivially changed, it's just a threshold
168 2016-05-09T09:50:35  <gmaxwell> some kinds of datastructures are fairly hard to resize at runtime. ... bloom filters being an example.
169 2016-05-09T09:50:40  <wumpus> the leveldb caches on the other hand probably require re-opening the dtabase
170 2016-05-09T09:51:17  <wumpus> true, but I don't think we have any user-sizable bloom filters
171 2016-05-09T09:54:23  <wumpus> travis is stil suffering from unrelated zmq issues: https://github.com/bitcoin/bitcoin/pull/8006
172 2016-05-09T09:55:46  <wumpus> I think it makes sense to temporarily revert fa05e22e919b7e2e816606f0c0d3dea1bd325bfd so that missing python-zmq package is not fatal
173 2016-05-09T09:58:36  *** amiller has quit IRC
174 2016-05-09T09:59:21  <paveljanik> or you can temporarily add python-zmq to travis
175 2016-05-09T09:59:34  <paveljanik> but anyway: +1
176 2016-05-09T09:59:37  <GitHub128> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f17032f70328...e29cfc48fc08
177 2016-05-09T09:59:38  <GitHub128> bitcoin/master c8b9248 21E14: Remove obsolete reference to CValidationState from UpdateCoins.
178 2016-05-09T09:59:38  <GitHub128> bitcoin/master e29cfc4 Wladimir J. van der Laan: Merge #7976: Remove obsolete reference to CValidationState from UpdateCoins....
179 2016-05-09T09:59:47  <GitHub10> [bitcoin] laanwj closed pull request #7976: Remove obsolete reference to CValidationState from UpdateCoins. (master...cleancoinsupdate) https://github.com/bitcoin/bitcoin/pull/7976
180 2016-05-09T10:00:01  <wumpus> paveljanik: I'm not convinced that that solves the issue
181 2016-05-09T10:00:26  <wumpus> last time I checked the travis configuration it *should* be okay, if not, that'd be the obvious solution
182 2016-05-09T10:01:47  <paveljanik> you have checked that the tests were done using python2 and python-zmq (ie. python-zmq for Python2) was installed?
183 2016-05-09T10:02:07  <wumpus> the tests cannot be done using python 2 anymore
184 2016-05-09T10:02:35  <paveljanik> even if the branch was created at the time when python2 was used?
185 2016-05-09T10:02:59  <wumpus> as I understand it, the travis testing merges your changes into master then runs the tests
186 2016-05-09T10:03:05  <wumpus> so the python 3 test framework will get applied to it
187 2016-05-09T10:03:56  *** fengling__ is now known as fengling
188 2016-05-09T10:05:01  <paveljanik> wumpus, yes.
189 2016-05-09T10:05:11  <paveljanik> in the case, you linked to, python-zmq was installed
190 2016-05-09T10:05:20  <paveljanik> but python3-zmq was needed
191 2016-05-09T10:05:29  <paveljanik> ie. travis used wrong config IMO
192 2016-05-09T10:05:40  <paveljanik> the old one from pre-python3
193 2016-05-09T10:05:58  <wumpus> ah! so it uses the travis configuration from the branch it is testing, not master with the changes merged in
194 2016-05-09T10:05:59  *** Guest89406 has joined #bitcoin-core-dev
195 2016-05-09T10:06:20  <wumpus> as I'm fairly sure master's travis.yml specifies python3-zmq correctly
196 2016-05-09T10:06:24  <paveljanik> so rebasing the branch is the solution
197 2016-05-09T10:06:26  <paveljanik> yup
198 2016-05-09T10:06:47  *** gevs has quit IRC
199 2016-05-09T10:07:50  <wumpus> yes, but asking everyone to rebase their pull request because of completely unrelated issues is messy
200 2016-05-09T10:09:04  <phantomcircuit> i think travis is screwing up on 8026
201 2016-05-09T10:09:26  <paveljanik> yes, so if travis is using the old config and new test scripts from master, then yes, reverting the mentioned commit can help
202 2016-05-09T10:09:44  <phantomcircuit> hmm maybe not
203 2016-05-09T10:10:40  <phantomcircuit> oh i see
204 2016-05-09T10:10:41  <phantomcircuit> heh
205 2016-05-09T10:10:54  <phantomcircuit> fundrawtransaction.py tries to encrypt the wallet...
206 2016-05-09T10:13:49  <GitHub96> [bitcoin] laanwj opened pull request #8030: test: Revert fatal-ness of missing python-zmq (master...2016_05_revert_zmq_req_tests) https://github.com/bitcoin/bitcoin/pull/8030
207 2016-05-09T10:18:46  <jonasschnelli> The idea I had with resize the caches was that Bitcoin-Qt could ask for a db cache size during first run (like the datadir), then It could allocate ~>1GB, after IBD it could reduce it back to 100MB.
208 2016-05-09T10:19:30  <jonasschnelli> Using 1.5GB would probably reduce IBD form a couple of days to a couple of hours
209 2016-05-09T10:20:41  *** gill3s has quit IRC
210 2016-05-09T10:20:55  <wumpus> sounds like a good idea to me, probably the same option should hold when the node has been down for a while, while catching up
211 2016-05-09T10:21:38  <wumpus> it should be optional of course; not everyone cares about fast sync speed, some people prefer it to happen in the background with as little system load (cpu, memory) as possible
212 2016-05-09T10:23:16  <jonasschnelli> right
213 2016-05-09T10:24:02  <wumpus> but a choice when first launching the software would make snse
214 2016-05-09T10:24:42  <wumpus> sync as fast as possible, but hogging the computer, or sync slowly and steadily in the background, this could also set -par
215 2016-05-09T10:41:45  *** laurentmt has joined #bitcoin-core-dev
216 2016-05-09T10:43:27  *** laurentmt has quit IRC
217 2016-05-09T11:15:57  *** fengling has quit IRC
218 2016-05-09T11:17:18  *** gill3s has joined #bitcoin-core-dev
219 2016-05-09T11:22:17  *** BashCo has joined #bitcoin-core-dev
220 2016-05-09T11:25:18  *** BashCo_ has quit IRC
221 2016-05-09T11:28:00  *** Ginnarr has quit IRC
222 2016-05-09T11:34:23  <GitHub123> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e29cfc48fc08...a68f56e727c3
223 2016-05-09T11:34:24  <GitHub123> bitcoin/master b02119e Pavel Janík: Remove useless argument to AlertNotify....
224 2016-05-09T11:34:25  <GitHub123> bitcoin/master a68f56e Wladimir J. van der Laan: Merge #7958: Remove useless argument to AlertNotify....
225 2016-05-09T11:34:34  <GitHub31> [bitcoin] laanwj closed pull request #7958: Remove useless argument to AlertNotify. (master...20160427_AlertNotify_remove_arg) https://github.com/bitcoin/bitcoin/pull/7958
226 2016-05-09T11:35:01  *** BashCo has quit IRC
227 2016-05-09T11:35:09  *** BashCo_ has joined #bitcoin-core-dev
228 2016-05-09T11:36:19  *** jannes has joined #bitcoin-core-dev
229 2016-05-09T11:36:41  <jonasschnelli> wumpus: what was the reason you have started with lmdb? Did you had problems compiling leveldb for Odroid?
230 2016-05-09T11:36:58  <wumpus> leveldb was horribly slow on my odroid-C2
231 2016-05-09T11:36:59  <jonasschnelli> I just successfully compiled (and running IBD) bitcoin-core master for Pine64
232 2016-05-09T11:37:37  <wumpus> I noticed high I/O latency, but had nothing to compare to, so I wondered whether another database would do better
233 2016-05-09T11:38:01  <wumpus> haven't had any problems with stability of leveldb on aarch64
234 2016-05-09T11:38:32  <jonasschnelli> wumpus: But i guess you ran with a high DB cache?
235 2016-05-09T11:39:35  <wumpus> yes, reasonably high, though the device has 2GB  of memory so some care has to be taken not to invite the OOM killer
236 2016-05-09T11:39:41  <jonasschnelli> I guess if i run with -dbcache=1500 it will result in only tiny disk i/o?
237 2016-05-09T11:40:05  <wumpus> as long as not the entire utxo set fits in memory you'll have fairly much disk i/o, especially after flushes
238 2016-05-09T11:40:56  <jonasschnelli> Right. This is a point.
239 2016-05-09T11:41:22  <wumpus> anyhow I wanted a lmdb branch to be able to compare databases, many people said they were going to try with lmdb over the years and no one actually did it :) And ARM going 64-bit as well makes it somewhat more attractive.
240 2016-05-09T11:41:29  *** raedah has quit IRC
241 2016-05-09T11:42:33  <wumpus> I also have a dummydb branch, whose point is to have the entire utxo set in memory but in a more compact format than expanded -dbcache
242 2016-05-09T11:44:27  <wumpus> e.g. an utxo dump takes about 1.5GB, whereas a sync with -dbcache=<lots> goes to about 5.5GB of memory usage, so there is some scope there (not enough to fit everything into the 2GB of memory of the odroid probably, there will always be some overhead, but okay)
243 2016-05-09T11:45:34  <jonasschnelli> wumpus: what i/o (disk) do you use? SDCard? USB/SSD?
244 2016-05-09T11:46:02  <wumpus> I've tried with external USB2 hdd and with a network block device mounted over 1000gb link
245 2016-05-09T11:46:25  <wumpus> sdcard is a pretty bad idea for the database, I've worn at least one USB stick that way :)
246 2016-05-09T11:47:00  <jonasschnelli> Right. We discussed that before. 1GB link is probably the fastest i/o (next to the GPIO).
247 2016-05-09T11:47:38  <wumpus> there's no SATA on the board unfortuantely or I'd have used that
248 2016-05-09T11:47:54  <wumpus> yes the network I/O is fast
249 2016-05-09T11:48:12  <wumpus> in throughput at least, latency was still disappointing here
250 2016-05-09T11:48:55  <jonasschnelli> Hmm... good point. Latency might be very important for the utxo set
251 2016-05-09T11:51:27  <jonasschnelli> Pine64<->USB2.0<->HDD should result in 30MB/s r/w. Not very powerful but should be enough for a full node.
252 2016-05-09T11:51:32  <wumpus> as for databases my (inconclusive) results seems to be that lmdb was somewhat better in query latency, but leveldb seems to be faster in writing
253 2016-05-09T11:51:37  <jonasschnelli> Disabling bloom filter should be done then.
254 2016-05-09T11:52:10  <wumpus> yes the throughput is good enough
255 2016-05-09T11:52:19  <wumpus> especially for block storage
256 2016-05-09T11:52:53  <jonasschnelli> But I guess also the latency. GBit Eth. has probably higher latencies (regarding utxo set)
257 2016-05-09T12:01:47  <GitHub145> [bitcoin] s-matthew-english opened pull request #8031: improvement to readability (master...patch-3) https://github.com/bitcoin/bitcoin/pull/8031
258 2016-05-09T12:05:58  *** bysherper has joined #bitcoin-core-dev
259 2016-05-09T12:09:04  *** earlest has quit IRC
260 2016-05-09T12:12:49  *** laurentmt has joined #bitcoin-core-dev
261 2016-05-09T12:13:15  *** laurentmt has quit IRC
262 2016-05-09T12:23:22  *** cryptapus_afk is now known as cryptapus
263 2016-05-09T12:26:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
264 2016-05-09T12:31:10  *** Ylbam has quit IRC
265 2016-05-09T12:49:34  *** MarcoFalke has joined #bitcoin-core-dev
266 2016-05-09T12:53:53  <MarcoFalke> wumpus, have you tried clearing the travis cache? If you look at  7938 there are also other pulls messed up (This one prob due to the cpp11 switch) ...
267 2016-05-09T12:54:11  <MarcoFalke> I am just guessing that it is caused by corrupt cache, though.
268 2016-05-09T12:59:06  <wumpus> I've tried clearing the caches for a few pulls, yes, what I have not tried is clearing all the caches
269 2016-05-09T12:59:24  <wumpus> (afraid it will hamper all testing)
270 2016-05-09T13:00:16  <wumpus> but I can try clearing 7938, sure
271 2016-05-09T13:00:37  <MarcoFalke> As I understand it, it should only make it slower until there is a commit to -master. But if you prefer to disable the zmq error, fine with me.
272 2016-05-09T13:02:34  <MarcoFalke> I'd rather have more travis failures than less because the test can only tell you something is wrong. They can never tell you something is right.
273 2016-05-09T13:02:59  <MarcoFalke> So the alternative would be to ignore unrelated errors as best as possible
274 2016-05-09T13:03:32  <MarcoFalke> if they accumulate to high nubers, though, it might be better to disable the test...
275 2016-05-09T13:03:36  <wumpus> but false positives are bad, the missing zmq error prevents all RPC tests from being run
276 2016-05-09T13:04:26  <wumpus> it's preferable to just not run the zmq test - especially if the pull in question doesn't change anything zmq related at all
277 2016-05-09T13:04:39  *** Ylbam has joined #bitcoin-core-dev
278 2016-05-09T13:04:40  <MarcoFalke> I am assuming it would fail the other test as well because there is something wrong with the cached python version
279 2016-05-09T13:05:03  <wumpus> I don't think there is anything wrong with the cached python version, apart from the missing python3-zmq package
280 2016-05-09T13:05:39  <wumpus> I think it's simply a matter of the wrong package being installed
281 2016-05-09T13:05:50  <wumpus> e.g. python-zmq is installed instead of python3-zmq
282 2016-05-09T13:05:59  <wumpus> so the test fails to find it
283 2016-05-09T13:07:10  <paveljanik> But anyway, this is the only test that needs separate package installed. I think it should be written as it "succeeds" when the is no such package. It will make testing easier on clean installs, will shorten the documentation etc.
284 2016-05-09T13:07:23  <paveljanik> s/the/there/
285 2016-05-09T13:07:31  <wumpus> that used to be the case
286 2016-05-09T13:07:39  <paveljanik> yes
287 2016-05-09T13:07:50  <paveljanik> But I respect the change.
288 2016-05-09T13:08:02  <wumpus> until #7851, https://github.com/bitcoin/bitcoin/pull/8030 would temporarily bring back that behavior
289 2016-05-09T13:09:30  <wumpus> I'm open to other solutions, but 'all old pulls have to be rebased' is not acceptable
290 2016-05-09T13:09:43  <MarcoFalke> paveljanik, The error message is pretty clear how to fix the issue on the user side (#ERROR: \"import zmq\" failed. Set ENABLE_ZMQ=0 or ...
291 2016-05-09T13:10:06  <paveljanik> MarcoFalke, yes, of course. But slows down the work a bit.
292 2016-05-09T13:10:19  <paveljanik> wumpus, yes, definitely. It can also help us to understand the problem.
293 2016-05-09T13:10:22  <MarcoFalke> and I want travis to fail if pzthon-zmq is missing instead of just returning 'succeed'
294 2016-05-09T13:10:24  <wumpus> as this would mean you could no longer submit pulls based on older commits for no good reason
295 2016-05-09T13:10:26  <paveljanik> right now, we are all guessing only.
296 2016-05-09T13:10:42  <MarcoFalke> 8030 temporarily, ACK from me
297 2016-05-09T13:10:55  <wumpus> yes let's just try it
298 2016-05-09T13:11:09  <paveljanik> +1
299 2016-05-09T13:12:09  <GitHub109> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a68f56e727c3...409a8a1637d4
300 2016-05-09T13:12:09  <GitHub109> bitcoin/master 65fee8e Wladimir J. van der Laan: test: Revert fatal-ness of missing python-zmq...
301 2016-05-09T13:12:10  <GitHub109> bitcoin/master 409a8a1 Wladimir J. van der Laan: Merge #8030: test: Revert fatal-ness of missing python-zmq...
302 2016-05-09T13:12:24  <GitHub21> [bitcoin] laanwj closed pull request #8030: test: Revert fatal-ness of missing python-zmq (master...2016_05_revert_zmq_req_tests) https://github.com/bitcoin/bitcoin/pull/8030
303 2016-05-09T13:13:13  <wumpus> re-triggering #8006
304 2016-05-09T13:14:16  *** fengling has joined #bitcoin-core-dev
305 2016-05-09T13:14:28  <wumpus> if it fails on something else now, it's clear that the problem goes deeper
306 2016-05-09T13:15:59  * paveljanik grabs some popcorn ;-)
307 2016-05-09T13:18:56  *** fengling has quit IRC
308 2016-05-09T13:27:12  *** laurentmt has joined #bitcoin-core-dev
309 2016-05-09T13:31:15  *** MarcoFalke has quit IRC
310 2016-05-09T13:36:56  *** shesek has joined #bitcoin-core-dev
311 2016-05-09T14:04:27  <wumpus> looks like it worked https://github.com/bitcoin/bitcoin/pull/8006
312 2016-05-09T14:15:47  *** muftop has joined #bitcoin-core-dev
313 2016-05-09T14:20:19  <wumpus> any other pulls that need travis respin now?
314 2016-05-09T14:26:22  *** ghtdak has quit IRC
315 2016-05-09T14:27:57  *** spudowiar has quit IRC
316 2016-05-09T14:28:19  *** ghtdak has joined #bitcoin-core-dev
317 2016-05-09T14:31:14  <BlueMatt> gmaxwell: yea, sipa and I spoke about collision-recovery and trying each tx or just requesting...
318 2016-05-09T14:31:24  *** Giszmo has joined #bitcoin-core-dev
319 2016-05-09T14:31:40  <BlueMatt> gmaxwell: I hadnt done it originally, but if I'm gonna drop it from 64 bits to something smaller it starts to matter
320 2016-05-09T14:32:47  *** raedah has joined #bitcoin-core-dev
321 2016-05-09T14:33:30  *** laurentmt has quit IRC
322 2016-05-09T14:49:43  *** gill3s has quit IRC
323 2016-05-09T14:54:57  *** MarcoFalke has joined #bitcoin-core-dev
324 2016-05-09T14:59:45  *** spudowiar has joined #bitcoin-core-dev
325 2016-05-09T15:00:45  <GitHub186> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/409a8a1637d4...3e90fe653420
326 2016-05-09T15:00:46  <GitHub186> bitcoin/master 5ea4508 Jonas Schnelli: Autofind rpc tests --srcdir
327 2016-05-09T15:00:47  <GitHub186> bitcoin/master 3e90fe6 MarcoFalke: Merge #8018: Autofind rpc tests --srcdir...
328 2016-05-09T15:00:58  <GitHub197> [bitcoin] MarcoFalke closed pull request #8018: Autofind rpc tests --srcdir (master...2016/05/fix_test_srcdir) https://github.com/bitcoin/bitcoin/pull/8018
329 2016-05-09T15:02:57  *** bsm1175321 has joined #bitcoin-core-dev
330 2016-05-09T15:03:11  *** bsm1175321 is now known as bsm117532
331 2016-05-09T15:03:50  *** raedah has quit IRC
332 2016-05-09T15:04:27  *** gill3s has joined #bitcoin-core-dev
333 2016-05-09T15:05:37  *** gill3s has quit IRC
334 2016-05-09T15:06:09  *** gill3s has joined #bitcoin-core-dev
335 2016-05-09T15:07:04  <GitHub98> [bitcoin] MarcoFalke pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/3e90fe653420...4e14afe42fdd
336 2016-05-09T15:07:05  <GitHub98> bitcoin/master fabbf6b MarcoFalke: [qa] Refactor test_framework and pull tester...
337 2016-05-09T15:07:06  <GitHub98> bitcoin/master 2222dae MarcoFalke: [qa] Update README.md
338 2016-05-09T15:07:06  <GitHub98> bitcoin/master fafb33c MarcoFalke: [qa] Stop other nodes, even when one fails to stop
339 2016-05-09T15:07:19  <GitHub50> [bitcoin] MarcoFalke closed pull request #7971: [qa] Refactor test_framework and pull tester (master...Mf1604-qaRefactor) https://github.com/bitcoin/bitcoin/pull/7971
340 2016-05-09T15:12:41  <jonasschnelli> gmaxwell, sipa: for keypools containing HD keys: do we need two keypools? one for internal (change), one for external usage?
341 2016-05-09T15:13:31  <sipa> yes
342 2016-05-09T15:13:42  <sipa> but i don't think that's a necessity for a first working version
343 2016-05-09T15:14:38  <jonasschnelli> sipa, okay will start using only the external chain.
344 2016-05-09T15:15:01  <jonasschnelli> Also,.. i will re-derive the external child key in each GenerateNewKey to keep the diff small and tight.
345 2016-05-09T15:17:28  *** fengling has joined #bitcoin-core-dev
346 2016-05-09T15:20:17  *** gill3s has quit IRC
347 2016-05-09T15:21:51  *** BashCo_ has quit IRC
348 2016-05-09T15:21:57  *** fengling has quit IRC
349 2016-05-09T15:27:39  *** gill3s has joined #bitcoin-core-dev
350 2016-05-09T15:33:42  *** raedah has joined #bitcoin-core-dev
351 2016-05-09T15:40:35  *** CubicEarth has joined #bitcoin-core-dev
352 2016-05-09T15:42:40  *** earlest has joined #bitcoin-core-dev
353 2016-05-09T15:45:34  *** bysherper has quit IRC
354 2016-05-09T15:45:52  *** BashCo has joined #bitcoin-core-dev
355 2016-05-09T15:48:29  <jonasschnelli> sipa, if we only have one hd master key in the database, would a static AES IV be okay for encrypting/decrypting the master key?
356 2016-05-09T15:48:57  <jonasschnelli> Or do i have to generate a random IV and store if in the same data-record?
357 2016-05-09T15:49:19  <jonasschnelli> nm, ... need to do the later
358 2016-05-09T15:49:24  <sipa> you can just make the master key itself a wallet key
359 2016-05-09T15:49:42  <sipa> and store the corresponding pubkeyhash in the wallet
360 2016-05-09T15:49:52  <jonasschnelli> meh..
361 2016-05-09T15:49:58  <sipa> so you automatically get the encryption benefits
362 2016-05-09T15:50:11  <jonasschnelli> though about that. But do we really want to loose the CExtKey metadata?
363 2016-05-09T15:50:26  <sipa> how do you mean?
364 2016-05-09T15:50:28  <jonasschnelli> This would really be hard to extend then (if we would use a CKey for the master key)
365 2016-05-09T15:50:38  <sipa> why?
366 2016-05-09T15:51:24  <jonasschnelli> What if someone wants to later start a wallet with a xpriv at m/44/0/0?
367 2016-05-09T15:52:02  <jonasschnelli> And how would we distinct between a normal CKey and a CKey thats used as bip32 masterkey?
368 2016-05-09T15:52:08  <jonasschnelli> Just over the metadata?
369 2016-05-09T15:52:24  <sipa> just make it a ckey that's not added to the keypool
370 2016-05-09T15:52:33  <sipa> so it's never exposed as a receive address
371 2016-05-09T15:52:55  <sipa> maybe add a field to its metadata to indicate that it's not a wallet key
372 2016-05-09T15:53:42  <jonasschnelli> hmm... but ckey is used for crypted keys, right? At least during db load we need to identify the ckey that is used for a master key.
373 2016-05-09T15:53:51  <sipa> why?
374 2016-05-09T15:54:17  <jonasschnelli> hmm... right, we could just store the pubkeyhash somewhere to identify the master key...
375 2016-05-09T15:54:42  <jonasschnelli> But all "ckey" objects get passed into LoadCryptedKey
376 2016-05-09T15:54:54  <sipa> yes, that's exactly what you want?
377 2016-05-09T15:55:06  <jonasschnelli> What if the wallet is unencrypted?!
378 2016-05-09T15:55:18  <sipa> then it's stored as an unencrypted key
379 2016-05-09T15:55:23  <jonasschnelli> heh...
380 2016-05-09T15:55:23  <sipa> also exactly what you want
381 2016-05-09T15:55:50  <jonasschnelli> Where do we store the chaincode? Unencrypted in metadata?
382 2016-05-09T15:56:01  <jonasschnelli> Ah.. wait.
383 2016-05-09T15:56:06  <jonasschnelli> We always use setMaster()
384 2016-05-09T15:56:09  *** raedah has quit IRC
385 2016-05-09T15:56:09  <sipa> yes, you'd have a hdderive wallet record which stores 1) the pubkeyhash of the master key 2) the path for derivation 3) how many keys have been derived already
386 2016-05-09T15:56:35  <sipa> you could avoid 3, and derive it at startup
387 2016-05-09T15:56:44  <jonasschnelli> Okay. I'll see. This is simpler. Thanks for the sparring.
388 2016-05-09T15:56:53  <jonasschnelli> 3 is necessary to refill the keypool i guess
389 2016-05-09T15:57:11  <sipa> right, but when generating a new key, you can just check whether you already have the newly derived key
390 2016-05-09T15:57:25  <sipa> and in that case, increment the (in-memory only) counter and try again
391 2016-05-09T15:57:44  <jonasschnelli> okay... this could get slow if your keypool gets bigger
392 2016-05-09T15:57:52  <sipa> perhaps you can even use exponential backoff, so it's only log(n) time in the number of keys
393 2016-05-09T15:58:06  <jonasschnelli> I don't use flexible keypath for now. So your 2) is not necessary for now.
394 2016-05-09T15:58:16  <jonasschnelli> Is will just use m/1/<key>
395 2016-05-09T15:58:24  <jonasschnelli> To avoid another 50L of code
396 2016-05-09T15:58:28  <sipa> ok
397 2016-05-09T16:07:45  *** BashCo_ has joined #bitcoin-core-dev
398 2016-05-09T16:10:06  *** raedah has joined #bitcoin-core-dev
399 2016-05-09T16:10:12  *** BashCo has quit IRC
400 2016-05-09T16:13:14  *** spudowiar has quit IRC
401 2016-05-09T16:25:35  *** CubicEarth has quit IRC
402 2016-05-09T16:40:58  *** kadoban has joined #bitcoin-core-dev
403 2016-05-09T16:41:11  *** Ylbam has quit IRC
404 2016-05-09T16:55:39  *** gill3s has quit IRC
405 2016-05-09T17:00:40  *** muftop has quit IRC
406 2016-05-09T17:01:01  *** raedah has quit IRC
407 2016-05-09T17:01:36  *** muftop has joined #bitcoin-core-dev
408 2016-05-09T17:02:30  *** raedah has joined #bitcoin-core-dev
409 2016-05-09T17:06:09  *** raedah has quit IRC
410 2016-05-09T17:07:24  *** raedah has joined #bitcoin-core-dev
411 2016-05-09T17:19:53  *** fengling has joined #bitcoin-core-dev
412 2016-05-09T17:24:36  *** fengling has quit IRC
413 2016-05-09T17:26:49  *** raedah has joined #bitcoin-core-dev
414 2016-05-09T17:27:02  *** Giszmo has quit IRC
415 2016-05-09T17:29:26  *** G1lius has quit IRC
416 2016-05-09T17:29:49  *** cheese_ has quit IRC
417 2016-05-09T17:32:51  *** raedah has left #bitcoin-core-dev
418 2016-05-09T17:38:23  *** Cheeseo has joined #bitcoin-core-dev
419 2016-05-09T17:38:23  *** Cheeseo has joined #bitcoin-core-dev
420 2016-05-09T17:44:11  *** BashCo has joined #bitcoin-core-dev
421 2016-05-09T17:45:51  *** BashCo_ has quit IRC
422 2016-05-09T17:46:32  *** Ylbam has joined #bitcoin-core-dev
423 2016-05-09T17:46:47  *** Chris_Stewart_5 has quit IRC
424 2016-05-09T17:49:47  *** waxmiguel_ has joined #bitcoin-core-dev
425 2016-05-09T18:18:49  *** bysherper has joined #bitcoin-core-dev
426 2016-05-09T18:22:04  *** earlest has quit IRC
427 2016-05-09T18:27:13  *** raedah1 has joined #bitcoin-core-dev
428 2016-05-09T18:28:50  *** gill3s has joined #bitcoin-core-dev
429 2016-05-09T18:32:31  *** MarcoFalke has quit IRC
430 2016-05-09T18:35:41  *** kadoban has quit IRC
431 2016-05-09T18:37:39  *** molz has joined #bitcoin-core-dev
432 2016-05-09T18:39:21  *** moli has quit IRC
433 2016-05-09T18:39:40  *** moli has joined #bitcoin-core-dev
434 2016-05-09T18:42:58  *** molz has quit IRC
435 2016-05-09T18:44:22  *** earlest has joined #bitcoin-core-dev
436 2016-05-09T18:47:34  *** bysherper has quit IRC
437 2016-05-09T18:55:24  *** waxmiguel_ has quit IRC
438 2016-05-09T19:00:44  *** molz has joined #bitcoin-core-dev
439 2016-05-09T19:03:37  *** moli has quit IRC
440 2016-05-09T19:05:23  *** molly has joined #bitcoin-core-dev
441 2016-05-09T19:07:39  *** molz has quit IRC
442 2016-05-09T19:14:34  *** molly has quit IRC
443 2016-05-09T19:24:48  *** TomMc has joined #bitcoin-core-dev
444 2016-05-09T19:46:49  *** fengling has joined #bitcoin-core-dev
445 2016-05-09T19:51:37  *** fengling has quit IRC
446 2016-05-09T19:58:54  <luke-jr> CodeShark: I think this is broken: if (pindex->nVersion > VERSIONBITS_LAST_OLD_BLOCK_VERSION && (pindex->nVersion & ~nExpectedVersion) != 0)
447 2016-05-09T20:21:51  <gmaxwell> BlueMatt: sipa suggests the sender choose the size, and send a byte with the number of bytes, constrained to 4-8.
448 2016-05-09T20:22:52  <gmaxwell> BlueMatt: sipa can probably suggest a decision table based on block/mempool size.
449 2016-05-09T20:34:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
450 2016-05-09T20:43:47  *** Chris_Stewart_5 has quit IRC
451 2016-05-09T20:47:10  *** jannes has quit IRC
452 2016-05-09T20:52:14  *** BitcoinErrorLog has joined #bitcoin-core-dev
453 2016-05-09T20:52:58  <BlueMatt> gmaxwell: yea, I was thinking I might have to split udp vs tcp for size, but thats a good point that you could even lookup-table-it
454 2016-05-09T20:53:08  <BlueMatt> though I'm not sure how useful that would be really well
455 2016-05-09T20:56:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
456 2016-05-09T20:58:33  <sipa> BlueMatt: the formula is just log2(mempool_txn * unmatched_txn / failure_rate)
457 2016-05-09T20:58:54  <sipa> if that's over 40, use 6 bytes, otherwise 5
458 2016-05-09T21:02:21  <gmaxwell> BlueMatt: did you see my comment about adding the orphan pool to your search.
459 2016-05-09T21:04:53  <BlueMatt> gmaxwell: I did not
460 2016-05-09T21:05:06  <BlueMatt> valid point, but "meh"
461 2016-05-09T21:07:02  <gmaxwell> BlueMatt: I instrumented my copy and a lot of the missed txn are in the orphan pool.
462 2016-05-09T21:07:50  <BlueMatt> WTF :(
463 2016-05-09T21:09:24  *** murch has quit IRC
464 2016-05-09T21:11:07  <gmaxwell> actually it makes a lot of sense until the node has been up a long time. the reason is that txn get stuck outside of the chain due to missing parents thanks to trickling.
465 2016-05-09T21:11:23  <gmaxwell> it'll be much better with 0.13 widely deployed, but it's cheap to check the orphan pool.
466 2016-05-09T21:20:54  <BlueMatt> yea, understood
467 2016-05-09T21:31:26  <gmaxwell> (we also need to fix some of the orphan pool issues that the trickle improvements exposed)
468 2016-05-09T21:32:34  <BlueMatt> yea, that
469 2016-05-09T21:33:04  *** moli has joined #bitcoin-core-dev
470 2016-05-09T21:49:49  *** fengling has joined #bitcoin-core-dev
471 2016-05-09T21:54:36  *** fengling has quit IRC
472 2016-05-09T21:56:38  *** erasmospunk has joined #bitcoin-core-dev
473 2016-05-09T22:12:49  *** TomMc has quit IRC
474 2016-05-09T22:20:33  *** kadoban has joined #bitcoin-core-dev
475 2016-05-09T22:23:33  *** cryptapus_ has joined #bitcoin-core-dev
476 2016-05-09T22:28:04  *** cryptapus_ has quit IRC
477 2016-05-09T22:29:41  *** TomMc has joined #bitcoin-core-dev
478 2016-05-09T22:50:52  *** Guyver2 has quit IRC
479 2016-05-09T23:14:31  *** AaronvanW has quit IRC
480 2016-05-09T23:38:24  *** belcher has joined #bitcoin-core-dev
481 2016-05-09T23:38:55  *** cryptapus is now known as cryptapus_afk
482 2016-05-09T23:40:48  *** tsunami11 has joined #bitcoin-core-dev
483 2016-05-09T23:45:42  *** fengling has joined #bitcoin-core-dev
484 2016-05-09T23:57:02  *** alpalp has joined #bitcoin-core-dev
485 2016-05-09T23:57:02  *** alpalp has joined #bitcoin-core-dev