1 2016-04-28T00:00:21  <gmaxwell> I think there isn't much point in using memset_s when currently nothing has it, AFAIK.
  2 2016-04-28T00:08:07  <cfields> gmaxwell: iirc it's required by c11? We could get really nasty and add a single c11 file :p
  3 2016-04-28T00:08:14  *** wallet42 has joined #bitcoin-core-dev
  4 2016-04-28T00:10:27  <luke-jr> C11 != C++11
  5 2016-04-28T00:10:56  <cfields> luke-jr: right, hence the single c11 file
  6 2016-04-28T00:11:21  <randy-waterhouse> cfields: re https://github.com/bitcoin/bitcoin/pull/7165 I dont think libsecpk251 requires c++11 ... or does it?
  7 2016-04-28T00:11:23  <luke-jr> ah, with a function call to it from C++?
  8 2016-04-28T00:11:35  <luke-jr> libsecpk251 is C89 IIRC
  9 2016-04-28T00:11:38  <cfields> luke-jr: yea. That wasn't a real suggestion, though
 10 2016-04-28T00:11:59  <luke-jr> oh, lol
 11 2016-04-28T00:13:05  <cfields> randy-waterhouse: ^^. That doesn't change anything for libsecp256k1
 12 2016-04-28T00:14:39  <randy-waterhouse> but the other dependencies now are all built using c++11
 13 2016-04-28T00:15:04  <cfields> randy-waterhouse: the c++ ones are. The c deps don't change
 14 2016-04-28T00:15:35  <randy-waterhouse> ah ok, lost sight of bigger picture
 15 2016-04-28T00:16:09  <sipa> i wonder if compiling libsecp256k1 with c++11 would work (without any extern "C" { blocks, i mean)
 16 2016-04-28T00:16:17  <cfields> sipa: yep
 17 2016-04-28T00:16:23  <cfields> sipa: c++14, at least
 18 2016-04-28T00:16:32  <sipa> ha
 19 2016-04-28T00:16:37  <cfields> i played with it a while back to see what i could make constexpr
 20 2016-04-28T00:16:49  <cfields> iirc there were 1 or 2 explicit casts needed, but nothing else
 21 2016-04-28T00:16:58  <sipa> interesting
 22 2016-04-28T00:17:09  * sipa used git rerere for the first time today
 23 2016-04-28T00:17:32  <cfields> sipa: ah damn, i meant to remind you about that at last week's meeting
 24 2016-04-28T00:18:01  <cfields> makes segwit rebasing a bit easier, i hope?
 25 2016-04-28T00:18:16  <sipa> i'm not rebasing segwit
 26 2016-04-28T00:18:32  <sipa> not until right before merge
 27 2016-04-28T00:18:56  <sipa> plan is to just add fixup commits, and have a single merge with master commit at the end
 28 2016-04-28T00:18:57  <cfields> oh, i figured you had a local branch that you were rebasing along the way
 29 2016-04-28T00:19:08  *** laurentmt has joined #bitcoin-core-dev
 30 2016-04-28T00:19:18  <cfields> gotcha
 31 2016-04-28T00:24:32  *** cryptapus_ has joined #bitcoin-core-dev
 32 2016-04-28T00:24:38  *** cryptapus_ is now known as cryptapus_afk
 33 2016-04-28T00:24:55  *** cryptapus has quit IRC
 34 2016-04-28T00:28:48  <luke-jr> sipa: I used to use git-rerere, but I found it too dangerous
 35 2016-04-28T00:40:24  *** AaronvanW has quit IRC
 36 2016-04-28T00:41:23  <gmaxwell> cfields: I don't think it's required, I think it's in an appendix.
 37 2016-04-28T00:50:12  *** laurentmt has quit IRC
 38 2016-04-28T00:56:16  *** frankenmint has joined #bitcoin-core-dev
 39 2016-04-28T01:01:08  *** Ylbam has quit IRC
 40 2016-04-28T01:07:44  *** cryptapus_afk is now known as cryptapus_
 41 2016-04-28T01:07:46  *** cryptapus_ is now known as cryptapus
 42 2016-04-28T01:14:45  *** cryptapus is now known as cryptapus_afk
 43 2016-04-28T01:15:58  *** Chris_Stewart_5 has quit IRC
 44 2016-04-28T01:20:57  *** aburan28 has quit IRC
 45 2016-04-28T01:23:01  *** fengling has joined #bitcoin-core-dev
 46 2016-04-28T01:29:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 47 2016-04-28T01:32:47  *** belcher has quit IRC
 48 2016-04-28T01:39:03  <achow101> would it be possible, for after segwit deployment, to have a command line option to have Bitcoin Core write blocks to the disk in the pre-fork block forkmat?
 49 2016-04-28T01:47:42  <gmaxwell> achow101: it needs the data itself... the block files really aren't meant to be consumed by external software.
 50 2016-04-28T01:51:05  *** Chris_Stewart_5 has quit IRC
 51 2016-04-28T01:57:14  <achow101> Yeah, I realize that and the situation is non-ideal. I just thought that it might be possible to prune the segwit data to maintain backwards compatibility with software like Armory
 52 2016-04-28T02:06:56  *** NotAnNSAgent has quit IRC
 53 2016-04-28T02:07:15  *** NotAnNSAgent has joined #bitcoin-core-dev
 54 2016-04-28T02:10:39  *** frankenmint has quit IRC
 55 2016-04-28T02:39:25  <GitHub154> [bitcoin] 21E14 opened pull request #7962: CalculateNextWorkRequired Cleanup (master...cleanpow) https://github.com/bitcoin/bitcoin/pull/7962
 56 2016-04-28T02:54:03  *** frankenmint has joined #bitcoin-core-dev
 57 2016-04-28T02:58:47  *** TomMc has joined #bitcoin-core-dev
 58 2016-04-28T03:12:02  *** luke-jr has quit IRC
 59 2016-04-28T03:13:09  *** TomMc has quit IRC
 60 2016-04-28T03:15:38  *** luke-jr has joined #bitcoin-core-dev
 61 2016-04-28T03:32:01  *** Alopex has quit IRC
 62 2016-04-28T03:33:07  *** Alopex has joined #bitcoin-core-dev
 63 2016-04-28T03:48:01  *** Alopex has quit IRC
 64 2016-04-28T03:49:06  *** Alopex has joined #bitcoin-core-dev
 65 2016-04-28T03:57:11  *** roidster has quit IRC
 66 2016-04-28T04:07:20  *** xiangfu has joined #bitcoin-core-dev
 67 2016-04-28T04:08:24  *** droark has joined #bitcoin-core-dev
 68 2016-04-28T04:09:33  *** molz has joined #bitcoin-core-dev
 69 2016-04-28T04:10:33  *** PRab_ has joined #bitcoin-core-dev
 70 2016-04-28T04:11:59  *** PRab has quit IRC
 71 2016-04-28T04:12:06  *** PRab_ is now known as PRab
 72 2016-04-28T04:13:34  *** moli has quit IRC
 73 2016-04-28T04:25:30  <NotAnNSAgent> verificationprogress: 0.86206621
 74 2016-04-28T04:25:38  <NotAnNSAgent> Zzz... it's been many days.
 75 2016-04-28T04:40:03  *** NotAnNSAgent has quit IRC
 76 2016-04-28T05:04:07  *** frankenmint has quit IRC
 77 2016-04-28T05:04:41  *** frankenmint has joined #bitcoin-core-dev
 78 2016-04-28T05:08:22  *** frankenmint has quit IRC
 79 2016-04-28T05:08:40  *** frankenmint has joined #bitcoin-core-dev
 80 2016-04-28T05:09:04  *** supasonic has quit IRC
 81 2016-04-28T05:09:31  *** supasonic has joined #bitcoin-core-dev
 82 2016-04-28T05:12:27  *** BonyM has joined #bitcoin-core-dev
 83 2016-04-28T05:30:36  *** fengling has quit IRC
 84 2016-04-28T05:51:39  *** grassass has joined #bitcoin-core-dev
 85 2016-04-28T05:54:59  *** ThomasV has joined #bitcoin-core-dev
 86 2016-04-28T05:56:42  *** Ylbam has joined #bitcoin-core-dev
 87 2016-04-28T06:00:44  *** arowser_ has quit IRC
 88 2016-04-28T06:01:14  *** arowser has joined #bitcoin-core-dev
 89 2016-04-28T06:07:37  *** jtimon has quit IRC
 90 2016-04-28T06:25:52  *** BashCo has quit IRC
 91 2016-04-28T06:35:34  *** ThomasV has quit IRC
 92 2016-04-28T06:48:46  *** BashCo has joined #bitcoin-core-dev
 93 2016-04-28T07:01:11  *** fengling has joined #bitcoin-core-dev
 94 2016-04-28T07:43:02  *** Alopex has quit IRC
 95 2016-04-28T07:44:07  *** Alopex has joined #bitcoin-core-dev
 96 2016-04-28T07:52:12  *** Amnez777 has quit IRC
 97 2016-04-28T07:57:30  *** Hmmmm has joined #bitcoin-core-dev
 98 2016-04-28T08:04:35  *** cjcj has joined #bitcoin-core-dev
 99 2016-04-28T08:11:17  *** AaronvanW has joined #bitcoin-core-dev
100 2016-04-28T08:12:50  *** Thireus has quit IRC
101 2016-04-28T08:22:01  *** cryptapus_afk has quit IRC
102 2016-04-28T08:22:29  *** supasonic has quit IRC
103 2016-04-28T08:23:28  *** Hmmmm has quit IRC
104 2016-04-28T08:24:59  *** cryptapus_afk has joined #bitcoin-core-dev
105 2016-04-28T08:25:18  *** Thireus has joined #bitcoin-core-dev
106 2016-04-28T08:52:23  <GitHub149> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/08b37c5e06bf...06162f19d7dd
107 2016-04-28T08:52:24  <GitHub149> bitcoin/master 67969af Wladimir J. van der Laan: build: Enable C++11 build, require C++11 compiler...
108 2016-04-28T08:52:24  <GitHub149> bitcoin/master a398549 Cory Fields: depends: use c++11
109 2016-04-28T08:52:25  <GitHub149> bitcoin/master 2aacc72 Wladimir J. van der Laan: build: update ax_cxx_compile_stdcxx to serial 4
110 2016-04-28T08:52:48  <GitHub116> [bitcoin] laanwj closed pull request #7165: build: Enable C++11 in build, require C++11 compiler (master...2015_12_c++11) https://github.com/bitcoin/bitcoin/pull/7165
111 2016-04-28T08:53:25  <gmaxwell> hurray
112 2016-04-28T08:57:57  <wumpus> yeahhh finally
113 2016-04-28T09:10:42  <sipa> \o/
114 2016-04-28T09:11:00  *** Guyver2 has joined #bitcoin-core-dev
115 2016-04-28T09:11:48  <wumpus> jonasschnelli: FYI (reading your post in #7917) debug.logs compress *very* well
116 2016-04-28T09:12:14  <jonasschnelli> Right. Was to lazy.
117 2016-04-28T09:12:18  <wumpus> heh
118 2016-04-28T09:12:20  <jonasschnelli> At least i should enable mod_deflate
119 2016-04-28T09:12:25  <jonasschnelli> (for apache)
120 2016-04-28T09:14:19  <wumpus> right, that'd at least save bandwidth
121 2016-04-28T09:14:49  <jonasschnelli> Post #7165 means we can use C++11 features now? Right? Core will no longer compile on non C++11 compilers?
122 2016-04-28T09:16:18  <gmaxwell> I belive the goal was to avoid refactoring to use c++11 but to mostly use it in new code, so that things that we have to backport won't need to be rewritten, and so weren't not causing gratitious churn right now.
123 2016-04-28T09:16:18  <sipa> i wonder how much performance we gained :)
124 2016-04-28T09:17:04  <jonasschnelli> Hmm... is there no plan for removing the boost beast longterm?
125 2016-04-28T09:17:29  <gmaxwell> Absolutely, but not now.
126 2016-04-28T09:17:32  <wumpus> yes, we can use C++11 features now
127 2016-04-28T09:17:57  <jonasschnelli> So, new code will use c++11 foreachs old code still sticks with BOOST_FOREACH?
128 2016-04-28T09:17:59  <wumpus> and yes I'd suggest mostly doing so in the anicillary parts, not in main.cpp and other things that should be backported to 0.12 for segwit
129 2016-04-28T09:18:10  <gmaxwell> I think we shouldn't do any major refactors to use C++11 things until we're no longer supporting a non-C++11 release. (on top of the orindary desire to not have a lot of refactor disruption)
130 2016-04-28T09:18:16  <wumpus> using it in things that are new features in 0.13 anyhow is fine
131 2016-04-28T09:18:17  <sipa> i think converting sync.h to use std::thread would be fine, for example
132 2016-04-28T09:18:24  <jonasschnelli> gmaxwell: good point!
133 2016-04-28T09:18:25  <sipa> as it is very unlikely to conflict with anything
134 2016-04-28T09:18:35  <sipa> but yes, don't go all over the code to convert everything
135 2016-04-28T09:18:39  <wumpus> sipa: definitely, that is very unlikely to have to be changed for segwit, or anything backported
136 2016-04-28T09:18:42  <gmaxwell> self contained things... yep, new features. yep.
137 2016-04-28T09:18:57  <wumpus> so for the utilities and such: fine
138 2016-04-28T09:19:28  <jonasschnelli> Okay. Are there any c++11 features we should avoid? Like atomics?
139 2016-04-28T09:19:45  <wumpus> after segwit is merged to 0.12 I don't care anymore and IMO we can go full c++11 crazy
140 2016-04-28T09:20:01  <wumpus> (keeping in mind the risks that refactors always bring, of course)
141 2016-04-28T09:20:30  <jonasschnelli> Right. I agree with gmaxwell: As long as we support 0.12 (non C++11) we should not refactor to much
142 2016-04-28T09:20:52  <wumpus> I've arbitrarily set the minimum to gcc 4.7 and clang 3.3 in release-notes, don't know if they have atomics, it's open for discussion anyhow
143 2016-04-28T09:21:05  <gmaxwell> atomics aren't a replacement for proper locking... I don't know that we'd have that much use for atomics, but I am not aware of a reason to bar them right now.
144 2016-04-28T09:21:20  <sipa> https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
145 2016-04-28T09:21:38  <sipa> 4.7 has atomics
146 2016-04-28T09:21:46  <wumpus> nice
147 2016-04-28T09:22:04  *** pedrobranco has joined #bitcoin-core-dev
148 2016-04-28T09:22:18  <gmaxwell> (like, for example, they might get used in the RNG.. but most places should just use conventional locking)
149 2016-04-28T09:22:48  <wumpus> right, definitely use convential locking unless there is a specific performance bottleneck where atomics wuld help a lot
150 2016-04-28T09:22:55  <gmaxwell> (because most of the time you need more complex data structures than atomics provide, and constructing safe data structures out of atomics is a bit rocket sciency for 99.999% of code)
151 2016-04-28T09:23:00  * sipa wants: auto, range for, rvalue references/moves, std::thread etc, nullptr, override, initializer lists
152 2016-04-28T09:23:12  <wumpus> code using atomics is usually even harder to review
153 2016-04-28T09:23:19  <gmaxwell> priorities should be changes that improve code safty, and changes that eliminate dependency on boost.
154 2016-04-28T09:23:25  <gmaxwell> once refactoring changes start.
155 2016-04-28T09:23:25  <wumpus> (unless it is for really trivial things like counters ...)
156 2016-04-28T09:23:56  <gmaxwell> wumpus: even with counters, you seldom have just one counter... :)
157 2016-04-28T09:24:23  <wumpus> right
158 2016-04-28T09:24:29  <sipa> for example for the debug=bench counters, atomics could be used i think?
159 2016-04-28T09:24:45  *** Amnez777 has joined #bitcoin-core-dev
160 2016-04-28T09:24:48  <sipa> all you need is += and get
161 2016-04-28T09:25:19  <gmaxwell> so long as you don't care if a print isn't mixing up data from seperate runs... for benchmarking its probably okay...
162 2016-04-28T09:25:34  <sipa> yeah
163 2016-04-28T09:26:16  <sipa> then again, they are currently just under cs_main and there is no reason to change that, as all the surrounding code also needs cs_main for now
164 2016-04-28T09:26:20  <wumpus> the debug=bench counters/accumulators are all used one at a time anyway afaik
165 2016-04-28T09:26:21  <gmaxwell> I've seen 'lock free' network stats code cause stupid failures in production systems, e.g. where there was a numerator and denominator, each updated atomically... and code that divided them and crashed with divide by zero because updating them indivigually atomically wasn't enough.
166 2016-04-28T09:27:48  <jonasschnelli> Call for a quick review: https://github.com/bitcoin/bitcoin/pull/7826 (<-- this will allow to GUI to display RBF conflicts)
167 2016-04-28T09:30:22  <gmaxwell> sipa: also when performance matters, cacheline bouncing is _really_ expensive.  atomics may not be a big performance win vs an ordinary lock... to get better performance: use per thread accumulators and infrequently merge them...
168 2016-04-28T09:31:29  <wumpus> jonasschnelli: it's a step forward - I do agree with marcofalke that what we really want here is a way to bring attention to the highest seq# transaction and 'grey out' the replaced ones. I'm not sure using the conflicts cross is the best way for that, it maybe looks to intimidating.
169 2016-04-28T09:31:42  <wumpus> (e.g. as if something is really wrong)
170 2016-04-28T09:32:14  <wumpus> but in any case your pull is a clear step forward
171 2016-04-28T09:32:46  <sipa> gmaxwell: aware (look at the crc code that you're running for me :p)
172 2016-04-28T09:32:50  <wumpus> better than showing both in the same way as waiting to be confirmed
173 2016-04-28T09:33:08  <wumpus> crc code?
174 2016-04-28T09:33:11  <jonasschnelli> wumpus: Right. I guess only RBF can result in a mempool conflict. So using a other icon should be fine.
175 2016-04-28T09:33:14  <jonasschnelli> Let me overhaul it.
176 2016-04-28T09:33:24  <sipa> wumpus: i'm benchmarking some crcs for a base32 address format :)
177 2016-04-28T09:34:08  <wumpus> sipa: have you seen https://github.com/laanwj/crcbench? (have been playing with crc instructions on aarch64 and sse42, and gmaxwell benchmarked on a few systems as well)
178 2016-04-28T09:34:24  <JackH> I know this is not the place for it, but could one of you help me out for a bitcoin-cli command I am struggling about? :)
179 2016-04-28T09:34:33  <wumpus> that's all for crc32c though as that's the one in leveldb
180 2016-04-28T09:35:01  <jonasschnelli> JackH: you are writing a new command (dev) or using a existing one (non-dev)?
181 2016-04-28T09:35:43  <sipa> wumpus: benchmarking how well they detect errors, not performance
182 2016-04-28T09:35:51  <wumpus> ohh okay
183 2016-04-28T09:35:52  <sipa> wumpus: https://github.com/sipa/ezbase32
184 2016-04-28T09:36:41  <JackH> what I want to do is to ./bitcoin-cli sendfrom but also include a fee. And I cant find any documentation on how to include both "sendfrom" and " settxfee ". The wiki doesnt explain it, and I am confused if I can type both commands on the same line?
185 2016-04-28T09:36:57  <sipa> JackH: settxfee modifies a global setting
186 2016-04-28T09:37:09  <wumpus> do the settxfee before the sendfrom
187 2016-04-28T09:37:10  <sipa> JackH: you need to run them separately
188 2016-04-28T09:37:36  <sipa> also, sendfrom will by default include a fee, based on estimations
189 2016-04-28T09:37:37  <JackH> ahh it modifies the global. So should I instead edit the .conf file and then do the sendfrom?
190 2016-04-28T09:37:53  <sipa> wumpus: latest development is a BCH code over GF(2^32) that guarantees detecting 4 errors with 6 base32 checksum
191 2016-04-28T09:38:04  <sipa> eh over GF(2^5)
192 2016-04-28T09:38:11  * jonasschnelli thinks we should probably add a optional feerate parameter to fundrawtransaction
193 2016-04-28T09:38:22  <wumpus> jonasschnelli: there isn't one yet?
194 2016-04-28T09:38:31  * jonasschnelli looking..
195 2016-04-28T09:38:39  <wumpus> I'm surprised, would be so much better than changing a global
196 2016-04-28T09:38:57  <jonasschnelli> no.. i don't think so. Maybe there is a PR.
197 2016-04-28T09:39:03  <sipa> there is a pr
198 2016-04-28T09:39:03  <jonasschnelli> Hard to keep track of everything. :)
199 2016-04-28T09:39:06  <wumpus> no, the PR does it wrong
200 2016-04-28T09:39:19  <jonasschnelli> It was an absolute fee IIRC
201 2016-04-28T09:39:38  <jonasschnelli> you pass in a feerate that one could determine with estimatefee
202 2016-04-28T09:39:45  <wumpus> ... which everyone is trying to convince the author of that it's a bad idea, but he won't reconsider, probably going to close it soon
203 2016-04-28T09:40:08  <jonasschnelli> The ugly thing is, that CreateTransaction uses the static DEFAULT_TARGET
204 2016-04-28T09:40:17  <wumpus> passing in an optional feerate would be the obvious thing to do
205 2016-04-28T09:40:20  <jonasschnelli> So, this would require some refactoring.
206 2016-04-28T09:40:34  <sipa> just add a confirmation target to coincontrol
207 2016-04-28T09:40:47  <jonasschnelli> Yes. This sounds good.
208 2016-04-28T09:40:47  <wumpus> right, just slap it into coincontrol
209 2016-04-28T09:40:56  <sipa> wasn't there a PR that added a bunch of options to fundrawtransaction?
210 2016-04-28T09:40:59  <sipa> including that
211 2016-04-28T09:41:04  <jonasschnelli> Not the feerate.
212 2016-04-28T09:41:10  <jonasschnelli> But the rest is merged.
213 2016-04-28T09:41:12  *** MarcoFalke has joined #bitcoin-core-dev
214 2016-04-28T09:41:24  <jonasschnelli> Which finally allows me to write my iOS Core Wallet client
215 2016-04-28T09:41:27  <wumpus> we have a bunch of options in fundrawtransactions, which is why I was confused
216 2016-04-28T09:41:39  <wumpus> yes that one was merged
217 2016-04-28T09:41:46  <jonasschnelli> (keep keys on smartphone, use watchonly core wallet, use fundrawtransactin, sign on the smartphone)
218 2016-04-28T09:41:52  <wumpus> jonasschnelli: nice
219 2016-04-28T09:42:31  <wumpus> sipa: how does that compare to standard CRC32?
220 2016-04-28T09:42:36  <jonasschnelli> It really made me thing that the wallet (in watchonly mode) is just a utility to keep track of user-(group-)relevant transactions.
221 2016-04-28T09:42:51  <jonasschnelli> like a selective tx-/address-index
222 2016-04-28T09:42:58  <wumpus> jonasschnelli: it is
223 2016-04-28T09:43:08  <wumpus> joinmarket uses it the same way
224 2016-04-28T09:43:25  <sipa> wumpus: a CRC32 isn't compatible with base32 (as it would produce 6.4 characters)
225 2016-04-28T09:43:47  <sipa> wumpus: i'm including a CRC30 though, and it seems to perform way better than the theory would predict
226 2016-04-28T09:46:03  <wumpus> sipa: ah right, get it now, output needs to be a multiple of 5 bits, not 32 bit
227 2016-04-28T09:46:42  <sipa> right, it's a checksum on base32 elements, so it takes a series of base32 tokens, and produces 6 extra ones
228 2016-04-28T09:47:17  <wumpus> instead of doing the checksum before the encoding, you do it afterward on the encoding itself
229 2016-04-28T09:47:39  <wumpus> I suppose that does make it easier to reason about the properties, yes
230 2016-04-28T09:48:19  <wumpus> and it's also slightly more convenient, no need to decode to check
231 2016-04-28T10:06:32  <sipa> indeed, though decoding base32 is sufficiently simple that it does not really matter
232 2016-04-28T10:06:46  <wumpus> yes it's not so unfortunate as base58
233 2016-04-28T10:15:56  *** Evel-Knievel has quit IRC
234 2016-04-28T10:21:51  <GitHub185> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/06162f19d7dd...574ddc63d6ff
235 2016-04-28T10:21:52  <GitHub185> bitcoin/master 17a6a21 Wladimir J. van der Laan: qt: Make it possible to show details for multiple transactions...
236 2016-04-28T10:21:52  <GitHub185> bitcoin/master f135e3c Wladimir J. van der Laan: qt: Add transaction hash to details window title
237 2016-04-28T10:21:53  <GitHub185> bitcoin/master 574ddc6 Wladimir J. van der Laan: Merge #7939: qt: Make it possible to show details for multiple transactions...
238 2016-04-28T10:22:01  <GitHub134> [bitcoin] laanwj closed pull request #7939: qt: Make it possible to show details for multiple transactions (master...2016_04_qt_multiple_transaction_details) https://github.com/bitcoin/bitcoin/pull/7939
239 2016-04-28T10:22:46  *** ghtdak has quit IRC
240 2016-04-28T10:23:26  *** ghtdak has joined #bitcoin-core-dev
241 2016-04-28T10:25:50  *** arowser has quit IRC
242 2016-04-28T10:26:07  *** arowser has joined #bitcoin-core-dev
243 2016-04-28T10:35:08  *** cjcj has quit IRC
244 2016-04-28T10:56:00  <GitHub110> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/574ddc63d6ff...d9594bfe0c3e
245 2016-04-28T10:56:00  <GitHub110> bitcoin/master 8aa7226 jmacwhyte: Fix IsInitialBlockDownload to play nice with testnet
246 2016-04-28T10:56:01  <GitHub110> bitcoin/master d9594bf Wladimir J. van der Laan: Merge #7514: Fix IsInitialBlockDownload for testnet...
247 2016-04-28T10:56:05  <GitHub167> [bitcoin] laanwj closed pull request #7514: Fix IsInitialBlockDownload for testnet (master...fixisinitialblock) https://github.com/bitcoin/bitcoin/pull/7514
248 2016-04-28T11:32:11  *** pmienk has quit IRC
249 2016-04-28T11:34:46  <wumpus> re: c++11 refactoring, we should convert the auto_ptrs to unique_ptrs IMO
250 2016-04-28T11:36:44  <sipa> i'm seeing the very strange error "Insufficient funds" in listtransactions.py (segwit branch, but nothing should have changed there)
251 2016-04-28T11:36:53  <sipa> but only when i run it through rpc-tests
252 2016-04-28T11:37:15  <sipa> if i run it standalone it works
253 2016-04-28T11:37:22  <sipa> is there any difference in setup between them?
254 2016-04-28T11:37:35  <wumpus> try deleting all cache directories
255 2016-04-28T11:38:40  <wumpus> otherwise, no, there is no difference in setup, rpc-tests simply starts the individual tests as processes
256 2016-04-28T11:39:58  *** cryptapus has joined #bitcoin-core-dev
257 2016-04-28T11:45:03  <GitHub41> [bitcoin] laanwj opened pull request #7964: Minor changes for c++11 consistency (master...2016_04_c++11_consistency) https://github.com/bitcoin/bitcoin/pull/7964
258 2016-04-28T11:45:32  *** NotAnNSAgent has joined #bitcoin-core-dev
259 2016-04-28T11:48:22  *** dermoth_ has joined #bitcoin-core-dev
260 2016-04-28T11:51:44  *** dermoth has quit IRC
261 2016-04-28T11:53:23  <GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d9594bfe0c3e...a9c8b744e887
262 2016-04-28T11:53:23  <GitHub168> bitcoin/master 61c0170 Pavel Janík: Log invalid block hash to make debugging easier.
263 2016-04-28T11:53:24  <GitHub168> bitcoin/master a9c8b74 Wladimir J. van der Laan: Merge #7952: Log invalid block hash to make debugging easier....
264 2016-04-28T11:53:33  <GitHub128> [bitcoin] laanwj closed pull request #7952: Log invalid block hash to make debugging easier. (master...20160426_Log_invalid_block) https://github.com/bitcoin/bitcoin/pull/7952
265 2016-04-28T12:08:39  *** xiangfu has quit IRC
266 2016-04-28T12:10:36  *** fengling has quit IRC
267 2016-04-28T12:13:07  *** Evel-Knievel has joined #bitcoin-core-dev
268 2016-04-28T12:32:13  *** randy-waterhouse has quit IRC
269 2016-04-28T12:36:02  <GitHub95> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a9c8b744e887...5725807402ec
270 2016-04-28T12:36:02  <GitHub95> bitcoin/master 9c0bcb6 instagibbs: push back getaddednodeinfo dead value
271 2016-04-28T12:36:03  <GitHub95> bitcoin/master 5725807 Wladimir J. van der Laan: Merge #7926: [RPC] push back getaddednodeinfo dead value...
272 2016-04-28T12:36:07  <GitHub86> [bitcoin] laanwj closed pull request #7926: [RPC] push back getaddednodeinfo dead value (master...getaddedpushbackmaster) https://github.com/bitcoin/bitcoin/pull/7926
273 2016-04-28T12:48:36  *** BonyM has quit IRC
274 2016-04-28T12:48:44  *** jtimon has joined #bitcoin-core-dev
275 2016-04-28T12:53:04  *** BonyM has joined #bitcoin-core-dev
276 2016-04-28T13:10:42  *** laurentmt has joined #bitcoin-core-dev
277 2016-04-28T13:15:28  *** Amnez777 has quit IRC
278 2016-04-28T13:16:51  *** Amnez777 has joined #bitcoin-core-dev
279 2016-04-28T13:32:10  *** Giszmo has joined #bitcoin-core-dev
280 2016-04-28T13:34:05  <GitHub81> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5725807402ec...20f9ecd343bb
281 2016-04-28T13:34:05  <GitHub81> bitcoin/master c7aac2d 21E14: Deprecating the remaining LogPrintf dependencies that were made obsolete in PR #7459.
282 2016-04-28T13:34:06  <GitHub81> bitcoin/master 20f9ecd Wladimir J. van der Laan: Merge #7962: CalculateNextWorkRequired Cleanup...
283 2016-04-28T13:34:11  <GitHub69> [bitcoin] laanwj closed pull request #7962: CalculateNextWorkRequired Cleanup (master...cleanpow) https://github.com/bitcoin/bitcoin/pull/7962
284 2016-04-28T13:40:40  *** jtimon_ has joined #bitcoin-core-dev
285 2016-04-28T13:40:52  *** jtimon_ has quit IRC
286 2016-04-28T13:53:52  *** shesek has quit IRC
287 2016-04-28T13:57:29  *** cryptapus_ has joined #bitcoin-core-dev
288 2016-04-28T13:59:08  *** TomMc has joined #bitcoin-core-dev
289 2016-04-28T14:01:15  *** cryptapus has quit IRC
290 2016-04-28T14:15:53  *** laurentmt has quit IRC
291 2016-04-28T14:22:12  *** cryptapus_ has quit IRC
292 2016-04-28T14:22:26  *** cryptapus_ has joined #bitcoin-core-dev
293 2016-04-28T14:26:09  *** Chris_Stewart_5 has joined #bitcoin-core-dev
294 2016-04-28T14:29:54  *** cryptapus_ is now known as cryptapus
295 2016-04-28T14:46:28  *** shesek has joined #bitcoin-core-dev
296 2016-04-28T15:03:02  *** frankenmint has quit IRC
297 2016-04-28T15:19:15  *** Guyver2_ has joined #bitcoin-core-dev
298 2016-04-28T15:20:12  *** Guyver2 has quit IRC
299 2016-04-28T15:20:19  *** Guyver2_ is now known as Guyver2
300 2016-04-28T15:23:06  <Chris_Stewart_5> "BIP 68 prevents a non-final transaction from being selected for inclusion in a block until the corresponding input has reached the specified age,"
301 2016-04-28T15:23:14  <Chris_Stewart_5> Shouldn't 'input' be changed to 'output'?
302 2016-04-28T15:23:40  <Chris_Stewart_5> this is in BIP112
303 2016-04-28T15:40:25  *** supasonic has joined #bitcoin-core-dev
304 2016-04-28T15:46:17  <kanzure> for syncing an external application against bitcoind block history, i think getblock and _batch requests of getblockhash are the only options when receiving a blocknotify event, right?
305 2016-04-28T15:46:37  <kanzure> i was thinking about implementing a getallblockhashes rpc command. i'm hesitant though because i'm not sure why it doesn't already exist.
306 2016-04-28T15:48:17  *** Chris_Stewart_5 has quit IRC
307 2016-04-28T15:50:26  <kanzure> the only other way to check if you are missing gaps of block history is by recursively calling getblockhash and getblock (starting from your last known best block) and ignoring the blocknotify parameter value. however, this is problematic for developers because they would have to also implement a "reverse" mode because if you run "getblock" from your last known block in some database then you will also have to go back in history in ...
308 2016-04-28T15:50:32  <kanzure> ... the event of a recent reorg (e.g. maybe you had a stale block at your tip). this seems like more work than just working with a list of all blockhashes and comparing against your list of known blockhashes. right?
309 2016-04-28T15:51:02  *** BashCo has quit IRC
310 2016-04-28T15:52:32  <kanzure> alternatively: how much overhead is _batch rpc stuff in comparison to a single rpc call like a hypothetical "getallblockhashes"?
311 2016-04-28T15:55:15  <wumpus> pretty much the same
312 2016-04-28T15:56:04  <wumpus> the RPC batching functionality is severly underused, an example is contrib/linearize
313 2016-04-28T15:56:35  <instagibbs> wumpus, so, how do I use it
314 2016-04-28T15:56:36  <wumpus> it requests all the block hashes, though not in a way that copes with reorgs
315 2016-04-28T15:56:48  <wumpus> (it's meant as one-shot)
316 2016-04-28T15:57:01  <kanzure> https://github.com/bitcoin/bitcoin/blob/7fc25c2e5d493f4ef46c9b5831d92886bcea17a8/contrib/linearize/linearize-hashes.py#L64
317 2016-04-28T15:57:08  <kanzure> oh this is using an interval
318 2016-04-28T15:57:24  <kanzure> alright well, my method copes with reorgs by grabbing all blockhashes
319 2016-04-28T15:57:47  <sipa> https://github.com/sipa/bitcoin-stats/blob/master/keepdump.pl
320 2016-04-28T15:57:58  <sipa> that maintains a list of all blocks in a text file
321 2016-04-28T15:58:05  <kanzure> _batch 500,000 rpc requests for getblockhash is taking me like >10 seconds. wouldn't a hypothetical "getallblockhashes" take less than this? do we have an index in leveldb of all the blockhashes?
322 2016-04-28T15:58:08  <sipa> it also doesn't deal with reorgs, as it just puts all blocks there
323 2016-04-28T15:58:19  <sipa> kanzure: nope, in memory
324 2016-04-28T15:58:21  <sipa> :p
325 2016-04-28T15:58:35  <kanzure> in memory sounds good, that should be fast to dump over rpc
326 2016-04-28T15:58:41  <kanzure> yeah we should do this
327 2016-04-28T15:58:53  <sipa> sounds like something for the REST interface
328 2016-04-28T15:59:07  <sipa> actually, doesn't it already have that?
329 2016-04-28T15:59:11  <sipa> fetching a range of block headers
330 2016-04-28T15:59:25  <kanzure> range is incompatible with reorgs
331 2016-04-28T16:00:07  <kanzure> you can do range + confirmationwaitdepth i guess (where confirmationwaitdepth is your risk threshold for accepting deposits or payments or whatever)
332 2016-04-28T16:00:27  <wumpus> kanzure: until http streaming is implemented we don't really want anything that returns that much data
333 2016-04-28T16:00:57  <kanzure> wumpus: well, that makes sense, but in the mean time i'm not sure what applications are using...? calling getblock a few hundred thousand times is dumb.
334 2016-04-28T16:01:09  <wumpus> in the meantime just use batching
335 2016-04-28T16:01:22  <kanzure> but... it's slow.
336 2016-04-28T16:01:30  <sipa> kanzure: you only need to call it a few 100000 times at first startup
337 2016-04-28T16:01:37  <wumpus> REST is much faster than using getblock
338 2016-04-28T16:01:49  <sipa> kanzure: after that you just look at the tip, and go backwards to update your best known state
339 2016-04-28T16:01:49  <wumpus> saves the encoding overhead as first hex then JSON
340 2016-04-28T16:01:59  <kanzure> getblock isn't the problem, i'm using _batch with getblockhash only
341 2016-04-28T16:02:01  <wumpus> and you can pipeline requests on the same TCP connection
342 2016-04-28T16:02:31  <wumpus> also how many times do you expect to do this? is ten seconds really a problem?
343 2016-04-28T16:02:33  <kanzure> sipa: "go backwards" using getblock? i am "going backwards" using _batch getblockhash because i don't want to call "getblock" a few thousand times.
344 2016-04-28T16:02:48  <kanzure> wumpus: well i am getting socket timeouts... so yes. usually it does not take that long. but it varies. sometimes i am getting socket timeouts.
345 2016-04-28T16:02:58  <sipa> kanzure: i don't understand why you need to see all hashes
346 2016-04-28T16:03:02  <wumpus> increase your socket timeout
347 2016-04-28T16:03:09  <wumpus> it's the client that timeouts, never the server
348 2016-04-28T16:03:22  <wumpus> server won't timeout while it's working and not waiting for client input
349 2016-04-28T16:03:22  <kanzure> sipa: i don't need to see all the hashes, i agreed with you that a range is OK (like in the linearize script) plus/minus the number of confirmations that you feel safe waiting for, e.g. so that you can be reorg-compatible.
350 2016-04-28T16:03:34  <sipa> kanzure: no, that is not what i mean
351 2016-04-28T16:04:02  <sipa> kanzure: i mean you keep a list of hashes in your application; at block notify, you call getblockhash backward from the tip until you hit a hash you've already seen
352 2016-04-28T16:04:11  <kanzure> wumpus: correct. it's definitely the client that is timing out.
353 2016-04-28T16:04:13  <wumpus> FYI my attempt at http streaming (still kind of unstable) https://github.com/bitcoin/bitcoin/pull/7759
354 2016-04-28T16:04:34  <wumpus> kanzure: the default timeout is set to 30 seconds or so, that's not a lot, esp if you're batching
355 2016-04-28T16:05:01  <wumpus> instagibbs: linearize provides an example, I should also have a very simple proof of concept somewhere but can't find it  right now
356 2016-04-28T16:05:07  <kanzure> sipa: i guess i could limit the getblockhash calls in my _batch request, to be (blockheight in database) minus (200 confirmations) or something.
357 2016-04-28T16:05:23  <kanzure> wumpus: is that server or client socket timeout default?
358 2016-04-28T16:05:27  <sipa> kanzure: i think using batching is overkill; just go one by one
359 2016-04-28T16:05:33  <kanzure> sipa: that takes a lot longer.
360 2016-04-28T16:05:44  <sipa> in almost all cases you just need 1 call!
361 2016-04-28T16:05:49  <wumpus> kanzure: I don't know, check for yourself
362 2016-04-28T16:05:56  <wumpus> (it depends on what client library you use)
363 2016-04-28T16:05:59  *** pmienk has joined #bitcoin-core-dev
364 2016-04-28T16:06:43  <kanzure> sipa: hmm okay. right.
365 2016-04-28T16:06:50  <wumpus> with python authserviceproxy you can simply specify it in the constructor
366 2016-04-28T16:07:02  <wumpus> instagibbs: https://gist.github.com/laanwj/f2e0238bd151d5365c07bdd03467588b
367 2016-04-28T16:09:32  <kanzure> wumpus: sipa: thank you.
368 2016-04-28T16:22:34  *** BCBot has joined #bitcoin-core-dev
369 2016-04-28T16:24:00  *** cdecker has joined #bitcoin-core-dev
370 2016-04-28T16:25:08  *** cdecker has quit IRC
371 2016-04-28T16:26:16  <instagibbs> cool thanks
372 2016-04-28T16:34:32  *** BashCo has joined #bitcoin-core-dev
373 2016-04-28T16:40:31  *** Thireus1 has joined #bitcoin-core-dev
374 2016-04-28T16:40:41  *** Thireus has quit IRC
375 2016-04-28T16:42:35  *** BCBot has quit IRC
376 2016-04-28T16:42:42  *** BCBot has joined #bitcoin-core-dev
377 2016-04-28T16:57:25  *** earlest has joined #bitcoin-core-dev
378 2016-04-28T17:00:34  *** bysherper has quit IRC
379 2016-04-28T17:01:58  *** bysherper has joined #bitcoin-core-dev
380 2016-04-28T17:04:24  *** MarcoFalke has quit IRC
381 2016-04-28T17:05:04  *** earlest has quit IRC
382 2016-04-28T17:07:50  <GitHub114> [bitcoin] laanwj opened pull request #7966: http: Do a pending c++11 simplification handling work items (master...2016_04_httpserver_c++11) https://github.com/bitcoin/bitcoin/pull/7966
383 2016-04-28T17:26:56  *** wallet421 has joined #bitcoin-core-dev
384 2016-04-28T17:32:17  *** pmienk has quit IRC
385 2016-04-28T17:32:25  *** laurentmt has joined #bitcoin-core-dev
386 2016-04-28T17:44:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
387 2016-04-28T17:45:16  *** molz has quit IRC
388 2016-04-28T17:48:16  *** pmienk has joined #bitcoin-core-dev
389 2016-04-28T18:01:19  *** laurentmt has quit IRC
390 2016-04-28T18:05:14  *** moli has joined #bitcoin-core-dev
391 2016-04-28T18:14:36  *** pedrobranco has quit IRC
392 2016-04-28T18:17:59  *** pedrobranco has joined #bitcoin-core-dev
393 2016-04-28T18:22:20  *** pedrobranco has quit IRC
394 2016-04-28T18:27:14  *** belcher has joined #bitcoin-core-dev
395 2016-04-28T18:29:24  *** treehug88 has joined #bitcoin-core-dev
396 2016-04-28T18:35:27  *** pedrobranco has joined #bitcoin-core-dev
397 2016-04-28T18:36:34  *** bysherper has quit IRC
398 2016-04-28T18:36:46  *** wallet421 has quit IRC
399 2016-04-28T18:39:59  *** pedrobranco has quit IRC
400 2016-04-28T18:50:17  *** Guest45728 has joined #bitcoin-core-dev
401 2016-04-28T18:50:50  <jonasschnelli> why does CFeeRate has not setter?
402 2016-04-28T18:51:02  <jonasschnelli> Or am I missing something?
403 2016-04-28T18:51:48  *** Guest45728 is now known as roidster
404 2016-04-28T18:56:25  *** cjcj has joined #bitcoin-core-dev
405 2016-04-28T18:57:25  <wumpus> it's just a value, if you need to assign a new value just assign a new CFeeRate(...) object
406 2016-04-28T18:57:39  *** BonyM has quit IRC
407 2016-04-28T18:57:57  <wumpus> no need to be able to change it partially
408 2016-04-28T18:57:57  <jonasschnelli> Right. But overloading = op. with a CAmount would be something. Not?
409 2016-04-28T18:58:13  <wumpus> I don't think that's necessary
410 2016-04-28T18:58:25  <wumpus> (sounds slightly confusing to me)
411 2016-04-28T18:58:27  <jonasschnelli> But right. feeRate = CFeeRate(new) is fine.
412 2016-04-28T18:58:36  <wumpus> better to be explicit
413 2016-04-28T18:59:28  <gmaxwell> Meeting time soon.
414 2016-04-28T18:59:49  <jonasschnelli> jtimon: meeting now.
415 2016-04-28T19:00:09  <jtimon> thanks
416 2016-04-28T19:00:11  <wumpus> #startmeeting
417 2016-04-28T19:00:11  <lightningbot> Meeting started Thu Apr 28 19:00:11 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
418 2016-04-28T19:00:11  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
419 2016-04-28T19:00:12  <gmaxwell> sipa: jonasschnelli wumpus morcos sdaftuar kanzure BlueMatt jtimon cfields luke-jr petertodd
420 2016-04-28T19:00:29  <wumpus> proposed topics?
421 2016-04-28T19:00:30  <sipa> mildly present
422 2016-04-28T19:00:48  <kanzure> i propose follow-up from last week re: segwit code review, and new/upcoming tasks on that front
423 2016-04-28T19:00:50  <morcos> i'm here for 10 mins
424 2016-04-28T19:01:02  <kanzure> gmaxwell: thanks for the ping
425 2016-04-28T19:01:03  <jonasschnelli> I have two very small topic proposals: wording for RBF, a request for creating/storing CI material
426 2016-04-28T19:01:05  <gmaxwell> morcos: anything you want to talk about in 10 minutes.
427 2016-04-28T19:01:10  <cfields> thanks, here
428 2016-04-28T19:01:25  *** chris2000 has joined #bitcoin-core-dev
429 2016-04-28T19:01:31  <morcos> just to encourage anyone who is going to review segwit to get on it!  :)
430 2016-04-28T19:01:56  <wumpus> action items of last time were a) more code review of segwit 2) kanzure: look at test coverage output 3) (Luke) update GBT segwit stuff 4) (jtimon) tutorial to enable travis on your own repo 5) (cfields) travis changes requiring some downtime 6) merge #7920 when cfields says so
431 2016-04-28T19:01:56  <kanzure> i have some segwit review notes but they are not precisely publicly consumable, can i get a volunteer to go through my notes? ideally not sipa :)
432 2016-04-28T19:01:59  <gmaxwell> What is the status of the segwit BIPs? are they all consistent with the implementation right now?
433 2016-04-28T19:02:09  *** grubles has joined #bitcoin-core-dev
434 2016-04-28T19:02:27  <kanzure> wumpus: if i was supposed to look at test coverage output then i totally barfed on that, my bad-- i thought someone else took that.
435 2016-04-28T19:02:29  <wumpus> last two items are done at least, transition to trusty and c++11 was succesful
436 2016-04-28T19:02:50  <gmaxwell> \O/
437 2016-04-28T19:02:52  <wumpus> kanzure: yes the name is who suggested it, Idon't know the context
438 2016-04-28T19:02:52  <jtimon> wumpus: re 4 I thought cfields was going to write the tutorail, not me...I'm still on https://docs.travis-ci.com/user/getting-started/
439 2016-04-28T19:02:58  <sdaftuar> kanzure: i'd be happy to review your notes
440 2016-04-28T19:03:07  <kanzure> sdaftuar: cool, i will spam you with them
441 2016-04-28T19:03:16  <cfields> jtimon: sorry, i got lost in the transition stuff
442 2016-04-28T19:03:24  <wumpus> jtimon: oh maybe he's going to, but he had a lot on his hands
443 2016-04-28T19:03:46  <jtimon> no hurry, just saying that I'm not working on that
444 2016-04-28T19:04:01  <wumpus> okay :)
445 2016-04-28T19:04:25  <wumpus> how is the review of segwit going?
446 2016-04-28T19:04:34  <kanzure> sdaftuar: you have been spammed, thanks.
447 2016-04-28T19:05:53  <morcos> wumpus: i'm feeling pretty good, but it's hard to tell who all has done deep commit by commit reviews
448 2016-04-28T19:05:55  <kanzure> topic suggestion-- how to convince sipa to give more context about testing status of segwit
449 2016-04-28T19:06:15  <sdaftuar> wumpus: i'm slowly making my way through
450 2016-04-28T19:06:23  <wumpus> morcos: good to hear that you're making your way through
451 2016-04-28T19:06:24  <kanzure> morcos: perhaps we should all post about our review status?
452 2016-04-28T19:06:31  <cfields> tangentially: I've finally started working with the mining pools (with Kang's help translating) to ensure that their real-world environments. Aim is to get at least one segnet block mined by each pool. Happy to report that last night, BTCC's patched pool mined a few blocks. I'll be working with the others in the coming days
453 2016-04-28T19:06:49  <morcos> cfields: oh thats great!
454 2016-04-28T19:07:00  <cfields> *segnet block with witness txs, ofc
455 2016-04-28T19:07:07  <kanzure> i have done a preliminary read of all the diffs for segwit but not commit-by-commit.... i have a number of places that i am considering investigating the test situation more closely but it's all probably dead-ends ( sdaftuar to advise ).
456 2016-04-28T19:07:09  <morcos> time for someone else to get some segnet coins, i have too many
457 2016-04-28T19:07:45  <sipa> i could list a few areas where i think mildly tricky things are done that warrant review
458 2016-04-28T19:07:50  <kanzure> yes please.
459 2016-04-28T19:08:50  <wumpus> #action (sipa) list a few areas where i think mildly tricky things are done that warrant review
460 2016-04-28T19:08:55  <morcos> sipa: in particular the areas that are new for me (such as the wallet/signing code) are harder to be confident about.  i'd feel better knowing others are reviewing it as well
461 2016-04-28T19:09:20  <sipa> good to know
462 2016-04-28T19:09:32  <kanzure> signaturehash changes were specified by bip and one (trivial) review task is "confirm it follows the bip spec"
463 2016-04-28T19:09:47  <morcos> sipa: harder b/c of me, not b/c the code is tricky looking
464 2016-04-28T19:10:14  <instagibbs> morcos, maybe have people express review coverage with amount of certainty based on familiarity with the code
465 2016-04-28T19:10:33  <sipa> the wallet signing code adds a refactor to stop working directly on scriotsigs, but initially work on just the stacks being pushed, and only convert them at the last step
466 2016-04-28T19:10:52  <instagibbs> for me, review of wallet code was much easier than parsing the tree commitment stuff
467 2016-04-28T19:11:02  <cfields> kanzure: some input from other projects (NicolasDorier *poke*) may be helpful there.
468 2016-04-28T19:11:12  *** To7 has joined #bitcoin-core-dev
469 2016-04-28T19:11:14  <morcos> instagibbs: i like that idea. not sure how easy it is to break up
470 2016-04-28T19:11:37  <instagibbs> that said, I read *every* commit, and attempted best-effort understanding
471 2016-04-28T19:11:37  <sipa> cfields: i'd like some comments from you ob luke-jr's proposed bip9 gbt changes
472 2016-04-28T19:11:43  *** BonyM has joined #bitcoin-core-dev
473 2016-04-28T19:11:54  <morcos> ok got to run.  overall, yay for c++11, yay for segwit!
474 2016-04-28T19:11:54  <cfields> sipa: ah, right. ack.
475 2016-04-28T19:11:55  *** NotAnNSAgent has quit IRC
476 2016-04-28T19:12:14  *** NotAnNSAgent has joined #bitcoin-core-dev
477 2016-04-28T19:12:17  <gmaxwell> I was talking to nickler about doing consensus harness tests for verifying consensus consistence, e.g. between 0.13 and 0.12.x or pre-segwit. Maybe there will be something to report there in a week or so.
478 2016-04-28T19:12:36  *** kadoban has joined #bitcoin-core-dev
479 2016-04-28T19:12:47  <jtimon> yeah, for example, I'm less familiar with the p2p and wallet parts, unfortunately I don't think I will be able to give a full utACK to #7910, but that of course shouldn't not stop it from being merged
480 2016-04-28T19:13:21  <instagibbs> jtimon, which brings me to my point, aside from sipa and a few others, I doubt anyone can full utACK #7910
481 2016-04-28T19:14:09  <kanzure> one of the things i'd like to investigate more closely is the set of tests that were written versus the expected set of tests... but hard to find all the corner cases.
482 2016-04-28T19:14:38  *** wallet421 has joined #bitcoin-core-dev
483 2016-04-28T19:14:59  <jtimon> instagibbs: good point, the PR touches many parts. I think I will focus on the consensus and relay policy parts and only utACK that
484 2016-04-28T19:15:03  <sipa> also in general: what do people think of the strategy i've been following to not rebase/squash, but only add small patches and a changing merge commit at the end?
485 2016-04-28T19:15:23  <kanzure> sipa: i think that is a good idea. it gives us time to ACK various older commits.
486 2016-04-28T19:15:31  <instagibbs> jtimon, seems wise, people have to self-select what they feel competent to review
487 2016-04-28T19:15:35  *** wallet421 has quit IRC
488 2016-04-28T19:16:00  <sipa> at some point i'll squash and rebase in such a way that the resulting tree id identical to the old broken down branch
489 2016-04-28T19:16:07  <jtimon> sipa: no strong opinion but it seems to partly defeat the point of having the commits separated in related sections (btw, I would separate p2p from consensus)
490 2016-04-28T19:16:42  <kanzure> tree id similarity is a nice approach....
491 2016-04-28T19:16:49  <kanzure> (git ls-tree and such)
492 2016-04-28T19:17:18  <sipa> jtimon: i'll keep the section
493 2016-04-28T19:17:25  <sdaftuar> sipa: some kind of warning before you squash/rebase would be helpful for me at least
494 2016-04-28T19:17:44  <sdaftuar> sipa: but i like how you've done it so far
495 2016-04-28T19:17:46  <kanzure> it would also be good if you could keep the original commits around on your git repo
496 2016-04-28T19:17:52  <sipa> kanzure: of course
497 2016-04-28T19:17:54  <jtimon> sipa: I see, so your question is more about squashing only once at the end, fine with me
498 2016-04-28T19:17:59  <sipa> it needs to be verifiable
499 2016-04-28T19:18:03  <kanzure> good, thanks.
500 2016-04-28T19:18:25  <cfields> sipa: you can just push to a spare branch before final squash, then we can diff the two
501 2016-04-28T19:18:42  <jonasschnelli> only add commits, once we have enough ACKS, hash the diff, rebase, check the hash of the diff and merge?
502 2016-04-28T19:18:55  <sipa> jonasschnelli: indeed
503 2016-04-28T19:20:06  <wumpus> ok next topic?
504 2016-04-28T19:20:29  <wumpus> #topic status of the segwit BIPs
505 2016-04-28T19:21:18  <wumpus> (gmaxwell)
506 2016-04-28T19:21:29  <achow101> bip 144 needs to include the service bit stuff
507 2016-04-28T19:22:23  <wumpus> everyone agree?
508 2016-04-28T19:22:48  <sipa> ugh, that was never uodated
509 2016-04-28T19:22:51  <sipa> yes, agree
510 2016-04-28T19:23:15  <wumpus> #action bip 144 needs to include the service bit stuff
511 2016-04-28T19:23:31  <gmaxwell> I suppose we should try to extract some feedback e.g. from roastbeef to reimplemented, who might be aware of other limitations in the spec.
512 2016-04-28T19:23:50  <instagibbs> roasbeef*
513 2016-04-28T19:24:00  <petertodd> just noticed someone has a python-bitcoinlib segwit branch too
514 2016-04-28T19:24:07  <achow101> armory does as well
515 2016-04-28T19:24:27  <petertodd> (sorry, just got in)
516 2016-04-28T19:24:53  *** matsjj has joined #bitcoin-core-dev
517 2016-04-28T19:24:59  <wumpus> petertodd: just in time for the python-bitcoinlib segwit branch!
518 2016-04-28T19:25:31  <petertodd> wumpus: ha yeah - no credit to me though :)
519 2016-04-28T19:26:20  <wumpus> #action (gmaxwell) try to extract some feedback e.g. from roasbeef to reimplemented, who might be aware of other limitations in the spec
520 2016-04-28T19:26:46  <sipa> we have gotten some comments from a few people and making small clarifications frequently
521 2016-04-28T19:26:55  <sipa> including from tadge
522 2016-04-28T19:27:29  <sipa> i'm surprised nobody commented about the service bit
523 2016-04-28T19:27:52  <achow101> sipa: I think I brought it up a couple of weeks ago but didn't follow up on it
524 2016-04-28T19:28:02  <sipa> achow101: sorry then!
525 2016-04-28T19:29:22  <instagibbs> I can verify 141 and 143 match up
526 2016-04-28T19:30:33  <wumpus> great
527 2016-04-28T19:31:04  *** laurentmt has joined #bitcoin-core-dev
528 2016-04-28T19:31:09  *** laurentmt has quit IRC
529 2016-04-28T19:32:15  <sipa> small update: the reviewer that btcdrak contacted about ctaes wrote a report
530 2016-04-28T19:32:33  <jonasschnelli> sipa: the tor lead dev?
531 2016-04-28T19:32:51  <sipa> jonasschnelli: no, someone mathhew green recommemded
532 2016-04-28T19:33:04  <sipa> he formally proved that some parts were correct, and analyzed the condtant timeness
533 2016-04-28T19:33:07  <jonasschnelli> Okay. Good. What was the result?
534 2016-04-28T19:33:09  <sipa> i can share the reoort
535 2016-04-28T19:33:11  <petertodd> sipa: +1
536 2016-04-28T19:33:16  <sipa> a+ :)
537 2016-04-28T19:33:24  <jonasschnelli> sipa: Can you add it on your ctaes repository?
538 2016-04-28T19:33:27  <wumpus> awesome!
539 2016-04-28T19:33:49  <cfields> sipa: nice!
540 2016-04-28T19:34:03  *** gevs has quit IRC
541 2016-04-28T19:35:16  <sipa> any more topics? i'll be off otherwise
542 2016-04-28T19:35:30  <jonasschnelli> RBF naming: should we flag/attribute RBF transaction as "replaceable" or should we attribute "current" non RBF transaction as "non-replacable"?
543 2016-04-28T19:35:59  <petertodd> jonasschnelli: I'd lean towards replacable, as non-replacable implies we're promising something...
544 2016-04-28T19:36:00  <jl2012> bringing segwit testing to testnet?
545 2016-04-28T19:36:09  <gmaxwell> the former, I think. It's incorrect to say non-RBF is non-replacable; they're just somewhat less replacable.
546 2016-04-28T19:36:55  <wumpus> agree with gmaxwell
547 2016-04-28T19:37:13  <jonasschnelli> Okay. I agree as well. Will continue with this term.
548 2016-04-28T19:37:16  <instagibbs> 'mempool-replaceable' ?
549 2016-04-28T19:37:26  <petertodd> doublespends happen all the time, and only a small subset of them are opt-in RBF txs
550 2016-04-28T19:37:42  <wumpus> but RBF transactions the user can easily replace themselves
551 2016-04-28T19:37:42  <jl2012> sipa: are we ready to define the testnet BIP9 parameter for segwit?
552 2016-04-28T19:37:47  <wumpus> that should be the focus imo
553 2016-04-28T19:38:06  <wumpus> what the user can do with it
554 2016-04-28T19:38:10  <jonasschnelli> instagibbs: I was also thinking about that. But does the normal bitcoin-qt user really knows what the mempool is?
555 2016-04-28T19:38:13  <jtimon> "standard-policy-0.12-replaceable"?
556 2016-04-28T19:38:26  <jonasschnelli> :}
557 2016-04-28T19:38:40  <petertodd> jtimon: all the user's node knowns is they think it's replacable, so the 0.12 is implicit :)
558 2016-04-28T19:38:40  <jonasschnelli> "standard-policy-0.12-BIP125-replaceable"
559 2016-04-28T19:38:50  *** chris2000 has quit IRC
560 2016-04-28T19:39:13  <wumpus> yes the 0.12 is implicit, the BIP125 part makes sense
561 2016-04-28T19:39:34  <jtimon> yeah, 0.12 was kind of joking, the point is all tx are equally replaceable with a custom policy, the opt-in stuff is just about the standard policy
562 2016-04-28T19:39:36  <petertodd> don't we already have a bip125-replacable or similar name used in the RPC anyway?
563 2016-04-28T19:39:54  <jonasschnelli> petertodd: Yes. Listtransaction
564 2016-04-28T19:40:03  <wumpus> yes entry.push_back(Pair("bip125-replaceable", rbfStatus));
565 2016-04-28T19:40:21  <jtimon> ack bip125-replaceable
566 2016-04-28T19:40:26  <jonasschnelli> Also I think someone should refactor the RBF BIP125 rules to the new rbf.cpp
567 2016-04-28T19:40:31  <petertodd> jtimon: you can also replace txs by flooding mempools and getting them kicked out :)
568 2016-04-28T19:40:40  <jonasschnelli> The bumpfee or feealter command could than re-check the validity
569 2016-04-28T19:40:42  *** Michail1 has joined #bitcoin-core-dev
570 2016-04-28T19:40:52  <jonasschnelli> s/re-check/pre-check
571 2016-04-28T19:41:37  <jonasschnelli> In the GUI we should probably just use the term "replaceable".
572 2016-04-28T19:42:22  <jtimon> then we have the same problem I think
573 2016-04-28T19:42:24  <petertodd> jonasschnelli: "easily replacable"
574 2016-04-28T19:42:27  <jtimon> opt-in-repleaceable ?
575 2016-04-28T19:42:38  <petertodd> jonasschnelli: or heck, "trivially replacable"
576 2016-04-28T19:42:45  <paveljanik> "updatable"?
577 2016-04-28T19:43:03  <luke-jr> "replacement-requested"
578 2016-04-28T19:43:04  <jonasschnelli> of "signs replicability"?
579 2016-04-28T19:43:21  <petertodd> paveljanik: eh, changing the name to something other than replacable would invite trolling possibly
580 2016-04-28T19:43:39  <paveljanik> replacability signalled ;-)
581 2016-04-28T19:43:48  <jonasschnelli> replacability signalled: +1
582 2016-04-28T19:43:57  <wumpus> yes I think whatever the name is it should contain 'replace', otherwise it's too confusing, introducing completely new terminology
583 2016-04-28T19:44:02  <petertodd> wumpus: +1
584 2016-04-28T19:44:05  *** muuqwaul has joined #bitcoin-core-dev
585 2016-04-28T19:44:06  <jonasschnelli> Indeed
586 2016-04-28T19:44:12  <wumpus> replaceability signalled sounds good to me
587 2016-04-28T19:44:22  <petertodd> sure, why not
588 2016-04-28T19:44:36  <jonasschnelli> ack
589 2016-04-28T19:44:38  <jtimon> "replace explicitly allowed"?
590 2016-04-28T19:44:41  <sdaftuar> fee-replaceable ?
591 2016-04-28T19:44:56  <jonasschnelli> sdaftuar: but it could also add a output
592 2016-04-28T19:44:57  <jtimon> I mean, "replacability signalled" is good enough for me
593 2016-04-28T19:45:28  <jonasschnelli> sdaftuar: but right. You mean replaceable by fee
594 2016-04-28T19:45:37  <sdaftuar> yeah, you can replace it if you up the fee
595 2016-04-28T19:45:58  <jonasschnelli> "fee-replacability signalled"?
596 2016-04-28T19:46:06  <petertodd> jonasschnelli: which is tricky, because any low fee tx is in practice replacable by fee regardless of whether bip125 is used or not
597 2016-04-28T19:46:20  <sdaftuar> but not by your wallet
598 2016-04-28T19:46:38  <wumpus> I don't think the GUI term needs to be so specific - just make sure that the mouseover or other documentation explains it in more detail
599 2016-04-28T19:46:43  *** gevs has joined #bitcoin-core-dev
600 2016-04-28T19:46:44  *** gevs has joined #bitcoin-core-dev
601 2016-04-28T19:46:45  <sdaftuar> +1
602 2016-04-28T19:46:46  <jonasschnelli> Sure. But the term would also be for attributing incoming payment.
603 2016-04-28T19:46:47  <petertodd> oh, key question: are we going to show this for all txs, or just txs sent by the user?
604 2016-04-28T19:46:54  <paveljanik> sdaftuar, depends on the wallet IMO
605 2016-04-28T19:46:56  <jtimon> petertodd: exactly, for all we know, miners could replace by hash alphabetic order rather than fees
606 2016-04-28T19:47:01  <cfields> sdaftuar: i like that, but it describes the mechanics more than the intent.
607 2016-04-28T19:47:07  <jonasschnelli> petertodd: incoming and outdoing.
608 2016-04-28T19:47:25  <petertodd> jonasschnelli: see, if it was just outgoing, this conversation would be a lot simpler :)
609 2016-04-28T19:48:11  <wumpus> replacability signalled is fine, let's move on
610 2016-04-28T19:48:15  <jonasschnelli> incoming tx: "replacability signalled", create tx: "[ ] signall replacability"
611 2016-04-28T19:48:18  <jonasschnelli> ack.
612 2016-04-28T19:48:21  <jtimon> what was wrong about "Opted in to replacement" or something along those lines?
613 2016-04-28T19:48:23  <wumpus> any other topics?
614 2016-04-28T19:48:44  <jtimon> yeah, nv, "replacability signalled" does it
615 2016-04-28T19:48:59  <jtimon> s/nv/never mind
616 2016-04-28T19:49:01  <jonasschnelli> topic: another boring one, not sure if this is the right place: Someone contacted me that we should have a repository for Bitcoin Core logos and communication material.
617 2016-04-28T19:49:11  <jonasschnelli> Somehow that made me think that Bitcoin Core has no clear logo/visual identity. Its not define what to use when, the font, the colors. Not sure if anyone from us cares about that though.
618 2016-04-28T19:49:25  <paveljanik> press kit? ;-)
619 2016-04-28T19:49:30  <petertodd> paveljanik: +1
620 2016-04-28T19:49:44  <jonasschnelli> We probably don't care. But out userbase does a lot
621 2016-04-28T19:49:46  <petertodd> paveljanik: or maybe call it "media kit" to shift focus to all media in general
622 2016-04-28T19:49:50  <jonasschnelli> *our
623 2016-04-28T19:49:59  <btcdrak> jonasschnelli: a press kit would be a good idea
624 2016-04-28T19:50:06  <wumpus> we don't have that, but if anyone wants to make it and collect some things why not
625 2016-04-28T19:50:54  <jonasschnelli> It would imply that we first need to create a identity, proper logo, font, etc. I'm not interested ATM, but happy if someone know someone who is.
626 2016-04-28T19:50:56  <btcdrak> jonaschnelli: ideally we could store that in a "media kit" repository.
627 2016-04-28T19:51:16  <jonasschnelli> I think it should be a subarea of the website
628 2016-04-28T19:51:37  <petertodd> jonasschnelli: that makes sense
629 2016-04-28T19:51:46  <wumpus> yes I think the question is more *who* than if, I don't think press kits are very usual for open source projects, but if someone wants to work on that I don't want to discourage
630 2016-04-28T19:52:21  <jonasschnelli> Agree.
631 2016-04-28T19:52:26  <sipa> wumpus: they're very common among altcoins though :p
632 2016-04-28T19:52:27  <cfields> wumpus: for open-source, they almost always accompany a licensing policy
633 2016-04-28T19:52:41  <cfields> (lived through that hell for a while in a past life)
634 2016-04-28T19:52:50  <wumpus> cfields: yes, as for firefox
635 2016-04-28T19:52:54  <cfields> right
636 2016-04-28T19:53:38  <cfields> so for us, unless we wanted to police it, a press kit would be more of a collection of recommended images/text that we also use.
637 2016-04-28T19:54:08  <cfields> i suppose that was the idea, though
638 2016-04-28T19:54:08  <wumpus> right
639 2016-04-28T19:54:10  <jonasschnelli> Yes. There is even no clear logo that Bitcoin Core uses/represents.
640 2016-04-28T19:54:15  <warren>             "\nExamples:\n"
641 2016-04-28T19:54:17  <warren>             + HelpExampleCli("getnewaddress", "")
642 2016-04-28T19:54:21  <warren>             + HelpExampleRpc("getnewaddress", "")
643 2016-04-28T19:54:23  <warren> Any idea why this has both, and they're identical?
644 2016-04-28T19:54:25  <jonasschnelli> warren: dumpprivatekey
645 2016-04-28T19:54:39  <wumpus> warren: we're in the middle of a meeting
646 2016-04-28T19:54:45  <warren> oops sorry!
647 2016-04-28T19:54:45  <wumpus> well, at the end
648 2016-04-28T19:55:20  <wumpus> I think we're done
649 2016-04-28T19:55:34  <jonasschnelli> \ö/
650 2016-04-28T19:55:37  <wumpus> #endmeeting
651 2016-04-28T19:55:37  <lightningbot> Meeting ended Thu Apr 28 19:55:37 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
652 2016-04-28T19:55:37  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.html
653 2016-04-28T19:55:37  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.txt
654 2016-04-28T19:55:37  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-28-19.00.log.html
655 2016-04-28T19:55:50  <warren> jonasschnelli: ok, not understanding what you mean
656 2016-04-28T19:55:55  <wumpus> warren: we have cli and rpc examples for all the help items
657 2016-04-28T19:56:06  <warren> why are they both provided when identical?
658 2016-04-28T19:56:08  <wumpus> warren: just do 'help getnewaddress' to see what the output is
659 2016-04-28T19:56:17  <jonasschnelli> warren: nm. RPC does form a different help line then cli
660 2016-04-28T19:56:28  <wumpus> they aren't identical
661 2016-04-28T19:56:46  <wumpus> the result is different, they call different functions that have different output, just happens to be with the same arguments
662 2016-04-28T19:56:55  <warren> oh ok, thanks
663 2016-04-28T19:57:25  <wumpus> as said, just check 'bitcoin-cli help getnewaddress` and you'll see
664 2016-04-28T20:05:11  *** earlest has joined #bitcoin-core-dev
665 2016-04-28T20:05:48  *** cryptapus has quit IRC
666 2016-04-28T20:07:46  <GitHub17> [bitcoin] jonasschnelli opened pull request #7967: [RPC] add feerate option to fundrawtransaction (master...2016/04/fund_fee) https://github.com/bitcoin/bitcoin/pull/7967
667 2016-04-28T20:08:04  *** muuqwaul has quit IRC
668 2016-04-28T20:13:59  *** laurentmt has joined #bitcoin-core-dev
669 2016-04-28T20:14:35  *** cjcj has quit IRC
670 2016-04-28T20:19:45  *** laurentmt has quit IRC
671 2016-04-28T20:50:54  *** ThomasV has joined #bitcoin-core-dev
672 2016-04-28T20:52:04  *** guest78678 has joined #bitcoin-core-dev
673 2016-04-28T20:53:05  <guest78678> why are we keeping AcceptToMemoryPoolWorker in main?
674 2016-04-28T20:55:12  *** xiangfu has joined #bitcoin-core-dev
675 2016-04-28T20:57:07  *** guest78678 has quit IRC
676 2016-04-28T21:10:58  *** jannes has quit IRC
677 2016-04-28T21:15:35  *** ThomasV has quit IRC
678 2016-04-28T21:15:59  *** cryptapus_afk is now known as cryptapus
679 2016-04-28T21:24:11  <instagibbs> did someone volunteer to fix up bip144? missed the last part of meeting
680 2016-04-28T21:36:38  <btcdrak> instagibbs: it was you iirc.
681 2016-04-28T21:37:37  *** treehug88 has quit IRC
682 2016-04-28T21:39:17  <achow101> instagibbs: I was going to do it in a few minutes if no one else did, but you can do it if you want
683 2016-04-28T21:39:48  *** zooko has joined #bitcoin-core-dev
684 2016-04-28T21:40:03  <btcdrak> achow101: I was teasing instagibbs. Go ahead.
685 2016-04-28T21:41:07  *** xiangfu has quit IRC
686 2016-04-28T21:41:26  *** frankenmint has joined #bitcoin-core-dev
687 2016-04-28T21:42:58  * instagibbs shakes fist at btcdrak 
688 2016-04-28T21:43:05  <instagibbs> achow101, good, go for it
689 2016-04-28T21:43:11  <instagibbs> wanted to make sure *someone* was doing it
690 2016-04-28T21:43:19  <instagibbs> I can review after the fact
691 2016-04-28T21:43:34  <achow101> which bit is it?
692 2016-04-28T21:44:15  <instagibbs> not sure, I'd find out, but have family stuff to do
693 2016-04-28T21:44:23  <instagibbs> I think the service hex is "d"
694 2016-04-28T21:44:38  <instagibbs> bbl if you still havent figured it out
695 2016-04-28T21:46:03  <achow101> found it
696 2016-04-28T21:50:35  *** grassass has quit IRC
697 2016-04-28T21:53:17  *** zooko has quit IRC
698 2016-04-28T21:53:47  <achow101> done https://github.com/bitcoin/bips/pull/380
699 2016-04-28T22:03:28  *** lecusemble has quit IRC
700 2016-04-28T22:04:55  *** Alopex has quit IRC
701 2016-04-28T22:05:07  *** lecusemble has joined #bitcoin-core-dev
702 2016-04-28T22:07:03  <btcdrak> achow101: it's probably worth a mail to the bitcoin-dev list to say we're intending to use the (1 << 3) service bit for segwit.
703 2016-04-28T22:10:27  <GitHub23> [bitcoin] wtogami opened pull request #7968: doc: Fedora build requirements (master...fedora_build_readme) https://github.com/bitcoin/bitcoin/pull/7968
704 2016-04-28T22:13:28  <achow101> btcdrak: I'd let sipa do that
705 2016-04-28T22:16:06  *** Alopex has joined #bitcoin-core-dev
706 2016-04-28T22:32:28  *** Chris_Stewart_5 has quit IRC
707 2016-04-28T22:34:35  *** cryptapus is now known as cryptapus_afk
708 2016-04-28T22:38:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
709 2016-04-28T22:47:24  *** Chris_Stewart_5 has quit IRC
710 2016-04-28T22:53:01  *** Alopex has quit IRC
711 2016-04-28T22:53:10  *** laurentmt has joined #bitcoin-core-dev
712 2016-04-28T22:54:00  *** laurentmt has quit IRC
713 2016-04-28T22:54:07  *** Alopex has joined #bitcoin-core-dev
714 2016-04-28T22:57:03  *** AaronvanW has quit IRC
715 2016-04-28T23:24:50  *** Guyver2 has quit IRC
716 2016-04-28T23:44:36  *** belcher has quit IRC