12016-04-14T00:03:27 *** cguida has quit IRC
22016-04-14T00:11:41 *** randy-waterhouse has joined #bitcoin-core-dev
32016-04-14T00:12:35 *** cguida has joined #bitcoin-core-dev
42016-04-14T00:12:55 *** BlueMatt_ is now known as BlueMatt
52016-04-14T00:12:55 *** BlueMatt has joined #bitcoin-core-dev
62016-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
72016-04-14T00:15:51 <cfields_> BlueMatt: yes, that's preserved.
82016-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
92016-04-14T00:16:24 <BlueMatt> though if you change the getaddednodeinfo stuff too much it'll be useless?
102016-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
112016-04-14T00:16:42 <BlueMatt> well how does it know which are currently connected without a dns lookup?
122016-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
132016-04-14T00:17:19 <cfields_> BlueMatt: node should preserve the original dns as well as the resolved
142016-04-14T00:17:48 <BlueMatt> "original"?
152016-04-14T00:17:55 <BlueMatt> oh, you mean CNode?
162016-04-14T00:18:06 <cfields_> yea
172016-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
182016-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
192016-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
202016-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
212016-04-14T00:19:58 <cfields_> BlueMatt: ah i see your point
222016-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?"
232016-04-14T00:22:51 <cfields_> BlueMatt: erm wait no, that doesn't follow. If i addnode foo.com, it resolves to 1.2.3.4, connects, then changes to 5.6.7.8, i'd say it's reasonable for rpc to report that foo.com is connected.
242016-04-14T00:24:40 <cfields_> yes, i see now that it's unclear.
252016-04-14T00:24:55 <BlueMatt> yea, I prefer the RPC to work the other way
262016-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
272016-04-14T00:25:20 <BlueMatt> which it is
282016-04-14T00:26:35 <cfields_> ah, there's the problem. i didn't get that logic right after all :)
292016-04-14T00:28:37 <cfields_> BlueMatt: thanks, understood now. I'll fix that up.
302016-04-14T00:37:02 *** murch has quit IRC
312016-04-14T00:39:21 *** PaulCapestany has quit IRC
322016-04-14T00:44:57 *** PaulCapestany has joined #bitcoin-core-dev
332016-04-14T00:45:32 *** cguida has quit IRC
342016-04-14T00:56:43 *** PaulCapestany has quit IRC
352016-04-14T01:11:22 *** cguida has joined #bitcoin-core-dev
362016-04-14T01:24:25 *** cguida has quit IRC
372016-04-14T01:30:07 *** dermoth has quit IRC
382016-04-14T01:31:02 *** dermoth has joined #bitcoin-core-dev
392016-04-14T01:35:54 *** kinlo has quit IRC
402016-04-14T01:45:07 *** kinlo has joined #bitcoin-core-dev
412016-04-14T01:49:35 *** cguida has joined #bitcoin-core-dev
422016-04-14T02:01:59 *** cguida has quit IRC
432016-04-14T02:13:34 *** arowser_ has joined #bitcoin-core-dev
442016-04-14T02:14:54 *** arowser has quit IRC
452016-04-14T02:18:02 *** xiangfu has joined #bitcoin-core-dev
462016-04-14T02:25:17 *** jl2012 has quit IRC
472016-04-14T02:27:52 *** Chris_Stewart_5 has quit IRC
482016-04-14T02:41:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
492016-04-14T02:45:52 *** mrkent_ has quit IRC
502016-04-14T02:48:02 *** cguida has joined #bitcoin-core-dev
512016-04-14T02:55:04 *** randy-waterhouse has quit IRC
522016-04-14T02:55:17 *** xiangfu has quit IRC
532016-04-14T02:55:53 *** cryptocoder has quit IRC
542016-04-14T02:55:55 *** cguida has quit IRC
552016-04-14T02:56:06 *** jtimon has quit IRC
562016-04-14T02:56:37 *** ryankung has joined #bitcoin-core-dev
572016-04-14T02:57:03 *** xiangfu has joined #bitcoin-core-dev
582016-04-14T03:00:29 *** xiangfu has quit IRC
592016-04-14T03:11:27 *** Chris_Stewart_5 has quit IRC
602016-04-14T03:15:19 *** droark has quit IRC
612016-04-14T03:16:59 *** mrkent has joined #bitcoin-core-dev
622016-04-14T03:37:22 *** arowser has joined #bitcoin-core-dev
632016-04-14T03:38:16 *** arowser_ has quit IRC
642016-04-14T03:47:21 *** randy-waterhouse has joined #bitcoin-core-dev
652016-04-14T03:48:10 *** droark has joined #bitcoin-core-dev
662016-04-14T04:04:38 *** xiangfu has joined #bitcoin-core-dev
672016-04-14T04:10:50 *** johnwhitton has quit IRC
682016-04-14T04:11:50 *** johnwhitton has joined #bitcoin-core-dev
692016-04-14T04:25:52 *** johnwhitton has quit IRC
702016-04-14T04:26:30 *** johnwhitton has joined #bitcoin-core-dev
712016-04-14T04:28:51 *** PRab_ has joined #bitcoin-core-dev
722016-04-14T04:30:54 *** PRab has quit IRC
732016-04-14T04:30:55 *** da2ce7_mobile has quit IRC
742016-04-14T04:31:08 *** PRab_ is now known as PRab
752016-04-14T04:31:24 *** pavel_ has quit IRC
762016-04-14T04:31:25 *** arubi has quit IRC
772016-04-14T04:31:51 *** paveljanik has joined #bitcoin-core-dev
782016-04-14T04:31:58 *** ryan-c has quit IRC
792016-04-14T04:32:23 *** da2ce7_mobile has joined #bitcoin-core-dev
802016-04-14T04:32:47 *** ryan-c has joined #bitcoin-core-dev
812016-04-14T04:33:16 *** justanotheruser has quit IRC
822016-04-14T04:37:22 *** justanotheruser has joined #bitcoin-core-dev
832016-04-14T04:43:01 *** Alopex has quit IRC
842016-04-14T04:43:04 *** arubi has joined #bitcoin-core-dev
852016-04-14T04:44:06 *** Alopex has joined #bitcoin-core-dev
862016-04-14T04:44:59 *** johnwhitton has quit IRC
872016-04-14T04:45:36 *** johnwhitton has joined #bitcoin-core-dev
882016-04-14T05:02:01 *** Alopex has quit IRC
892016-04-14T05:03:06 *** Alopex has joined #bitcoin-core-dev
902016-04-14T05:12:31 *** mrkent has quit IRC
912016-04-14T05:15:47 *** d_t has joined #bitcoin-core-dev
922016-04-14T05:19:28 *** d_t has quit IRC
932016-04-14T05:23:28 *** cryptocoder has joined #bitcoin-core-dev
942016-04-14T05:27:02 *** Alopex has quit IRC
952016-04-14T05:28:07 *** Alopex has joined #bitcoin-core-dev
962016-04-14T05:43:01 *** Alopex has quit IRC
972016-04-14T05:44:06 *** Alopex has joined #bitcoin-core-dev
982016-04-14T05:48:30 *** droark has quit IRC
992016-04-14T05:57:58 *** cguida has joined #bitcoin-core-dev
1002016-04-14T05:58:40 *** cheese_ has joined #bitcoin-core-dev
1012016-04-14T05:58:40 *** cheese_ has joined #bitcoin-core-dev
1022016-04-14T06:00:04 *** dermoth has quit IRC
1032016-04-14T06:00:54 *** dermoth has joined #bitcoin-core-dev
1042016-04-14T06:02:02 *** Alopex has quit IRC
1052016-04-14T06:02:13 *** luke-jr_ has joined #bitcoin-core-dev
1062016-04-14T06:03:03 *** xabbix__ has joined #bitcoin-core-dev
1072016-04-14T06:03:07 *** Alopex has joined #bitcoin-core-dev
1082016-04-14T06:03:58 *** sturles_ has joined #bitcoin-core-dev
1092016-04-14T06:04:15 *** OxADADA_ has joined #bitcoin-core-dev
1102016-04-14T06:04:33 *** aureianimus_ has joined #bitcoin-core-dev
1112016-04-14T06:05:36 *** goregrin1 has joined #bitcoin-core-dev
1122016-04-14T06:05:42 *** sturles has quit IRC
1132016-04-14T06:05:42 *** sturles_ is now known as sturles
1142016-04-14T06:06:37 *** petertod1 has joined #bitcoin-core-dev
1152016-04-14T06:08:08 *** jyap_ has joined #bitcoin-core-dev
1162016-04-14T06:08:43 *** johnwhitton has quit IRC
1172016-04-14T06:08:44 *** ryan-c has quit IRC
1182016-04-14T06:08:44 *** Giszmo has quit IRC
1192016-04-14T06:08:45 *** aureianimus has quit IRC
1202016-04-14T06:08:45 *** RoyceX has quit IRC
1212016-04-14T06:08:45 *** TD-Linux has quit IRC
1222016-04-14T06:08:45 *** zxzzt has quit IRC
1232016-04-14T06:08:45 *** OxADADA has quit IRC
1242016-04-14T06:08:45 *** goregrind has quit IRC
1252016-04-14T06:08:45 *** jyap has quit IRC
1262016-04-14T06:08:45 *** crescendo has quit IRC
1272016-04-14T06:08:46 *** binns has quit IRC
1282016-04-14T06:08:47 *** Luke-Jr has quit IRC
1292016-04-14T06:08:47 *** xabbix_ has quit IRC
1302016-04-14T06:08:47 *** baldur has quit IRC
1312016-04-14T06:08:47 *** cfields_ has quit IRC
1322016-04-14T06:08:47 *** slackircbridge has quit IRC
1332016-04-14T06:08:48 *** teward has quit IRC
1342016-04-14T06:08:49 *** petertodd has quit IRC
1352016-04-14T06:08:49 *** Expanse has quit IRC
1362016-04-14T06:08:50 *** TD--Linux has joined #bitcoin-core-dev
1372016-04-14T06:08:50 *** jyap_ is now known as jyap
1382016-04-14T06:08:50 *** jyap has joined #bitcoin-core-dev
1392016-04-14T06:09:06 *** johnwhitton_ has joined #bitcoin-core-dev
1402016-04-14T06:10:04 *** luke-jr_ is now known as Luke-Jr
1412016-04-14T06:10:17 *** ryan-c has joined #bitcoin-core-dev
1422016-04-14T06:11:26 *** zxzzt has joined #bitcoin-core-dev
1432016-04-14T06:12:00 *** crescendo has joined #bitcoin-core-dev
1442016-04-14T06:14:24 *** teward has joined #bitcoin-core-dev
1452016-04-14T06:14:39 *** fkhan_ has quit IRC
1462016-04-14T06:16:10 *** baldur has joined #bitcoin-core-dev
1472016-04-14T06:20:30 *** Giszmo has joined #bitcoin-core-dev
1482016-04-14T06:21:06 *** d_t has joined #bitcoin-core-dev
1492016-04-14T06:21:06 *** Expanse has joined #bitcoin-core-dev
1502016-04-14T06:21:08 *** d_t has quit IRC
1512016-04-14T06:21:38 *** d_t has joined #bitcoin-core-dev
1522016-04-14T06:28:07 *** fkhan_ has joined #bitcoin-core-dev
1532016-04-14T06:33:15 *** d_t has quit IRC
1542016-04-14T06:36:01 *** Alopex has quit IRC
1552016-04-14T06:37:06 *** Alopex has joined #bitcoin-core-dev
1562016-04-14T06:45:25 *** teward has quit IRC
1572016-04-14T06:47:27 *** teward has joined #bitcoin-core-dev
1582016-04-14T06:52:14 *** randy-waterhouse has quit IRC
1592016-04-14T06:57:55 *** cfields has joined #bitcoin-core-dev
1602016-04-14T07:01:59 *** droark has joined #bitcoin-core-dev
1612016-04-14T07:03:27 *** binns has joined #bitcoin-core-dev
1622016-04-14T07:13:22 <jonasschnelli> lmdb -reindex with default dbcache took ~6h42' http://pastebin.com/ERWMGb1p
1632016-04-14T07:13:36 *** Thireus1 has quit IRC
1642016-04-14T07:14:31 <jonasschnelli> So ~2.5* slower then leveldb on the 4core 64bit linux machine I have testes.
1652016-04-14T07:14:56 <gmaxwell> doesn't really make sense that reindex would be slower.
1662016-04-14T07:15:02 <gmaxwell> since the sync is so much faster.
1672016-04-14T07:15:09 <gmaxwell> must be some reindex specific bug.
1682016-04-14T07:15:22 <jonasschnelli> gmaxwell: the sync is faster because it didn't touch the db (was dbcache=9000)
1692016-04-14T07:15:43 <gmaxwell> jonasschnelli: I benchmarked lmdb sync last weekend with default db cache.
1702016-04-14T07:15:51 <gmaxwell> it was _significantly_ faster than leveldb.
1712016-04-14T07:16:04 <jonasschnelli> hmm...
1722016-04-14T07:16:43 *** Thireus has joined #bitcoin-core-dev
1732016-04-14T07:16:48 <gmaxwell> 5 hours 5 minutes vs 8 hours 27minutes.
1742016-04-14T07:16:51 <jonasschnelli> I'll do now a reindex with the same parameter on current master (leveldb).
1752016-04-14T07:17:31 <wumpus> so normally a reindex takes 2h40 on that machine with leveldb with default params?
1762016-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.
1772016-04-14T07:18:49 <jonasschnelli> I mean these are not scientific benchmarks... I'm just playing around.
1782016-04-14T07:18:51 <wumpus> compare reindex against reindex please :)
1792016-04-14T07:18:59 <jonasschnelli> yes. I'll do now.
1802016-04-14T07:19:07 <wumpus> sync from network can be faster than reindex in some cases
1812016-04-14T07:19:12 <gmaxwell> do we still have the thing where signature checks run during reindex at all blocks?
1822016-04-14T07:19:21 <jonasschnelli> I just expected the lmdb reindex to be faster then the leveldb random peer sync
1832016-04-14T07:19:41 <jonasschnelli> But right. could be an performance issue in reindex
1842016-04-14T07:19:46 <wumpus> (for that reason I tend to benchmark syncing from a fast local-network peer instead of reindex these days)
1852016-04-14T07:20:36 <wumpus> gmaxwell: I don't know, I don't think I even know of that issue
1862016-04-14T07:20:47 <NicolasDorier> wumpus: how is it possible ? as I thought reindex would do less work than a resync
1872016-04-14T07:21:16 * gmaxwell checks the microphone.
1882016-04-14T07:21:23 <wumpus> NicolasDorier: you'd expect so
1892016-04-14T07:22:13 <gmaxwell> yes it appears we do.
1902016-04-14T07:22:24 *** mrkent has joined #bitcoin-core-dev
1912016-04-14T07:22:24 <gmaxwell> wumpus: I complained about it so much that I gave up complaining.
1922016-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
1932016-04-14T07:22:32 <wumpus> gmaxwell: did you ever file a github issue?
1942016-04-14T07:22:36 <gmaxwell> It's mildly hard to fix.
1952016-04-14T07:22:38 <gmaxwell> lemme see
1962016-04-14T07:22:54 <gmaxwell> and it looks still unfixed.
1972016-04-14T07:23:23 <wumpus> please do file an issue if there is none, complaining on IRC always gets lost
1982016-04-14T07:23:42 <gmaxwell> basically the reindex doesn't run headers first, so it doesn't have the headers ahead of the blocks
1992016-04-14T07:23:48 <gmaxwell> thus if (pindexLastCheckpoint && pindexLastCheckpoint->GetAncestor(pindex->nHeight) == pindex) {
2002016-04-14T07:23:51 <gmaxwell> doesn't work.
2012016-04-14T07:23:57 <gmaxwell> and scriptchecks run on all blocks.
2022016-04-14T07:24:09 <jonasschnelli> okay. Thats explains it.
2032016-04-14T07:24:12 <jonasschnelli> We need to fix that. :)
2042016-04-14T07:24:17 <wumpus> yes
2052016-04-14T07:24:19 <gmaxwell> I'm looking to see if there is an issue. I believe there was.
2062016-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
2072016-04-14T07:24:33 <wumpus> NicolasDorier: read what gmaxwell writes above
2082016-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. :)
2092016-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
2102016-04-14T07:25:47 <NicolasDorier> oh
2112016-04-14T07:25:55 <NicolasDorier> I understand, thanks
2122016-04-14T07:26:30 <NicolasDorier> well, if you want to test performance, it is better to NOT have checkpoints right ?
2132016-04-14T07:26:48 <gmaxwell> NicolasDorier: sure but it resulted in jonasschnelli doing an apples/oranges test.
2142016-04-14T07:26:49 <wumpus> depends on what performance you want to measure, just compare apples against apples
2152016-04-14T07:26:51 <GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/514993554c37...8bb5d3dff46d
2162016-04-14T07:26:51 <GitHub33> bitcoin/master 4a1d5c1 fanquake: [Doc] Update gitian build guide to debian 8.4.0
2172016-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...
2182016-04-14T07:27:00 <gmaxwell> https://github.com/bitcoin/bitcoin/issues/7875
2192016-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
2202016-04-14T07:27:14 <wumpus> if you want to compare pure database performance, disabling validation makes some sense
2212016-04-14T07:27:18 <jonasschnelli> gmaxwell: Yes. Right. Now started comparing Apple/Apples (reindex leveldb is running).
2222016-04-14T07:27:34 <jonasschnelli> What we really want is a db benchmark script.
2232016-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...
2242016-04-14T07:27:43 <jonasschnelli> script = test-suite thing.
2252016-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 :)
2262016-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
2272016-04-14T07:31:17 <jonasschnelli> Right. That could work.
2282016-04-14T07:31:24 <wumpus> (at least not anything that involves internet peers)
2292016-04-14T07:31:36 <jonasschnelli> I think sync from a local peer is also not really representative.
2302016-04-14T07:31:43 <wumpus> why not?
2312016-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.).
2322016-04-14T07:32:24 <gmaxwell> if it's local you control that.
2332016-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
2342016-04-14T07:32:51 <jonasschnelli> Sure. But I'd prefer something that exclude network and another linux.
2352016-04-14T07:32:52 <gmaxwell> bigger problem is that low latency peers will conceal pipelining failures.
2362016-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.
2372016-04-14T07:33:32 <gmaxwell> of course, one can simulate real networks locally using dummynet.
2382016-04-14T07:33:50 <wumpus> yes there it gets into really difficult territory
2392016-04-14T07:33:54 <jonasschnelli> I think the reindex with disabled verification is probably better
2402016-04-14T07:33:54 <wumpus> benchmarking the network code
2412016-04-14T07:34:02 <wumpus> we're in 'benchmarking for dummies' here with the database :)
2422016-04-14T07:34:05 <gmaxwell> jonasschnelli: depends on what you're testing.
2432016-04-14T07:34:21 <jonasschnelli> For the db performance comparison
2442016-04-14T07:34:52 <wumpus> for the db performance comparison using a reliable local peer is good enough - that won't be the bottleneck
2452016-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.
2462016-04-14T07:35:13 <wumpus> if you want to test pipelining in networking, well, good luck, there's stacks of books written about that :)
2472016-04-14T07:35:17 <gmaxwell> so my point is that the reindex like test is informative, but not complete.
2482016-04-14T07:35:42 <gmaxwell> wumpus: one can do a lot better just by testing with a more realistic setup.
2492016-04-14T07:35:47 <wumpus> maybe we can find a phd student hehe
2502016-04-14T07:36:11 *** ryankung has quit IRC
2512016-04-14T07:36:15 <wumpus> gmaxwell: sure
2522016-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.
2532016-04-14T07:36:56 <gmaxwell> (with actual systems, though that test could have been done with dummynet and VMs okay, I think)
2542016-04-14T07:36:59 <wumpus> tools that reproduce internet circumstances on a simluated network are great for that, absolutely
2552016-04-14T07:46:00 *** cryptocoder has quit IRC
2562016-04-14T07:46:31 *** cryptocoder has joined #bitcoin-core-dev
2572016-04-14T07:46:55 *** cryptocoder has quit IRC
2582016-04-14T07:47:17 *** cryptocoder has joined #bitcoin-core-dev
2592016-04-14T07:47:42 *** cryptocoder has quit IRC
2602016-04-14T07:55:52 *** frankenmint has joined #bitcoin-core-dev
2612016-04-14T07:58:44 *** mase has joined #bitcoin-core-dev
2622016-04-14T07:58:47 <mase> hey
2632016-04-14T07:59:05 <mase> I am unravling the secrets of bitcion
2642016-04-14T07:59:16 *** mase has left #bitcoin-core-dev
2652016-04-14T08:03:13 *** mrkent has quit IRC
2662016-04-14T08:03:30 *** mrkent has joined #bitcoin-core-dev
2672016-04-14T08:08:43 *** p15x has joined #bitcoin-core-dev
2682016-04-14T08:13:58 *** jannes has joined #bitcoin-core-dev
2692016-04-14T08:19:46 *** Guest85557 has quit IRC
2702016-04-14T08:19:46 *** Guest85557 has joined #bitcoin-core-dev
2712016-04-14T08:19:46 *** Guest85557 is now known as amiller
2722016-04-14T08:23:10 *** murch has joined #bitcoin-core-dev
2732016-04-14T08:35:32 *** Luke-Jr has quit IRC
2742016-04-14T08:39:39 *** droark has quit IRC
2752016-04-14T08:41:10 *** Luke-Jr has joined #bitcoin-core-dev
2762016-04-14T08:48:20 *** laurentmt has joined #bitcoin-core-dev
2772016-04-14T08:50:44 *** Guyver2 has joined #bitcoin-core-dev
2782016-04-14T09:00:15 *** laurentmt has quit IRC
2792016-04-14T09:03:28 *** jonasschnelli has quit IRC
2802016-04-14T09:08:09 *** jonasschnelli has joined #bitcoin-core-dev
2812016-04-14T09:11:07 *** xiangfu has quit IRC
2822016-04-14T09:25:53 <jonasschnelli> We really need something like https://github.com/bitcoin/bitcoin/pull/7551 for 0.13
2832016-04-14T09:26:27 <jonasschnelli> Importing a couple of addresses (for watching) is sooo painful on mainnet today.
2842016-04-14T09:26:40 <wumpus> I'm just in the preparations for merging it
2852016-04-14T09:27:11 <wumpus> agree, of course, it was long due
2862016-04-14T09:27:35 <sipa> concept ack on importmulti
2872016-04-14T09:27:40 <jonasschnelli> I also blame myself because I have never tested PR #7551
2882016-04-14T09:27:48 <sipa> sorry for not having looked at it more
2892016-04-14T09:28:24 <jonasschnelli> wumpus: while you at it (*duck*): https://github.com/bitcoin/bitcoin/pull/7518
2902016-04-14T09:28:26 <jonasschnelli> This PR seems also very valuable.
2912016-04-14T09:28:36 <sipa> wumpus: can you wait one second
2922016-04-14T09:28:44 <jonasschnelli> I have tested it a couple of times... but probably needs at least another tACK
2932016-04-14T09:29:11 <wumpus> jonasschnelli: will take a look
2942016-04-14T09:31:00 *** mrkent has quit IRC
2952016-04-14T09:31:30 *** frankenm_ has joined #bitcoin-core-dev
2962016-04-14T09:31:55 *** murch has quit IRC
2972016-04-14T09:32:25 *** p15x has quit IRC
2982016-04-14T09:32:36 *** ibrightly has quit IRC
2992016-04-14T09:33:01 *** zxzzt has quit IRC
3002016-04-14T09:33:02 *** aj has quit IRC
3012016-04-14T09:33:34 *** frankenmint has quit IRC
3022016-04-14T09:33:35 *** Giszmo has quit IRC
3032016-04-14T09:33:35 *** TD--Linux has quit IRC
3042016-04-14T09:33:36 *** dgenr8 has quit IRC
3052016-04-14T09:33:36 *** hybridsole has quit IRC
3062016-04-14T09:33:49 *** dgenr8 has joined #bitcoin-core-dev
3072016-04-14T09:34:55 *** zxzzt has joined #bitcoin-core-dev
3082016-04-14T09:35:18 *** aj has joined #bitcoin-core-dev
3092016-04-14T09:37:40 *** Luke-Jr has quit IRC
3102016-04-14T09:37:54 *** Luke-Jr has joined #bitcoin-core-dev
3112016-04-14T09:39:53 *** hybridsole has joined #bitcoin-core-dev
3122016-04-14T09:40:52 *** ibrightly has joined #bitcoin-core-dev
3132016-04-14T09:43:05 <wumpus> thanks for the review on #7551 sipa
3142016-04-14T09:46:16 *** murch has joined #bitcoin-core-dev
3152016-04-14T09:48:16 *** Giszmo has joined #bitcoin-core-dev
3162016-04-14T09:50:06 *** TD-Linux has joined #bitcoin-core-dev
3172016-04-14T09:52:24 *** Thireus has quit IRC
3182016-04-14T10:09:13 <GitHub43> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/8bb5d3dff46d...536b75e946fb
3192016-04-14T10:09:14 <GitHub43> bitcoin/master 11114a6 MarcoFalke: [amount] test negative fee rates and full constructor
3202016-04-14T10:09:14 <GitHub43> bitcoin/master fa2da2c MarcoFalke: [amount] Add support for negative fee rates...
3212016-04-14T10:09:15 <GitHub43> bitcoin/master facf5a4 MarcoFalke: [amount] tests: Fix off-by-one mistake
3222016-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
3232016-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.
3242016-04-14T10:09:39 <jonasschnelli> What if you need to add an input to fit the new fee?
3252016-04-14T10:09:56 <sipa> yes?
3262016-04-14T10:10:15 <jonasschnelli> bigger tx size, more fee required.
3272016-04-14T10:10:18 <GitHub187> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/536b75e946fb...b778e5993af9
3282016-04-14T10:10:18 <GitHub187> bitcoin/master fa6399d MarcoFalke: [doc] gitian: Replace precise with trusty
3292016-04-14T10:10:19 <GitHub187> bitcoin/master b778e59 Wladimir J. van der Laan: Merge #7855: [doc] gitian: Replace precise with trusty...
3302016-04-14T10:10:25 <jonasschnelli> Just adding minTxRelayFee is not sufficient IMO
3312016-04-14T10:10:26 <sipa> jonasschnelli: yes, which the relay fee will account for
3322016-04-14T10:10:37 <sipa> minTxRelayFee is a feerate, you multiply it by the size of the tx
3332016-04-14T10:11:01 <jonasschnelli> But you don't know the size before you did ran the coinselection...
3342016-04-14T10:11:50 <jonasschnelli> rucksack problem, thats why I though running the CreateTransaction logic again
3352016-04-14T10:12:36 <jonasschnelli> s/rucksack/knapsack
3362016-04-14T10:12:40 <sipa> ok, i'm missing some context i think
3372016-04-14T10:13:36 * jonasschnelli afk for 1h
3382016-04-14T10:13:58 *** murch has quit IRC
3392016-04-14T10:15:24 <GitHub61> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b778e5993af9...72c54e388315
3402016-04-14T10:15:25 <GitHub61> bitcoin/master 85c807c Rusty Russell: getblockchaininfo: make bip9_softforks an object, not an array....
3412016-04-14T10:15:25 <GitHub61> bitcoin/master d12760b Rusty Russell: rpc-tests: handle KeyError nicely in test_framework.py...
3422016-04-14T10:15:26 <GitHub61> bitcoin/master 72c54e3 Wladimir J. van der Laan: Merge #7863: getblockchaininfo: make bip9_softforks an object, not an array....
3432016-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
3442016-04-14T10:18:29 <sipa> do we backport 7863 to 0.12?
3452016-04-14T10:21:47 *** gevs has joined #bitcoin-core-dev
3462016-04-14T10:25:49 <wumpus> yes, it needs to be backported to 0.12 eventually
3472016-04-14T10:26:14 <wumpus> if there is 0.12.1rc3 may as well be in it
3482016-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.
3492016-04-14T10:27:43 <Luke-Jr> probably not important enough to matter
3502016-04-14T10:28:30 <wumpus> yes, feel no need to even have an opinion about it
3512016-04-14T10:31:02 *** erasmospunk has joined #bitcoin-core-dev
3522016-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
3532016-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)
3542016-04-14T10:41:07 <sipa> wumpus: squashfs? :p
3552016-04-14T10:42:06 <wumpus> lol would you compress the binaries or the source code?
3562016-04-14T10:42:19 <sipa> oops, i mean unionfs
3572016-04-14T10:43:55 <wumpus> could work I guess, but seems overkill, every project just supports out-of-tree builds except bitcoin core :)
3582016-04-14T10:47:13 <wumpus> but unionfs does look interesting, could help in some other cases
3592016-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)
3602016-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
3612016-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
3622016-04-14T11:24:34 *** laurentmt has joined #bitcoin-core-dev
3632016-04-14T11:24:56 *** laurentmt has quit IRC
3642016-04-14T11:28:09 *** harding_ has quit IRC
3652016-04-14T11:28:09 *** davec has quit IRC
3662016-04-14T11:28:16 *** harding has joined #bitcoin-core-dev
3672016-04-14T11:28:21 *** davec has joined #bitcoin-core-dev
3682016-04-14T11:29:42 *** gavinandresen has quit IRC
3692016-04-14T11:29:50 *** gavinandresen has joined #bitcoin-core-dev
3702016-04-14T11:37:27 *** gmaxwell has quit IRC
3712016-04-14T11:37:34 *** gmaxwell has joined #bitcoin-core-dev
3722016-04-14T11:37:59 *** gmaxwell is now known as Guest75512
3732016-04-14T11:39:00 *** molz has quit IRC
3742016-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
3752016-04-14T11:39:23 *** molz has joined #bitcoin-core-dev
3762016-04-14T11:47:53 *** dermoth_ has joined #bitcoin-core-dev
3772016-04-14T11:48:16 *** dermoth has quit IRC
3782016-04-14T11:56:02 *** Cory has quit IRC
3792016-04-14T11:59:01 *** Cory has joined #bitcoin-core-dev
3802016-04-14T12:01:18 *** RoyceX has joined #bitcoin-core-dev
3812016-04-14T12:03:55 *** roasbeef_ has quit IRC
3822016-04-14T12:04:01 *** roasbeef has joined #bitcoin-core-dev
3832016-04-14T12:04:21 *** cheese_ has quit IRC
3842016-04-14T12:11:17 *** aureianimus_ has quit IRC
3852016-04-14T12:11:43 *** aureianimus has joined #bitcoin-core-dev
3862016-04-14T12:15:08 *** jtimon has joined #bitcoin-core-dev
3872016-04-14T12:15:25 *** spikeheadon has joined #bitcoin-core-dev
3882016-04-14T12:16:14 *** spikeheadon has quit IRC
3892016-04-14T12:17:00 *** spikeheadon has joined #bitcoin-core-dev
3902016-04-14T12:18:22 *** spikeheadon has quit IRC
3912016-04-14T12:19:11 *** spikeheadon has joined #bitcoin-core-dev
3922016-04-14T12:20:00 *** spikeheadon has quit IRC
3932016-04-14T12:20:08 *** lejitz has joined #bitcoin-core-dev
3942016-04-14T12:20:51 *** spikeheadon has joined #bitcoin-core-dev
3952016-04-14T12:21:43 *** spikeheadon has quit IRC
3962016-04-14T12:22:33 *** spikeheadon has joined #bitcoin-core-dev
3972016-04-14T12:22:37 *** lejitz has quit IRC
3982016-04-14T12:23:26 *** spikeheadon has quit IRC
3992016-04-14T12:24:12 *** spikeheadon has joined #bitcoin-core-dev
4002016-04-14T12:25:51 *** spikeheadon has joined #bitcoin-core-dev
4012016-04-14T12:26:58 *** spikeheadon has quit IRC
4022016-04-14T12:27:46 *** spikeheadon has joined #bitcoin-core-dev
4032016-04-14T12:28:34 *** spikeheadon has quit IRC
4042016-04-14T12:29:27 *** spikeheadon has joined #bitcoin-core-dev
4052016-04-14T12:30:17 *** spikeheadon has quit IRC
4062016-04-14T12:31:04 *** spikeheadon has joined #bitcoin-core-dev
4072016-04-14T12:31:55 *** spikeheadon has quit IRC
4082016-04-14T12:32:40 *** spikeheadon has joined #bitcoin-core-dev
4092016-04-14T12:34:04 *** Expanse has quit IRC
4102016-04-14T12:34:31 *** jl2012 has joined #bitcoin-core-dev
4112016-04-14T12:36:39 *** OxADADA_ is now known as OxADADA
4122016-04-14T12:36:51 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4132016-04-14T12:41:42 *** Expanse has joined #bitcoin-core-dev
4142016-04-14T12:47:05 <GitHub198> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/229a17ca915c...ab8586e6677a
4152016-04-14T12:47:06 <GitHub198> bitcoin/master 4521f00 Wladimir J. van der Laan: tests: add varints_bitpatterns test...
4162016-04-14T12:47:06 <GitHub198> bitcoin/master ab8586e Wladimir J. van der Laan: Merge #7849: tests: add varints_bitpatterns test...
4172016-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
4182016-04-14T12:54:56 *** erasmospunk has quit IRC
4192016-04-14T12:55:23 <GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ab8586e6677a...97d0b9889f15
4202016-04-14T12:55:23 <GitHub183> bitcoin/master 7e91f63 Suhas Daftuar: Use txid as key in mapAlreadyAskedFor...
4212016-04-14T12:55:24 <GitHub183> bitcoin/master 97d0b98 Wladimir J. van der Laan: Merge #7862: Use txid as key in mapAlreadyAskedFor...
4222016-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
4232016-04-14T13:02:49 *** erasmospunk has joined #bitcoin-core-dev
4242016-04-14T13:05:17 *** dgenr8 has quit IRC
4252016-04-14T13:06:09 *** dgenr8 has joined #bitcoin-core-dev
4262016-04-14T13:11:29 *** achow101 has quit IRC
4272016-04-14T13:11:58 *** achow101 has joined #bitcoin-core-dev
4282016-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
4292016-04-14T13:15:15 *** erasmosp_ has joined #bitcoin-core-dev
4302016-04-14T13:15:41 *** cguida_ has joined #bitcoin-core-dev
4312016-04-14T13:15:47 *** arowser has quit IRC
4322016-04-14T13:16:41 *** arowser has joined #bitcoin-core-dev
4332016-04-14T13:16:57 *** ibrightly_ has joined #bitcoin-core-dev
4342016-04-14T13:17:07 *** ibrightly has quit IRC
4352016-04-14T13:17:16 *** paveljanik has quit IRC
4362016-04-14T13:17:16 *** isis has quit IRC
4372016-04-14T13:17:16 *** ibrightly_ is now known as ibrightly
4382016-04-14T13:17:54 *** erasmospunk has quit IRC
4392016-04-14T13:17:54 *** roasbeef has quit IRC
4402016-04-14T13:17:55 *** dermoth_ has quit IRC
4412016-04-14T13:17:55 *** Giszmo has quit IRC
4422016-04-14T13:17:55 *** cguida has quit IRC
4432016-04-14T13:17:55 *** jarret has quit IRC
4442016-04-14T13:17:55 *** sdaftuar has quit IRC
4452016-04-14T13:18:01 *** cguida_ is now known as cguida
4462016-04-14T13:18:07 *** roasbeef has joined #bitcoin-core-dev
4472016-04-14T13:18:33 *** Lightsword has quit IRC
4482016-04-14T13:18:55 *** Lightsword has joined #bitcoin-core-dev
4492016-04-14T13:18:55 *** dermoth_ has joined #bitcoin-core-dev
4502016-04-14T13:18:58 *** Giszmo has joined #bitcoin-core-dev
4512016-04-14T13:19:51 *** isis has joined #bitcoin-core-dev
4522016-04-14T13:20:19 *** jarret has joined #bitcoin-core-dev
4532016-04-14T13:33:40 *** ebfull has quit IRC
4542016-04-14T13:35:13 *** ebfull has joined #bitcoin-core-dev
4552016-04-14T13:41:25 *** muuqwaul has joined #bitcoin-core-dev
4562016-04-14T13:46:10 *** frankenmint has joined #bitcoin-core-dev
4572016-04-14T13:47:36 <GitHub171> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/97d0b9889f15...491171f92954
4582016-04-14T13:47:37 <GitHub171> bitcoin/master 5eeb913 Pieter Wuille: Clean up lockorder data of destroyed mutexes...
4592016-04-14T13:47:37 <GitHub171> bitcoin/master 491171f Wladimir J. van der Laan: Merge #7846: Clean up lockorder data of destroyed mutexes...
4602016-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
4612016-04-14T13:47:52 *** Amnez777 has quit IRC
4622016-04-14T13:48:28 *** hybridsole has quit IRC
4632016-04-14T13:48:29 *** zxzzt has quit IRC
4642016-04-14T13:48:29 *** frankenm_ has quit IRC
4652016-04-14T13:48:29 *** fkhan_ has quit IRC
4662016-04-14T13:48:29 *** crescendo has quit IRC
4672016-04-14T13:49:05 *** Cory has quit IRC
4682016-04-14T13:49:05 *** jannes has quit IRC
4692016-04-14T13:49:06 *** sturles has quit IRC
4702016-04-14T13:49:06 *** da2ce7_mobile has quit IRC
4712016-04-14T13:49:06 *** kinlo has quit IRC
4722016-04-14T13:49:39 *** kinlo has joined #bitcoin-core-dev
4732016-04-14T13:50:12 *** zxzzt has joined #bitcoin-core-dev
4742016-04-14T13:50:13 *** crescendo has joined #bitcoin-core-dev
4752016-04-14T13:50:23 *** sturles has joined #bitcoin-core-dev
4762016-04-14T13:50:31 *** d_t has joined #bitcoin-core-dev
4772016-04-14T13:51:03 *** Pasha has joined #bitcoin-core-dev
4782016-04-14T13:53:07 *** TomMc has joined #bitcoin-core-dev
4792016-04-14T13:54:18 *** hybridsole has joined #bitcoin-core-dev
4802016-04-14T13:54:53 *** d_t has quit IRC
4812016-04-14T13:55:47 *** Amnez777 has joined #bitcoin-core-dev
4822016-04-14T13:56:05 *** ryankung has joined #bitcoin-core-dev
4832016-04-14T13:57:44 *** da2ce7_mobile has joined #bitcoin-core-dev
4842016-04-14T13:57:56 *** Pasha is now known as Cory
4852016-04-14T14:01:04 *** jannes has joined #bitcoin-core-dev
4862016-04-14T14:01:06 *** fkhan_ has joined #bitcoin-core-dev
4872016-04-14T14:04:09 *** ryankung has quit IRC
4882016-04-14T14:10:31 <GitHub48> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/491171f92954...d97101e5a84b
4892016-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
4902016-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...
4912016-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
4922016-04-14T14:12:31 *** muuqwaul has quit IRC
4932016-04-14T14:12:56 *** muuqwaul has joined #bitcoin-core-dev
4942016-04-14T14:13:57 *** muuqwaul has joined #bitcoin-core-dev
4952016-04-14T14:15:44 *** muuqwaul has quit IRC
4962016-04-14T14:16:11 *** muuqwaul has joined #bitcoin-core-dev
4972016-04-14T14:24:44 *** Schlorted has joined #bitcoin-core-dev
4982016-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
4992016-04-14T14:35:24 <GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d97101e5a84b...430fffefaab6
5002016-04-14T14:35:24 <GitHub101> bitcoin/master 4f7c959 Jonas Schnelli: Refactor IsRBFOptIn, avoid exception
5012016-04-14T14:35:25 <GitHub101> bitcoin/master 430fffe Wladimir J. van der Laan: Merge #7812: Tiny refactor of `IsRBFOptIn`, avoid exception...
5022016-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
5032016-04-14T14:42:12 *** laurentmt has joined #bitcoin-core-dev
5042016-04-14T14:45:26 <jtimon> ping #7779
5052016-04-14T14:54:49 *** laurentmt has quit IRC
5062016-04-14T14:56:26 *** laurentmt has joined #bitcoin-core-dev
5072016-04-14T14:57:21 *** johnwhitton_ has quit IRC
5082016-04-14T15:01:15 *** MarcoFalke has joined #bitcoin-core-dev
5092016-04-14T15:01:15 *** hsmiths has quit IRC
5102016-04-14T15:03:27 *** hsmiths has joined #bitcoin-core-dev
5112016-04-14T15:04:38 *** laurentmt has quit IRC
5122016-04-14T15:10:14 *** Giszmo has quit IRC
5132016-04-14T15:13:32 *** Giszmo has joined #bitcoin-core-dev
5142016-04-14T15:15:53 *** xiangfu has joined #bitcoin-core-dev
5152016-04-14T15:17:45 *** paveljanik has joined #bitcoin-core-dev
5162016-04-14T15:17:45 *** paveljanik has joined #bitcoin-core-dev
5172016-04-14T15:19:37 *** spikeheadon has quit IRC
5182016-04-14T15:19:41 *** muuqwaul has quit IRC
5192016-04-14T15:20:07 *** muuqwaul has joined #bitcoin-core-dev
5202016-04-14T15:25:55 *** xiangfu has quit IRC
5212016-04-14T15:47:15 <GitHub90> [bitcoin] laanwj closed pull request #7131: Add 'setblockmaxsize' RPC interface (master...setblockmaxsize) https://github.com/bitcoin/bitcoin/pull/7131
5222016-04-14T15:49:44 *** Thireus has joined #bitcoin-core-dev
5232016-04-14T15:50:54 *** MarcoFalke has quit IRC
5242016-04-14T15:54:31 *** Squidicuz has joined #bitcoin-core-dev
5252016-04-14T15:57:01 *** johnwhitton has joined #bitcoin-core-dev
5262016-04-14T16:05:50 *** droark has joined #bitcoin-core-dev
5272016-04-14T16:19:19 *** Samdney has joined #bitcoin-core-dev
5282016-04-14T16:19:55 *** murch has joined #bitcoin-core-dev
5292016-04-14T16:20:29 *** Samdney has quit IRC
5302016-04-14T16:21:30 *** Ylbam has joined #bitcoin-core-dev
5312016-04-14T16:21:54 *** Samdney has joined #bitcoin-core-dev
5322016-04-14T16:24:06 *** cryptocoder has joined #bitcoin-core-dev
5332016-04-14T16:27:16 *** Chris_Stewart_5 has quit IRC
5342016-04-14T16:28:48 *** laurentmt has joined #bitcoin-core-dev
5352016-04-14T16:30:17 *** laurentmt has quit IRC
5362016-04-14T16:33:16 *** zooko has joined #bitcoin-core-dev
5372016-04-14T16:34:37 *** jannes has quit IRC
5382016-04-14T16:59:10 *** Guest75512 is now known as gmaxwell
5392016-04-14T16:59:25 *** gmaxwell has joined #bitcoin-core-dev
5402016-04-14T17:02:30 *** MarcoFalke has joined #bitcoin-core-dev
5412016-04-14T17:17:52 *** molly has joined #bitcoin-core-dev
5422016-04-14T17:18:01 *** cryptocoder_ has joined #bitcoin-core-dev
5432016-04-14T17:18:37 *** hsmiths2 has joined #bitcoin-core-dev
5442016-04-14T17:19:02 *** erasmospunk has joined #bitcoin-core-dev
5452016-04-14T17:19:58 *** hsmiths has quit IRC
5462016-04-14T17:20:31 *** cryptocoder has quit IRC
5472016-04-14T17:20:31 *** Thireus has quit IRC
5482016-04-14T17:20:31 *** Schlorted has quit IRC
5492016-04-14T17:20:32 *** sturles has quit IRC
5502016-04-14T17:20:32 *** erasmosp_ has quit IRC
5512016-04-14T17:20:38 *** cryptocoder_ is now known as cryptocoder
5522016-04-14T17:21:05 *** zxzzt has quit IRC
5532016-04-14T17:21:05 *** arowser has quit IRC
5542016-04-14T17:21:05 *** jtimon has quit IRC
5552016-04-14T17:21:06 *** molz has quit IRC
5562016-04-14T17:21:37 *** arowser has joined #bitcoin-core-dev
5572016-04-14T17:21:47 *** jtimon has joined #bitcoin-core-dev
5582016-04-14T17:21:56 *** sturles has joined #bitcoin-core-dev
5592016-04-14T17:26:26 *** cryptocoder_ has joined #bitcoin-core-dev
5602016-04-14T17:27:30 *** cryptocoder has quit IRC
5612016-04-14T17:27:31 *** cryptocoder_ is now known as cryptocoder
5622016-04-14T17:37:02 *** Thireus has joined #bitcoin-core-dev
5632016-04-14T17:37:04 *** zxzzt has joined #bitcoin-core-dev
5642016-04-14T17:38:01 *** Schlorted has joined #bitcoin-core-dev
5652016-04-14T17:48:03 *** erasmosp_ has joined #bitcoin-core-dev
5662016-04-14T17:50:54 *** zxzzt has quit IRC
5672016-04-14T17:50:54 *** erasmospunk has quit IRC
5682016-04-14T17:51:08 *** zxzzt has joined #bitcoin-core-dev
5692016-04-14T17:51:33 *** murch has quit IRC
5702016-04-14T17:51:34 *** pigeons has quit IRC
5712016-04-14T17:51:41 *** pigeons has joined #bitcoin-core-dev
5722016-04-14T17:52:05 *** pigeons is now known as Guest69947
5732016-04-14T17:53:53 *** sdaftuar has joined #bitcoin-core-dev
5742016-04-14T17:54:37 *** murch has joined #bitcoin-core-dev
5752016-04-14T17:54:54 *** muuqwaul has quit IRC
5762016-04-14T17:55:21 *** muuqwaul has joined #bitcoin-core-dev
5772016-04-14T17:55:28 <OxADADA> we're using Kramdown for the bitcoin-core website, yes? GitHub is moving away from the other Markdown parsers.
5782016-04-14T17:55:47 <OxADADA> yes, we are using kramdown, we're good
5792016-04-14T17:57:38 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5802016-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
5812016-04-14T18:09:10 *** erasmosp_ has quit IRC
5822016-04-14T18:11:40 <jonasschnelli> Here is the comparison between reindex of current master vs wumpuses LMDB branch:
5832016-04-14T18:11:40 <jonasschnelli> http://pastebin.com/raw/evx62gak
5842016-04-14T18:12:31 <jonasschnelli> leveldb was 1.2842709773 faster
5852016-04-14T18:17:20 *** MarcoFalke has quit IRC
5862016-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)?
5872016-04-14T18:19:59 <sipa> there is not even an rpc that can show the fee of a raw transaction :)
5882016-04-14T18:20:10 <sipa> oh, you mean the estimated necessary fee for a transaction?
5892016-04-14T18:20:29 *** Guest69947 is now known as pigeons
5902016-04-14T18:20:29 <jonasschnelli> No. Forget about the example calculation above (its wrong).
5912016-04-14T18:20:44 <jonasschnelli> The absolute fee and the feerate would be nice.
5922016-04-14T18:20:52 <jonasschnelli> we should add that to decoderawtransaction
5932016-04-14T18:21:31 <sipa> we can't
5942016-04-14T18:21:38 <sipa> transactions don't have a "fee" field
5952016-04-14T18:21:41 <sipa> you need to know the input
5962016-04-14T18:21:50 <jonasschnelli> Lookup?
5972016-04-14T18:22:08 <sipa> decoderawtransaction decodes
5982016-04-14T18:22:17 <jonasschnelli> Thats true.
5992016-04-14T18:22:19 <sipa> it also doesn't tell you what scriptPubKeys were spent
6002016-04-14T18:22:29 <sipa> or what height the transaction is in
6012016-04-14T18:22:38 <sipa> furthermore, we generally *cannot* look that up
6022016-04-14T18:22:43 <jonasschnelli> Well, at least we could tell the estimate fee (size*estimatefee(2))
6032016-04-14T18:22:47 <sipa> because that information is no longer in the UTXO set
6042016-04-14T18:23:00 <jonasschnelli> Yes. Would only work for unspent inputs.
6052016-04-14T18:23:06 <sipa> right
6062016-04-14T18:23:11 <sipa> i guess that's still useful
6072016-04-14T18:23:49 <jonasschnelli> Hmm.. but can be confusing if the rawtx is not signed,... maybe estimating the signature size *duck*
6082016-04-14T18:27:06 <gmaxwell> showing an estimate fee there would be potentially dangerous when someone mistakes it for the actual fee.
6092016-04-14T18:29:48 *** Evel-Knievel has joined #bitcoin-core-dev
6102016-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.
6112016-04-14T18:32:28 <jonasschnelli> estimatefee(2)*decoderawtransaction(<hex>)['size']
6122016-04-14T18:32:52 <jonasschnelli> missing a /1000
6132016-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.
6142016-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.
6152016-04-14T18:34:49 <jonasschnelli> Agree. decoderawtransaction(<hex>)['size'] is stupid
6162016-04-14T18:35:00 <jonasschnelli> Only makes sense if you also need other data form the call.
6172016-04-14T18:37:59 *** muuqwaul has quit IRC
6182016-04-14T18:38:25 *** muuqwaul has joined #bitcoin-core-dev
6192016-04-14T18:43:05 <sipa> gmaxwell: i guess it would be convenient past segwit
6202016-04-14T18:43:08 <sipa> to get vsize
6212016-04-14T18:59:02 *** Chris_Stewart_5 has quit IRC
6222016-04-14T19:00:35 <cfields> meeting?
6232016-04-14T19:00:42 <gmaxwell> Hi all.
6242016-04-14T19:00:46 <wumpus> I guess?
6252016-04-14T19:00:49 <sdaftuar> hello
6262016-04-14T19:00:50 <wumpus> #startmeeting
6272016-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.
6282016-04-14T19:00:50 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
6292016-04-14T19:00:56 <morcos> confidence inspiring wumpus
6302016-04-14T19:01:01 <btcdrak> gavel wont be attending due to last week's beating.
6312016-04-14T19:01:04 <cfields> heh
6322016-04-14T19:01:06 <gmaxwell> "If I have to."
6332016-04-14T19:01:12 <wumpus> topics?
6342016-04-14T19:01:32 <gmaxwell> Whats up with the 0.12.1 release? I haven't been paying attention to it.
6352016-04-14T19:01:34 <morcos> status of 12.1
6362016-04-14T19:01:41 <btcdrak> 0.12.1 status
6372016-04-14T19:01:57 <wumpus> 0.12.1 is at rc2
6382016-04-14T19:02:29 <wumpus> haven't heard of any issues with it
6392016-04-14T19:02:36 <gmaxwell> There was a 0.12.1(rc) block mined in the last week.
6402016-04-14T19:02:41 <sipa> i suggest we go ahead with release?
6412016-04-14T19:02:50 <jonasschnelli> +1
6422016-04-14T19:02:53 <btcdrak> +10
6432016-04-14T19:02:56 <sipa> -11
6442016-04-14T19:03:02 <btcdrak> doh!
6452016-04-14T19:03:02 *** arowser has quit IRC
6462016-04-14T19:03:03 <gmaxwell> +1i.
6472016-04-14T19:03:46 <sipa> gmaxwell: interesting; block version 0x2..?
6482016-04-14T19:03:52 <sipa> but not classic
6492016-04-14T19:03:53 <Luke-Jr> we should release 0.12.1 when 0.12.1 is observed to be released.
6502016-04-14T19:04:18 <sipa> Luke-Jr is the first member of the club containing Luke-Jr as first member
6512016-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. :)
6522016-04-14T19:04:37 <Luke-Jr> that sounds lonely.
6532016-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
6542016-04-14T19:04:44 <sipa> wumpus: ok
6552016-04-14T19:04:47 <wumpus> but if you insist
6562016-04-14T19:05:01 <sipa> topic suggestion: segwit and backports
6572016-04-14T19:05:08 <btcdrak> let's insist
6582016-04-14T19:05:08 <jonasschnelli> Yes. We should wait at least one week.
6592016-04-14T19:05:10 <gmaxwell> sipa: but at least thats just a one time event.
6602016-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. :)
6612016-04-14T19:05:43 <Luke-Jr> could start the gitian building now and wait the rest of the week to publish?
6622016-04-14T19:06:11 <jonasschnelli> the tag could be seen as "release"
6632016-04-14T19:06:11 <btcdrak> 1 business week is 5 days :)
6642016-04-14T19:06:27 <wumpus> good to hear a block would mined with 0.12.1 though, hadn't heard that yet
6652016-04-14T19:06:32 <wumpus> s/would/was
6662016-04-14T19:06:54 <btcdrak> why not tag 0.12.1 we can build over the weekend and release on Monday?
6672016-04-14T19:07:14 <jonasschnelli> Why not tag on monday and build on monday?
6682016-04-14T19:07:22 *** moli has joined #bitcoin-core-dev
6692016-04-14T19:07:22 <jonasschnelli> You don't need to handhold you bulder?
6702016-04-14T19:07:24 <sipa> wumpus decides
6712016-04-14T19:07:26 <gmaxwell> the building has latency.
6722016-04-14T19:07:28 <wumpus> you're too eager
6732016-04-14T19:07:46 <btcdrak> gotta build, cfields needs to sign etc.
6742016-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.
6752016-04-14T19:08:13 <wumpus> huh
6762016-04-14T19:08:16 <jonasschnelli> we could agree on a commit and build that and tag later.
6772016-04-14T19:08:17 *** molly has quit IRC
6782016-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.
6792016-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
6802016-04-14T19:08:43 <wumpus> is this still serious?
6812016-04-14T19:08:44 <cfields> fwiw, dropping the commit hash in the binary would create a few more options
6822016-04-14T19:08:55 <sipa> wumpus: no
6832016-04-14T19:09:00 <wumpus> ok...
6842016-04-14T19:09:02 <wumpus> next topic?
6852016-04-14T19:09:13 <jonasschnelli> [21:05:02] <sipa> topic suggestion: segwit and backports
6862016-04-14T19:09:17 <btcdrak> segwit backports
6872016-04-14T19:09:28 <wumpus> #topic segwit and backports
6882016-04-14T19:09:42 <sipa> so, segwit branch is currently on top of 0.12.1
6892016-04-14T19:09:43 *** arowser has joined #bitcoin-core-dev
6902016-04-14T19:10:04 <btcdrak> so you'd be forward porting it to master
6912016-04-14T19:10:13 <sipa> with a set of backports from master and some PRs first
6922016-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
6932016-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
6942016-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.
6952016-04-14T19:10:53 <Luke-Jr> gmaxwell: nice!
6962016-04-14T19:11:13 <cfields> sipa: woohoo!
6972016-04-14T19:11:28 <wumpus> gmaxwell: "and then having binary days delayed is suboptimal." why don't you ever gitian-build? :p
6982016-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
6992016-04-14T19:11:49 <sipa> which happens to include the necessary backports
7002016-04-14T19:11:49 <btcdrak> sipa: I hear you are good at magic
7012016-04-14T19:12:01 <Luke-Jr> sipa: what's the current segwit branch?
7022016-04-14T19:12:05 <Luke-Jr> without segnet ideally
7032016-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)
7042016-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
7052016-04-14T19:12:53 <sipa> Luke-Jr: they have segnet, though the commits for segnet are separate and can easily be skipped
7062016-04-14T19:13:17 <gmaxwell> wumpus: if you'd like me to do so, I will. (re gitian builds)
7072016-04-14T19:13:28 <sipa> that's anohter question: do we merge segnet?
7082016-04-14T19:13:36 <btcdrak> gmaxwell: yes please.
7092016-04-14T19:13:42 <wumpus> gmaxwell: I dont mind, but please don't complain if you're not involved okay :)
7102016-04-14T19:13:55 <btcdrak> sipa: do we really need segnet?
7112016-04-14T19:14:00 <sipa> btcdrak: i don't think so
7122016-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.
7132016-04-14T19:14:22 <sipa> that sounds fine to me
7142016-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
7152016-04-14T19:14:33 <btcdrak> morcos: no complaints
7162016-04-14T19:14:36 <morcos> We should just rip the bandaid off and get it in
7172016-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.
7182016-04-14T19:14:59 <morcos> And then every other PR out there can get conflicted once and be done with it
7192016-04-14T19:15:02 <btcdrak> in all fairness there has been so much testing and peer review and help from downstream consumers with segwit.
7202016-04-14T19:15:16 <sipa> ok, will PR soon
7212016-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.
7222016-04-14T19:15:31 <sipa> both master and 0.12
7232016-04-14T19:15:39 <btcdrak> super. jonasschnelli you should close your preview PR so it doesnt get confusing
7242016-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.
7252016-04-14T19:16:07 <jonasschnelli> Yes. Will close. Its pointing also to the wrong branch.
7262016-04-14T19:16:24 <btcdrak> gmaxwell: maybe we dont need to over complicate if the PR/backport will come soon.
7272016-04-14T19:16:30 *** brg444 has joined #bitcoin-core-dev
7282016-04-14T19:16:32 *** johnwhitton has quit IRC
7292016-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.
7302016-04-14T19:18:29 <sipa> that makes sense
7312016-04-14T19:20:19 <sipa> any other topics?
7322016-04-14T19:20:34 <wumpus> what about c++11 status?
7332016-04-14T19:20:39 <sipa> ack
7342016-04-14T19:20:47 <wumpus> #topic c++11 status
7352016-04-14T19:20:55 * sipa summons cfields
7362016-04-14T19:21:16 <cfields> wumpus: travis has enabled caching but only for flagged projects. I mailed this morning and asked for the flag.
7372016-04-14T19:21:34 <sipa> cfields: is that the final blocker?
7382016-04-14T19:21:43 <cfields> sipa: as far as i know, yes
7392016-04-14T19:21:47 <sipa> awesome
7402016-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?
7412016-04-14T19:22:01 *** Schlorted has quit IRC
7422016-04-14T19:22:06 <wumpus> hopefully theyll give it :)
7432016-04-14T19:22:07 <cfields> wumpus: no, for trusty
7442016-04-14T19:22:08 <cfields> sec..
7452016-04-14T19:22:46 <cfields> https://github.com/travis-ci/travis-scheduler/pull/14
7462016-04-14T19:23:07 <cfields> merged last week
7472016-04-14T19:23:32 *** johnwhitton has joined #bitcoin-core-dev
7482016-04-14T19:23:33 <wumpus> great!
7492016-04-14T19:23:47 <sipa> how do we plan to proceed after that?
7502016-04-14T19:23:50 <wumpus> hopefully we can start supporting it this week then
7512016-04-14T19:23:56 <gmaxwell> would we be using C++11 in 0.13 then?
7522016-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
7532016-04-14T19:24:32 <wumpus> gmaxwell: that was the plan
7542016-04-14T19:24:33 <Luke-Jr> Travis is not willing to flag just any projects. We should try to avoid relying on it.
7552016-04-14T19:24:40 <gmaxwell> wumpus: good. :)
7562016-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...
7572016-04-14T19:25:00 <cfields> otherwise, I'm afraid it'll be endless PRs
7582016-04-14T19:25:10 <cfields> Luke-Jr: it's just a flag while it's in testing
7592016-04-14T19:25:10 <sipa> cfields: there are a couple of mechanic translations i think we'll want ayt some point
7602016-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
7612016-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.
7622016-04-14T19:25:49 <gmaxwell> at least thats my intuition.
7632016-04-14T19:25:50 <sipa> cfields: BOOST_FOREACH and boost::thread are good examples
7642016-04-14T19:25:56 <wumpus> replacing boost is far from mechanical
7652016-04-14T19:26:00 <wumpus> well ok some parts
7662016-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.
7672016-04-14T19:26:16 <morcos> is there any downside to using c++11 in new code while not yet doing any modernization PR's?
7682016-04-14T19:26:16 <sipa> but for example: adding move constructors instead of swaps everywhere
7692016-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.
7702016-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?
7712016-04-14T19:26:23 <cfields> (and emplace, which would be significant in several places)
7722016-04-14T19:26:25 <BlueMatt> Start with only new code is C++11, then only boost-replacement, then revisit
7732016-04-14T19:26:26 <BlueMatt> ?
7742016-04-14T19:26:29 <gmaxwell> because that would vastly complicate backports.
7752016-04-14T19:26:41 <sipa> one option is building with c++11 and c++03 both for a while
7762016-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)
7772016-04-14T19:26:46 <wumpus> meh
7782016-04-14T19:26:47 <cfields> morcos: i think that would be my preference
7792016-04-14T19:26:56 <wumpus> we can already build with c++11 for quite a while, that's nothing new
7802016-04-14T19:27:12 <sipa> ok
7812016-04-14T19:27:25 <sipa> just not too actively replace things initially
7822016-04-14T19:27:42 <BlueMatt> I mean for 0.13 Id say dont actively replace anything unless its a big performance win
7832016-04-14T19:27:43 <Luke-Jr> at the very least, let's add something to configure that fails if C++11 is not supported?
7842016-04-14T19:27:49 <wumpus> we've never let refactors through too quickly
7852016-04-14T19:27:54 <wumpus> correctness is most imporant
7862016-04-14T19:28:02 <Luke-Jr> that way we get user reports
7872016-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.
7882016-04-14T19:28:07 <wumpus> Luke-Jr: yes, see the pull I quoted
7892016-04-14T19:28:20 <wumpus> Luke-Jr: it fails without c++11 support
7902016-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
7912016-04-14T19:28:28 <cfields> wumpus: let's use a real example.. adding move ctors to our containers
7922016-04-14T19:28:31 <cfields> yea or nay?
7932016-04-14T19:28:39 <sipa> cfields: yay, please... but maybe not immediately
7942016-04-14T19:28:49 <BlueMatt> cfields: for 0.13, I'd vote only new code, maybe boost replacement, too
7952016-04-14T19:28:57 <wumpus> cfields: if it helps performance, absolute yay
7962016-04-14T19:28:58 *** kangx has joined #bitcoin-core-dev
7972016-04-14T19:28:59 <sipa> (prevector specifically is unsafe to use for more complex types now)
7982016-04-14T19:29:07 <BlueMatt> but I'm always the annoyingly conservative one, sooooo
7992016-04-14T19:29:11 *** slackircbridge has joined #bitcoin-core-dev
8002016-04-14T19:29:11 <wumpus> boost replacement is too late for 0.13
8012016-04-14T19:29:15 <sipa> wumpus: agree
8022016-04-14T19:29:15 <wumpus> too much work
8032016-04-14T19:29:29 <BlueMatt> wumpus: ehh, I meant partial-boost-replacement
8042016-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
8052016-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.
8062016-04-14T19:29:44 <sipa> just turning on c++11 may already give a performance improvement, because STL magically gets move constructors
8072016-04-14T19:30:01 <jonasschnelli> At least we could throw out boost::filesystem soon (there is no c++11 equivalent).
8082016-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
8092016-04-14T19:30:09 <wumpus> do a release from master
8102016-04-14T19:30:21 <wumpus> may work better with cfields' holiday too
8112016-04-14T19:30:32 <morcos> wumpus: but then not release segwit for 0.12?
8122016-04-14T19:30:40 <cfields> stupid inconvenient honeymoon...
8132016-04-14T19:30:49 <morcos> thats the issue right.. are we only going to support it on 0.13?
8142016-04-14T19:30:50 <sipa> cfields: priorities!
8152016-04-14T19:30:54 <jonasschnelli> heh!
8162016-04-14T19:30:56 <gmaxwell> morcos: I don't think we should do that.
8172016-04-14T19:30:59 <sipa> i think we should backport segwit to 0.12
8182016-04-14T19:31:03 <wumpus> (we have to change the release schedule a bit anyway)
8192016-04-14T19:31:08 <sipa> let's not push users too much
8202016-04-14T19:31:24 <btcdrak> if we release 0.13 we still have to backport to 0.12
8212016-04-14T19:31:34 <btcdrak> since we support this and prev version
8222016-04-14T19:31:36 <gmaxwell> wumpus: what kind of schedule change are you thinking of?
8232016-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?
8242016-04-14T19:32:44 <btcdrak> maybe backport to 0.12 and release 0.13 early.
8252016-04-14T19:33:14 <morcos> whats the hurry to release 0.13 early in that case?
8262016-04-14T19:33:15 <wumpus> yes was a bad idea
8272016-04-14T19:33:19 <btcdrak> This is the list of 0.13 milestones https://github.com/bitcoin/bitcoin/milestones/0.13.0
8282016-04-14T19:33:19 <wumpus> ntext topic
8292016-04-14T19:33:21 <phantomcircuit> jonasschnelli: was that benchmark of leveldb vs lmdb on a system with a hdd or ssd?
8302016-04-14T19:33:32 <jonasschnelli> ssd
8312016-04-14T19:33:40 <phantomcircuit> interesting
8322016-04-14T19:33:52 <jonasschnelli> (can be discussed after the meeting)
8332016-04-14T19:34:15 <gmaxwell> btcdrak: there are things people are working on that aren't PRs yet.
8342016-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
8352016-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?
8362016-04-14T19:35:00 <Luke-Jr> (and there's no reason it can't wait for 0.14 etc)
8372016-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
8382016-04-14T19:35:29 <wumpus> but we can just as well postpone it to later, moving it ealier was just a stupid idea
8392016-04-14T19:35:36 <cfields> no reason to change just for me?
8402016-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.
8412016-04-14T19:35:51 <wumpus> well the rc cycle was exactly planned that
8422016-04-14T19:35:56 <wumpus> then*
8432016-04-14T19:36:03 <gmaxwell> wumpus: I dunno that its stupid. But it should be made with consideration.
8442016-04-14T19:36:07 <wumpus> can do that in july instead of june , no problem
8452016-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.
8462016-04-14T19:36:37 <wumpus> BlueMatt: release schedule 0.13: https://github.com/bitcoin/bitcoin/issues/7679
8472016-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.
8482016-04-14T19:36:40 <morcos> wumpus: yes i like the idea of pushing back 0.13 a bit
8492016-04-14T19:36:48 <sipa> gmaxwell: ack
8502016-04-14T19:36:49 <BlueMatt> gmaxwell: ACK
8512016-04-14T19:36:55 *** lclc has quit IRC
8522016-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)
8532016-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
8542016-04-14T19:37:17 <BlueMatt> wumpus: ok, so release schedule stays as-is for now?
8552016-04-14T19:37:29 <wumpus> BlueMatt: I proposed moving the rc phase to july instead of june
8562016-04-14T19:37:33 <jonasschnelli> sdaftuar: good point.
8572016-04-14T19:37:34 <Luke-Jr> in talking about using C++11, we won't need GCC 5, right?
8582016-04-14T19:37:44 <Luke-Jr> because GCC 5 is not really a reasonable minimum yet
8592016-04-14T19:37:44 <BlueMatt> when does cfields gete back?
8602016-04-14T19:37:53 <morcos> wumpus: ack
8612016-04-14T19:37:59 <cfields> Luke-Jr: 4.8 should be fine, i think
8622016-04-14T19:38:02 <wumpus> no, we don't need gcc5, the features we should use of c++11 shoudl work in gcc4.8+
8632016-04-14T19:38:02 <Luke-Jr> k
8642016-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
8652016-04-14T19:38:11 <wumpus> otherwise we can't use trusty for building
8662016-04-14T19:38:18 <cfields> BlueMatt: july4ish
8672016-04-14T19:38:20 <wumpus> and that's the whole point
8682016-04-14T19:38:35 <sipa> that's clear, thank you
8692016-04-14T19:39:05 <cfields> BlueMatt: if it turns out to be too problematic, i can revisit the dates.
8702016-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.
8712016-04-14T19:39:22 <BlueMatt> cfields: lol, dont change honeymoon for us
8722016-04-14T19:39:23 <wumpus> cfields: no
8732016-04-14T19:39:27 <gmaxwell> Luke-Jr: https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
8742016-04-14T19:39:28 <morcos> cfields: you better hope your fiance doesnt read these logs
8752016-04-14T19:39:38 <jonasschnelli> haha
8762016-04-14T19:40:02 *** muuqwaul has quit IRC
8772016-04-14T19:40:13 <cfields> heh
8782016-04-14T19:40:26 *** muuqwaul has joined #bitcoin-core-dev
8792016-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
8802016-04-14T19:40:38 <wumpus> sdaftuar: if we move the rc phase a month we can move the feature freeze with the same amount
8812016-04-14T19:40:48 <BlueMatt> wumpus: eg things that get reviewed in zurich can be cleaned up and merged before freeze
8822016-04-14T19:40:51 <wumpus> BlueMatt: right
8832016-04-14T19:40:52 <sdaftuar> wumpus: sounds good to me
8842016-04-14T19:41:01 <BlueMatt> ACKs on pushing a month?
8852016-04-14T19:41:06 <btcdrak> ACK
8862016-04-14T19:41:11 <wumpus> ack
8872016-04-14T19:41:12 <jonasschnelli> ack
8882016-04-14T19:41:14 <gmaxwell> ok
8892016-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?
8902016-04-14T19:41:15 <morcos> ACK
8912016-04-14T19:41:29 * Luke-Jr not care on 0.13 schedule
8922016-04-14T19:41:33 *** lclc has joined #bitcoin-core-dev
8932016-04-14T19:42:05 <wumpus> #action move 0.13 schedule a month forward
8942016-04-14T19:42:39 <cfields> Luke-Jr: what issues?
8952016-04-14T19:42:40 *** johnwhitton has quit IRC
8962016-04-14T19:42:41 <sipa> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/7165#issuecomment-165499462
8972016-04-14T19:42:52 <sipa> all known ABI issues result in link errors
8982016-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.
8992016-04-14T19:43:31 <wumpus> hah, c++14
9002016-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),
9012016-04-14T19:43:39 <wumpus> not looking forward to going through this again :(
9022016-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.
9032016-04-14T19:44:22 <BlueMatt> I think gmaxwell is more excited about tcp-smaller-block relay since his internet at home sucks
9042016-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.
9052016-04-14T19:44:27 <cfields> nice
9062016-04-14T19:44:33 <cfields> BlueMatt: you have a branch somewhere?
9072016-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 :)
9082016-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
9092016-04-14T19:45:21 <wumpus> cfields: how does it make sense that they will build with c++14 by default?!
9102016-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
9112016-04-14T19:45:48 <cfields> wumpus: i suppose because it should all be forward compat, in theory
9122016-04-14T19:45:50 <sipa> wumpus: i think c++14 has less impact on standard libraries
9132016-04-14T19:45:50 <cfields> BlueMatt: thanks
9142016-04-14T19:46:09 <sipa> and is much more incremental than c++11 was
9152016-04-14T19:46:09 <BlueMatt> cfields: if you want to tackle the udp-wip changing to libevent I'd owe you :)
9162016-04-14T19:46:12 <cfields> yes, c++14 as i see it is kinda a c++11 fixup
9172016-04-14T19:46:23 <wumpus> ok...
9182016-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.
9192016-04-14T19:46:36 <sipa> c++14 finally has a solution for the exponentially-sized error messages
9202016-04-14T19:46:37 <Luke-Jr> sipa: ok
9212016-04-14T19:46:57 <cfields> Luke-Jr: that has nothing to do with how we compile though. That'll be the case either way.
9222016-04-14T19:47:00 <gmaxwell> BlueMatt: mostly trying to avoid bleeding out over load increases permitted by segwit. :)
9232016-04-14T19:47:06 <wumpus> sipa: nice!
9242016-04-14T19:47:13 <cfields> BlueMatt: heh yes, we should sync up some
9252016-04-14T19:47:24 *** johnwhitton has joined #bitcoin-core-dev
9262016-04-14T19:47:34 <Luke-Jr> cfields: ? our dependencies are compiled with C++98 in almost all cases today
9272016-04-14T19:47:37 <wumpus> anyhow any other meeting topics?
9282016-04-14T19:47:49 <kanzure> MAST bip status?
9292016-04-14T19:48:06 <gmaxwell> lol. way too premature for discussion here.
9302016-04-14T19:48:13 <btcdrak> kanzure: it got published BIP114
9312016-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.
9322016-04-14T19:48:19 <wumpus> Luke-Jr: cfields let's leave the small implementation details about the c++11 switch to after the meeting
9332016-04-14T19:48:27 <cfields> ack
9342016-04-14T19:48:36 <Luke-Jr> cfields: we do not build our dependencies typically.
9352016-04-14T19:48:49 <Luke-Jr> wumpus: k
9362016-04-14T19:49:03 <wumpus> I'm sure we'll get it to work somehow
9372016-04-14T19:49:31 <wumpus> #topic MAST bip status
9382016-04-14T19:49:44 <kanzure> no no, it was sufficiently NACKed
9392016-04-14T19:49:59 <sipa> i haven't looked at it yet
9402016-04-14T19:50:17 <instagibbs> https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki < fwiw
9412016-04-14T19:50:30 <wumpus> #link https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
9422016-04-14T19:51:43 <Luke-Jr> possible topic?: using SHA256d for segwit
9432016-04-14T19:52:15 *** johnwhitton has quit IRC
9442016-04-14T19:52:30 <wumpus> sha256d?
9452016-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
9462016-04-14T19:53:04 <sipa> wumpus: background: p2wsh scriptPubKeys contain a SHA256 (not double SHA256) of the witness program
9472016-04-14T19:53:09 <paveljanik> double sha256
9482016-04-14T19:53:26 <sipa> which is incompatible with the "P2SH^2" scheme that greg proposed a while ago
9492016-04-14T19:53:35 <wumpus> oh right
9502016-04-14T19:53:43 <wumpus> it would be consistent
9512016-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.
9522016-04-14T19:54:00 *** johnwhitton has joined #bitcoin-core-dev
9532016-04-14T19:54:12 <gmaxwell> And consistency, I suppose.
9542016-04-14T19:54:15 <sipa> ... which interacts with the discussion of addresses for native segwit
9552016-04-14T19:54:17 <Luke-Jr> gmaxwell: there's no address types for bare segwit yet
9562016-04-14T19:54:36 <sipa> Luke-Jr: i do plan on proposing one
9572016-04-14T19:54:41 <sipa> (though not immediately)
9582016-04-14T19:54:59 <Luke-Jr> yes, my point is that we have an opportunity to avoid breaking compatibility
9592016-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.
9602016-04-14T19:55:44 <phantomcircuit> gmaxwell: sha256d also prevents length extention attacks although i dont see how that's applicable here at all
9612016-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.
9622016-04-14T19:55:56 <Luke-Jr> sipa: am I incorrect in assuming adjusting downstream code for this would be super trivial?
9632016-04-14T19:56:26 <sipa> Luke-Jr: probably, but we also don't have a way to deploy P2SH^2 easily
9642016-04-14T19:56:27 *** johnwhitton has quit IRC
9652016-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
9662016-04-14T19:56:59 *** d_t has joined #bitcoin-core-dev
9672016-04-14T19:57:00 <Luke-Jr> sipa: that's not something we need to bundle with making it possible
9682016-04-14T19:57:37 <gmaxwell> we should close the meeting and continue the discussion.
9692016-04-14T19:57:40 <sipa> ok
9702016-04-14T19:57:46 <gmaxwell> no resolution to this will happen this instant.
9712016-04-14T19:58:04 *** johnwhitton has joined #bitcoin-core-dev
9722016-04-14T19:58:51 <sipa> #shutdown -h now meeting
9732016-04-14T19:59:04 <jonasschnelli> sudo!
9742016-04-14T19:59:08 <wumpus> #endmeeting
9752016-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)
9762016-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
9772016-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
9782016-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
9792016-04-14T19:59:28 <paveljanik> jonasschnelli, no need for sudo once you have # ;-)
9802016-04-14T19:59:48 *** mrkent has joined #bitcoin-core-dev
9812016-04-14T19:59:50 <jonasschnelli> nerds! oO
9822016-04-14T19:59:52 *** johnwhitton has quit IRC
9832016-04-14T19:59:55 <jtimon> meeting?
9842016-04-14T19:59:55 <gmaxwell> So, wrt p2sh^2. That got proposed eons ago and I think it's unlikely to ever get implemented.
9852016-04-14T20:00:00 <jonasschnelli> jtimon: hahaha
9862016-04-14T20:00:01 <gmaxwell> jtimon: an hour ago.
9872016-04-14T20:00:18 <jtimon> oh...
9882016-04-14T20:00:27 <phantomcircuit> timezones strike again
9892016-04-14T20:00:31 <jtimon> well, read the logs I guess
9902016-04-14T20:00:33 <btcdrak> jtimons needs to run an ntp daemon
9912016-04-14T20:00:33 <kanzure> this is why we should abolish time zones
9922016-04-14T20:00:37 <Luke-Jr> gmaxwell: isn't the only major hold-up the backward compat issue?
9932016-04-14T20:00:46 <Luke-Jr> kanzure: tonal time! :D
9942016-04-14T20:00:55 <kanzure> i would be willing to accept tonal time if it means no more time zones
9952016-04-14T20:00:55 <paveljanik> meeting bot should be modified to ping people beforehand :-)
9962016-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". :)
9972016-04-14T20:01:02 <gmaxwell> Luke-Jr: no, well it requires yet another kind of witness data in transactions.
9982016-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
9992016-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
10002016-04-14T20:01:25 <Luke-Jr> gmaxwell: that's pretty simple now with segwit
10012016-04-14T20:01:34 *** johnwhitton has joined #bitcoin-core-dev
10022016-04-14T20:01:34 <gmaxwell> the pairing crypto based scheme I came up with didn't have those issues but it's slow.
10032016-04-14T20:01:36 *** Chris_Stewart_5 has joined #bitcoin-core-dev
10042016-04-14T20:01:38 <jtimon> jonasschnelli: that would be indeed useful
10052016-04-14T20:01:42 <Luke-Jr> sipa: that assumes miners are willing to cooperate in the spam
10062016-04-14T20:01:44 <Luke-Jr> actively
10072016-04-14T20:01:59 <sipa> Luke-Jr: why wouldn't they, if people want to pay
10082016-04-14T20:02:03 <Luke-Jr> at the very least, such miners would likely opt to charge higher fees (I hope)
10092016-04-14T20:02:42 <jtimon> never mind much, I will eventually adapt to this without putting it in google calendar, you'll see
10102016-04-14T20:02:57 <sipa> p2sh^2 is also incompatible with forward compatible address types
10112016-04-14T20:03:14 <gmaxwell> sipa: I dunno, thats kind of an argument against any non-stanardness. Dust limits have been effective.
10122016-04-14T20:03:23 <sipa> gmaxwell: fair enough
10132016-04-14T20:03:29 <Luke-Jr> not necessarily? if all future address types are p2sh^2
10142016-04-14T20:03:29 <gmaxwell> But yes, it would be incompatible with address types that change the top hashing scheme.
10152016-04-14T20:03:36 <wumpus> jtimon: date -u , if it shows thursday 19:00-20:00 it's time for the meeting :)
10162016-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
10172016-04-14T20:04:10 <sipa> then it can be compatible
10182016-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.
10192016-04-14T20:04:30 <gmaxwell> No but we can be a bit more future robust than p2sh was.
10202016-04-14T20:04:49 <gmaxwell> There is a greater archectural question around the pace of script changes.
10212016-04-14T20:04:52 *** ebfull has quit IRC
10222016-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.
10232016-04-14T20:05:28 *** ebfull has joined #bitcoin-core-dev
10242016-04-14T20:05:54 <CodeShark> how is simply encoding the scriptPubKey not fully general?
10252016-04-14T20:06:04 <sipa> CodeShark: it doesn't cover P2SH^2
10262016-04-14T20:06:11 <Luke-Jr> gmaxwell: hopefully all scripts will be inside the witness
10272016-04-14T20:06:15 <sipa> CodeShark: but apary from that, yes
10282016-04-14T20:06:24 <sipa> Luke-Jr: the witness version number needs to be outside
10292016-04-14T20:06:27 <CodeShark> what's P2SH^2?
10302016-04-14T20:06:34 <Luke-Jr> kanzure: http://176.9.18.83:5984/buddy-clock/_design/site/_list/show/by_tz btw
10312016-04-14T20:06:54 <Luke-Jr> sipa: yes, but that doesn't interfere with p2sh^2
10322016-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)
10332016-04-14T20:07:12 <instagibbs> can we get the post on p2sh^2? I read it like 3 years ago, forgot the details
10342016-04-14T20:07:26 <instagibbs> oh ok
10352016-04-14T20:07:37 <sipa> CodeShark: this guarantees that the data in the output is a hash, and not data storage
10362016-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).
10372016-04-14T20:08:24 <gmaxwell> A practice which is a major accounting nusance for many parties.
10382016-04-14T20:08:47 <sipa> b.i will of course publish all the preimages they see in the network
10392016-04-14T20:08:49 <CodeShark> so no more shakespeare in the blockchain? :( https://www.smartbit.com.au/tx/8f64d2b7a762767e3870c4aee95f8c7b5439cf02cf7d7e5d99b6e39967ecada8
10402016-04-14T20:08:51 <sipa> *ducks*
10412016-04-14T20:09:18 <gmaxwell> CodeShark: not in the UTXO set, of course that stuff could still end up in witnesses.
10422016-04-14T20:09:26 <instagibbs> sipa, sigh, you are of course correct
10432016-04-14T20:09:39 <instagibbs> or just captured by sybil anti-laundering services
10442016-04-14T20:09:50 <gmaxwell> sipa: I wouldn't be so sure.
10452016-04-14T20:09:53 *** cguida has quit IRC
10462016-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)
10472016-04-14T20:10:51 <sipa> very minor, and possibly something that can't be maintained for future witness script version anyway
10482016-04-14T20:10:53 <Luke-Jr> nah, addresses are either p2sh or p2wsh, not both.
10492016-04-14T20:11:05 <sipa> Luke-Jr: scripts, not addresses
10502016-04-14T20:11:26 <sipa> but i agree it's minor
10512016-04-14T20:11:30 <wumpus> * [new tag] v0.12.1 -> v0.12.1
10522016-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..?
10532016-04-14T20:12:06 <sipa> Luke-Jr: you have an index from Hash160 -> script for known scripts
10542016-04-14T20:12:17 <sipa> Luke-Jr: that can be used for matching both P2SH and P2WSH
10552016-04-14T20:12:36 <Luke-Jr> but you don't need scripts for p2wsh in that index
10562016-04-14T20:13:08 <sipa> perhaps it's better that it's a separate index
10572016-04-14T20:13:10 <sipa> maybe
10582016-04-14T20:13:37 <Luke-Jr> oh, you mean just having two different indexes at all, even if non-overlapping
10592016-04-14T20:14:07 <sipa> well you need an index anyway for p2wsh scripts
10602016-04-14T20:14:26 <sipa> the question is whether it can be the same one or not :)
10612016-04-14T20:14:46 * sipa afk
10622016-04-14T20:18:33 *** frankenmint has quit IRC
10632016-04-14T20:19:36 *** mrkent_ has joined #bitcoin-core-dev
10642016-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
10652016-04-14T20:21:47 <CodeShark> this would give us flexibility to apply other hash functions or transformations later on
10662016-04-14T20:22:01 *** Chris_Stewart_5 has quit IRC
10672016-04-14T20:22:04 *** muuqwaul has quit IRC
10682016-04-14T20:22:06 <CodeShark> but I would like to avoid special cases
10692016-04-14T20:22:30 *** muuqwaul has joined #bitcoin-core-dev
10702016-04-14T20:22:34 *** mrkent has quit IRC
10712016-04-14T20:29:41 *** zooko has quit IRC
10722016-04-14T20:36:26 *** Chris_Stewart_5 has joined #bitcoin-core-dev
10732016-04-14T20:39:34 *** slackircbridge has quit IRC
10742016-04-14T20:40:48 *** slackircbridge has joined #bitcoin-core-dev
10752016-04-14T20:51:07 *** muuqwaul has quit IRC
10762016-04-14T20:51:30 *** muuqwaul has joined #bitcoin-core-dev
10772016-04-14T20:54:50 *** johnwhitton has quit IRC
10782016-04-14T20:55:02 *** cguida has joined #bitcoin-core-dev
10792016-04-14T20:58:37 *** erasmospunk has joined #bitcoin-core-dev
10802016-04-14T21:00:11 *** brg444 has quit IRC
10812016-04-14T21:05:47 *** cguida has quit IRC
10822016-04-14T21:12:28 *** Chris_Stewart_5 has quit IRC
10832016-04-14T21:21:00 *** johnwhitton has joined #bitcoin-core-dev
10842016-04-14T21:27:11 *** mrkent has joined #bitcoin-core-dev
10852016-04-14T21:28:52 *** mrkent_ has quit IRC
10862016-04-14T21:39:11 *** muuqwaul has quit IRC
10872016-04-14T21:39:35 *** muuqwaul has joined #bitcoin-core-dev
10882016-04-14T21:40:00 *** muuqwaul has quit IRC
10892016-04-14T21:40:25 *** muuqwaul has joined #bitcoin-core-dev
10902016-04-14T21:42:50 *** johnwhitton has quit IRC
10912016-04-14T21:43:27 *** johnwhitton has joined #bitcoin-core-dev
10922016-04-14T21:47:06 *** johnwhitton has quit IRC
10932016-04-14T21:52:56 *** Squidicuz has quit IRC
10942016-04-14T21:53:15 *** ryan-c has quit IRC
10952016-04-14T21:53:18 *** kangx has quit IRC
10962016-04-14T21:53:33 *** dgenr8 has quit IRC
10972016-04-14T21:54:47 *** pigeons has quit IRC
10982016-04-14T21:55:25 *** Evel-Knievel has quit IRC
10992016-04-14T21:56:08 *** pigeons has joined #bitcoin-core-dev
11002016-04-14T21:56:10 *** Evel-Knievel has joined #bitcoin-core-dev
11012016-04-14T21:56:31 *** pigeons is now known as Guest46972
11022016-04-14T21:56:47 *** ryan-c has joined #bitcoin-core-dev
11032016-04-14T21:58:45 *** dgenr8 has joined #bitcoin-core-dev
11042016-04-14T21:59:53 *** Guest46972 is now known as pigeons
11052016-04-14T22:00:48 *** johnwhitton has joined #bitcoin-core-dev
11062016-04-14T22:00:57 *** slackircbridge has quit IRC
11072016-04-14T22:04:31 *** sdaftuar has quit IRC
11082016-04-14T22:05:53 *** sdaftuar has joined #bitcoin-core-dev
11092016-04-14T22:08:16 *** TomMc has quit IRC
11102016-04-14T22:08:20 *** zooko has joined #bitcoin-core-dev
11112016-04-14T22:09:46 *** murch has quit IRC
11122016-04-14T22:10:33 *** dgenr8 has quit IRC
11132016-04-14T22:12:43 *** dgenr8 has joined #bitcoin-core-dev
11142016-04-14T22:13:24 *** johnwhitton has quit IRC
11152016-04-14T22:18:23 *** mrkent has quit IRC
11162016-04-14T22:22:03 *** Squidicuz has joined #bitcoin-core-dev
11172016-04-14T22:23:29 *** johnwhitton has joined #bitcoin-core-dev
11182016-04-14T22:24:42 *** erasmospunk has quit IRC
11192016-04-14T22:24:45 *** mrkent has joined #bitcoin-core-dev
11202016-04-14T22:26:20 *** johnwhitton has quit IRC
11212016-04-14T22:26:39 *** erasmospunk has joined #bitcoin-core-dev
11222016-04-14T22:27:35 *** johnwhitton has joined #bitcoin-core-dev
11232016-04-14T22:28:16 *** johnwhitton has quit IRC
11242016-04-14T22:29:50 *** davec has quit IRC
11252016-04-14T22:31:17 *** erasmospunk has quit IRC
11262016-04-14T22:31:47 *** isis has quit IRC
11272016-04-14T22:35:42 *** davec has joined #bitcoin-core-dev
11282016-04-14T22:39:19 *** isis has joined #bitcoin-core-dev
11292016-04-14T22:54:00 *** Cory has quit IRC
11302016-04-14T22:57:01 *** Cory has joined #bitcoin-core-dev
11312016-04-14T23:01:31 *** bsm117532 has quit IRC
11322016-04-14T23:09:31 *** Samdney has left #bitcoin-core-dev
11332016-04-14T23:26:39 *** Chris_Stewart_5 has joined #bitcoin-core-dev
11342016-04-14T23:58:05 *** Guyver2 has quit IRC