1 2016-04-14T00:03:27  *** cguida has quit IRC
   2 2016-04-14T00:11:41  *** randy-waterhouse has joined #bitcoin-core-dev
   3 2016-04-14T00:12:35  *** cguida has joined #bitcoin-core-dev
   4 2016-04-14T00:12:55  *** BlueMatt_ is now known as BlueMatt
   5 2016-04-14T00:12:55  *** BlueMatt has joined #bitcoin-core-dev
   6 2016-04-14T00:13:57  <BlueMatt> cfields_: the only logic in the added node stuff that I think is really useful to keep around is the logic around the connecting thread
   7 2016-04-14T00:15:51  <cfields_> BlueMatt: yes, that's preserved.
   8 2016-04-14T00:16:11  <BlueMatt> cfields_: eg if you change an added dns name's ip it should connect to one of the new ones
   9 2016-04-14T00:16:24  <BlueMatt> though if you change the getaddednodeinfo stuff too much it'll be useless?
  10 2016-04-14T00:16:25  <cfields_> BlueMatt: but as far as rpc is concerned, I think that logic should kinda be a black box. It should only be reporting which addresses you've requested to connect to, and which are currently connected
  11 2016-04-14T00:16:42  <BlueMatt> well how does it know which are currently connected without a dns lookup?
  12 2016-04-14T00:17:17  <BlueMatt> unless you keep a cache from dns -> ip that is updated every time the connect thread runs through its loop
  13 2016-04-14T00:17:19  <cfields_> BlueMatt: node should preserve the original dns as well as the resolved
  14 2016-04-14T00:17:48  <BlueMatt> "original"?
  15 2016-04-14T00:17:55  <BlueMatt> oh, you mean CNode?
  16 2016-04-14T00:18:06  <cfields_> yea
  17 2016-04-14T00:18:41  <BlueMatt> no, thats not sufficient...if you change the ip of a dns name, then the rpc will still report that you're connected even if you're not connected to the new name
  18 2016-04-14T00:19:05  <cfields_> BlueMatt: that's my point though, doing a new resolve won't necessarily give you the same results. For ex, if you add a seed node, which has a very short ttl, you won't find a match if you resolve again a few min later
  19 2016-04-14T00:19:14  <BlueMatt> this is confusing because now the background thread is doing something that is inconsistent with what the rpc will show you
  20 2016-04-14T00:19:53  <BlueMatt> ehh, I'm less concerned about that, but if thats your concern then it seems the only way is for the background addnodes thread to keep a cache of its resolutions
  21 2016-04-14T00:19:58  <cfields_> BlueMatt: ah i see your point
  22 2016-04-14T00:22:46  <BlueMatt> I guess I see the RPC as answering the question "Am I currently connected to what the background thread would connect to if it ran right now?"
  23 2016-04-14T00:22:51  <cfields_> BlueMatt: erm wait no, that doesn't follow. If i addnode foo.com, it resolves to, connects, then changes to, i'd say it's reasonable for rpc to report that foo.com is connected.
  24 2016-04-14T00:24:40  <cfields_> yes, i see now that it's unclear.
  25 2016-04-14T00:24:55  <BlueMatt> yea, I prefer the RPC to work the other way
  26 2016-04-14T00:25:19  <BlueMatt> I'd say the RPC thread should report that it is not connected, because that would imply to the user that its going to try to connect
  27 2016-04-14T00:25:20  <BlueMatt> which it is
  28 2016-04-14T00:26:35  <cfields_> ah, there's the problem. i didn't get that logic right after all :)
  29 2016-04-14T00:28:37  <cfields_> BlueMatt: thanks, understood now. I'll fix that up.
  30 2016-04-14T00:37:02  *** murch has quit IRC
  31 2016-04-14T00:39:21  *** PaulCapestany has quit IRC
  32 2016-04-14T00:44:57  *** PaulCapestany has joined #bitcoin-core-dev
  33 2016-04-14T00:45:32  *** cguida has quit IRC
  34 2016-04-14T00:56:43  *** PaulCapestany has quit IRC
  35 2016-04-14T01:11:22  *** cguida has joined #bitcoin-core-dev
  36 2016-04-14T01:24:25  *** cguida has quit IRC
  37 2016-04-14T01:30:07  *** dermoth has quit IRC
  38 2016-04-14T01:31:02  *** dermoth has joined #bitcoin-core-dev
  39 2016-04-14T01:35:54  *** kinlo has quit IRC
  40 2016-04-14T01:45:07  *** kinlo has joined #bitcoin-core-dev
  41 2016-04-14T01:49:35  *** cguida has joined #bitcoin-core-dev
  42 2016-04-14T02:01:59  *** cguida has quit IRC
  43 2016-04-14T02:13:34  *** arowser_ has joined #bitcoin-core-dev
  44 2016-04-14T02:14:54  *** arowser has quit IRC
  45 2016-04-14T02:18:02  *** xiangfu has joined #bitcoin-core-dev
  46 2016-04-14T02:25:17  *** jl2012 has quit IRC
  47 2016-04-14T02:27:52  *** Chris_Stewart_5 has quit IRC
  48 2016-04-14T02:41:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  49 2016-04-14T02:45:52  *** mrkent_ has quit IRC
  50 2016-04-14T02:48:02  *** cguida has joined #bitcoin-core-dev
  51 2016-04-14T02:55:04  *** randy-waterhouse has quit IRC
  52 2016-04-14T02:55:17  *** xiangfu has quit IRC
  53 2016-04-14T02:55:53  *** cryptocoder has quit IRC
  54 2016-04-14T02:55:55  *** cguida has quit IRC
  55 2016-04-14T02:56:06  *** jtimon has quit IRC
  56 2016-04-14T02:56:37  *** ryankung has joined #bitcoin-core-dev
  57 2016-04-14T02:57:03  *** xiangfu has joined #bitcoin-core-dev
  58 2016-04-14T03:00:29  *** xiangfu has quit IRC
  59 2016-04-14T03:11:27  *** Chris_Stewart_5 has quit IRC
  60 2016-04-14T03:15:19  *** droark has quit IRC
  61 2016-04-14T03:16:59  *** mrkent has joined #bitcoin-core-dev
  62 2016-04-14T03:37:22  *** arowser has joined #bitcoin-core-dev
  63 2016-04-14T03:38:16  *** arowser_ has quit IRC
  64 2016-04-14T03:47:21  *** randy-waterhouse has joined #bitcoin-core-dev
  65 2016-04-14T03:48:10  *** droark has joined #bitcoin-core-dev
  66 2016-04-14T04:04:38  *** xiangfu has joined #bitcoin-core-dev
  67 2016-04-14T04:10:50  *** johnwhitton has quit IRC
  68 2016-04-14T04:11:50  *** johnwhitton has joined #bitcoin-core-dev
  69 2016-04-14T04:25:52  *** johnwhitton has quit IRC
  70 2016-04-14T04:26:30  *** johnwhitton has joined #bitcoin-core-dev
  71 2016-04-14T04:28:51  *** PRab_ has joined #bitcoin-core-dev
  72 2016-04-14T04:30:54  *** PRab has quit IRC
  73 2016-04-14T04:30:55  *** da2ce7_mobile has quit IRC
  74 2016-04-14T04:31:08  *** PRab_ is now known as PRab
  75 2016-04-14T04:31:24  *** pavel_ has quit IRC
  76 2016-04-14T04:31:25  *** arubi has quit IRC
  77 2016-04-14T04:31:51  *** paveljanik has joined #bitcoin-core-dev
  78 2016-04-14T04:31:58  *** ryan-c has quit IRC
  79 2016-04-14T04:32:23  *** da2ce7_mobile has joined #bitcoin-core-dev
  80 2016-04-14T04:32:47  *** ryan-c has joined #bitcoin-core-dev
  81 2016-04-14T04:33:16  *** justanotheruser has quit IRC
  82 2016-04-14T04:37:22  *** justanotheruser has joined #bitcoin-core-dev
  83 2016-04-14T04:43:01  *** Alopex has quit IRC
  84 2016-04-14T04:43:04  *** arubi has joined #bitcoin-core-dev
  85 2016-04-14T04:44:06  *** Alopex has joined #bitcoin-core-dev
  86 2016-04-14T04:44:59  *** johnwhitton has quit IRC
  87 2016-04-14T04:45:36  *** johnwhitton has joined #bitcoin-core-dev
  88 2016-04-14T05:02:01  *** Alopex has quit IRC
  89 2016-04-14T05:03:06  *** Alopex has joined #bitcoin-core-dev
  90 2016-04-14T05:12:31  *** mrkent has quit IRC
  91 2016-04-14T05:15:47  *** d_t has joined #bitcoin-core-dev
  92 2016-04-14T05:19:28  *** d_t has quit IRC
  93 2016-04-14T05:23:28  *** cryptocoder has joined #bitcoin-core-dev
  94 2016-04-14T05:27:02  *** Alopex has quit IRC
  95 2016-04-14T05:28:07  *** Alopex has joined #bitcoin-core-dev
  96 2016-04-14T05:43:01  *** Alopex has quit IRC
  97 2016-04-14T05:44:06  *** Alopex has joined #bitcoin-core-dev
  98 2016-04-14T05:48:30  *** droark has quit IRC
  99 2016-04-14T05:57:58  *** cguida has joined #bitcoin-core-dev
 100 2016-04-14T05:58:40  *** cheese_ has joined #bitcoin-core-dev
 101 2016-04-14T05:58:40  *** cheese_ has joined #bitcoin-core-dev
 102 2016-04-14T06:00:04  *** dermoth has quit IRC
 103 2016-04-14T06:00:54  *** dermoth has joined #bitcoin-core-dev
 104 2016-04-14T06:02:02  *** Alopex has quit IRC
 105 2016-04-14T06:02:13  *** luke-jr_ has joined #bitcoin-core-dev
 106 2016-04-14T06:03:03  *** xabbix__ has joined #bitcoin-core-dev
 107 2016-04-14T06:03:07  *** Alopex has joined #bitcoin-core-dev
 108 2016-04-14T06:03:58  *** sturles_ has joined #bitcoin-core-dev
 109 2016-04-14T06:04:15  *** OxADADA_ has joined #bitcoin-core-dev
 110 2016-04-14T06:04:33  *** aureianimus_ has joined #bitcoin-core-dev
 111 2016-04-14T06:05:36  *** goregrin1 has joined #bitcoin-core-dev
 112 2016-04-14T06:05:42  *** sturles has quit IRC
 113 2016-04-14T06:05:42  *** sturles_ is now known as sturles
 114 2016-04-14T06:06:37  *** petertod1 has joined #bitcoin-core-dev
 115 2016-04-14T06:08:08  *** jyap_ has joined #bitcoin-core-dev
 116 2016-04-14T06:08:43  *** johnwhitton has quit IRC
 117 2016-04-14T06:08:44  *** ryan-c has quit IRC
 118 2016-04-14T06:08:44  *** Giszmo has quit IRC
 119 2016-04-14T06:08:45  *** aureianimus has quit IRC
 120 2016-04-14T06:08:45  *** RoyceX has quit IRC
 121 2016-04-14T06:08:45  *** TD-Linux has quit IRC
 122 2016-04-14T06:08:45  *** zxzzt has quit IRC
 123 2016-04-14T06:08:45  *** OxADADA has quit IRC
 124 2016-04-14T06:08:45  *** goregrind has quit IRC
 125 2016-04-14T06:08:45  *** jyap has quit IRC
 126 2016-04-14T06:08:45  *** crescendo has quit IRC
 127 2016-04-14T06:08:46  *** binns has quit IRC
 128 2016-04-14T06:08:47  *** Luke-Jr has quit IRC
 129 2016-04-14T06:08:47  *** xabbix_ has quit IRC
 130 2016-04-14T06:08:47  *** baldur has quit IRC
 131 2016-04-14T06:08:47  *** cfields_ has quit IRC
 132 2016-04-14T06:08:47  *** slackircbridge has quit IRC
 133 2016-04-14T06:08:48  *** teward has quit IRC
 134 2016-04-14T06:08:49  *** petertodd has quit IRC
 135 2016-04-14T06:08:49  *** Expanse has quit IRC
 136 2016-04-14T06:08:50  *** TD--Linux has joined #bitcoin-core-dev
 137 2016-04-14T06:08:50  *** jyap_ is now known as jyap
 138 2016-04-14T06:08:50  *** jyap has joined #bitcoin-core-dev
 139 2016-04-14T06:09:06  *** johnwhitton_ has joined #bitcoin-core-dev
 140 2016-04-14T06:10:04  *** luke-jr_ is now known as Luke-Jr
 141 2016-04-14T06:10:17  *** ryan-c has joined #bitcoin-core-dev
 142 2016-04-14T06:11:26  *** zxzzt has joined #bitcoin-core-dev
 143 2016-04-14T06:12:00  *** crescendo has joined #bitcoin-core-dev
 144 2016-04-14T06:14:24  *** teward has joined #bitcoin-core-dev
 145 2016-04-14T06:14:39  *** fkhan_ has quit IRC
 146 2016-04-14T06:16:10  *** baldur has joined #bitcoin-core-dev
 147 2016-04-14T06:20:30  *** Giszmo has joined #bitcoin-core-dev
 148 2016-04-14T06:21:06  *** d_t has joined #bitcoin-core-dev
 149 2016-04-14T06:21:06  *** Expanse has joined #bitcoin-core-dev
 150 2016-04-14T06:21:08  *** d_t has quit IRC
 151 2016-04-14T06:21:38  *** d_t has joined #bitcoin-core-dev
 152 2016-04-14T06:28:07  *** fkhan_ has joined #bitcoin-core-dev
 153 2016-04-14T06:33:15  *** d_t has quit IRC
 154 2016-04-14T06:36:01  *** Alopex has quit IRC
 155 2016-04-14T06:37:06  *** Alopex has joined #bitcoin-core-dev
 156 2016-04-14T06:45:25  *** teward has quit IRC
 157 2016-04-14T06:47:27  *** teward has joined #bitcoin-core-dev
 158 2016-04-14T06:52:14  *** randy-waterhouse has quit IRC
 159 2016-04-14T06:57:55  *** cfields has joined #bitcoin-core-dev
 160 2016-04-14T07:01:59  *** droark has joined #bitcoin-core-dev
 161 2016-04-14T07:03:27  *** binns has joined #bitcoin-core-dev
 162 2016-04-14T07:13:22  <jonasschnelli> lmdb -reindex with default dbcache took ~6h42' http://pastebin.com/ERWMGb1p
 163 2016-04-14T07:13:36  *** Thireus1 has quit IRC
 164 2016-04-14T07:14:31  <jonasschnelli> So ~2.5* slower then leveldb on the 4core 64bit linux machine I have testes.
 165 2016-04-14T07:14:56  <gmaxwell> doesn't really make sense that reindex would be slower.
 166 2016-04-14T07:15:02  <gmaxwell> since the sync is so much faster.
 167 2016-04-14T07:15:09  <gmaxwell> must be some reindex specific bug.
 168 2016-04-14T07:15:22  <jonasschnelli> gmaxwell: the sync is faster because it didn't touch the db (was dbcache=9000)
 169 2016-04-14T07:15:43  <gmaxwell> jonasschnelli: I benchmarked lmdb sync last weekend with default db cache.
 170 2016-04-14T07:15:51  <gmaxwell> it was _significantly_ faster than leveldb.
 171 2016-04-14T07:16:04  <jonasschnelli> hmm...
 172 2016-04-14T07:16:43  *** Thireus has joined #bitcoin-core-dev
 173 2016-04-14T07:16:48  <gmaxwell> 5 hours 5 minutes vs 8 hours 27minutes.
 174 2016-04-14T07:16:51  <jonasschnelli> I'll do now a reindex with the same parameter on current master (leveldb).
 175 2016-04-14T07:17:31  <wumpus> so normally a reindex takes 2h40 on that machine with leveldb with default params?
 176 2016-04-14T07:18:24  <jonasschnelli> Hmm... the 2h40 was a sync from random peers. Not sure if I acctually did a reindex with leveldb. Doing now.
 177 2016-04-14T07:18:49  <jonasschnelli> I mean these are not scientific benchmarks... I'm just playing around.
 178 2016-04-14T07:18:51  <wumpus> compare reindex against reindex please :)
 179 2016-04-14T07:18:59  <jonasschnelli> yes. I'll do now.
 180 2016-04-14T07:19:07  <wumpus> sync from network can be faster than reindex in some cases
 181 2016-04-14T07:19:12  <gmaxwell> do we still have the thing where signature checks run during reindex at all blocks?
 182 2016-04-14T07:19:21  <jonasschnelli> I just expected the lmdb reindex to be faster then the leveldb random peer sync
 183 2016-04-14T07:19:41  <jonasschnelli> But right. could be an performance issue in reindex
 184 2016-04-14T07:19:46  <wumpus> (for that reason I tend to benchmark syncing from a fast local-network peer instead of reindex these days)
 185 2016-04-14T07:20:36  <wumpus> gmaxwell: I don't know, I don't think I even know of that issue
 186 2016-04-14T07:20:47  <NicolasDorier> wumpus: how is it possible ? as I thought reindex would do less work than a resync
 187 2016-04-14T07:21:16  * gmaxwell checks the microphone.
 188 2016-04-14T07:21:23  <wumpus> NicolasDorier: you'd expect so
 189 2016-04-14T07:22:13  <gmaxwell> yes it appears we do.
 190 2016-04-14T07:22:24  *** mrkent has joined #bitcoin-core-dev
 191 2016-04-14T07:22:24  <gmaxwell> wumpus: I complained about it so much that I gave up complaining.
 192 2016-04-14T07:22:27  <wumpus> NicolasDorier: the difference is that a reindex doesn't need to write to block files, just read, and does so linearly instead of haphazard
 193 2016-04-14T07:22:32  <wumpus> gmaxwell: did you ever file a github issue?
 194 2016-04-14T07:22:36  <gmaxwell> It's mildly hard to fix.
 195 2016-04-14T07:22:38  <gmaxwell> lemme see
 196 2016-04-14T07:22:54  <gmaxwell> and it looks still unfixed.
 197 2016-04-14T07:23:23  <wumpus> please do file an issue if there is none, complaining on IRC always gets lost
 198 2016-04-14T07:23:42  <gmaxwell> basically the reindex doesn't run headers first, so it doesn't have the headers ahead of the blocks
 199 2016-04-14T07:23:48  <gmaxwell> thus         if (pindexLastCheckpoint && pindexLastCheckpoint->GetAncestor(pindex->nHeight) == pindex) {
 200 2016-04-14T07:23:51  <gmaxwell> doesn't work.
 201 2016-04-14T07:23:57  <gmaxwell> and scriptchecks run on all blocks.
 202 2016-04-14T07:24:09  <jonasschnelli> okay. Thats explains it.
 203 2016-04-14T07:24:12  <jonasschnelli> We need to fix that. :)
 204 2016-04-14T07:24:17  <wumpus> yes
 205 2016-04-14T07:24:19  <gmaxwell> I'm looking to see if there is an issue. I believe there was.
 206 2016-04-14T07:24:23  <NicolasDorier> wumpus: if reindex does not need to write to block file, why is it slower ? it does not make sense oO
 207 2016-04-14T07:24:33  <wumpus> NicolasDorier: read what gmaxwell writes above
 208 2016-04-14T07:24:36  <gmaxwell> secp256k1 made it so much faster that it was like fixing it... at least for a bit, chain growth is compensating. :)
 209 2016-04-14T07:25:35  <wumpus> this is not a concurrent i/o issue but a validation issue, apparently, I also always assumed it had something to do with i/o but reasoning that through doesn't make a single bit of sense
 210 2016-04-14T07:25:47  <NicolasDorier> oh
 211 2016-04-14T07:25:55  <NicolasDorier> I understand, thanks
 212 2016-04-14T07:26:30  <NicolasDorier> well, if you want to test performance, it is better to NOT have checkpoints right ?
 213 2016-04-14T07:26:48  <gmaxwell> NicolasDorier: sure but it resulted in jonasschnelli doing an apples/oranges test.
 214 2016-04-14T07:26:49  <wumpus> depends on what performance you want to measure, just compare apples against apples
 215 2016-04-14T07:26:51  <GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/514993554c37...8bb5d3dff46d
 216 2016-04-14T07:26:51  <GitHub33> bitcoin/master 4a1d5c1 fanquake: [Doc] Update gitian build guide to debian 8.4.0
 217 2016-04-14T07:26:52  <GitHub33> bitcoin/master 8bb5d3d Wladimir J. van der Laan: Merge #7838: [Doc] Update gitian build guide to debian 8.4.0...
 218 2016-04-14T07:27:00  <gmaxwell> https://github.com/bitcoin/bitcoin/issues/7875
 219 2016-04-14T07:27:01  <GitHub9> [bitcoin] laanwj closed pull request #7838: [Doc] Update gitian build guide to debian 8.4.0 (master...gitian-debian-84) https://github.com/bitcoin/bitcoin/pull/7838
 220 2016-04-14T07:27:14  <wumpus> if you want to compare pure database performance, disabling validation makes some sense
 221 2016-04-14T07:27:18  <jonasschnelli> gmaxwell: Yes. Right. Now started comparing Apple/Apples (reindex leveldb is running).
 222 2016-04-14T07:27:34  <jonasschnelli> What we really want is a db benchmark script.
 223 2016-04-14T07:27:38  <gmaxwell> in any case, we'd also like to get rid of checkpoints for script check bypassing, but what we'd replace them with would also need the headers... so...
 224 2016-04-14T07:27:43  <jonasschnelli> script = test-suite thing.
 225 2016-04-14T07:28:51  <wumpus> well it's easy enough to write a script that compares leveldb and lmdb (see e.g. the one in blockdb-troubleshoot that copies db-to-db), however what we want to measure is bitcoind's specific usage pattern not some dumb micro-benchmark - and that's almost impossible with an external script :)
 226 2016-04-14T07:31:00  <wumpus> I agree though that a more reproducible kind of benchmark would be nice. In principle a reindex with disabled validation wouldb e an ok one I think
 227 2016-04-14T07:31:17  <jonasschnelli> Right. That could work.
 228 2016-04-14T07:31:24  <wumpus> (at least not anything that involves internet peers)
 229 2016-04-14T07:31:36  <jonasschnelli> I think sync from a local peer is also not really representative.
 230 2016-04-14T07:31:43  <wumpus> why not?
 231 2016-04-14T07:32:05  <jonasschnelli> The local peer could do some other work during your test (like a backup or a heavy log rotate, etc.).
 232 2016-04-14T07:32:24  <gmaxwell> if it's local you control that.
 233 2016-04-14T07:32:44  <wumpus> well no I make sure it is completely available to the other node for downloading, it has no other network connections
 234 2016-04-14T07:32:51  <jonasschnelli> Sure. But I'd prefer something that exclude network and another linux.
 235 2016-04-14T07:32:52  <gmaxwell> bigger problem is that low latency peers will conceal pipelining failures.
 236 2016-04-14T07:33:15  <gmaxwell> like, if you fetch one block at a time, a local peer will not be that slow, but then add a 50ms RTT and it's MUCH slower.
 237 2016-04-14T07:33:32  <gmaxwell> of course, one can simulate real networks locally using dummynet.
 238 2016-04-14T07:33:50  <wumpus> yes there it gets into really difficult territory
 239 2016-04-14T07:33:54  <jonasschnelli> I think the reindex with disabled verification is probably better
 240 2016-04-14T07:33:54  <wumpus> benchmarking the network code
 241 2016-04-14T07:34:02  <wumpus> we're in 'benchmarking for dummies' here with the database :)
 242 2016-04-14T07:34:05  <gmaxwell> jonasschnelli: depends on what you're testing.
 243 2016-04-14T07:34:21  <jonasschnelli> For the db performance comparison
 244 2016-04-14T07:34:52  <wumpus> for the db performance comparison using a reliable local peer is good enough - that won't be the bottleneck
 245 2016-04-14T07:34:58  <gmaxwell> e.g. faults in the database handling can take the form of excessive seralization such that IO and network doesn't overlap; testing only with reindex will hide that.
 246 2016-04-14T07:35:13  <wumpus> if you want to test pipelining in networking, well, good luck, there's stacks of books written about that :)
 247 2016-04-14T07:35:17  <gmaxwell> so my point is that the reindex like test is informative, but not complete.
 248 2016-04-14T07:35:42  <gmaxwell> wumpus: one can do a lot better just by testing with a more realistic setup.
 249 2016-04-14T07:35:47  <wumpus> maybe we can find a phd student hehe
 250 2016-04-14T07:36:11  *** ryankung has quit IRC
 251 2016-04-14T07:36:15  <wumpus> gmaxwell: sure
 252 2016-04-14T07:36:23  <gmaxwell> e.g. for the testing for the recent inv changes sipa and I are working on, I setup a 14 node topology.
 253 2016-04-14T07:36:56  <gmaxwell> (with actual systems, though that test could have been done with dummynet and VMs okay, I think)
 254 2016-04-14T07:36:59  <wumpus> tools that reproduce internet circumstances on a simluated network are great for that, absolutely
 255 2016-04-14T07:46:00  *** cryptocoder has quit IRC
 256 2016-04-14T07:46:31  *** cryptocoder has joined #bitcoin-core-dev
 257 2016-04-14T07:46:55  *** cryptocoder has quit IRC
 258 2016-04-14T07:47:17  *** cryptocoder has joined #bitcoin-core-dev
 259 2016-04-14T07:47:42  *** cryptocoder has quit IRC
 260 2016-04-14T07:55:52  *** frankenmint has joined #bitcoin-core-dev
 261 2016-04-14T07:58:44  *** mase has joined #bitcoin-core-dev
 262 2016-04-14T07:58:47  <mase> hey
 263 2016-04-14T07:59:05  <mase> I am unravling the secrets of bitcion
 264 2016-04-14T07:59:16  *** mase has left #bitcoin-core-dev
 265 2016-04-14T08:03:13  *** mrkent has quit IRC
 266 2016-04-14T08:03:30  *** mrkent has joined #bitcoin-core-dev
 267 2016-04-14T08:08:43  *** p15x has joined #bitcoin-core-dev
 268 2016-04-14T08:13:58  *** jannes has joined #bitcoin-core-dev
 269 2016-04-14T08:19:46  *** Guest85557 has quit IRC
 270 2016-04-14T08:19:46  *** Guest85557 has joined #bitcoin-core-dev
 271 2016-04-14T08:19:46  *** Guest85557 is now known as amiller
 272 2016-04-14T08:23:10  *** murch has joined #bitcoin-core-dev
 273 2016-04-14T08:35:32  *** Luke-Jr has quit IRC
 274 2016-04-14T08:39:39  *** droark has quit IRC
 275 2016-04-14T08:41:10  *** Luke-Jr has joined #bitcoin-core-dev
 276 2016-04-14T08:48:20  *** laurentmt has joined #bitcoin-core-dev
 277 2016-04-14T08:50:44  *** Guyver2 has joined #bitcoin-core-dev
 278 2016-04-14T09:00:15  *** laurentmt has quit IRC
 279 2016-04-14T09:03:28  *** jonasschnelli has quit IRC
 280 2016-04-14T09:08:09  *** jonasschnelli has joined #bitcoin-core-dev
 281 2016-04-14T09:11:07  *** xiangfu has quit IRC
 282 2016-04-14T09:25:53  <jonasschnelli> We really need something like https://github.com/bitcoin/bitcoin/pull/7551 for 0.13
 283 2016-04-14T09:26:27  <jonasschnelli> Importing a couple of addresses (for watching) is sooo painful on mainnet today.
 284 2016-04-14T09:26:40  <wumpus> I'm just in the preparations for merging it
 285 2016-04-14T09:27:11  <wumpus> agree, of course, it was long due
 286 2016-04-14T09:27:35  <sipa> concept ack on importmulti
 287 2016-04-14T09:27:40  <jonasschnelli> I also blame myself because I have never tested PR #7551
 288 2016-04-14T09:27:48  <sipa> sorry for not having looked at it more
 289 2016-04-14T09:28:24  <jonasschnelli> wumpus: while you at it (*duck*): https://github.com/bitcoin/bitcoin/pull/7518
 290 2016-04-14T09:28:26  <jonasschnelli> This PR seems also very valuable.
 291 2016-04-14T09:28:36  <sipa> wumpus: can you wait one second
 292 2016-04-14T09:28:44  <jonasschnelli> I have tested it a couple of times... but probably needs at least another tACK
 293 2016-04-14T09:29:11  <wumpus> jonasschnelli: will take a look
 294 2016-04-14T09:31:00  *** mrkent has quit IRC
 295 2016-04-14T09:31:30  *** frankenm_ has joined #bitcoin-core-dev
 296 2016-04-14T09:31:55  *** murch has quit IRC
 297 2016-04-14T09:32:25  *** p15x has quit IRC
 298 2016-04-14T09:32:36  *** ibrightly has quit IRC
 299 2016-04-14T09:33:01  *** zxzzt has quit IRC
 300 2016-04-14T09:33:02  *** aj has quit IRC
 301 2016-04-14T09:33:34  *** frankenmint has quit IRC
 302 2016-04-14T09:33:35  *** Giszmo has quit IRC
 303 2016-04-14T09:33:35  *** TD--Linux has quit IRC
 304 2016-04-14T09:33:36  *** dgenr8 has quit IRC
 305 2016-04-14T09:33:36  *** hybridsole has quit IRC
 306 2016-04-14T09:33:49  *** dgenr8 has joined #bitcoin-core-dev
 307 2016-04-14T09:34:55  *** zxzzt has joined #bitcoin-core-dev
 308 2016-04-14T09:35:18  *** aj has joined #bitcoin-core-dev
 309 2016-04-14T09:37:40  *** Luke-Jr has quit IRC
 310 2016-04-14T09:37:54  *** Luke-Jr has joined #bitcoin-core-dev
 311 2016-04-14T09:39:53  *** hybridsole has joined #bitcoin-core-dev
 312 2016-04-14T09:40:52  *** ibrightly has joined #bitcoin-core-dev
 313 2016-04-14T09:43:05  <wumpus> thanks for the review on #7551 sipa
 314 2016-04-14T09:46:16  *** murch has joined #bitcoin-core-dev
 315 2016-04-14T09:48:16  *** Giszmo has joined #bitcoin-core-dev
 316 2016-04-14T09:50:06  *** TD-Linux has joined #bitcoin-core-dev
 317 2016-04-14T09:52:24  *** Thireus has quit IRC
 318 2016-04-14T10:09:13  <GitHub43> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/8bb5d3dff46d...536b75e946fb
 319 2016-04-14T10:09:14  <GitHub43> bitcoin/master 11114a6 MarcoFalke: [amount] test negative fee rates and full constructor
 320 2016-04-14T10:09:14  <GitHub43> bitcoin/master fa2da2c MarcoFalke: [amount] Add support for negative fee rates...
 321 2016-04-14T10:09:15  <GitHub43> bitcoin/master facf5a4 MarcoFalke: [amount] tests: Fix off-by-one mistake
 322 2016-04-14T10:09:23  <GitHub175> [bitcoin] laanwj closed pull request #7796: [amount] Add support for negative fee rates (master...Mf1604-amountNeg64) https://github.com/bitcoin/bitcoin/pull/7796
 323 2016-04-14T10:09:30  <jonasschnelli> sipa: > nOldFee already is enough for all previously replaced ones, so you only need to add minTxRelayFee to account for everything. That's the logic used by the replacement code as well.
 324 2016-04-14T10:09:39  <jonasschnelli> What if you need to add an input to fit the new fee?
 325 2016-04-14T10:09:56  <sipa> yes?
 326 2016-04-14T10:10:15  <jonasschnelli> bigger tx size, more fee required.
 327 2016-04-14T10:10:18  <GitHub187> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/536b75e946fb...b778e5993af9
 328 2016-04-14T10:10:18  <GitHub187> bitcoin/master fa6399d MarcoFalke: [doc] gitian: Replace precise with trusty
 329 2016-04-14T10:10:19  <GitHub187> bitcoin/master b778e59 Wladimir J. van der Laan: Merge #7855: [doc] gitian: Replace precise with trusty...
 330 2016-04-14T10:10:25  <jonasschnelli> Just adding minTxRelayFee is not sufficient IMO
 331 2016-04-14T10:10:26  <sipa> jonasschnelli: yes, which the relay fee will account for
 332 2016-04-14T10:10:37  <sipa> minTxRelayFee is a feerate, you multiply it by the size of the tx
 333 2016-04-14T10:11:01  <jonasschnelli> But you don't know the size before you did ran the coinselection...
 334 2016-04-14T10:11:50  <jonasschnelli> rucksack problem, thats why I though running the CreateTransaction logic again
 335 2016-04-14T10:12:36  <jonasschnelli> s/rucksack/knapsack
 336 2016-04-14T10:12:40  <sipa> ok, i'm missing some context i think
 337 2016-04-14T10:13:36  * jonasschnelli afk for 1h
 338 2016-04-14T10:13:58  *** murch has quit IRC
 339 2016-04-14T10:15:24  <GitHub61> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b778e5993af9...72c54e388315
 340 2016-04-14T10:15:25  <GitHub61> bitcoin/master 85c807c Rusty Russell: getblockchaininfo: make bip9_softforks an object, not an array....
 341 2016-04-14T10:15:25  <GitHub61> bitcoin/master d12760b Rusty Russell: rpc-tests: handle KeyError nicely in test_framework.py...
 342 2016-04-14T10:15:26  <GitHub61> bitcoin/master 72c54e3 Wladimir J. van der Laan: Merge #7863: getblockchaininfo: make bip9_softforks an object, not an array....
 343 2016-04-14T10:15:32  <GitHub19> [bitcoin] laanwj closed pull request #7863: getblockchaininfo: make bip9_softforks an object, not an array. (master...bip9-status-as-object) https://github.com/bitcoin/bitcoin/pull/7863
 344 2016-04-14T10:18:29  <sipa> do we backport 7863 to 0.12?
 345 2016-04-14T10:21:47  *** gevs has joined #bitcoin-core-dev
 346 2016-04-14T10:25:49  <wumpus> yes, it needs to be backported to 0.12 eventually
 347 2016-04-14T10:26:14  <wumpus> if there is 0.12.1rc3 may as well be in it
 348 2016-04-14T10:27:02  <Luke-Jr> I wonder sometimes if it should be named "bip9", but I can argue both ways, so I haven't brought it up.
 349 2016-04-14T10:27:43  <Luke-Jr> probably not important enough to matter
 350 2016-04-14T10:28:30  <wumpus> yes, feel no need to even have an opinion about it
 351 2016-04-14T10:31:02  *** erasmospunk has joined #bitcoin-core-dev
 352 2016-04-14T10:38:46  <wumpus> cfields: let's have a chat some time about how to handle out-of-tree builds (#7466), I'd really like that working, we have two solutions, but I guess neither is mergeable yet and I'm not sure how to continue
 353 2016-04-14T10:40:18  <wumpus> (I'd really like to switch to a setup where the source code is on a different disk from the binaries)
 354 2016-04-14T10:41:07  <sipa> wumpus: squashfs? :p
 355 2016-04-14T10:42:06  <wumpus> lol would you compress the binaries or the source code?
 356 2016-04-14T10:42:19  <sipa> oops, i mean unionfs
 357 2016-04-14T10:43:55  <wumpus> could work I guess, but seems overkill, every project just supports out-of-tree builds except bitcoin core :)
 358 2016-04-14T10:47:13  <wumpus> but unionfs does look interesting, could help in some other cases
 359 2016-04-14T10:47:55  <sipa> hah, seems unionfs was the original used by Knoppix, since then there has been aufs (which was rejected by linux mainline, but the alternative overlayfs was merged)
 360 2016-04-14T10:48:51  <wumpus> the main motivation really (besides maybe performance) is to have a clearer separation between stuff that needs to be backed up and stuff that could just be rebuilt if lost
 361 2016-04-14T10:50:28  <sipa> maybe it would be interesting for me as well... whenever my laptop battaery dies while compiling bitcoin core (not surprisingly, that's the most common activity during which power fails), my git tree is corrupted
 362 2016-04-14T11:24:34  *** laurentmt has joined #bitcoin-core-dev
 363 2016-04-14T11:24:56  *** laurentmt has quit IRC
 364 2016-04-14T11:28:09  *** harding_ has quit IRC
 365 2016-04-14T11:28:09  *** davec has quit IRC
 366 2016-04-14T11:28:16  *** harding has joined #bitcoin-core-dev
 367 2016-04-14T11:28:21  *** davec has joined #bitcoin-core-dev
 368 2016-04-14T11:29:42  *** gavinandresen has quit IRC
 369 2016-04-14T11:29:50  *** gavinandresen has joined #bitcoin-core-dev
 370 2016-04-14T11:37:27  *** gmaxwell has quit IRC
 371 2016-04-14T11:37:34  *** gmaxwell has joined #bitcoin-core-dev
 372 2016-04-14T11:37:59  *** gmaxwell is now known as Guest75512
 373 2016-04-14T11:39:00  *** molz has quit IRC
 374 2016-04-14T11:39:18  <GitHub62> [bitcoin] laanwj closed pull request #7850: Removed call to `TryCreateDirectory` from `GetDefaultDataDir` in `src/util.cpp`. (master...issue7845) https://github.com/bitcoin/bitcoin/pull/7850
 375 2016-04-14T11:39:23  *** molz has joined #bitcoin-core-dev
 376 2016-04-14T11:47:53  *** dermoth_ has joined #bitcoin-core-dev
 377 2016-04-14T11:48:16  *** dermoth has quit IRC
 378 2016-04-14T11:56:02  *** Cory has quit IRC
 379 2016-04-14T11:59:01  *** Cory has joined #bitcoin-core-dev
 380 2016-04-14T12:01:18  *** RoyceX has joined #bitcoin-core-dev
 381 2016-04-14T12:03:55  *** roasbeef_ has quit IRC
 382 2016-04-14T12:04:01  *** roasbeef has joined #bitcoin-core-dev
 383 2016-04-14T12:04:21  *** cheese_ has quit IRC
 384 2016-04-14T12:11:17  *** aureianimus_ has quit IRC
 385 2016-04-14T12:11:43  *** aureianimus has joined #bitcoin-core-dev
 386 2016-04-14T12:15:08  *** jtimon has joined #bitcoin-core-dev
 387 2016-04-14T12:15:25  *** spikeheadon has joined #bitcoin-core-dev
 388 2016-04-14T12:16:14  *** spikeheadon has quit IRC
 389 2016-04-14T12:17:00  *** spikeheadon has joined #bitcoin-core-dev
 390 2016-04-14T12:18:22  *** spikeheadon has quit IRC
 391 2016-04-14T12:19:11  *** spikeheadon has joined #bitcoin-core-dev
 392 2016-04-14T12:20:00  *** spikeheadon has quit IRC
 393 2016-04-14T12:20:08  *** lejitz has joined #bitcoin-core-dev
 394 2016-04-14T12:20:51  *** spikeheadon has joined #bitcoin-core-dev
 395 2016-04-14T12:21:43  *** spikeheadon has quit IRC
 396 2016-04-14T12:22:33  *** spikeheadon has joined #bitcoin-core-dev
 397 2016-04-14T12:22:37  *** lejitz has quit IRC
 398 2016-04-14T12:23:26  *** spikeheadon has quit IRC
 399 2016-04-14T12:24:12  *** spikeheadon has joined #bitcoin-core-dev
 400 2016-04-14T12:25:51  *** spikeheadon has joined #bitcoin-core-dev
 401 2016-04-14T12:26:58  *** spikeheadon has quit IRC
 402 2016-04-14T12:27:46  *** spikeheadon has joined #bitcoin-core-dev
 403 2016-04-14T12:28:34  *** spikeheadon has quit IRC
 404 2016-04-14T12:29:27  *** spikeheadon has joined #bitcoin-core-dev
 405 2016-04-14T12:30:17  *** spikeheadon has quit IRC
 406 2016-04-14T12:31:04  *** spikeheadon has joined #bitcoin-core-dev
 407 2016-04-14T12:31:55  *** spikeheadon has quit IRC
 408 2016-04-14T12:32:40  *** spikeheadon has joined #bitcoin-core-dev
 409 2016-04-14T12:34:04  *** Expanse has quit IRC
 410 2016-04-14T12:34:31  *** jl2012 has joined #bitcoin-core-dev
 411 2016-04-14T12:36:39  *** OxADADA_ is now known as OxADADA
 412 2016-04-14T12:36:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 413 2016-04-14T12:41:42  *** Expanse has joined #bitcoin-core-dev
 414 2016-04-14T12:47:05  <GitHub198> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/229a17ca915c...ab8586e6677a
 415 2016-04-14T12:47:06  <GitHub198> bitcoin/master 4521f00 Wladimir J. van der Laan: tests: add varints_bitpatterns test...
 416 2016-04-14T12:47:06  <GitHub198> bitcoin/master ab8586e Wladimir J. van der Laan: Merge #7849: tests: add varints_bitpatterns test...
 417 2016-04-14T12:47:13  <GitHub14> [bitcoin] laanwj closed pull request #7849: tests: add varints_bitpatterns test (master...2016_04_varint_bit_pattern_tests) https://github.com/bitcoin/bitcoin/pull/7849
 418 2016-04-14T12:54:56  *** erasmospunk has quit IRC
 419 2016-04-14T12:55:23  <GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ab8586e6677a...97d0b9889f15
 420 2016-04-14T12:55:23  <GitHub183> bitcoin/master 7e91f63 Suhas Daftuar: Use txid as key in mapAlreadyAskedFor...
 421 2016-04-14T12:55:24  <GitHub183> bitcoin/master 97d0b98 Wladimir J. van der Laan: Merge #7862: Use txid as key in mapAlreadyAskedFor...
 422 2016-04-14T12:55:34  <GitHub70> [bitcoin] laanwj closed pull request #7862: Use txid as key in mapAlreadyAskedFor (master...inv-to-txid-mapalreadyaskedfor) https://github.com/bitcoin/bitcoin/pull/7862
 423 2016-04-14T13:02:49  *** erasmospunk has joined #bitcoin-core-dev
 424 2016-04-14T13:05:17  *** dgenr8 has quit IRC
 425 2016-04-14T13:06:09  *** dgenr8 has joined #bitcoin-core-dev
 426 2016-04-14T13:11:29  *** achow101 has quit IRC
 427 2016-04-14T13:11:58  *** achow101 has joined #bitcoin-core-dev
 428 2016-04-14T13:14:26  <GitHub168> [bitcoin] jtimon opened pull request #7876: Globals: Explicitly pass const CChainParams& to UpdateTip() (master...0.12.99-globals-chainparams-updatetip) https://github.com/bitcoin/bitcoin/pull/7876
 429 2016-04-14T13:15:15  *** erasmosp_ has joined #bitcoin-core-dev
 430 2016-04-14T13:15:41  *** cguida_ has joined #bitcoin-core-dev
 431 2016-04-14T13:15:47  *** arowser has quit IRC
 432 2016-04-14T13:16:41  *** arowser has joined #bitcoin-core-dev
 433 2016-04-14T13:16:57  *** ibrightly_ has joined #bitcoin-core-dev
 434 2016-04-14T13:17:07  *** ibrightly has quit IRC
 435 2016-04-14T13:17:16  *** paveljanik has quit IRC
 436 2016-04-14T13:17:16  *** isis has quit IRC
 437 2016-04-14T13:17:16  *** ibrightly_ is now known as ibrightly
 438 2016-04-14T13:17:54  *** erasmospunk has quit IRC
 439 2016-04-14T13:17:54  *** roasbeef has quit IRC
 440 2016-04-14T13:17:55  *** dermoth_ has quit IRC
 441 2016-04-14T13:17:55  *** Giszmo has quit IRC
 442 2016-04-14T13:17:55  *** cguida has quit IRC
 443 2016-04-14T13:17:55  *** jarret has quit IRC
 444 2016-04-14T13:17:55  *** sdaftuar has quit IRC
 445 2016-04-14T13:18:01  *** cguida_ is now known as cguida
 446 2016-04-14T13:18:07  *** roasbeef has joined #bitcoin-core-dev
 447 2016-04-14T13:18:33  *** Lightsword has quit IRC
 448 2016-04-14T13:18:55  *** Lightsword has joined #bitcoin-core-dev
 449 2016-04-14T13:18:55  *** dermoth_ has joined #bitcoin-core-dev
 450 2016-04-14T13:18:58  *** Giszmo has joined #bitcoin-core-dev
 451 2016-04-14T13:19:51  *** isis has joined #bitcoin-core-dev
 452 2016-04-14T13:20:19  *** jarret has joined #bitcoin-core-dev
 453 2016-04-14T13:33:40  *** ebfull has quit IRC
 454 2016-04-14T13:35:13  *** ebfull has joined #bitcoin-core-dev
 455 2016-04-14T13:41:25  *** muuqwaul has joined #bitcoin-core-dev
 456 2016-04-14T13:46:10  *** frankenmint has joined #bitcoin-core-dev
 457 2016-04-14T13:47:36  <GitHub171> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/97d0b9889f15...491171f92954
 458 2016-04-14T13:47:37  <GitHub171> bitcoin/master 5eeb913 Pieter Wuille: Clean up lockorder data of destroyed mutexes...
 459 2016-04-14T13:47:37  <GitHub171> bitcoin/master 491171f Wladimir J. van der Laan: Merge #7846: Clean up lockorder data of destroyed mutexes...
 460 2016-04-14T13:47:41  <GitHub9> [bitcoin] laanwj closed pull request #7846: Clean up lockorder data of destroyed mutexes (master...cleanlocks) https://github.com/bitcoin/bitcoin/pull/7846
 461 2016-04-14T13:47:52  *** Amnez777 has quit IRC
 462 2016-04-14T13:48:28  *** hybridsole has quit IRC
 463 2016-04-14T13:48:29  *** zxzzt has quit IRC
 464 2016-04-14T13:48:29  *** frankenm_ has quit IRC
 465 2016-04-14T13:48:29  *** fkhan_ has quit IRC
 466 2016-04-14T13:48:29  *** crescendo has quit IRC
 467 2016-04-14T13:49:05  *** Cory has quit IRC
 468 2016-04-14T13:49:05  *** jannes has quit IRC
 469 2016-04-14T13:49:06  *** sturles has quit IRC
 470 2016-04-14T13:49:06  *** da2ce7_mobile has quit IRC
 471 2016-04-14T13:49:06  *** kinlo has quit IRC
 472 2016-04-14T13:49:39  *** kinlo has joined #bitcoin-core-dev
 473 2016-04-14T13:50:12  *** zxzzt has joined #bitcoin-core-dev
 474 2016-04-14T13:50:13  *** crescendo has joined #bitcoin-core-dev
 475 2016-04-14T13:50:23  *** sturles has joined #bitcoin-core-dev
 476 2016-04-14T13:50:31  *** d_t has joined #bitcoin-core-dev
 477 2016-04-14T13:51:03  *** Pasha has joined #bitcoin-core-dev
 478 2016-04-14T13:53:07  *** TomMc has joined #bitcoin-core-dev
 479 2016-04-14T13:54:18  *** hybridsole has joined #bitcoin-core-dev
 480 2016-04-14T13:54:53  *** d_t has quit IRC
 481 2016-04-14T13:55:47  *** Amnez777 has joined #bitcoin-core-dev
 482 2016-04-14T13:56:05  *** ryankung has joined #bitcoin-core-dev
 483 2016-04-14T13:57:44  *** da2ce7_mobile has joined #bitcoin-core-dev
 484 2016-04-14T13:57:56  *** Pasha is now known as Cory
 485 2016-04-14T14:01:04  *** jannes has joined #bitcoin-core-dev
 486 2016-04-14T14:01:06  *** fkhan_ has joined #bitcoin-core-dev
 487 2016-04-14T14:04:09  *** ryankung has quit IRC
 488 2016-04-14T14:10:31  <GitHub48> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/491171f92954...d97101e5a84b
 489 2016-04-14T14:10:32  <GitHub48> bitcoin/master 62a6486 Pavel Janík: RPC: do not print ping info in getpeerinfo when no ping received yet, fix help
 490 2016-04-14T14:10:32  <GitHub48> bitcoin/master d97101e Wladimir J. van der Laan: Merge #7842: RPC: do not print minping time in getpeerinfo when no ping received yet...
 491 2016-04-14T14:10:41  <GitHub93> [bitcoin] laanwj closed pull request #7842: RPC: do not print minping time in getpeerinfo when no ping received yet (master...20160408_getpeerinfo_no_ping_yet) https://github.com/bitcoin/bitcoin/pull/7842
 492 2016-04-14T14:12:31  *** muuqwaul has quit IRC
 493 2016-04-14T14:12:56  *** muuqwaul has joined #bitcoin-core-dev
 494 2016-04-14T14:13:57  *** muuqwaul has joined #bitcoin-core-dev
 495 2016-04-14T14:15:44  *** muuqwaul has quit IRC
 496 2016-04-14T14:16:11  *** muuqwaul has joined #bitcoin-core-dev
 497 2016-04-14T14:24:44  *** Schlorted has joined #bitcoin-core-dev
 498 2016-04-14T14:27:40  <GitHub86> [bitcoin] sipa opened pull request #7877: Change mapRelay to store CTransactions (master...relayctransaction) https://github.com/bitcoin/bitcoin/pull/7877
 499 2016-04-14T14:35:24  <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d97101e5a84b...430fffefaab6
 500 2016-04-14T14:35:24  <GitHub101> bitcoin/master 4f7c959 Jonas Schnelli: Refactor IsRBFOptIn, avoid exception
 501 2016-04-14T14:35:25  <GitHub101> bitcoin/master 430fffe Wladimir J. van der Laan: Merge #7812: Tiny refactor of `IsRBFOptIn`, avoid exception...
 502 2016-04-14T14:35:31  <GitHub24> [bitcoin] laanwj closed pull request #7812: Tiny refactor of `IsRBFOptIn`, avoid exception (master...2016/04/rbf_refact) https://github.com/bitcoin/bitcoin/pull/7812
 503 2016-04-14T14:42:12  *** laurentmt has joined #bitcoin-core-dev
 504 2016-04-14T14:45:26  <jtimon> ping #7779
 505 2016-04-14T14:54:49  *** laurentmt has quit IRC
 506 2016-04-14T14:56:26  *** laurentmt has joined #bitcoin-core-dev
 507 2016-04-14T14:57:21  *** johnwhitton_ has quit IRC
 508 2016-04-14T15:01:15  *** MarcoFalke has joined #bitcoin-core-dev
 509 2016-04-14T15:01:15  *** hsmiths has quit IRC
 510 2016-04-14T15:03:27  *** hsmiths has joined #bitcoin-core-dev
 511 2016-04-14T15:04:38  *** laurentmt has quit IRC
 512 2016-04-14T15:10:14  *** Giszmo has quit IRC
 513 2016-04-14T15:13:32  *** Giszmo has joined #bitcoin-core-dev
 514 2016-04-14T15:15:53  *** xiangfu has joined #bitcoin-core-dev
 515 2016-04-14T15:17:45  *** paveljanik has joined #bitcoin-core-dev
 516 2016-04-14T15:17:45  *** paveljanik has joined #bitcoin-core-dev
 517 2016-04-14T15:19:37  *** spikeheadon has quit IRC
 518 2016-04-14T15:19:41  *** muuqwaul has quit IRC
 519 2016-04-14T15:20:07  *** muuqwaul has joined #bitcoin-core-dev
 520 2016-04-14T15:25:55  *** xiangfu has quit IRC
 521 2016-04-14T15:47:15  <GitHub90> [bitcoin] laanwj closed pull request #7131: Add 'setblockmaxsize' RPC interface (master...setblockmaxsize) https://github.com/bitcoin/bitcoin/pull/7131
 522 2016-04-14T15:49:44  *** Thireus has joined #bitcoin-core-dev
 523 2016-04-14T15:50:54  *** MarcoFalke has quit IRC
 524 2016-04-14T15:54:31  *** Squidicuz has joined #bitcoin-core-dev
 525 2016-04-14T15:57:01  *** johnwhitton has joined #bitcoin-core-dev
 526 2016-04-14T16:05:50  *** droark has joined #bitcoin-core-dev
 527 2016-04-14T16:19:19  *** Samdney has joined #bitcoin-core-dev
 528 2016-04-14T16:19:55  *** murch has joined #bitcoin-core-dev
 529 2016-04-14T16:20:29  *** Samdney has quit IRC
 530 2016-04-14T16:21:30  *** Ylbam has joined #bitcoin-core-dev
 531 2016-04-14T16:21:54  *** Samdney has joined #bitcoin-core-dev
 532 2016-04-14T16:24:06  *** cryptocoder has joined #bitcoin-core-dev
 533 2016-04-14T16:27:16  *** Chris_Stewart_5 has quit IRC
 534 2016-04-14T16:28:48  *** laurentmt has joined #bitcoin-core-dev
 535 2016-04-14T16:30:17  *** laurentmt has quit IRC
 536 2016-04-14T16:33:16  *** zooko has joined #bitcoin-core-dev
 537 2016-04-14T16:34:37  *** jannes has quit IRC
 538 2016-04-14T16:59:10  *** Guest75512 is now known as gmaxwell
 539 2016-04-14T16:59:25  *** gmaxwell has joined #bitcoin-core-dev
 540 2016-04-14T17:02:30  *** MarcoFalke has joined #bitcoin-core-dev
 541 2016-04-14T17:17:52  *** molly has joined #bitcoin-core-dev
 542 2016-04-14T17:18:01  *** cryptocoder_ has joined #bitcoin-core-dev
 543 2016-04-14T17:18:37  *** hsmiths2 has joined #bitcoin-core-dev
 544 2016-04-14T17:19:02  *** erasmospunk has joined #bitcoin-core-dev
 545 2016-04-14T17:19:58  *** hsmiths has quit IRC
 546 2016-04-14T17:20:31  *** cryptocoder has quit IRC
 547 2016-04-14T17:20:31  *** Thireus has quit IRC
 548 2016-04-14T17:20:31  *** Schlorted has quit IRC
 549 2016-04-14T17:20:32  *** sturles has quit IRC
 550 2016-04-14T17:20:32  *** erasmosp_ has quit IRC
 551 2016-04-14T17:20:38  *** cryptocoder_ is now known as cryptocoder
 552 2016-04-14T17:21:05  *** zxzzt has quit IRC
 553 2016-04-14T17:21:05  *** arowser has quit IRC
 554 2016-04-14T17:21:05  *** jtimon has quit IRC
 555 2016-04-14T17:21:06  *** molz has quit IRC
 556 2016-04-14T17:21:37  *** arowser has joined #bitcoin-core-dev
 557 2016-04-14T17:21:47  *** jtimon has joined #bitcoin-core-dev
 558 2016-04-14T17:21:56  *** sturles has joined #bitcoin-core-dev
 559 2016-04-14T17:26:26  *** cryptocoder_ has joined #bitcoin-core-dev
 560 2016-04-14T17:27:30  *** cryptocoder has quit IRC
 561 2016-04-14T17:27:31  *** cryptocoder_ is now known as cryptocoder
 562 2016-04-14T17:37:02  *** Thireus has joined #bitcoin-core-dev
 563 2016-04-14T17:37:04  *** zxzzt has joined #bitcoin-core-dev
 564 2016-04-14T17:38:01  *** Schlorted has joined #bitcoin-core-dev
 565 2016-04-14T17:48:03  *** erasmosp_ has joined #bitcoin-core-dev
 566 2016-04-14T17:50:54  *** zxzzt has quit IRC
 567 2016-04-14T17:50:54  *** erasmospunk has quit IRC
 568 2016-04-14T17:51:08  *** zxzzt has joined #bitcoin-core-dev
 569 2016-04-14T17:51:33  *** murch has quit IRC
 570 2016-04-14T17:51:34  *** pigeons has quit IRC
 571 2016-04-14T17:51:41  *** pigeons has joined #bitcoin-core-dev
 572 2016-04-14T17:52:05  *** pigeons is now known as Guest69947
 573 2016-04-14T17:53:53  *** sdaftuar has joined #bitcoin-core-dev
 574 2016-04-14T17:54:37  *** murch has joined #bitcoin-core-dev
 575 2016-04-14T17:54:54  *** muuqwaul has quit IRC
 576 2016-04-14T17:55:21  *** muuqwaul has joined #bitcoin-core-dev
 577 2016-04-14T17:55:28  <OxADADA> we're using Kramdown for the bitcoin-core website, yes? GitHub is moving away from the other Markdown parsers.
 578 2016-04-14T17:55:47  <OxADADA> yes, we are using kramdown, we're good
 579 2016-04-14T17:57:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 580 2016-04-14T18:01:54  <GitHub44> [bitcoin] MarcoFalke opened pull request #7878: [test] bctest.py: Revert faa41ee (master...Mf1604-bctestPy) https://github.com/bitcoin/bitcoin/pull/7878
 581 2016-04-14T18:09:10  *** erasmosp_ has quit IRC
 582 2016-04-14T18:11:40  <jonasschnelli> Here is the comparison between reindex of current master vs wumpuses LMDB branch:
 583 2016-04-14T18:11:40  <jonasschnelli> http://pastebin.com/raw/evx62gak
 584 2016-04-14T18:12:31  <jonasschnelli> leveldb was 1.2842709773 faster
 585 2016-04-14T18:17:20  *** MarcoFalke has quit IRC
 586 2016-04-14T18:19:35  <jonasschnelli> Is there an rpc call to show the feerate of a rawtx? Or do I need to calc it myself strlen(hex/2)*estimatefee(2)?
 587 2016-04-14T18:19:59  <sipa> there is not even an rpc that can show the fee of a raw transaction :)
 588 2016-04-14T18:20:10  <sipa> oh, you mean the estimated necessary fee for a transaction?
 589 2016-04-14T18:20:29  *** Guest69947 is now known as pigeons
 590 2016-04-14T18:20:29  <jonasschnelli> No. Forget about the example calculation above (its wrong).
 591 2016-04-14T18:20:44  <jonasschnelli> The absolute fee and the feerate would be nice.
 592 2016-04-14T18:20:52  <jonasschnelli> we should add that to decoderawtransaction
 593 2016-04-14T18:21:31  <sipa> we can't
 594 2016-04-14T18:21:38  <sipa> transactions don't have a "fee" field
 595 2016-04-14T18:21:41  <sipa> you need to know the input
 596 2016-04-14T18:21:50  <jonasschnelli> Lookup?
 597 2016-04-14T18:22:08  <sipa> decoderawtransaction decodes
 598 2016-04-14T18:22:17  <jonasschnelli> Thats true.
 599 2016-04-14T18:22:19  <sipa> it also doesn't tell you what scriptPubKeys were spent
 600 2016-04-14T18:22:29  <sipa> or what height the transaction is in
 601 2016-04-14T18:22:38  <sipa> furthermore, we generally *cannot* look that up
 602 2016-04-14T18:22:43  <jonasschnelli> Well, at least we could tell the estimate fee (size*estimatefee(2))
 603 2016-04-14T18:22:47  <sipa> because that information is no longer in the UTXO set
 604 2016-04-14T18:23:00  <jonasschnelli> Yes. Would only work for unspent inputs.
 605 2016-04-14T18:23:06  <sipa> right
 606 2016-04-14T18:23:11  <sipa> i guess that's still useful
 607 2016-04-14T18:23:49  <jonasschnelli> Hmm.. but can be confusing if the rawtx is not signed,... maybe estimating the signature size *duck*
 608 2016-04-14T18:27:06  <gmaxwell> showing an estimate fee there would be potentially dangerous when someone mistakes it for the actual fee.
 609 2016-04-14T18:29:48  *** Evel-Knievel has joined #bitcoin-core-dev
 610 2016-04-14T18:31:56  <jonasschnelli> Yes. I think the nested command extension I have added to the GUI could be usefull for bitcoin-cli for such situations.
 611 2016-04-14T18:32:28  <jonasschnelli> estimatefee(2)*decoderawtransaction(<hex>)['size']
 612 2016-04-14T18:32:52  <jonasschnelli> missing a /1000
 613 2016-04-14T18:34:10  <gmaxwell> using decode raw transactions to determine the number of bytes in a hex string seems weird... also, was mentioned, it doesn't include signatures at the point where you're estimating the fee.
 614 2016-04-14T18:34:47  <gmaxwell> when you're author a transaction the fee calculation should be based on how many and what kind of inputs you're using and how many and what kind of outputs.
 615 2016-04-14T18:34:49  <jonasschnelli> Agree. decoderawtransaction(<hex>)['size'] is stupid
 616 2016-04-14T18:35:00  <jonasschnelli> Only makes sense if you also need other data form the call.
 617 2016-04-14T18:37:59  *** muuqwaul has quit IRC
 618 2016-04-14T18:38:25  *** muuqwaul has joined #bitcoin-core-dev
 619 2016-04-14T18:43:05  <sipa> gmaxwell: i guess it would be convenient past segwit
 620 2016-04-14T18:43:08  <sipa> to get vsize
 621 2016-04-14T18:59:02  *** Chris_Stewart_5 has quit IRC
 622 2016-04-14T19:00:35  <cfields> meeting?
 623 2016-04-14T19:00:42  <gmaxwell> Hi all.
 624 2016-04-14T19:00:46  <wumpus> I guess?
 625 2016-04-14T19:00:49  <sdaftuar> hello
 626 2016-04-14T19:00:50  <wumpus> #startmeeting
 627 2016-04-14T19:00:50  <lightningbot> Meeting started Thu Apr 14 19:00:50 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 628 2016-04-14T19:00:50  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 629 2016-04-14T19:00:56  <morcos> confidence inspiring wumpus
 630 2016-04-14T19:01:01  <btcdrak> gavel wont be attending due to last week's beating.
 631 2016-04-14T19:01:04  <cfields> heh
 632 2016-04-14T19:01:06  <gmaxwell> "If I have to."
 633 2016-04-14T19:01:12  <wumpus> topics?
 634 2016-04-14T19:01:32  <gmaxwell> Whats up with the 0.12.1 release? I haven't been paying attention to it.
 635 2016-04-14T19:01:34  <morcos> status of 12.1
 636 2016-04-14T19:01:41  <btcdrak> 0.12.1 status
 637 2016-04-14T19:01:57  <wumpus> 0.12.1 is at rc2
 638 2016-04-14T19:02:29  <wumpus> haven't heard of any issues with it
 639 2016-04-14T19:02:36  <gmaxwell> There was a 0.12.1(rc) block mined in the last week.
 640 2016-04-14T19:02:41  <sipa> i suggest we go ahead with release?
 641 2016-04-14T19:02:50  <jonasschnelli> +1
 642 2016-04-14T19:02:53  <btcdrak> +10
 643 2016-04-14T19:02:56  <sipa> -11
 644 2016-04-14T19:03:02  <btcdrak> doh!
 645 2016-04-14T19:03:02  *** arowser has quit IRC
 646 2016-04-14T19:03:03  <gmaxwell> +1i.
 647 2016-04-14T19:03:46  <sipa> gmaxwell: interesting; block version 0x2..?
 648 2016-04-14T19:03:52  <sipa> but not classic
 649 2016-04-14T19:03:53  <Luke-Jr> we should release 0.12.1 when 0.12.1 is observed to be released.
 650 2016-04-14T19:04:18  <sipa> Luke-Jr is the first member of the club containing Luke-Jr as first member
 651 2016-04-14T19:04:33  <gmaxwell> sipa: yes, it seems we kinda flubbed the part of the motivation with the BIP9 starting dates to remove the possibility of warings in advance of a release. :)
 652 2016-04-14T19:04:37  <Luke-Jr> that sounds lonely.
 653 2016-04-14T19:04:38  <wumpus> usually we wait a week after the release of the binaries before labeling the rc as final, the binary release was only 3 days ago
 654 2016-04-14T19:04:44  <sipa> wumpus: ok
 655 2016-04-14T19:04:47  <wumpus> but if you insist
 656 2016-04-14T19:05:01  <sipa> topic suggestion: segwit and backports
 657 2016-04-14T19:05:08  <btcdrak> let's insist
 658 2016-04-14T19:05:08  <jonasschnelli> Yes. We should wait at least one week.
 659 2016-04-14T19:05:10  <gmaxwell> sipa: but at least thats just a one time event.
 660 2016-04-14T19:05:38  <gmaxwell> well 1 week - 3 days is still before the next meeting. So the action should be release 0.12.1 prior to the next meeting. :)
 661 2016-04-14T19:05:43  <Luke-Jr> could start the gitian building now and wait the rest of the week to publish?
 662 2016-04-14T19:06:11  <jonasschnelli> the tag could be seen as "release"
 663 2016-04-14T19:06:11  <btcdrak> 1 business week is 5 days :)
 664 2016-04-14T19:06:27  <wumpus> good to hear a block would mined with 0.12.1 though, hadn't heard that yet
 665 2016-04-14T19:06:32  <wumpus> s/would/was
 666 2016-04-14T19:06:54  <btcdrak> why not tag 0.12.1 we can build over the weekend and release on Monday?
 667 2016-04-14T19:07:14  <jonasschnelli> Why not tag on monday and build on monday?
 668 2016-04-14T19:07:22  *** moli has joined #bitcoin-core-dev
 669 2016-04-14T19:07:22  <jonasschnelli> You don't need to handhold you bulder?
 670 2016-04-14T19:07:24  <sipa> wumpus decides
 671 2016-04-14T19:07:26  <gmaxwell> the building has latency.
 672 2016-04-14T19:07:28  <wumpus> you're too eager
 673 2016-04-14T19:07:46  <btcdrak> gotta build, cfields needs to sign etc.
 674 2016-04-14T19:07:50  <gmaxwell> in the future we should figure out how to deseralize builds of the final release and publication of the tag.
 675 2016-04-14T19:08:13  <wumpus> huh
 676 2016-04-14T19:08:16  <jonasschnelli> we could agree on a commit and build that and tag later.
 677 2016-04-14T19:08:17  *** molly has quit IRC
 678 2016-04-14T19:08:40  <gmaxwell> the fact that we've been doing "releases" that get announced and circulated ahead of the project's announcement and then having binary days delayed is suboptimal.
 679 2016-04-14T19:08:41  <sipa> we need to have gitian build inside a homomorphically encrypted environment, so that we can verify binary correctness, but only release the key at release time
 680 2016-04-14T19:08:43  <wumpus> is this still serious?
 681 2016-04-14T19:08:44  <cfields> fwiw, dropping the commit hash in the binary would create a few more options
 682 2016-04-14T19:08:55  <sipa> wumpus: no
 683 2016-04-14T19:09:00  <wumpus> ok...
 684 2016-04-14T19:09:02  <wumpus> next topic?
 685 2016-04-14T19:09:13  <jonasschnelli> [21:05:02]  <sipa>	topic suggestion: segwit and backports
 686 2016-04-14T19:09:17  <btcdrak> segwit backports
 687 2016-04-14T19:09:28  <wumpus> #topic segwit and backports
 688 2016-04-14T19:09:42  <sipa> so, segwit branch is currently on top of 0.12.1
 689 2016-04-14T19:09:43  *** arowser has joined #bitcoin-core-dev
 690 2016-04-14T19:10:04  <btcdrak> so you'd be forward porting it to master
 691 2016-04-14T19:10:13  <sipa> with a set of backports from master and some PRs first
 692 2016-04-14T19:10:37  <Luke-Jr> it would be ideal if the same branch can merge into both 0.12 and master, but that seems unlikely for segwit
 693 2016-04-14T19:10:40  <sipa> i don't know what the best way forward is, but i think we're close to PRing it for bitcoin
 694 2016-04-14T19:10:40  <gmaxwell> FWIW on the other implementations front, btcd has what looks like a more or less complete implementation of the consensus changes for segwit and is interoperating with segnet4.
 695 2016-04-14T19:10:53  <Luke-Jr> gmaxwell: nice!
 696 2016-04-14T19:11:13  <cfields> sipa: woohoo!
 697 2016-04-14T19:11:28  <wumpus> gmaxwell:  "and then having binary days delayed is suboptimal." why don't you ever gitian-build? :p
 698 2016-04-14T19:11:35  <sipa> do we rebase on master, have that merged first, and then "magically" come up with a 0.12 backport? :D
 699 2016-04-14T19:11:49  <sipa> which happens to include the necessary backports
 700 2016-04-14T19:11:49  <btcdrak> sipa: I hear you are good at magic
 701 2016-04-14T19:12:01  <Luke-Jr> sipa: what's the current segwit branch?
 702 2016-04-14T19:12:05  <Luke-Jr> without segnet ideally
 703 2016-04-14T19:12:34  <sipa> Luke-Jr: segwit4 and segwit (the first is where i continuously rebase, the second i push to whenever there is something significant)
 704 2016-04-14T19:12:36  <wumpus> the reason for the delay is that a certian minimum threshold of number of people have to build it, submit signatures, etc., the only way to speed it up wouldb e if people build it quicker, although it's already lots faster than it used to be
 705 2016-04-14T19:12:53  <sipa> Luke-Jr: they have segnet, though the commits for segnet are separate and can easily be skipped
 706 2016-04-14T19:13:17  <gmaxwell> wumpus: if you'd like me to do so, I will. (re gitian builds)
 707 2016-04-14T19:13:28  <sipa> that's anohter question: do we merge segnet?
 708 2016-04-14T19:13:36  <btcdrak> gmaxwell: yes please.
 709 2016-04-14T19:13:42  <wumpus> gmaxwell: I dont mind, but please don't complain if you're not involved okay :)
 710 2016-04-14T19:13:55  <btcdrak> sipa: do we really need segnet?
 711 2016-04-14T19:14:00  <sipa> btcdrak: i don't think so
 712 2016-04-14T19:14:07  <morcos> This might sound crazy, but I'd be in favor of merging the segwit PR very quickly.  I think we should make the PR's for master and 0.12 at roughly the same time.  And then we should all bust our ass to review them at roughly the same time.
 713 2016-04-14T19:14:22  <sipa> that sounds fine to me
 714 2016-04-14T19:14:28  <morcos> If they are outstanding for a while, then we'll all be reviewing different code as its rebased or merge conflicts are addressed or whatever
 715 2016-04-14T19:14:33  <btcdrak> morcos: no complaints
 716 2016-04-14T19:14:36  <morcos> We should just rip the bandaid off and get it in
 717 2016-04-14T19:14:39  <gmaxwell> wumpus: my complaint wasn't about any of the people, for sure. if it were, I'd just build. Also, it wasn't really a complaint with anything we're doing. It's a complaint that the community prereleases our releases, but we can't stop that; so the best fix is to reduce latency, I think.
 718 2016-04-14T19:14:59  <morcos> And then every other PR out there can get conflicted once and be done with it
 719 2016-04-14T19:15:02  <btcdrak> in all fairness there has been so much testing and peer review and help from downstream consumers with segwit.
 720 2016-04-14T19:15:16  <sipa> ok, will PR soon
 721 2016-04-14T19:15:29  <jonasschnelli> A quick merge sound good. Also, nobody can complain we haven gave any change for review because there is already an open pr since weeks/month.
 722 2016-04-14T19:15:31  <sipa> both master and 0.12
 723 2016-04-14T19:15:39  <btcdrak> super. jonasschnelli you should close your preview PR so it doesnt get confusing
 724 2016-04-14T19:15:43  <gmaxwell> I've felt bad about working on 0.13 in areas that I know will need to be tweaked for segwit, so I can agree with that. As soon as 0.12 is tagged this could be done. If we end up needing a 0.12.2 without segwit we could branch 0.12 pre-segwit.
 725 2016-04-14T19:16:07  <jonasschnelli> Yes. Will close. Its pointing also to the wrong branch.
 726 2016-04-14T19:16:24  <btcdrak> gmaxwell: maybe we dont need to over complicate if the PR/backport will come soon.
 727 2016-04-14T19:16:30  *** brg444 has joined #bitcoin-core-dev
 728 2016-04-14T19:16:32  *** johnwhitton has quit IRC
 729 2016-04-14T19:18:19  <morcos> My main point is that it is goign to be a lot of work to adequeately review and test segwit.  It'll be more efficient use of everyones time if we concentrate that effort at the same time.
 730 2016-04-14T19:18:29  <sipa> that makes sense
 731 2016-04-14T19:20:19  <sipa> any other topics?
 732 2016-04-14T19:20:34  <wumpus> what about c++11 status?
 733 2016-04-14T19:20:39  <sipa> ack
 734 2016-04-14T19:20:47  <wumpus> #topic c++11 status
 735 2016-04-14T19:20:55  * sipa summons cfields
 736 2016-04-14T19:21:16  <cfields> wumpus: travis has enabled caching but only for flagged projects. I mailed this morning and asked for the flag.
 737 2016-04-14T19:21:34  <sipa> cfields: is that the final blocker?
 738 2016-04-14T19:21:43  <cfields> sipa: as far as i know, yes
 739 2016-04-14T19:21:47  <sipa> awesome
 740 2016-04-14T19:21:53  <wumpus> that was already the case right? open source projects needed a flag to support caching. But we need a new one now?
 741 2016-04-14T19:22:01  *** Schlorted has quit IRC
 742 2016-04-14T19:22:06  <wumpus> hopefully theyll give it :)
 743 2016-04-14T19:22:07  <cfields> wumpus: no, for trusty
 744 2016-04-14T19:22:08  <cfields> sec..
 745 2016-04-14T19:22:46  <cfields> https://github.com/travis-ci/travis-scheduler/pull/14
 746 2016-04-14T19:23:07  <cfields> merged last week
 747 2016-04-14T19:23:32  *** johnwhitton has joined #bitcoin-core-dev
 748 2016-04-14T19:23:33  <wumpus> great!
 749 2016-04-14T19:23:47  <sipa> how do we plan to proceed after that?
 750 2016-04-14T19:23:50  <wumpus> hopefully we can start supporting it this week then
 751 2016-04-14T19:23:56  <gmaxwell> would we be using C++11 in 0.13 then?
 752 2016-04-14T19:24:05  <cfields> if there's a delay with this step, I'm completely ok with saying "screw it" and disabling whatever we need so that we can limp along until it's not blocking anymore
 753 2016-04-14T19:24:32  <wumpus> gmaxwell: that was the plan
 754 2016-04-14T19:24:33  <Luke-Jr> Travis is not willing to flag just any projects. We should try to avoid relying on it.
 755 2016-04-14T19:24:40  <gmaxwell> wumpus: good. :)
 756 2016-04-14T19:24:43  <cfields> so, I've been hacking on c++11 on a branch of mine for a while. One thing that's clear is that we need a policy on what modernizations we'll allow...
 757 2016-04-14T19:25:00  <cfields> otherwise, I'm afraid it'll be endless PRs
 758 2016-04-14T19:25:10  <cfields> Luke-Jr: it's just a flag while it's in testing
 759 2016-04-14T19:25:10  <sipa> cfields: there are a couple of mechanic translations i think we'll want ayt some point
 760 2016-04-14T19:25:21  <wumpus> I created this in december, a bit optimistic maybe, but five months later :) https://github.com/bitcoin/bitcoin/pull/7165
 761 2016-04-14T19:25:39  <gmaxwell> We should keep modernization PRs slow initially. Then do the mechanical updates (e.g. replace boost with C++11).. and only after go back and make more changes.
 762 2016-04-14T19:25:49  <gmaxwell> at least thats my intuition.
 763 2016-04-14T19:25:50  <sipa> cfields: BOOST_FOREACH and boost::thread are good examples
 764 2016-04-14T19:25:56  <wumpus> replacing boost is far from mechanical
 765 2016-04-14T19:26:00  <wumpus> well ok some parts
 766 2016-04-14T19:26:10  <cfields> sipa: yes, for sure. what I worry about it thousands of PRs that sprinkle in std::move all over the place.
 767 2016-04-14T19:26:16  <morcos> is there any downside to using c++11 in new code while not yet doing any modernization PR's?
 768 2016-04-14T19:26:16  <sipa> but for example: adding move constructors instead of swaps everywhere
 769 2016-04-14T19:26:17  <gmaxwell> in particular I think it's probably unwise to do many moderinization updates when non C++11 versions are still supported.
 770 2016-04-14T19:26:20  <Luke-Jr> someone remind me why are we not doing a release that fails with C++11 at configure, before actually introducing C++11 code?
 771 2016-04-14T19:26:23  <cfields> (and emplace, which would be significant in several places)
 772 2016-04-14T19:26:25  <BlueMatt> Start with only new code is C++11, then only boost-replacement, then revisit
 773 2016-04-14T19:26:26  <BlueMatt> ?
 774 2016-04-14T19:26:29  <gmaxwell> because that would vastly complicate backports.
 775 2016-04-14T19:26:41  <sipa> one option is building with c++11 and c++03 both for a while
 776 2016-04-14T19:26:44  <morcos> I would say we have a lot on our plate in the next couple months, and we should just say no modernaization right now.  (sounds like what BlueMatt said)
 777 2016-04-14T19:26:46  <wumpus> meh
 778 2016-04-14T19:26:47  <cfields> morcos: i think that would be my preference
 779 2016-04-14T19:26:56  <wumpus> we can already build with c++11 for quite a while, that's nothing new
 780 2016-04-14T19:27:12  <sipa> ok
 781 2016-04-14T19:27:25  <sipa> just not too actively replace things initially
 782 2016-04-14T19:27:42  <BlueMatt> I mean for 0.13 Id say dont actively replace anything unless its a big performance win
 783 2016-04-14T19:27:43  <Luke-Jr> at the very least, let's add something to configure that fails if C++11 is not supported?
 784 2016-04-14T19:27:49  <wumpus> we've never let refactors through too quickly
 785 2016-04-14T19:27:54  <wumpus> correctness is most imporant
 786 2016-04-14T19:28:02  <Luke-Jr> that way we get user reports
 787 2016-04-14T19:28:03  <gmaxwell> Matt has an upcoming PR that uses C++11 that it might be nice to not have to port to C++03.
 788 2016-04-14T19:28:07  <wumpus> Luke-Jr: yes, see the pull I quoted
 789 2016-04-14T19:28:20  <wumpus> Luke-Jr: it fails without c++11 support
 790 2016-04-14T19:28:21  <BlueMatt> gmaxwell: for the tcp stuff I think it actually doesnt matter, I was just lazy...udp would be annoying to fix, I think
 791 2016-04-14T19:28:28  <cfields> wumpus: let's use a real example.. adding move ctors to our containers
 792 2016-04-14T19:28:31  <cfields> yea or nay?
 793 2016-04-14T19:28:39  <sipa> cfields: yay, please... but maybe not immediately
 794 2016-04-14T19:28:49  <BlueMatt> cfields: for 0.13, I'd vote only new code, maybe boost replacement, too
 795 2016-04-14T19:28:57  <wumpus> cfields: if it helps performance, absolute yay
 796 2016-04-14T19:28:58  *** kangx has joined #bitcoin-core-dev
 797 2016-04-14T19:28:59  <sipa> (prevector specifically is unsafe to use for more complex types now)
 798 2016-04-14T19:29:07  <BlueMatt> but I'm always the annoyingly conservative one, sooooo
 799 2016-04-14T19:29:11  *** slackircbridge has joined #bitcoin-core-dev
 800 2016-04-14T19:29:11  <wumpus> boost replacement is too late for 0.13
 801 2016-04-14T19:29:15  <sipa> wumpus: agree
 802 2016-04-14T19:29:15  <wumpus> too much work
 803 2016-04-14T19:29:29  <BlueMatt> wumpus: ehh, I meant partial-boost-replacement
 804 2016-04-14T19:29:32  <wumpus> we can do some minor things and use it in new code, but aiming to replace boost enitrely just won't work
 805 2016-04-14T19:29:38  <gmaxwell> New code +1, especially new features, but as I mentioned, I think we should avoid making backports to 0.12 harder while 0.12 is still supported.
 806 2016-04-14T19:29:44  <sipa> just turning on c++11 may already give a performance improvement, because STL magically gets move constructors
 807 2016-04-14T19:30:01  <jonasschnelli> At least we could throw out boost::filesystem soon (there is no c++11 equivalent).
 808 2016-04-14T19:30:05  <wumpus> to me it seems we want to backport so much to 0.12 it is starting to make more sense to do 0.13 sooner
 809 2016-04-14T19:30:09  <wumpus> do a release from master
 810 2016-04-14T19:30:21  <wumpus> may work better with cfields' holiday too
 811 2016-04-14T19:30:32  <morcos> wumpus: but then not release segwit for 0.12?
 812 2016-04-14T19:30:40  <cfields> stupid inconvenient honeymoon...
 813 2016-04-14T19:30:49  <morcos> thats the issue right..  are we only going to support it on 0.13?
 814 2016-04-14T19:30:50  <sipa> cfields: priorities!
 815 2016-04-14T19:30:54  <jonasschnelli> heh!
 816 2016-04-14T19:30:56  <gmaxwell> morcos: I don't think we should do that.
 817 2016-04-14T19:30:59  <sipa> i think we should backport segwit to 0.12
 818 2016-04-14T19:31:03  <wumpus> (we have to change the release schedule a bit anyway)
 819 2016-04-14T19:31:08  <sipa> let's not push users too much
 820 2016-04-14T19:31:24  <btcdrak> if we release 0.13 we still have to backport to 0.12
 821 2016-04-14T19:31:34  <btcdrak> since we support this and prev version
 822 2016-04-14T19:31:36  <gmaxwell> wumpus: what kind of schedule change are you thinking of?
 823 2016-04-14T19:32:42  <gmaxwell> Can we talk about what notable features are still in flight that people are working on with an intent of targeting 0.13?
 824 2016-04-14T19:32:44  <btcdrak> maybe backport to 0.12 and release 0.13 early.
 825 2016-04-14T19:33:14  <morcos> whats the hurry to release 0.13 early in that case?
 826 2016-04-14T19:33:15  <wumpus> yes was a bad idea
 827 2016-04-14T19:33:19  <btcdrak> This is the list of 0.13 milestones https://github.com/bitcoin/bitcoin/milestones/0.13.0
 828 2016-04-14T19:33:19  <wumpus> ntext topic
 829 2016-04-14T19:33:21  <phantomcircuit> jonasschnelli: was that benchmark of leveldb vs lmdb on a system with a hdd or ssd?
 830 2016-04-14T19:33:32  <jonasschnelli> ssd
 831 2016-04-14T19:33:40  <phantomcircuit> interesting
 832 2016-04-14T19:33:52  <jonasschnelli> (can be discussed after the meeting)
 833 2016-04-14T19:34:15  <gmaxwell> btcdrak: there are things people are working on that aren't PRs yet.
 834 2016-04-14T19:34:18  <Luke-Jr> gmaxwell: I'd like to rework the config/arg stuff, but I don't know I'll have time to finish it before 0.13 forks
 835 2016-04-14T19:34:43  <BlueMatt> wumpus: next topic? we didnt really come to a conclusion at all here yet? what is the release schedule for 0.13 looking like, and does that mesh with turning on C++11 and allowing new code to use it?
 836 2016-04-14T19:35:00  <Luke-Jr> (and there's no reason it can't wait for 0.14 etc)
 837 2016-04-14T19:35:07  <wumpus> well the change we have to make in the 0.13 release schedule is to clear june - this works btter for cfields
 838 2016-04-14T19:35:29  <wumpus> but we can just as well postpone it to later, moving it ealier was just a stupid idea
 839 2016-04-14T19:35:36  <cfields> no reason to change just for me?
 840 2016-04-14T19:35:47  <btcdrak> oh just a note regarding ctaes, independent review is in progress from one of Matthew Green's graduates, hopefully available in a couple of weeks.
 841 2016-04-14T19:35:51  <wumpus> well the rc cycle was exactly planned that
 842 2016-04-14T19:35:56  <wumpus> then*
 843 2016-04-14T19:36:03  <gmaxwell> wumpus: I dunno that its stupid. But it should be made with consideration.
 844 2016-04-14T19:36:07  <wumpus> can do that in july instead of june , no problem
 845 2016-04-14T19:36:14  <morcos> gmaxwell: yes, i'm working on 2 things that might be nice to get in.  an improvement to fee estimation and some measurement of policy alignment.  they are goign to be annoying for anyone to review, but they also stand alone.
 846 2016-04-14T19:36:37  <wumpus> BlueMatt: release schedule 0.13: https://github.com/bitcoin/bitcoin/issues/7679
 847 2016-04-14T19:36:37  <gmaxwell> BlueMatt: C++11 is getting turned on, in a week barring emergencies if I understood above. And it sounded like new things could use it, but we'd avoid going and refactoring for more until 0.14.
 848 2016-04-14T19:36:40  <morcos> wumpus: yes i like the idea of pushing back 0.13 a bit
 849 2016-04-14T19:36:48  <sipa> gmaxwell: ack
 850 2016-04-14T19:36:49  <BlueMatt> gmaxwell: ACK
 851 2016-04-14T19:36:55  *** lclc has quit IRC
 852 2016-04-14T19:37:13  <jonasschnelli> Features I'd like to see in 0.13: wallet/RBF (+GUI), simple profiles (maybe GUI only), BIP32 (probably not in 0.13 because of lack of review)
 853 2016-04-14T19:37:15  <sdaftuar> regarding 0.13, i thought it might make sense to push the freature freeze back slightly, since there's a meetup happening in zurich a week afterward that many of us would be at
 854 2016-04-14T19:37:17  <BlueMatt> wumpus: ok, so release schedule stays as-is for now?
 855 2016-04-14T19:37:29  <wumpus> BlueMatt: I proposed moving the rc phase to july instead of june
 856 2016-04-14T19:37:33  <jonasschnelli> sdaftuar: good point.
 857 2016-04-14T19:37:34  <Luke-Jr> in talking about using C++11, we won't need GCC 5, right?
 858 2016-04-14T19:37:44  <Luke-Jr> because GCC 5 is not really a reasonable minimum yet
 859 2016-04-14T19:37:44  <BlueMatt> when does cfields gete back?
 860 2016-04-14T19:37:53  <morcos> wumpus: ack
 861 2016-04-14T19:37:59  <cfields> Luke-Jr: 4.8 should be fine, i think
 862 2016-04-14T19:38:02  <wumpus> no, we don't need gcc5, the features we should use of c++11 shoudl work in gcc4.8+
 863 2016-04-14T19:38:02  <Luke-Jr> k
 864 2016-04-14T19:38:05  <sipa> Luke-Jr: i believe (but cfields correct me) that the features from c++11 we'd want are almost entirely support in 4.8
 865 2016-04-14T19:38:11  <wumpus> otherwise we can't use trusty for building
 866 2016-04-14T19:38:18  <cfields> BlueMatt: july4ish
 867 2016-04-14T19:38:20  <wumpus> and that's the whole point
 868 2016-04-14T19:38:35  <sipa> that's clear, thank you
 869 2016-04-14T19:39:05  <cfields> BlueMatt: if it turns out to be too problematic, i can revisit the dates.
 870 2016-04-14T19:39:20  <gmaxwell> Luke-Jr: C++11 is fully supported in 4.9, and 4.8 has basically everything. I think we could reference 4.8 for compatibility.
 871 2016-04-14T19:39:22  <BlueMatt> cfields: lol, dont change honeymoon for us
 872 2016-04-14T19:39:23  <wumpus> cfields: no
 873 2016-04-14T19:39:27  <gmaxwell> Luke-Jr: https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
 874 2016-04-14T19:39:28  <morcos> cfields: you better hope your fiance doesnt read these logs
 875 2016-04-14T19:39:38  <jonasschnelli> haha
 876 2016-04-14T19:40:02  *** muuqwaul has quit IRC
 877 2016-04-14T19:40:13  <cfields> heh
 878 2016-04-14T19:40:26  *** muuqwaul has joined #bitcoin-core-dev
 879 2016-04-14T19:40:36  <BlueMatt> wumpus: ACK pushing 0.13 a month...gives a week or two for post-zurich things to make the feature freeze
 880 2016-04-14T19:40:38  <wumpus> sdaftuar: if we move the rc phase a month we can move the feature freeze with the same amount
 881 2016-04-14T19:40:48  <BlueMatt> wumpus: eg things that get reviewed in zurich can be cleaned up and merged before freeze
 882 2016-04-14T19:40:51  <wumpus> BlueMatt: right
 883 2016-04-14T19:40:52  <sdaftuar> wumpus: sounds good to me
 884 2016-04-14T19:41:01  <BlueMatt> ACKs on pushing a month?
 885 2016-04-14T19:41:06  <btcdrak> ACK
 886 2016-04-14T19:41:11  <wumpus> ack
 887 2016-04-14T19:41:12  <jonasschnelli> ack
 888 2016-04-14T19:41:14  <gmaxwell> ok
 889 2016-04-14T19:41:14  <Luke-Jr> I don't see any resolution to C++11's ABI issues in the github tracker - did that get resolved?
 890 2016-04-14T19:41:15  <morcos> ACK
 891 2016-04-14T19:41:29  * Luke-Jr not care on 0.13 schedule
 892 2016-04-14T19:41:33  *** lclc has joined #bitcoin-core-dev
 893 2016-04-14T19:42:05  <wumpus> #action move 0.13 schedule a month forward
 894 2016-04-14T19:42:39  <cfields> Luke-Jr: what issues?
 895 2016-04-14T19:42:40  *** johnwhitton has quit IRC
 896 2016-04-14T19:42:41  <sipa> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/7165#issuecomment-165499462
 897 2016-04-14T19:42:52  <sipa> all known ABI issues result in link errors
 898 2016-04-14T19:43:05  <cfields> for that matter, gcc6 will build with c++14 by default. So either way (maybe even for 0.12 backport), we need to specify the standard we're using.
 899 2016-04-14T19:43:31  <wumpus> hah, c++14
 900 2016-04-14T19:43:34  <gmaxwell> As far as other in-flight stuff, Matt has implemented efficient block relay; related to a design I've been circulating for a long while.  He has code up, and it works pretty well.. I get about a 96% reduction in block bandwidth. The protocol needs a few tweaks still but once in, it should be able to send the vast majority of blocks in 0.5 round-trip times (plus whatever awful overhead TCP adds),
 901 2016-04-14T19:43:39  <wumpus> not looking forward to going through this again :(
 902 2016-04-14T19:43:40  <gmaxwell>  the rest will need 1.5 RTT. I've started on a BIP. Matt has also been working on some other things that go further and eliminate even more latency, though that work is likely only going to be interesting to miners.
 903 2016-04-14T19:44:22  <BlueMatt> I think gmaxwell is more excited about tcp-smaller-block relay since his internet at home sucks
 904 2016-04-14T19:44:27  <gmaxwell> I think with segwit upcoming I'd really like to see that work make its way into 0.13, since we really need propagation time mitigations, and the relay network client only goes so far.
 905 2016-04-14T19:44:27  <cfields> nice
 906 2016-04-14T19:44:33  <cfields> BlueMatt: you have a branch somewhere?
 907 2016-04-14T19:44:39  <BlueMatt> I see it more as foundational work that is useful for compression on the wire, but is primarily for udp-based relay which is nice and fast :)
 908 2016-04-14T19:45:02  <BlueMatt> cfields: simple tcp stuff at https://github.com/TheBlueMatt/bitcoin/commits/udp, udp-based stuff which hasnt been fully rebased on top at https://github.com/TheBlueMatt/bitcoin/commits/udp-wip
 909 2016-04-14T19:45:21  <wumpus> cfields: how does it make sense that they will build with c++14 by default?!
 910 2016-04-14T19:45:44  <BlueMatt> tcp stuff is close to ready with one or two stubs to be replaced, pr next week when I'm off vacation, udp stuff is a bit longer-term
 911 2016-04-14T19:45:48  <cfields> wumpus: i suppose because it should all be forward compat, in theory
 912 2016-04-14T19:45:50  <sipa> wumpus: i think c++14 has less impact on standard libraries
 913 2016-04-14T19:45:50  <cfields> BlueMatt: thanks
 914 2016-04-14T19:46:09  <sipa> and is much more incremental than c++11 was
 915 2016-04-14T19:46:09  <BlueMatt> cfields: if you want to tackle the udp-wip changing to libevent I'd owe you :)
 916 2016-04-14T19:46:12  <cfields> yes, c++14 as i see it is kinda a c++11 fixup
 917 2016-04-14T19:46:23  <wumpus> ok...
 918 2016-04-14T19:46:30  <Luke-Jr> cfields: IIRC, binaries (incl libraries) compiled with C++11 mode are incomptible with libraries compiled with C++98 mode.
 919 2016-04-14T19:46:36  <sipa> c++14 finally has a solution for the exponentially-sized error messages
 920 2016-04-14T19:46:37  <Luke-Jr> sipa: ok
 921 2016-04-14T19:46:57  <cfields> Luke-Jr: that has nothing to do with how we compile though. That'll be the case either way.
 922 2016-04-14T19:47:00  <gmaxwell> BlueMatt: mostly trying to avoid bleeding out over load increases permitted by segwit. :)
 923 2016-04-14T19:47:06  <wumpus> sipa: nice!
 924 2016-04-14T19:47:13  <cfields> BlueMatt: heh yes, we should sync up some
 925 2016-04-14T19:47:24  *** johnwhitton has joined #bitcoin-core-dev
 926 2016-04-14T19:47:34  <Luke-Jr> cfields: ? our dependencies are compiled with C++98 in almost all cases today
 927 2016-04-14T19:47:37  <wumpus> anyhow any other meeting topics?
 928 2016-04-14T19:47:49  <kanzure> MAST bip status?
 929 2016-04-14T19:48:06  <gmaxwell> lol. way too premature for discussion here.
 930 2016-04-14T19:48:13  <btcdrak> kanzure: it got published BIP114
 931 2016-04-14T19:48:18  <cfields> Luke-Jr: yes, and they'll be switched to c++11 for the ones we build. Otherwise it's a cointoss what users have on their systems, sticking with c++03 could be equally incompatible for them.
 932 2016-04-14T19:48:19  <wumpus> Luke-Jr: cfields let's leave the small implementation details about the c++11 switch to after the meeting
 933 2016-04-14T19:48:27  <cfields> ack
 934 2016-04-14T19:48:36  <Luke-Jr> cfields: we do not build our dependencies typically.
 935 2016-04-14T19:48:49  <Luke-Jr> wumpus: k
 936 2016-04-14T19:49:03  <wumpus> I'm sure we'll get it to work somehow
 937 2016-04-14T19:49:31  <wumpus> #topic MAST bip status
 938 2016-04-14T19:49:44  <kanzure> no no, it was sufficiently NACKed
 939 2016-04-14T19:49:59  <sipa> i haven't looked at it yet
 940 2016-04-14T19:50:17  <instagibbs> https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki < fwiw
 941 2016-04-14T19:50:30  <wumpus> #link https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
 942 2016-04-14T19:51:43  <Luke-Jr> possible topic?: using SHA256d for segwit
 943 2016-04-14T19:52:15  *** johnwhitton has quit IRC
 944 2016-04-14T19:52:30  <wumpus> sha256d?
 945 2016-04-14T19:52:33  <sipa> Luke-Jr: i'd rather not break all tests and downstream code that was written yet... though we'll want new segwit script versions soon, and they can use sha256d hashing
 946 2016-04-14T19:53:04  <sipa> wumpus: background: p2wsh scriptPubKeys contain a SHA256 (not double SHA256) of the witness program
 947 2016-04-14T19:53:09  <paveljanik> double sha256
 948 2016-04-14T19:53:26  <sipa> which is incompatible with the "P2SH^2" scheme that greg proposed a while ago
 949 2016-04-14T19:53:35  <wumpus> oh right
 950 2016-04-14T19:53:43  <wumpus> it would be consistent
 951 2016-04-14T19:53:47  <gmaxwell> The only advantage of it that I'm aware of is the p2sh^2 trick which would need new address types and such to ever get used. Disadvantage is that its slow.
 952 2016-04-14T19:54:00  *** johnwhitton has joined #bitcoin-core-dev
 953 2016-04-14T19:54:12  <gmaxwell> And consistency, I suppose.
 954 2016-04-14T19:54:15  <sipa> ... which interacts with the discussion of addresses for native segwit
 955 2016-04-14T19:54:17  <Luke-Jr> gmaxwell: there's no address types for bare segwit yet
 956 2016-04-14T19:54:36  <sipa> Luke-Jr: i do plan on proposing one
 957 2016-04-14T19:54:41  <sipa> (though not immediately)
 958 2016-04-14T19:54:59  <Luke-Jr> yes, my point is that we have an opportunity to avoid breaking compatibility
 959 2016-04-14T19:55:11  <gmaxwell> we'd purposefully moved them out to avoid shedpainting and address-type-deployment issues from harming segwit consensus code deployment.
 960 2016-04-14T19:55:44  <phantomcircuit> gmaxwell: sha256d also prevents length extention attacks although i dont see how that's applicable here at all
 961 2016-04-14T19:55:49  <gmaxwell> Luke-Jr: I think that nativesegwit of that initial type is not likely to see long term use, see also that MAST bip.
 962 2016-04-14T19:55:56  <Luke-Jr> sipa: am I incorrect in assuming adjusting downstream code for this would be super trivial?
 963 2016-04-14T19:56:26  <sipa> Luke-Jr: probably, but we also don't have a way to deploy P2SH^2 easily
 964 2016-04-14T19:56:27  *** johnwhitton has quit IRC
 965 2016-04-14T19:56:32  <Luke-Jr> gmaxwell: yes, but I think sipa wants an address format that works for all segwit outputs, regardless of version
 966 2016-04-14T19:56:59  *** d_t has joined #bitcoin-core-dev
 967 2016-04-14T19:57:00  <Luke-Jr> sipa: that's not something we need to bundle with making it possible
 968 2016-04-14T19:57:37  <gmaxwell> we should close the meeting and continue the discussion.
 969 2016-04-14T19:57:40  <sipa> ok
 970 2016-04-14T19:57:46  <gmaxwell> no resolution to this will happen this instant.
 971 2016-04-14T19:58:04  *** johnwhitton has joined #bitcoin-core-dev
 972 2016-04-14T19:58:51  <sipa> #shutdown -h now meeting
 973 2016-04-14T19:59:04  <jonasschnelli> sudo!
 974 2016-04-14T19:59:08  <wumpus> #endmeeting
 975 2016-04-14T19:59:09  <lightningbot> Meeting ended Thu Apr 14 19:59:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 976 2016-04-14T19:59:09  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.html
 977 2016-04-14T19:59:09  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.txt
 978 2016-04-14T19:59:09  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.log.html
 979 2016-04-14T19:59:28  <paveljanik> jonasschnelli, no need for sudo once you have # ;-)
 980 2016-04-14T19:59:48  *** mrkent has joined #bitcoin-core-dev
 981 2016-04-14T19:59:50  <jonasschnelli> nerds! oO
 982 2016-04-14T19:59:52  *** johnwhitton has quit IRC
 983 2016-04-14T19:59:55  <jtimon> meeting?
 984 2016-04-14T19:59:55  <gmaxwell> So, wrt p2sh^2. That got proposed eons ago and I think it's unlikely to ever get implemented.
 985 2016-04-14T20:00:00  <jonasschnelli> jtimon: hahaha
 986 2016-04-14T20:00:01  <gmaxwell> jtimon: an hour ago.
 987 2016-04-14T20:00:18  <jtimon> oh...
 988 2016-04-14T20:00:27  <phantomcircuit> timezones strike again
 989 2016-04-14T20:00:31  <jtimon> well, read the logs I guess
 990 2016-04-14T20:00:33  <btcdrak> jtimons needs to run an ntp daemon
 991 2016-04-14T20:00:33  <kanzure> this is why we should abolish time zones
 992 2016-04-14T20:00:37  <Luke-Jr> gmaxwell: isn't the only major hold-up the backward compat issue?
 993 2016-04-14T20:00:46  <Luke-Jr> kanzure: tonal time! :D
 994 2016-04-14T20:00:55  <kanzure> i would be willing to accept tonal time if it means no more time zones
 995 2016-04-14T20:00:55  <paveljanik> meeting bot should be modified to ping people beforehand :-)
 996 2016-04-14T20:00:58  <jonasschnelli> jtimon: I can add a cron job that sends you a PM 10mins before the meeting? But people where using alarm-clock back in the "old days". :)
 997 2016-04-14T20:01:02  <gmaxwell> Luke-Jr: no, well it requires yet another kind of witness data in transactions.
 998 2016-04-14T20:01:03  <sipa> Luke-Jr: plus that it's easily bypassable, and we could end up encouraging people to send to miners directly
 999 2016-04-14T20:01:23  <jtimon> phantomcircuit: I would share last week it was a 22:00, but it may may that I forgot about my last mistake
1000 2016-04-14T20:01:25  <Luke-Jr> gmaxwell: that's pretty simple now with segwit
1001 2016-04-14T20:01:34  *** johnwhitton has joined #bitcoin-core-dev
1002 2016-04-14T20:01:34  <gmaxwell> the pairing crypto based scheme I came up with didn't have those issues but it's slow.
1003 2016-04-14T20:01:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1004 2016-04-14T20:01:38  <jtimon> jonasschnelli: that would be indeed useful
1005 2016-04-14T20:01:42  <Luke-Jr> sipa: that assumes miners are willing to cooperate in the spam
1006 2016-04-14T20:01:44  <Luke-Jr> actively
1007 2016-04-14T20:01:59  <sipa> Luke-Jr: why wouldn't they, if people want to pay
1008 2016-04-14T20:02:03  <Luke-Jr> at the very least, such miners would likely opt to charge higher fees (I hope)
1009 2016-04-14T20:02:42  <jtimon> never mind much, I will eventually adapt to this without putting it in google calendar, you'll see
1010 2016-04-14T20:02:57  <sipa> p2sh^2 is also incompatible with forward compatible address types
1011 2016-04-14T20:03:14  <gmaxwell> sipa: I dunno, thats kind of an argument against any non-stanardness. Dust limits have been effective.
1012 2016-04-14T20:03:23  <sipa> gmaxwell: fair enough
1013 2016-04-14T20:03:29  <Luke-Jr> not necessarily? if all future address types are p2sh^2
1014 2016-04-14T20:03:29  <gmaxwell> But yes, it would be incompatible with address types that change the top hashing scheme.
1015 2016-04-14T20:03:36  <wumpus> jtimon: date -u , if it shows thursday 19:00-20:00 it's time for the meeting :)
1016 2016-04-14T20:04:04  <sipa> Luke-Jr: i guess if we stick to 1) there is some scheme below that results in 32-byte data 2) on top of that there is single SHA256
1017 2016-04-14T20:04:10  <sipa> then it can be compatible
1018 2016-04-14T20:04:10  <Luke-Jr> we tried a one-size-fits-all address type for p2sh, and that failed with segwit. I'm not sure it's possible to make future-proof here really.
1019 2016-04-14T20:04:30  <gmaxwell> No but we can be a bit more future robust than p2sh was.
1020 2016-04-14T20:04:49  <gmaxwell> There is a greater archectural question around the pace of script changes.
1021 2016-04-14T20:04:52  *** ebfull has quit IRC
1022 2016-04-14T20:05:24  <gmaxwell> If there are a lot of little script changes that do nothing other than add OP_SWEETANDSOURCHECKSIG then its essential there be an address type that automagically covers them.
1023 2016-04-14T20:05:28  *** ebfull has joined #bitcoin-core-dev
1024 2016-04-14T20:05:54  <CodeShark> how is simply encoding the scriptPubKey not fully general?
1025 2016-04-14T20:06:04  <sipa> CodeShark: it doesn't cover P2SH^2
1026 2016-04-14T20:06:11  <Luke-Jr> gmaxwell: hopefully all scripts will be inside the witness
1027 2016-04-14T20:06:15  <sipa> CodeShark: but apary from that, yes
1028 2016-04-14T20:06:24  <sipa> Luke-Jr: the witness version number needs to be outside
1029 2016-04-14T20:06:27  <CodeShark> what's P2SH^2?
1030 2016-04-14T20:06:34  <Luke-Jr> kanzure: btw
1031 2016-04-14T20:06:54  <Luke-Jr> sipa: yes, but that doesn't interfere with p2sh^2
1032 2016-04-14T20:07:10  <sipa> CodeShark: you have an address that encodes SHA256(script), and the output contains SHA256(SHA256(script))... but for relay you're required to also provide SHA256(script) (which does not go into blocks, however)
1033 2016-04-14T20:07:12  <instagibbs> can we get the post on p2sh^2? I read it like 3 years ago, forgot the details
1034 2016-04-14T20:07:26  <instagibbs> oh ok
1035 2016-04-14T20:07:37  <sipa> CodeShark: this guarantees that the data in the output is a hash, and not data storage
1036 2016-04-14T20:08:08  <gmaxwell> CodeShark: and also makes it somewhat harder to just send funds to random "addresses" culled from the blockchain (you need the preimage side information).
1037 2016-04-14T20:08:24  <gmaxwell> A practice which is a major accounting nusance for many parties.
1038 2016-04-14T20:08:47  <sipa> b.i will of course publish all the preimages they see in the network
1039 2016-04-14T20:08:49  <CodeShark> so no more shakespeare in the blockchain? :( https://www.smartbit.com.au/tx/8f64d2b7a762767e3870c4aee95f8c7b5439cf02cf7d7e5d99b6e39967ecada8
1040 2016-04-14T20:08:51  <sipa> *ducks*
1041 2016-04-14T20:09:18  <gmaxwell> CodeShark: not in the UTXO set, of course that stuff could still end up in witnesses.
1042 2016-04-14T20:09:26  <instagibbs> sipa, sigh, you are of course correct
1043 2016-04-14T20:09:39  <instagibbs> or just captured by sybil anti-laundering services
1044 2016-04-14T20:09:50  <gmaxwell> sipa: I wouldn't be so sure.
1045 2016-04-14T20:09:53  *** cguida has quit IRC
1046 2016-04-14T20:10:27  <sipa> there is also a minor downside to using sha256^2 for script hashes, namely that it means wallet needs to maintain two indexes for scripts (one for p2sh, one for p2wsh, because their hashes are not compatible)
1047 2016-04-14T20:10:51  <sipa> very minor, and possibly something that can't be maintained for future witness script version anyway
1048 2016-04-14T20:10:53  <Luke-Jr> nah, addresses are either p2sh or p2wsh, not both.
1049 2016-04-14T20:11:05  <sipa> Luke-Jr: scripts, not addresses
1050 2016-04-14T20:11:26  <sipa> but i agree it's minor
1051 2016-04-14T20:11:30  <wumpus>  * [new tag]         v0.12.1 -> v0.12.1
1052 2016-04-14T20:11:42  <Luke-Jr> I don't follow. If it's used in a p2sh address, you don't need to index the script for p2wsh..?
1053 2016-04-14T20:12:06  <sipa> Luke-Jr: you have an index from Hash160 -> script for known scripts
1054 2016-04-14T20:12:17  <sipa> Luke-Jr: that can be used for matching both P2SH and P2WSH
1055 2016-04-14T20:12:36  <Luke-Jr> but you don't need scripts for p2wsh in that index
1056 2016-04-14T20:13:08  <sipa> perhaps it's better that it's a separate index
1057 2016-04-14T20:13:10  <sipa> maybe
1058 2016-04-14T20:13:37  <Luke-Jr> oh, you mean just having two different indexes at all, even if non-overlapping
1059 2016-04-14T20:14:07  <sipa> well you need an index anyway for p2wsh scripts
1060 2016-04-14T20:14:26  <sipa> the question is whether it can be the same one or not :)
1061 2016-04-14T20:14:46  * sipa afk
1062 2016-04-14T20:18:33  *** frankenmint has quit IRC
1063 2016-04-14T20:19:36  *** mrkent_ has joined #bitcoin-core-dev
1064 2016-04-14T20:20:28  <CodeShark> we could in principle add another marker to the address to indicate some operation to be performed on the data to transform it into the scriptPubKey
1065 2016-04-14T20:21:47  <CodeShark> this would give us flexibility to apply other hash functions or transformations later on
1066 2016-04-14T20:22:01  *** Chris_Stewart_5 has quit IRC
1067 2016-04-14T20:22:04  *** muuqwaul has quit IRC
1068 2016-04-14T20:22:06  <CodeShark> but I would like to avoid special cases
1069 2016-04-14T20:22:30  *** muuqwaul has joined #bitcoin-core-dev
1070 2016-04-14T20:22:34  *** mrkent has quit IRC
1071 2016-04-14T20:29:41  *** zooko has quit IRC
1072 2016-04-14T20:36:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1073 2016-04-14T20:39:34  *** slackircbridge has quit IRC
1074 2016-04-14T20:40:48  *** slackircbridge has joined #bitcoin-core-dev
1075 2016-04-14T20:51:07  *** muuqwaul has quit IRC
1076 2016-04-14T20:51:30  *** muuqwaul has joined #bitcoin-core-dev
1077 2016-04-14T20:54:50  *** johnwhitton has quit IRC
1078 2016-04-14T20:55:02  *** cguida has joined #bitcoin-core-dev
1079 2016-04-14T20:58:37  *** erasmospunk has joined #bitcoin-core-dev
1080 2016-04-14T21:00:11  *** brg444 has quit IRC
1081 2016-04-14T21:05:47  *** cguida has quit IRC
1082 2016-04-14T21:12:28  *** Chris_Stewart_5 has quit IRC
1083 2016-04-14T21:21:00  *** johnwhitton has joined #bitcoin-core-dev
1084 2016-04-14T21:27:11  *** mrkent has joined #bitcoin-core-dev
1085 2016-04-14T21:28:52  *** mrkent_ has quit IRC
1086 2016-04-14T21:39:11  *** muuqwaul has quit IRC
1087 2016-04-14T21:39:35  *** muuqwaul has joined #bitcoin-core-dev
1088 2016-04-14T21:40:00  *** muuqwaul has quit IRC
1089 2016-04-14T21:40:25  *** muuqwaul has joined #bitcoin-core-dev
1090 2016-04-14T21:42:50  *** johnwhitton has quit IRC
1091 2016-04-14T21:43:27  *** johnwhitton has joined #bitcoin-core-dev
1092 2016-04-14T21:47:06  *** johnwhitton has quit IRC
1093 2016-04-14T21:52:56  *** Squidicuz has quit IRC
1094 2016-04-14T21:53:15  *** ryan-c has quit IRC
1095 2016-04-14T21:53:18  *** kangx has quit IRC
1096 2016-04-14T21:53:33  *** dgenr8 has quit IRC
1097 2016-04-14T21:54:47  *** pigeons has quit IRC
1098 2016-04-14T21:55:25  *** Evel-Knievel has quit IRC
1099 2016-04-14T21:56:08  *** pigeons has joined #bitcoin-core-dev
1100 2016-04-14T21:56:10  *** Evel-Knievel has joined #bitcoin-core-dev
1101 2016-04-14T21:56:31  *** pigeons is now known as Guest46972
1102 2016-04-14T21:56:47  *** ryan-c has joined #bitcoin-core-dev
1103 2016-04-14T21:58:45  *** dgenr8 has joined #bitcoin-core-dev
1104 2016-04-14T21:59:53  *** Guest46972 is now known as pigeons
1105 2016-04-14T22:00:48  *** johnwhitton has joined #bitcoin-core-dev
1106 2016-04-14T22:00:57  *** slackircbridge has quit IRC
1107 2016-04-14T22:04:31  *** sdaftuar has quit IRC
1108 2016-04-14T22:05:53  *** sdaftuar has joined #bitcoin-core-dev
1109 2016-04-14T22:08:16  *** TomMc has quit IRC
1110 2016-04-14T22:08:20  *** zooko has joined #bitcoin-core-dev
1111 2016-04-14T22:09:46  *** murch has quit IRC
1112 2016-04-14T22:10:33  *** dgenr8 has quit IRC
1113 2016-04-14T22:12:43  *** dgenr8 has joined #bitcoin-core-dev
1114 2016-04-14T22:13:24  *** johnwhitton has quit IRC
1115 2016-04-14T22:18:23  *** mrkent has quit IRC
1116 2016-04-14T22:22:03  *** Squidicuz has joined #bitcoin-core-dev
1117 2016-04-14T22:23:29  *** johnwhitton has joined #bitcoin-core-dev
1118 2016-04-14T22:24:42  *** erasmospunk has quit IRC
1119 2016-04-14T22:24:45  *** mrkent has joined #bitcoin-core-dev
1120 2016-04-14T22:26:20  *** johnwhitton has quit IRC
1121 2016-04-14T22:26:39  *** erasmospunk has joined #bitcoin-core-dev
1122 2016-04-14T22:27:35  *** johnwhitton has joined #bitcoin-core-dev
1123 2016-04-14T22:28:16  *** johnwhitton has quit IRC
1124 2016-04-14T22:29:50  *** davec has quit IRC
1125 2016-04-14T22:31:17  *** erasmospunk has quit IRC
1126 2016-04-14T22:31:47  *** isis has quit IRC
1127 2016-04-14T22:35:42  *** davec has joined #bitcoin-core-dev
1128 2016-04-14T22:39:19  *** isis has joined #bitcoin-core-dev
1129 2016-04-14T22:54:00  *** Cory has quit IRC
1130 2016-04-14T22:57:01  *** Cory has joined #bitcoin-core-dev
1131 2016-04-14T23:01:31  *** bsm117532 has quit IRC
1132 2016-04-14T23:09:31  *** Samdney has left #bitcoin-core-dev
1133 2016-04-14T23:26:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1134 2016-04-14T23:58:05  *** Guyver2 has quit IRC