1 2016-02-11 01:39:20 <Chris_Stewart_5> ["", "0 0 'a' 'b' 2 CHECKMULTISIG VERIFY DEPTH 0 EQUAL", "P2SH,STRICTENC", "Test from up to 20 pubkeys, all not checked"] what is the '2' for in this test case?
  2 2016-02-11 01:39:38 <Chris_Stewart_5> Is this for bug in OP_CHECKMULTISIG that requires it consume another arguement?
  3 2016-02-11 01:46:45 <Chris_Stewart_5> or is that what the first 0 represents in the example scriptPubKey?
  4 2016-02-11 02:00:41 <kadoban> Chris_Stewart_5: 2 is the number of public keys, which are the 'a' and 'b'. That first zero is for the bug, yeah.
  5 2016-02-11 02:05:17 <Chris_Stewart_5> kadoban: Thanks
  6 2016-02-11 04:43:42 <cluelessperson_> hm
  7 2016-02-11 07:00:10 <btcdrak> miners have released a statement about Bitcoin Classic https://twitter.com/btcroundtable/status/697672824282939393
  8 2016-02-11 07:05:11 <aj> so that's 60% of the hashrate (f2pool 29%, bitfury 17%, btcc 14%) ?
  9 2016-02-11 07:32:59 <bsm1175321> Cooler heads prevail, thankfully.
 10 2016-02-11 10:23:21 <wiz> does anyone have a script/utility to test low/high S value ECDSA signature TX conformity
 11 2016-02-11 10:26:00 <wumpus> not that I know, but you could roll something with bitcoin-pythonlib quite easily I think
 12 2016-02-11 10:26:45 <wiz> "The Swiss Army Knife of the Bitcoin protocol." - sweet
 13 2016-02-11 10:28:22 <wumpus> (bitcoin core doesn't have a "validate but don't send" RPC, maybe it should)
 14 2016-02-11 10:30:47 <gmaxwell> wumpus: every time I've gone to write that I realized that I also needed parent transactions and decided it wasn't important enough to do now.
 15 2016-02-11 10:31:12 <gmaxwell> (perhaps a block proposal...)
 16 2016-02-11 10:36:13 <wumpus> yes it'd need an argument for parent transactions, maybe just take a list instead of a single tx
 17 2016-02-11 10:37:18 <wumpus> right, that'd be effectively a block proposal
 18 2016-02-11 12:03:15 <waxwing> wiz: you could just look at it :)
 19 2016-02-11 14:31:36 <btcdrak> gavinandresen is deleting comments again from his PR.
 20 2016-02-11 15:02:08 <JackH> where
 21 2016-02-11 15:04:11 <paveljanik> btcdrak, people do not like to be repeatedly educated about their mistakes...
 22 2016-02-11 15:05:03 <paveljanik> lets live with it...
 23 2016-02-11 15:08:05 <JackH> paveljanik, in Gavin's case this is no longer an excuse
 24 2016-02-11 15:08:15 <JackH> this is the third damn time he pulls out the big block glove
 25 2016-02-11 15:08:19 <JackH> enough is enough from this man
 26 2016-02-11 15:08:46 <JackH> we are in some eternal stall mode because of fucking gavin
 27 2016-02-11 18:01:08 <Luke-Jr> blah, going to miss today's meeting again
 28 2016-02-11 18:08:09 <wumpus> Luke-Jr: oh :( why?
 29 2016-02-11 18:19:26 <Luke-Jr> wumpus: taking sick baby to dr.
 30 2016-02-11 18:19:40 <Luke-Jr> appt is at 2:30 and it's a 30 minute drive
 31 2016-02-11 18:19:55 <wumpus> ouch
 32 2016-02-11 18:20:35 <Luke-Jr> maybe I can get it rescheduled slightly. my wife forgot to confirm some things first
 33 2016-02-11 18:23:00 <bittrex-richie> what is the primary reason for wallets being slow?  number of tx's?  number of unspent inputs?
 34 2016-02-11 18:26:26 <Luke-Jr> wumpus: may I include system univalue support (the one merged to master) in backports for 0.12.1?
 35 2016-02-11 18:26:42 <maaku> Luke-Jr: :(
 36 2016-02-11 18:26:48 <maaku> hope all is well
 37 2016-02-11 18:27:17 <Luke-Jr> maaku: we're all sick here :/  hopefully I'll get over it soon, but my main concern is the baby wheezing
 38 2016-02-11 18:37:42 <Luke-Jr> looks like we're stuck with the 2:30 appt
 39 2016-02-11 18:46:24 <bittrex-richie> what is the primary reason for wallets being slow?  number of tx's?  number of unspent inputs? -- for context... i'm talking about a 2gb wallet with 500k+ transactions and usually anywhere between 20-30k unspent inputs.
 40 2016-02-11 18:48:23 <Luke-Jr> bittrex-richie: lack of optimisation
 41 2016-02-11 18:48:45 <Luke-Jr> bittrex-richie: recently we did some work on this, but I don't know how much is in 0.12
 42 2016-02-11 18:49:08 <bittrex-richie> is there anything i can do on my end?  does reducing the  number of unspents help at all?
 43 2016-02-11 18:49:22 <bittrex-richie> is it a diskio problem? or a cpu problem? so i know where to throw more resources at?
 44 2016-02-11 18:49:24 <Luke-Jr> bittrex-richie: if it is important to you, you may wish to consider hiring a dev to focus on it with some of those unspent outputs ;p
 45 2016-02-11 18:49:43 <Luke-Jr> someone should probably do benchmarking
 46 2016-02-11 18:51:00 <bittrex-richie> ehhe... we might do that one day..
 47 2016-02-11 18:51:06 <bittrex-richie> just curious what i can do in the shortterm.
 48 2016-02-11 18:51:08 <wumpus> Luke-Jr: yes, system univalue support is fine for 0.12.1, just not make it default
 49 2016-02-11 18:51:22 <Luke-Jr> bittrex-richie: have you tried 0.12 yet?
 50 2016-02-11 18:51:40 <Luke-Jr> (disclaimer: all software is as-is, no warranty if it destroys the wallet)
 51 2016-02-11 18:51:44 <Luke-Jr> (make backups etc)
 52 2016-02-11 18:54:14 <bittrex-richie> hehe. no
 53 2016-02-11 18:54:18 <bittrex-richie> still running a pretty old version
 54 2016-02-11 18:54:47 <Luke-Jr> well, the easy thing seems to be to try to see if it's improved enough already ;)
 55 2016-02-11 18:55:03 <bittrex-richie> scary proposition heh
 56 2016-02-11 18:55:20 <Luke-Jr> any optimisation is going to have risks
 57 2016-02-11 18:55:29 <Luke-Jr> sticking to old versions has risks too ;)
 58 2016-02-11 18:55:48 <gmaxwell> ahhh crap
 59 2016-02-11 18:55:59 <wumpus> the primary reason for wallets being slow is high number of transactions
 60 2016-02-11 18:56:15 <wumpus> and for coin selection number of unspent  outputs
 61 2016-02-11 18:57:07 <Luke-Jr> there's a reason Bitcoin is still an experiment :P
 62 2016-02-11 18:57:10 <wumpus> 500k+ transactions is really pushing it, that's much outside the general use case scenario of the core wallet
 63 2016-02-11 18:57:23 <bittrex-richie> will reducing the unseptns help? i'm about tocreate raws to just eat through eveyrthing to 0
 64 2016-02-11 18:57:38 <wumpus> what are you doing gmaxwell? :p
 65 2016-02-11 18:58:08 <wumpus> bittrex-richie: that helps making selection (for send) faster
 66 2016-02-11 18:59:06 <wumpus> in any case, no one is running it with those numbers, it would be interesting to benchmark/profile
 67 2016-02-11 18:59:18 <gmaxwell> wumpus: setting voice on everyone who's been active in recent meetings so we have the option of setting mode +zm during the metting (sets it so new comments need to be approved... to avoid disruption from people that don't know a meeting is going on)
 68 2016-02-11 18:59:27 <wumpus> though that only makes sense for a recent version
 69 2016-02-11 18:59:51 <wumpus> gmaxwell: okay
 70 2016-02-11 18:59:59 <gmaxwell> (and having some technical difficulties... but it's done now)
 71 2016-02-11 18:59:59 <wumpus> makes sense
 72 2016-02-11 19:00:18 <Luke-Jr> crap, I need to get going :x
 73 2016-02-11 19:00:35 <wumpus> good luck Luke-Jr, hope all is well
 74 2016-02-11 19:00:41 <wumpus> #meetingstart
 75 2016-02-11 19:00:42 <Luke-Jr> thanks, enjoy the meeting I guess
 76 2016-02-11 19:00:45 <lightningbot`> Meeting started Thu Feb 11 19:00:45 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 77 2016-02-11 19:00:45 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
 78 2016-02-11 19:00:45 <wumpus> #startmeeting
 79 2016-02-11 19:01:04 <wumpus> well thanks I guess :)
 80 2016-02-11 19:01:36 <wumpus> topic proposals?
 81 2016-02-11 19:01:50 <gmaxwell> Plans for RC37?
 82 2016-02-11 19:01:58 <wumpus> last meeting we had as action items ACTION: review and test ACK #7184 and #6564 (wumpus, 19:20:09)
 83 2016-02-11 19:02:03 <wumpus> almost gmaxwell
 84 2016-02-11 19:02:24 <bittrex-richie> ok.. we'll see what happens if i empty this awllet out
 85 2016-02-11 19:03:22 <gmaxwell> If cfields is around I'd like to hear an update about how his networking stack reworking is going.
 86 2016-02-11 19:03:41 <wumpus> rc4 and rc5 were just tagged in quick succession, so we'll skip executables for rc4
 87 2016-02-11 19:04:28 <cfields> gmaxwell: i'm hacking furiously trying to get it cleaned up. I've rewritten much of it a dozen or so times, but i've never considered it to be in a state where it's a good starting point for review.
 88 2016-02-11 19:05:13 <cfields> gmaxwell: as i've been saying for ages now, hope to have it ready for review in the next week or so.
 89 2016-02-11 19:05:13 <wumpus> rc6 to rc∞-1 can hopefully be skipped and this is finally final :)
 90 2016-02-11 19:05:35 <wumpus> #topic P2P code refactor
 91 2016-02-11 19:06:37 <wumpus> yes I think it's time to seriously look at that now
 92 2016-02-11 19:06:47 <sipa> agree
 93 2016-02-11 19:06:55 <gmaxwell> cfields: okay, -- sounds totally reasonable. I was worrying a bit that you've gone heads down on it long enough that the result might be big enough to make reviewing really hard; ... but if you're spending all that time redoing it rather than adding more code, then it should be no issue. :)
 94 2016-02-11 19:07:17 <cfields> gmaxwell: for a bit more info: i've whittled it down to little more than a replacement of the current networking threads. message parsing/processing/etc is intact for the sake of easier review/merge. I have refactors for those elsewhere, but as next steps
 95 2016-02-11 19:07:26 <_maddy> Where do I find the format of the blk0001.dat file in source code?
 96 2016-02-11 19:07:26 <wumpus> the time for something invasive like that to be merged is at the beginning of the release window, so around now, otherwise we'll probably have to postpone it to 0.14
 97 2016-02-11 19:07:31 <cfields> wumpus / gmaxwell / sipa: understood
 98 2016-02-11 19:08:20 <wumpus> okay clear, next topic?
 99 2016-02-11 19:08:55 <sipa> BIP112/68/113 plans?
100 2016-02-11 19:08:57 <wumpus> #topic BIP68 review
101 2016-02-11 19:09:06 <morcos> is maaku here?
102 2016-02-11 19:09:09 <wumpus> how is the review of the BIP68 pulls going?
103 2016-02-11 19:09:27 <morcos> sdaftuar found some more mistakes, i need to fix those, can do this afternoon
104 2016-02-11 19:09:29 <wumpus> (sorry, wasn't able to look at it much myself this week)
105 2016-02-11 19:09:41 <morcos> but there is other work that needs to be done, such as the soft fork logic
106 2016-02-11 19:09:55 <wumpus> ok, yes let's focus on the mempool only stuf now
107 2016-02-11 19:10:11 <morcos> wumpus: i think i disagree
108 2016-02-11 19:10:16 <wumpus> I think that's quite enough
109 2016-02-11 19:10:30 <wumpus> why?
110 2016-02-11 19:10:31 <petertodd> morcos: soft fork needs better unit tests IMO
111 2016-02-11 19:10:34 <sipa> the GetMedianTimePast behaviour is already in, right?
112 2016-02-11 19:10:40 <morcos> several months ago sdaftuar found a mistake in the mempool code only be thinking about how the soft fork logic would apply
113 2016-02-11 19:11:11 <wumpus> yes, but I mean the softfork code won't be considered until the mempool-only enforcement is in for a while
114 2016-02-11 19:11:17 <wumpus> thinking about it can't hurt, sure
115 2016-02-11 19:11:23 <morcos> wumpus: not necessary, its already non standard
116 2016-02-11 19:11:27 <morcos> tx version 2
117 2016-02-11 19:11:34 <jtimon> morcos: the softfork logic is not going to be merged with the policy-only implementations, we've never done it, why change now?
118 2016-02-11 19:11:50 <wumpus> well that's completely different than what was discussed last week ...
119 2016-02-11 19:11:58 <jtimon> specially when we would hopefully deploy it with bip9...
120 2016-02-11 19:12:05 <morcos> sorry , i don't think i was in the meeting last week
121 2016-02-11 19:12:18 <morcos> i thought i skimmed the conversation but i must have missed that
122 2016-02-11 19:12:18 <sipa> BIP113 needed mempool deployment before being safe as a softfork
123 2016-02-11 19:12:25 <sipa> but BIP68 and BIP112 don't, afaik
124 2016-02-11 19:12:47 <wumpus> introducing the softfork is going to require much more scrutiny, and tests, as petertodd says
125 2016-02-11 19:12:55 <morcos> in any case, i don't care if we merge the mempool code first and it might indeed make sense to do so, i just think we should look at the soft fork logic
126 2016-02-11 19:13:14 <maaku> morcos: yes I'm here
127 2016-02-11 19:13:14 <sipa> how about we merge mempool logic in master only
128 2016-02-11 19:13:24 <jtimon> last week my hope was that at least bip68 would finally be merged today or before today...
129 2016-02-11 19:13:51 <wumpus> jtimon: you mean mempool-only right?
130 2016-02-11 19:13:58 <morcos> maaku: i was wondering whether you were going to take over BIP 68 etc.. stuff again..  in particular the soft fork logic for it.
131 2016-02-11 19:14:04 <petertodd> morcos: by "soft fork logic" - i assume you mean something like bip9? I mean, the IsSuperMajority() mechanism is just a few lines of code
132 2016-02-11 19:14:04 <sipa> and then backport mempool+softfork to 0.12.x when the softfork is ready
133 2016-02-11 19:14:13 <wumpus> sipa: agree
134 2016-02-11 19:14:31 <jtimon> wumpus: of course, and I meant on master only as well (we cannot backport for 12.1 until we actually have 12.0, right?)
135 2016-02-11 19:14:40 <wumpus> jtimon: absolutely
136 2016-02-11 19:14:45 <sipa> jtimon: yeah
137 2016-02-11 19:14:55 <gmaxwell> we really need to migrate to a BIP9 style way of doing soft-forks...
138 2016-02-11 19:14:59 <morcos> ok i guess thats not unreasonable... if there is a change needed to the consensus logic in the mempool brought out by the softfork code , it doesn't matter if its only in master
139 2016-02-11 19:15:08 <sipa> gmaxwell: yes, but that needs usable code...
140 2016-02-11 19:15:37 <morcos> consensus logic that is (re)used by the mempool only version
141 2016-02-11 19:16:21 <maaku> morcos: I intended to rebase the CSV code against your BIP 68 branch once that merges
142 2016-02-11 19:16:29 <morcos> ok, well i think 7184 can be merged after i fix sdaftuars comments, they are relatively straight forward, i'll leave as a separate commit and maybe a couple of people that reviewed prior can just ack and we can squash on merge
143 2016-02-11 19:17:07 <maaku> petertodd: BIP 68 hasn't really been reviewed with a mindset of consensus validation
144 2016-02-11 19:17:09 <sipa> oh, topic suggestion: squash/rebase/merge recommendations
145 2016-02-11 19:17:18 <morcos> maaku: yes, thats why i thought you were working on it again.  but all of 68,112,113 need soft fork logic at some point...
146 2016-02-11 19:17:19 <sipa> maaku: i have
147 2016-02-11 19:17:50 <maaku> (I know because serious bugs were found in the enforcement long after ACKs of 6312)
148 2016-02-11 19:17:59 <morcos> maaku: thats my point, some of us have been trying to review it with that mindset but it would be easier to do so if we see the soft fork logic
149 2016-02-11 19:18:00 <maaku> some by sipa some by sdaftuar, thank you
150 2016-02-11 19:18:31 <jtimon> great! next action review/test/merge #6564 after we finally merge #7148 ?
151 2016-02-11 19:18:45 <petertodd> maaku: I did that with BIP68, and quickly came to the conclusion that it needed better unittests for consensus validation :)
152 2016-02-11 19:18:52 <maaku> morcos: imho we should merge BIP 68 policy-only, and open another PR with the soft-fork enforcement, just to get another round of ACKs specifically with an eye towards that
153 2016-02-11 19:18:54 <jtimon> I mean, it will need rebase first
154 2016-02-11 19:19:09 <wumpus> #action review/test/merge #7148 and #6564
155 2016-02-11 19:19:11 <morcos> maaku: yeah ok, as long as we are not backporting/releasing until we do that other PR, thats fine with me
156 2016-02-11 19:19:28 <morcos> wumpus: it's 7184, and we should hold off on 6564 till maaku rebases
157 2016-02-11 19:19:47 <jtimon> morcos: why that condition? we can backport as soon as we have a 12.0, no?
158 2016-02-11 19:19:50 <maaku> morcos: yeah the point is there's confusion about who has reviewed with an eye towards enforcement, and that's just delaying everything
159 2016-02-11 19:20:08 <sipa> jtimon: i would backport only as soon as there is softfork logic too
160 2016-02-11 19:20:20 <wumpus> yeah, it makes only sense to backport something complete
161 2016-02-11 19:20:32 <maaku> people are happy with 7184 (modulo some last minute fixes I saw go through), if we can merge that asap I'd be happy
162 2016-02-11 19:20:33 <sdaftuar> is the plan to only backport to 0.12?
163 2016-02-11 19:20:37 <wumpus> let's focus on getting the damn thing merged in master, this has been dragging along for too long
164 2016-02-11 19:20:38 <jtimon> I mean, I plan to backport it to https://github.com/jtimon/bitcoin/tree/backports-0.12 soon after it gets merged
165 2016-02-11 19:20:49 <maaku> (and I'll immediately rebase 6564 thereafter)
166 2016-02-11 19:20:55 <jtimon> why not merge it as policy only for 12.01?
167 2016-02-11 19:21:25 <maaku> when the soft-fork code is merged, it will be back ported to the two most recent releases, as per our recently adopted support policy
168 2016-02-11 19:21:27 <sipa> jtimon: what's the point?
169 2016-02-11 19:21:27 <wumpus> because we need to make sure it's correct first
170 2016-02-11 19:21:32 <wumpus> master is a good place to test things
171 2016-02-11 19:21:45 <maaku> BIP 68 and 112 don't need to be back ported until enforcement
172 2016-02-11 19:21:47 <wumpus> can always be adapted, or reverted there
173 2016-02-11 19:21:52 <gmaxwell> a policy only softfork merge for an already non-standard softfork will disrupt deployment of the feature if it needs to change.
174 2016-02-11 19:21:53 <maaku> *until soft-fork deployment
175 2016-02-11 19:21:53 <wumpus> I dont like doing that on a release version
176 2016-02-11 19:22:22 <jtimon> sipa: having it ready? if it's not ready for 12.1 at least users will have it as policy-only...what's the reason not to do it?
177 2016-02-11 19:22:31 <gmaxwell> (because if the behavior changes we may need to first policy out the old behavior before the soft-fork can begin.)
178 2016-02-11 19:22:34 <sipa> jtimon: having it as policy only has no use
179 2016-02-11 19:22:40 <sipa> except testing
180 2016-02-11 19:22:45 <wumpus> right sipa
181 2016-02-11 19:22:49 <gmaxwell> it's not that it has no use, it has potential anti-use.
182 2016-02-11 19:22:51 <morcos> ok, so to summarize.  i will add a small commit that address sdaftuars bugs within an hour of meeting end.  a couple people will review/ACK and we can merge this thing today
183 2016-02-11 19:23:04 <morcos> then we'll leave in master until we write the soft fork logic
184 2016-02-11 19:23:09 <morcos> maybe that should be the next topic
185 2016-02-11 19:23:15 <jtimon> gmaxwell: mhmm, I hadn't thought about the potential anti-use...
186 2016-02-11 19:23:16 <morcos> what should that look like and who is doing it
187 2016-02-11 19:23:33 <wumpus> #topic soft fork logic
188 2016-02-11 19:24:05 <gmaxwell> (I'm fine with policy only for things where were quite sure that the logic is final, but are only delaying deployment e.g. because of other soft-forks in flight-- in this case, it should just be done as soon as it's final)
189 2016-02-11 19:24:09 <jtimon> depends on bip9, proposed topic bip9 implementations and plan forward
190 2016-02-11 19:24:49 <morcos> i'm sorry that i volunteered and withdrew from bip9 work, but i'm trying to find things to do that it is easier to do head down and not lose concentration.
191 2016-02-11 19:25:37 <maaku> imho the issue of bip9 vs ISM should be determined by what is ready at the time that we are preparing the soft-fork enforcement code
192 2016-02-11 19:26:02 <maaku> so the question really is, when is the BIP 68/112(/113?) soft-fork going out?
193 2016-02-11 19:26:25 <morcos> maaku: the issue is there are so many outstanding potential soft forks, that if each keeps waiting for the others, that might delay them all.  and if we just decided to do BIP 9 we'd stop having that problem
194 2016-02-11 19:26:30 <morcos> don't forget segwit
195 2016-02-11 19:26:50 <morcos> and don't forget we're far more likely now to have soft forks that we think are going to activate but maybe struggle to do so
196 2016-02-11 19:27:08 <maaku> morcos: I don't think the delay argument stands up for uncontroversial soft-forks
197 2016-02-11 19:27:12 <wumpus> yes, BIP 9 still makes a lot of sense.
198 2016-02-11 19:27:25 <petertodd> morcos: granted, we've got code actually written for what, two of them basically? (csv stuff and segwit stuff)
199 2016-02-11 19:27:52 <jtimon> I don't want to stop anyone from do it, but I'm considering to write my own implementation, resuing some code from both CodeShark's and Rusty's implementation
200 2016-02-11 19:28:01 <morcos> petertodd: or BIP 68 could be viewed spearately from 112/113 actually
201 2016-02-11 19:28:07 <maaku> if CSV is ready next week, we can do ISV. and we can start segwit deployment via bip9 even if CSV deployment isn't finished
202 2016-02-11 19:28:11 <maaku> *ISM
203 2016-02-11 19:28:40 <petertodd> morcos: true, although even then, you *can* do concurrent ISM soft forks
204 2016-02-11 19:29:09 <maaku> My opinion is only that we shouldn't be holding up a valuable soft-fork due only to delay in bip9 development.
205 2016-02-11 19:29:21 <jtimon> maaku ack
206 2016-02-11 19:29:25 <paveljanik> +1
207 2016-02-11 19:29:28 <gmaxwell> petertodd: only if they're additive.
208 2016-02-11 19:29:45 <jtimon> that doesn't mean we don't want bip9 asap as well though
209 2016-02-11 19:29:49 <gmaxwell> Fortunately I don't think we're actually faced with a hold up question there.
210 2016-02-11 19:29:51 <wumpus> yes I think that's clear, we can use only what is there, if there is no BIP9 implmentation ready then we can't use it
211 2016-02-11 19:29:55 <petertodd> gmaxwell: you mean, only if they don't conflict with each other?
212 2016-02-11 19:30:39 <wumpus> there's no super hurry, but we can't hold up all softforks until BIP9 if there is no clear idea when it will be ready
213 2016-02-11 19:31:12 <gmaxwell> sure.
214 2016-02-11 19:31:17 <sipa> we should have a BIP9 implementation before we can even talk about delaying things for it
215 2016-02-11 19:31:24 <gmaxwell> ^ that.
216 2016-02-11 19:31:25 <wumpus> yeah
217 2016-02-11 19:31:28 <jtimon> I didn't knew that morcos had stopped working on it
218 2016-02-11 19:31:46 <morcos> and we're not concerned about an ISM soft fork activating too early because of miners runnign another implementation?
219 2016-02-11 19:31:59 <maaku> sipa: we should have *one* bip9 implementation ;) problem is we have 2 (soon to be 3)
220 2016-02-11 19:32:09 <morcos> jtimon: never started, but i got too depressed.
221 2016-02-11 19:32:13 <sipa> maaku: i don't mind trying to write one myself :p
222 2016-02-11 19:32:28 <sipa> (don't worry, i have enough other things to do...)
223 2016-02-11 19:32:34 <wumpus> maaku: it's more about having one that is ready to merge, having 100 half-finished implementations isn't going to help :)
224 2016-02-11 19:32:46 <sipa> s/ready to merge/merged/
225 2016-02-11 19:33:13 <petertodd> sipa: heh, I'm gonna have to actualy write my pseudo-versionbits implementation - the one that's about two lines of code :)
226 2016-02-11 19:33:18 <wumpus> what is the main problem with bip9 implementations?
227 2016-02-11 19:33:19 <maaku> morcos: thankfully CSV is non-controversial. if there was significant uptake on a hard fork block.nVersion voting, we can get those miners to patch CSV support in
228 2016-02-11 19:33:22 <wumpus> why do they peter out?
229 2016-02-11 19:33:26 <jtimon> morcos: that's fine (not that you got depressed), I was just pointing out that I found out today
230 2016-02-11 19:33:44 <maaku> (actually scratch that, partially bad logic because they leave the network)
231 2016-02-11 19:33:58 <sipa> wumpus: CodeShark's was a ton of code that seemed to do a dozen unrelated things, and rusty's never had the caching layer on top to make it efficient
232 2016-02-11 19:34:11 <petertodd> wumpus: frankly, bip9 is stateful and requires a bunch of stuff added to the database, which means there's a whole bunch of things to get right and test, among other issues
233 2016-02-11 19:34:18 <wumpus> sipa: ok thanks
234 2016-02-11 19:34:23 <sipa> petertodd: nope, no database changes needed
235 2016-02-11 19:34:50 <petertodd> sipa: huh? maybe I'm describing it misleadingly, but you have to store flags in the chainstate
236 2016-02-11 19:35:14 <wumpus> right, you have to somehow keep track of the current flags
237 2016-02-11 19:35:40 <petertodd> wumpus: which *is* a relatively big change, and has a lot of possible design space and testing to consider
238 2016-02-11 19:35:45 <sipa> petertodd: my idea was to have a versionbits state that you compute for every block % 2016, compute once, and remain immutable after that
239 2016-02-11 19:35:54 <sipa> petertodd: everything can be efficiently computed from that
240 2016-02-11 19:36:22 <sipa> and recompute at startup
241 2016-02-11 19:36:43 <sipa> anyway, off topic i guess
242 2016-02-11 19:36:44 <petertodd> sipa: ah, so you can get away without actually storing it... clever
243 2016-02-11 19:36:50 <wumpus> does that need 2016 blocks stored?
244 2016-02-11 19:36:52 <maaku> ok, an in-memory std::map database ;)
245 2016-02-11 19:37:06 <jtimon> maaku: aka cache
246 2016-02-11 19:37:12 <sipa> wumpus: no, a map of size (mapBlockIndex.size() / 2016)
247 2016-02-11 19:37:34 <wumpus> ok
248 2016-02-11 19:38:02 <sipa> i'd like to bring up the topic of squash/rebase recommendations (there was some recent discussion about that on the bip68 PR)
249 2016-02-11 19:38:13 <wumpus> #topic  squash/rebase recommendations
250 2016-02-11 19:38:29 <morcos> can i suggest that we make some sort of decision as to how to move forward on the soft forks first
251 2016-02-11 19:38:35 <morcos> its ok if that decision is ISM for now
252 2016-02-11 19:38:57 <sipa> morcos: whenever ready, we see what is ready; if BIP9 implementation is ready, use that, otherwise use ISM
253 2016-02-11 19:39:03 <jtimon> I believe decision is "no other choice than ISM until bip9 is merged"
254 2016-02-11 19:39:09 <sdaftuar> we need a volunteer to implement, do we have one?
255 2016-02-11 19:39:11 <morcos> sipa: what do you mean whenever ready
256 2016-02-11 19:39:12 <wumpus> I pretty much thin kthat was what said in the BIP68 topic says it all regarding this topic: https://github.com/bitcoin/bitcoin/pull/7184#issuecomment-182594295
257 2016-02-11 19:39:13 <sipa> perhaps we'll need to patch ISM to be nVersion & nFlags
258 2016-02-11 19:39:35 <jtimon> if there's no other volunteer, I think I can do it
259 2016-02-11 19:40:18 <wumpus> <jtimon> I believe decision is "no other choice than ISM until bip9 is merged" ACK
260 2016-02-11 19:41:40 <sipa> ok
261 2016-02-11 19:41:43 <jtimon> squash topic?
262 2016-02-11 19:41:56 <sipa> morcos: do you feel we're done with softforks?
263 2016-02-11 19:42:06 <morcos> ha ha ...   yes?
264 2016-02-11 19:42:10 <sipa> ok
265 2016-02-11 19:43:05 <sipa> so, maaku: maybe this wasn't clear from my comment on the morcos' BIP68 PR, but I didn't mean to say "this has to be squashed into a single commit, no matter what" - there were just a list of several fixup and nit addressing commits, and i don't believe those belong in the final merged history
266 2016-02-11 19:43:26 <sipa> but i'd like to hear what your opinion is there
267 2016-02-11 19:43:35 <wumpus> I think that's clear
268 2016-02-11 19:43:58 <morcos> my biggest concern with squashing/rebasing is knowing WHEN to do it.  its easier for future reviewers to do it but if other people are still in the midst of reviewing its annoying.
269 2016-02-11 19:44:28 <wumpus> commits have a logical function, you want to tell a story how you changed the code that is easy to review, not necessarily your chronological order of changes
270 2016-02-11 19:44:56 <sipa> we need a local review script, that stores which commit/tree you've reviewed, and later on, shows you the differences compared to what has been reviewed before :)
271 2016-02-11 19:45:02 <morcos> yes!
272 2016-02-11 19:45:02 <wumpus> if you have tons of 'fix issue X' where X was introduced in the same pull, that's not useful
273 2016-02-11 19:45:07 <petertodd> unfortunately there will be cases where "easy to review" is to squash, and cases where "easy to review" is to just add more commits
274 2016-02-11 19:45:10 <petertodd> sipa: +1
275 2016-02-11 19:45:35 <wumpus> sure, and mostly that's up to the developer to make that judgement
276 2016-02-11 19:46:02 <maaku> sipa: my position is the same as torvalds regarding squashing and rebasing in git: fine to do up until the point of submitting a PR.
277 2016-02-11 19:46:07 <wumpus> and also depending on what is changed, e.g. if you make a move+change pull it's clear that that's better as two commits
278 2016-02-11 19:46:11 <paveljanik> It can be worth to review the changes in two separate commits (e.g. MOVE-ONLY and a simple change) than in one merged commit (which is perfectly OK for merging). The question is when to move from separate commits and squash.
279 2016-02-11 19:46:23 <paveljanik> exactly
280 2016-02-11 19:46:24 <petertodd> wumpus: yes, and also, that's likely to depend on who is reviewing - more likely for a fresh reviewer to find a squash easier
281 2016-02-11 19:46:26 <jtimon> I think 7184 should have just built on top of its reviewed precessors during development, there's always time to squash later
282 2016-02-11 19:46:42 <sipa> paveljanik: i think it's always valuable to keep moveonly changes and others separate
283 2016-02-11 19:46:47 <maaku> few people if ever read the git history. far more benefit is had by having commit id's not change and use merge commits
284 2016-02-11 19:47:02 <morcos> jtimon: it would would be 30 commits now, half of which were undoing changes in earlier ones
285 2016-02-11 19:47:23 <wumpus> morcos: yes that's awful
286 2016-02-11 19:47:37 <wumpus> at least before merge those should be squashed
287 2016-02-11 19:47:43 <jtimon> and now (or a few weeks ago) you could have squashed, I really don't see the problem
288 2016-02-11 19:47:45 <maaku> rewriting history breaks linkage between what the review record of ACKS say, and what actually gets in the repo
289 2016-02-11 19:48:04 <paveljanik> sipa, for file renames, sure.
290 2016-02-11 19:48:12 <wumpus> maaku: with the commit ids in the replies you can still compare the trees
291 2016-02-11 19:48:18 <sipa> maaku: i recently did an ACK on a tree id rather than a commit, which doesn't break with a squash
292 2016-02-11 19:48:44 <morcos> maaku: yes i think thats the key.  a rebase/squash could maybe be accompied with more detailed information of which ACKS are still valid or something..
293 2016-02-11 19:49:14 <maaku> wumpus: if you have those commits.
294 2016-02-11 19:49:21 <wumpus> maaku: github has them
295 2016-02-11 19:49:22 <sdaftuar> should we all switch to what sipa did going forward, ack the tree id?
296 2016-02-11 19:49:31 <wumpus> nah, I don't know
297 2016-02-11 19:49:34 <petertodd> worth noting that even ACKing with commit ids isn't sufficient for security purposes, so we're still trusting maintainers not to merge malicious stuff, which means trusting them to fairly interpret how squashes interact with previous ACK's is more reasonable
298 2016-02-11 19:49:49 <sipa> maaku: only the people who looked at former state of the PR care about that
299 2016-02-11 19:49:50 <petertodd> sdaftuar: I don't think we need to do that, simply because github saves the information for us in the form of old commits
300 2016-02-11 19:49:54 <wumpus> I don't look forward to teaching everyone that
301 2016-02-11 19:50:01 <jtimon> the only time I reviewed 7184 is through one branch that morcos prepared rebasing 7184 on top of maaku's because that was simpler for me
302 2016-02-11 19:50:06 <maaku> sipa: how do you recover the tree id once there are no commits left in the available branches that create that tree?
303 2016-02-11 19:50:12 <petertodd> wumpus: it's also kinda inconvenient, especially for utACK's done on github
304 2016-02-11 19:50:16 <morcos> in any case, i think what works best for wumpus/sipa shoudl carry some weight here and then to the extent that other people do more heavy lifting on the code base, the process can evolve.  but if wumpus is the one who has to decide everytime if the ACK's are valid
305 2016-02-11 19:50:19 <wumpus> petertodd: yes
306 2016-02-11 19:50:20 <morcos> lets do what makes sense for him
307 2016-02-11 19:50:23 <sipa> maaku: i don't understand
308 2016-02-11 19:50:28 <maaku> this process is basically relying on the fact that github acts as a trusted repository of past tree state. i don't like that
309 2016-02-11 19:50:53 <petertodd> maaku: well, as long as we're putting our ACK's on github itself w/o signatures, it's mostly a trusted repo anyway
310 2016-02-11 19:51:04 <wumpus> if you really want to be paranoid then you should also sign your ACKs, as github posts can be edited
311 2016-02-11 19:51:40 <wumpus> feel free do do so, but I'm not going to make it a rule
312 2016-02-11 19:51:45 <wumpus> petertodd: yes, iwilcox is
313 2016-02-11 19:51:56 <maaku> petertodd: the issue isn't so much trust as process and standard practice. it's something that only works with a trusted, central party, which means the same behavior doesn't work so well in other contexts
314 2016-02-11 19:51:57 <paveljanik> looks like btcdrak is taking screenshots ;-)
315 2016-02-11 19:52:06 <wumpus> petertodd: https://github.com/zw/bitcoin-gh-meta
316 2016-02-11 19:52:19 <sipa> wumpus: ha, nice
317 2016-02-11 19:52:49 <petertodd> wumpus: ah cool - should figure out how to timestamp that!
318 2016-02-11 19:52:53 <jtimon> I think the general rule should be "whatever is easier to read and review", but of course sounds like some vague software engineering recommendation "things should be done the right way"...
319 2016-02-11 19:52:58 <maaku> or if github ever decides to clean house and purge old, unreferenced tree states, our historical record would be screwed
320 2016-02-11 19:53:20 <wumpus> it even come with the ghrip script so you can do your own version, if you don't trust him :)
321 2016-02-11 19:53:41 <sipa> maaku: why do you care about the historical state, if you're not one of the people who reviewed it in a non-final state?
322 2016-02-11 19:53:56 <jtimon> I think we're moving away from the topic
323 2016-02-11 19:54:00 <wumpus> any other topic? only few minutes to go
324 2016-02-11 19:54:24 <wumpus> jtimon: yes it sounds vague, but in complex subjects like this it's very hard to give exact procedures that makes sense in every case, if even possible
325 2016-02-11 19:54:26 <paveljanik> what is the status of BIP62 and namely handling High S?
326 2016-02-11 19:54:34 <sipa> paveljanik: retracted
327 2016-02-11 19:54:41 <wumpus> BIP62 is dead
328 2016-02-11 19:54:45 <paveljanik> yes, but any future plans?
329 2016-02-11 19:54:50 <sipa> paveljanik: segwit
330 2016-02-11 19:54:51 <paveljanik> for at east High S?
331 2016-02-11 19:55:05 <paveljanik> ok
332 2016-02-11 19:55:12 <jtimon> wumpus: yes, I'm afraid vague recommendations and examples is the best you can do with many of these things
333 2016-02-11 19:55:13 <petertodd> update on segwit prev-block-proofs: I'm deep in the rabbit hole of writing an article/paper/blog-post on fraud proofs, along with what data structures work for them
334 2016-02-11 19:55:40 <petertodd> AKA, saving a herd of goats :)
335 2016-02-11 19:55:44 <petertodd> *shaving
336 2016-02-11 19:56:13 <wumpus> great!
337 2016-02-11 19:56:24 <gmaxwell> paveljanik: for high-S specfically, it still may be soft-forked out at some point-- though with it non-standard I see no reason to rush into it.
338 2016-02-11 19:56:26 <maaku> petertodd: I would like to work with you on that
339 2016-02-11 19:56:53 <maaku> not the article, the fraud proofs and prev-block proofs
340 2016-02-11 19:56:57 <maaku> i've done my own explorations on that
341 2016-02-11 19:57:08 <petertodd> maaku: cool, be good to compare notes then
342 2016-02-11 19:57:19 <paveljanik> gmaxwell, people ask for it and I think that non-standardness is not enough for their use cases...
343 2016-02-11 19:57:20 <sipa> maaku, petertodd: perhaps you should also talk about the commitment structure
344 2016-02-11 19:57:37 <petertodd> what I'm writing is actually very heavily based on my explorations for fintech clients, e.g. my proofchains work
345 2016-02-11 19:57:57 <wumpus> #topic fraud proofs
346 2016-02-11 19:58:02 <gmaxwell> paveljanik: just inhibiting highS is not enough for any usecase I've ever seen expressed.
347 2016-02-11 19:58:23 <sipa> wumpus: i think that can be discussed outside of the meeting
348 2016-02-11 19:58:24 <petertodd> article is shaping up to mainly be an ideal redesign of bitcoin from scratch, to serve as example for comparison
349 2016-02-11 19:58:27 <petertodd> sipa: +1
350 2016-02-11 19:58:32 <wumpus> sipa: ok, closing the meeting then
351 2016-02-11 19:58:34 <jtimon> fisnish meeting?
352 2016-02-11 19:58:35 <wumpus> #endmeeting
353 2016-02-11 19:59:57 <petertodd> in progress article: http://0bin.net/paste/KJW6TagBV-g4yk+9#vPn0wyVabhtiza3qxaNepzz7xSpSX1bi8zfHh1MchwN
354 2016-02-11 20:00:35 <sipa> maaku: so regarding review, i think that having previous ACKs on former state of a PR only helps people who have acked before quickly re-ACK by seeing what changed since their former ACK
355 2016-02-11 20:00:48 <sipa> maaku: once merged, the only thing that matters is the final state, and who acked that final state
356 2016-02-11 20:01:50 <maaku> sipa: so history rewriting has other problems too. it makes merging more difficult if two branches have different versions of the same commit
357 2016-02-11 20:02:35 <maaku> which can happen, e.g. if a branch is spun up for some deployment that is still in development (like say, what we are both presently doing at work..)
358 2016-02-11 20:02:36 <morcos> maaku: that argument doesn't seem to apply very much to our development style though, we dont' have longstanding branches
359 2016-02-11 20:02:51 <maaku> morcos: not all bitcoin development happens in bitcoin/bitcoin on github
360 2016-02-11 20:03:15 <morcos> but the development process of bitcoin development should be optimized for that
361 2016-02-11 20:03:48 <maaku> Let's say, as a hypothetical, that some particular sidechain includes #7184 for its CSV support, and deploys that to customers before 7184 is merged by wumpus. Hypothetically.
362 2016-02-11 20:03:48 <petertodd> morcos: well, we do have longstanding branches - the stable branches - but what we don't have is features big enough to make for long-standing devel branches (in most cases)
363 2016-02-11 20:04:17 <maaku> Now any history rewriting generates merge conflicts that otherwise would have been sorted out, wasting some particular developer's time. Externalities.
364 2016-02-11 20:04:17 <petertodd> maaku: careful, sidechain's aren't yet something Bitcoin Core should be changing it's development practices for - that's someone elses problem
365 2016-02-11 20:04:45 <wumpus> if you have long-standing branches, feel free to not rebase/squash
366 2016-02-11 20:04:50 <sipa> maaku: i think it would be dangerous for the developer of said sidechain to rely on automatic merging by git anyway
367 2016-02-11 20:04:51 <maaku> petertodd: surely you are joking?
368 2016-02-11 20:05:01 <morcos> maaku: fundamentally i just think that the main Bitcoin development process is still evolving so rapidly that that is where we should be concentrating our efforts
369 2016-02-11 20:05:31 <wumpus> in most cases it's nice for review but we're not trying to force you to do anything...
370 2016-02-11 20:05:36 <gmaxwell> maaku: keeping other project's commit histories clean is not bitcoin core's problem.
371 2016-02-11 20:05:42 <petertodd> maaku: not at all - Bitcoin Core is currently separate from the bulk of any sidechain stuff, and politically speaking, we definitely don't want to give the impression blockstream's needs are being prioritised here
372 2016-02-11 20:05:50 <sipa> agree
373 2016-02-11 20:05:51 <morcos> maaku: that way of doing things is a huge turn off to those of us who are uninvolved with the private development
374 2016-02-11 20:06:04 <gmaxwell> I am not supportive of taking any cost in core to accomidate other projects, even friendly ones.
375 2016-02-11 20:06:32 <morcos> it sucks to not be a part of the cool stuff that is going on, so there should be a significant effort to concentrate as much cool stuff as possible in bitcoin/bitcoin (which i think we do more or less)
376 2016-02-11 20:06:37 <maaku> gmaxwell: even if the marginal cost is negligible -- what is the marginal cost of not squashing a commit? -- and the externalities significant?
377 2016-02-11 20:06:39 <gmaxwell> If there are free tweaks, OK great. But that stuff should be argued on its own merits and tie broken by considerations like that.
378 2016-02-11 20:07:00 <sipa> maaku: IMHO a readable commit history is valuable for reasons of transparency
379 2016-02-11 20:07:07 <jtimon> maaku I'm afraid you are asking for too much here, nits happen and usually the best way to address them is by rewriting history in the open PR
380 2016-02-11 20:07:18 <morcos> sure its great for ideas like CT/segwit/etc to be developed off site so to speak, but the developers of such features should be aware that the rest of the community might have input into changing their design after the fact
381 2016-02-11 20:07:19 <sipa> maaku: i have never been able to understand what is going on in highly branching/merging codebases
382 2016-02-11 20:07:24 <jtimon> until it's merged, you cannot consider is stable sadly
383 2016-02-11 20:07:45 <wumpus> I agree jtimon and sipa
384 2016-02-11 20:07:59 <maaku> morcos: you may take over BIP 112/113 development
385 2016-02-11 20:08:23 <jtimon> which is part of why it was so sad that bip68 is taking so so long to be merged
386 2016-02-11 20:08:33 <morcos> maaku: i'm not trying to imply that hasn't happened so far, i just saying its a cost of doing research work off site
387 2016-02-11 20:09:04 <petertodd> jtimon: well, keep in mind that the users of bip68 - things like the lightning network - don't seem to have been impacted, as they're not ready for deployment yet
388 2016-02-11 20:09:23 <petertodd> jtimon: note how even my own CLTV has had only trivial usage on mainnet so far
389 2016-02-11 20:09:37 <morcos> ugh, well i wasn't trying to piss him off, but he seemed quite upset that I was giving him feedback on BIP68 after so much work had been put into it previously
390 2016-02-11 20:09:50 <morcos> and i was just trying to explain that i think you need to expect that to happen
391 2016-02-11 20:10:59 <morcos> sigh, ok, well obviously what i said did not go over well.   can someone else help rectify this situation
392 2016-02-11 20:11:18 <jtimon> petertodd: I'm just noting that the code for bip68 is not "stable" until merged, not for lightning nor anyone else (that's why they cannot work on top of bitcoin core directly)
393 2016-02-11 20:11:53 <petertodd> jtimon: that's true, but equally, those same projects give us the confidence that bip68 is stable! chicken and egg
394 2016-02-11 20:16:04 <jtimon> petertodd: sure, but users of bip68 are potentially impacted by continued changes in the implementation
395 2016-02-11 20:16:27 <sipa> well hopefully the result of a long maturing process is that fewer and fewer changes are being made
396 2016-02-11 20:17:07 <petertodd> sipa: +1
397 2016-02-11 20:17:46 <petertodd> jtimon: I'm sure they'll be impacted, but they'll be more likely to be impacted by things that needed to change because their own usage revealed issues
398 2016-02-11 20:19:43 <jtimon> sipa yes, that was what I expected after 6 months of bip68 being deployed in alpha and 5 months of #6312 being opened reviewed, tested...
399 2016-02-11 20:20:09 <morcos> sipa: to be honest i have several more comments about the design, but i stopped making them in the interest of just getting the thing merged
400 2016-02-11 20:20:44 <sipa> the only weird thing about the design i find is that time bit flag in the middle
401 2016-02-11 20:20:47 <morcos> For instance SequenceLocks now takes a flags argument that just tells it whether the soft fork is active or not, which seems a bit of a weird place to put the logic for the soft fork
402 2016-02-11 20:21:51 <morcos> But it gets into a much bigger question of what is the right generalization of policy/consensus rules that aren't enforced in the scripts
403 2016-02-11 20:22:39 <jtimon> IMO we should only have ConsensusVerificationFlags and merge the new ones with the script ones, for example, to not need to to pass two different flag arguments to Consensus::VerifyTx (once it exists), for example
404 2016-02-11 20:23:07 <morcos> Seems to me a design where you said BIP68().isPolicy()   and BIP68().isConsensus() or something like that might be better...  yes or what jtimon said with the flags, or something
405 2016-02-11 20:24:09 <jtimon> I said that long ago, but I was told that "refactors can wait for later"
406 2016-02-11 20:25:07 <jtimon> and I agreed because I hoped we could have deployed CLTV and bip68/112 together
407 2016-02-11 20:26:20 <morcos> well, i think someone else is going to need to take over BIP 112 now, and i don't think it should be me, otherwise we're never going to have it
408 2016-02-11 20:26:47 <jtimon> it should be just rebase re-review and merge, no?
409 2016-02-11 20:28:10 <jtimon> isnt'btcdrak doing that?
410 2016-02-11 20:30:56 <morcos> i'd be interested in whether anyone else has an opinion on this comment: https://github.com/bitcoin/bitcoin/pull/6564#issuecomment-178636856
411 2016-02-11 20:31:45 <jtimon> anyway, can we merge bip68 and get it over with? I was waiting for that to rebase #7310...
412 2016-02-11 20:32:55 <sipa> morcos: i hadn't seen the comment, and thought the same thing while reviewing
413 2016-02-11 20:35:50 <bsm117532> petertodd: your doc about fraud proofs is making me depressed.
414 2016-02-11 20:36:19 <morcos> did the unit tests always take this long?
415 2016-02-11 20:37:55 <wumpus> there's a parameter to run them in verbose mode to see where it spends so much time
416 2016-02-11 20:41:45 <wumpus> -l test_suite
417 2016-02-11 20:43:11 <wumpus> ooh --color_output=yes is fancy
418 2016-02-11 20:44:14 <wumpus> test/addrman_tests.cpp(218): Leaving test case "addrman_tried_collisions"; testing time: 167819us   wallet/test/wallet_tests.cpp(68): Leaving test case "coin_selection_tests"; testing time: 3926033us seem to be the worst ones
419 2016-02-11 20:44:37 <morcos> my units are mks, what's that?
420 2016-02-11 20:44:50 <wumpus> mks?
421 2016-02-11 20:44:56 <morcos> what is your total testing time over a minute?
422 2016-02-11 20:45:29 <morcos> Leaving test case "addrman_tried_collisions"; testing time: 626807mks
423 2016-02-11 20:46:12 <morcos> argh, i think i compiled with DEBUG_LOCK_ORDER, sorry
424 2016-02-11 20:46:14 <wumpus> exactly 30 seconds for 186 test cases
425 2016-02-11 20:47:18 <wumpus> that could explain it, debug mode is much slower
426 2016-02-11 21:05:10 <CodeShark> Meh...I missed the meeting
427 2016-02-11 21:05:20 <CodeShark> Should have been there
428 2016-02-11 21:05:51 <CodeShark> versionbits is an important issue
429 2016-02-11 21:06:59 <CodeShark> Is the meeting over over?
430 2016-02-11 21:07:10 <CodeShark> Or can we still discuss this?
431 2016-02-11 23:00:15 <BCB> what is the latest wallet version in core?