--- Day changed Thu Apr 14 2016
00:02 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
00:03 -!- binns [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev
00:13 < jonasschnelli> lmdb -reindex with default dbcache took ~6h42' http://pastebin.com/ERWMGb1p
00:13 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
00:14 < jonasschnelli> So ~2.5* slower then leveldb on the 4core 64bit linux machine I have testes.
00:14 < gmaxwell> doesn't really make sense that reindex would be slower.
00:15 < gmaxwell> since the sync is so much faster.
00:15 < gmaxwell> must be some reindex specific bug.
00:15 < jonasschnelli> gmaxwell: the sync is faster because it didn't touch the db (was dbcache=9000)
00:15 < gmaxwell> jonasschnelli: I benchmarked lmdb sync last weekend with default db cache.
00:15 < gmaxwell> it was _significantly_ faster than leveldb.
00:16 < jonasschnelli> hmm...
00:16 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
00:16 < gmaxwell> 5 hours 5 minutes vs 8 hours 27minutes.
00:16 < jonasschnelli> I'll do now a reindex with the same parameter on current master (leveldb).
00:17 < wumpus> so normally a reindex takes 2h40 on that machine with leveldb with default params?
00:18 < jonasschnelli> Hmm... the 2h40 was a sync from random peers. Not sure if I acctually did a reindex with leveldb. Doing now.
00:18 < jonasschnelli> I mean these are not scientific benchmarks... I'm just playing around.
00:18 < wumpus> compare reindex against reindex please :)
00:19 < jonasschnelli> yes. I'll do now.
00:19 < wumpus> sync from network can be faster than reindex in some cases
00:19 < gmaxwell> do we still have the thing where signature checks run during reindex at all blocks?
00:19 < jonasschnelli> I just expected the lmdb reindex to be faster then the leveldb random peer sync
00:19 < jonasschnelli> But right. could be an performance issue in reindex
00:19 < wumpus> (for that reason I tend to benchmark syncing from a fast local-network peer instead of reindex these days)
00:20 < wumpus> gmaxwell: I don't know, I don't think I even know of that issue
00:20 < NicolasDorier> wumpus: how is it possible ? as I thought reindex would do less work than a resync
00:21  * gmaxwell checks the microphone.
00:21 < wumpus> NicolasDorier: you'd expect so
00:22 < gmaxwell> yes it appears we do.
00:22 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
00:22 < gmaxwell> wumpus: I complained about it so much that I gave up complaining.
00:22 < 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
00:22 < wumpus> gmaxwell: did you ever file a github issue?
00:22 < gmaxwell> It's mildly hard to fix.
00:22 < gmaxwell> lemme see
00:22 < gmaxwell> and it looks still unfixed.
00:23 < wumpus> please do file an issue if there is none, complaining on IRC always gets lost
00:23 < gmaxwell> basically the reindex doesn't run headers first, so it doesn't have the headers ahead of the blocks
00:23 < gmaxwell> thus         if (pindexLastCheckpoint && pindexLastCheckpoint->GetAncestor(pindex->nHeight) == pindex) {
00:23 < gmaxwell> doesn't work.
00:23 < gmaxwell> and scriptchecks run on all blocks.
00:24 < jonasschnelli> okay. Thats explains it.
00:24 < jonasschnelli> We need to fix that. :)
00:24 < wumpus> yes
00:24 < gmaxwell> I'm looking to see if there is an issue. I believe there was.
00:24 < NicolasDorier> wumpus: if reindex does not need to write to block file, why is it slower ? it does not make sense oO
00:24 < wumpus> NicolasDorier: read what gmaxwell writes above
00:24 < gmaxwell> secp256k1 made it so much faster that it was like fixing it... at least for a bit, chain growth is compensating. :)
00:25 < 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
00:25 < NicolasDorier> oh
00:25 < NicolasDorier> I understand, thanks
00:26 < NicolasDorier> well, if you want to test performance, it is better to NOT have checkpoints right ?
00:26 < gmaxwell> NicolasDorier: sure but it resulted in jonasschnelli doing an apples/oranges test.
00:26 < wumpus> depends on what performance you want to measure, just compare apples against apples
00:26 < GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/514993554c37...8bb5d3dff46d
00:26 < GitHub33> bitcoin/master 4a1d5c1 fanquake: [Doc] Update gitian build guide to debian 8.4.0
00:26 < GitHub33> bitcoin/master 8bb5d3d Wladimir J. van der Laan: Merge #7838: [Doc] Update gitian build guide to debian 8.4.0...
00:27 < gmaxwell> https://github.com/bitcoin/bitcoin/issues/7875
00:27 < 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
00:27 < wumpus> if you want to compare pure database performance, disabling validation makes some sense
00:27 < jonasschnelli> gmaxwell: Yes. Right. Now started comparing Apple/Apples (reindex leveldb is running).
00:27 < jonasschnelli> What we really want is a db benchmark script.
00:27 < 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...
00:27 < jonasschnelli> script = test-suite thing.
00:28 < 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 :)
00:31 < 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
00:31 < jonasschnelli> Right. That could work.
00:31 < wumpus> (at least not anything that involves internet peers)
00:31 < jonasschnelli> I think sync from a local peer is also not really representative.
00:31 < wumpus> why not?
00:32 < jonasschnelli> The local peer could do some other work during your test (like a backup or a heavy log rotate, etc.).
00:32 < gmaxwell> if it's local you control that.
00:32 < wumpus> well no I make sure it is completely available to the other node for downloading, it has no other network connections
00:32 < jonasschnelli> Sure. But I'd prefer something that exclude network and another linux.
00:32 < gmaxwell> bigger problem is that low latency peers will conceal pipelining failures.
00:33 < 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.
00:33 < gmaxwell> of course, one can simulate real networks locally using dummynet.
00:33 < wumpus> yes there it gets into really difficult territory
00:33 < jonasschnelli> I think the reindex with disabled verification is probably better
00:33 < wumpus> benchmarking the network code
00:34 < wumpus> we're in 'benchmarking for dummies' here with the database :)
00:34 < gmaxwell> jonasschnelli: depends on what you're testing.
00:34 < jonasschnelli> For the db performance comparison 
00:34 < wumpus> for the db performance comparison using a reliable local peer is good enough - that won't be the bottleneck
00:35 < 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.
00:35 < wumpus> if you want to test pipelining in networking, well, good luck, there's stacks of books written about that :)
00:35 < gmaxwell> so my point is that the reindex like test is informative, but not complete.
00:35 < gmaxwell> wumpus: one can do a lot better just by testing with a more realistic setup. 
00:35 < wumpus> maybe we can find a phd student hehe
00:36 -!- ryankung [~ryankung@219.133.170.82] has quit []
00:36 < wumpus> gmaxwell: sure
00:36 < gmaxwell> e.g. for the testing for the recent inv changes sipa and I are working on, I setup a 14 node topology. 
00:36 < gmaxwell> (with actual systems, though that test could have been done with dummynet and VMs okay, I think)
00:37 < wumpus> tools that reproduce internet circumstances on a simluated network are great for that, absolutely
00:46 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Quit: cryptocoder]
00:46 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
00:46 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Client Quit]
00:47 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
00:47 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Client Quit]
00:55 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
00:58 -!- mase [~masonw@dhcp-228.ove463.fastlab.unca.edu] has joined #bitcoin-core-dev
00:58 < mase> hey
00:59 < mase> I am unravling the secrets of bitcion
00:59 -!- mase [~masonw@dhcp-228.ove463.fastlab.unca.edu] has left #bitcoin-core-dev []
01:03 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
01:03 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
01:08 -!- p15x [~p15x@148.91.145.64.unassigned.bringover.net] has joined #bitcoin-core-dev
01:14 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:19 -!- Guest85557 [~socrates1@li175-104.members.linode.com] has quit [Changing host]
01:19 -!- Guest85557 [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-core-dev
01:19 -!- Guest85557 is now known as amiller
01:23 -!- murch [~murch@p4FE394A8.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:35 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: Konversation terminated!]
01:39 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…]
01:41 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
01:48 -!- laurentmt [~Thunderbi@128.79.141.196] has joined #bitcoin-core-dev
01:50 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:00 -!- laurentmt [~Thunderbi@128.79.141.196] has quit [Quit: laurentmt]
02:03 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 264 seconds]
02:08 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev
02:11 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection]
02:25 < jonasschnelli> We really need something like https://github.com/bitcoin/bitcoin/pull/7551 for 0.13
02:26 < jonasschnelli> Importing a couple of addresses (for watching) is sooo painful on mainnet today.
02:26 < wumpus> I'm just in the preparations for merging it
02:27 < wumpus> agree, of course, it was long due
02:27 < sipa> concept ack on importmulti
02:27 < jonasschnelli> I also blame myself because I have never tested PR #7551
02:27 < sipa> sorry for not having looked at it more
02:28 < jonasschnelli> wumpus: while you at it (*duck*): https://github.com/bitcoin/bitcoin/pull/7518
02:28 < jonasschnelli> This PR seems also very valuable.
02:28 < sipa> wumpus: can you wait one second
02:28 < jonasschnelli> I have tested it a couple of times... but probably needs at least another tACK
02:29 < wumpus> jonasschnelli: will take a look
02:31 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
02:31 -!- frankenm_ [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
02:31 -!- murch [~murch@p4FE394A8.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds]
02:32 -!- p15x [~p15x@148.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 244 seconds]
02:32 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-hkbukihngashvatl] has quit [Read error: Connection reset by peer]
02:33 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 252 seconds]
02:33 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 252 seconds]
02:33 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 252 seconds]
02:33 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 252 seconds]
02:33 -!- TD--Linux [~Thomas@kyoko.thomasdaede.com] has quit [Ping timeout: 252 seconds]
02:33 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 252 seconds]
02:33 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has quit [Ping timeout: 252 seconds]
02:33 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
02:34 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
02:35 -!- aj [aj@106.187.51.212] has joined #bitcoin-core-dev
02:37 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
02:37 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
02:39 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has joined #bitcoin-core-dev
02:40 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-uuthswencllsunig] has joined #bitcoin-core-dev
02:43 < wumpus> thanks for the review on #7551 sipa
02:46 -!- murch [~murch@p4FE394A8.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
02:48 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
02:50 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-core-dev
02:52 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
03:09 < GitHub43> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/8bb5d3dff46d...536b75e946fb
03:09 < GitHub43> bitcoin/master 11114a6 MarcoFalke: [amount] test negative fee rates and full constructor
03:09 < GitHub43> bitcoin/master fa2da2c MarcoFalke: [amount] Add support for negative fee rates...
03:09 < GitHub43> bitcoin/master facf5a4 MarcoFalke: [amount] tests: Fix off-by-one mistake
03:09 < GitHub175> [bitcoin] laanwj closed pull request #7796: [amount] Add support for negative fee rates (master...Mf1604-amountNeg64) https://github.com/bitcoin/bitcoin/pull/7796
03:09 < 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.
03:09 < jonasschnelli> What if you need to add an input to fit the new fee?
03:09 < sipa> yes?
03:10 < jonasschnelli> bigger tx size, more fee required.
03:10 < GitHub187> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/536b75e946fb...b778e5993af9
03:10 < GitHub187> bitcoin/master fa6399d MarcoFalke: [doc] gitian: Replace precise with trusty
03:10 < GitHub187> bitcoin/master b778e59 Wladimir J. van der Laan: Merge #7855: [doc] gitian: Replace precise with trusty...
03:10 < jonasschnelli> Just adding minTxRelayFee is not sufficient IMO
03:10 < sipa> jonasschnelli: yes, which the relay fee will account for
03:10 < sipa> minTxRelayFee is a feerate, you multiply it by the size of the tx
03:11 < jonasschnelli> But you don't know the size before you did ran the coinselection...
03:11 < jonasschnelli> rucksack problem, thats why I though running the CreateTransaction logic again
03:12 < jonasschnelli> s/rucksack/knapsack 
03:12 < sipa> ok, i'm missing some context i think
03:13  * jonasschnelli afk for 1h
03:14 -!- murch [~murch@p4FE394A8.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
03:15 < GitHub61> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b778e5993af9...72c54e388315
03:15 < GitHub61> bitcoin/master 85c807c Rusty Russell: getblockchaininfo: make bip9_softforks an object, not an array....
03:15 < GitHub61> bitcoin/master d12760b Rusty Russell: rpc-tests: handle KeyError nicely in test_framework.py...
03:15 < GitHub61> bitcoin/master 72c54e3 Wladimir J. van der Laan: Merge #7863: getblockchaininfo: make bip9_softforks an object, not an array....
03:15 < 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
03:18 < sipa> do we backport 7863 to 0.12?
03:21 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
03:25 < wumpus> yes, it needs to be backported to 0.12 eventually
03:26 < wumpus> if there is 0.12.1rc3 may as well be in it
03:27 < Luke-Jr> I wonder sometimes if it should be named "bip9", but I can argue both ways, so I haven't brought it up.
03:27 < Luke-Jr> probably not important enough to matter
03:28 < wumpus> yes, feel no need to even have an opinion about it
03:31 -!- erasmospunk [~erasmospu@151.41.89.199] has joined #bitcoin-core-dev
03:38 < 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
03:40 < wumpus> (I'd really like to switch to a setup where the source code is on a different disk from the binaries)
03:41 < sipa> wumpus: squashfs? :p
03:42 < wumpus> lol would you compress the binaries or the source code?
03:42 < sipa> oops, i mean unionfs
03:43 < wumpus> could work I guess, but seems overkill, every project just supports out-of-tree builds except bitcoin core :)
03:47 < wumpus> but unionfs does look interesting, could help in some other cases
03:47 < 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)
03:48 < 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
03:50 < 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
04:24 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
04:24 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
04:28 -!- harding_ [~harding@mail.dtrt.org] has quit [Ping timeout: 244 seconds]
04:28 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 244 seconds]
04:28 -!- harding [~harding@mail.dtrt.org] has joined #bitcoin-core-dev
04:28 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
04:29 -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has quit [Ping timeout: 244 seconds]
04:29 -!- gavinandresen [~gavin@unaffiliated/gavinandresen] has joined #bitcoin-core-dev
04:37 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has quit [Ping timeout: 244 seconds]
04:37 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev
04:38 -!- gmaxwell is now known as Guest75512
04:39 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
04:39 < 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
04:39 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
04:47 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has joined #bitcoin-core-dev
04:48 -!- dermoth [~thomas@dsl-66-36-145-24.mtl.aei.ca] has quit [Ping timeout: 244 seconds]
04:56 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 260 seconds]
04:59 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
05:01 -!- RoyceX [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
05:03 -!- roasbeef_ [~root@104.131.26.124] has quit [Ping timeout: 250 seconds]
05:04 -!- roasbeef [~root@104.131.26.124] has joined #bitcoin-core-dev
05:04 -!- cheese_ [~x@unaffiliated/cheeseo] has quit [Ping timeout: 250 seconds]
05:11 -!- aureianimus_ [~quassel@s55963df3.adsl.online.nl] has quit [Ping timeout: 250 seconds]
05:11 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev
05:15 -!- jtimon [~quassel@18.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
05:15 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:16 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:17 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:18 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:19 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:20 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:20 -!- lejitz [~lejitz@cpe-72-181-158-116.tx.res.rr.com] has joined #bitcoin-core-dev
05:20 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:21 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:22 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:22 -!- lejitz [~lejitz@cpe-72-181-158-116.tx.res.rr.com] has quit [Client Quit]
05:23 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:24 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:25 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:25 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:27 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:27 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:28 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:29 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:30 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:31 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:31 -!- spikeheadon [~spikes@122.168.199.215] has quit [Max SendQ exceeded]
05:32 -!- spikeheadon [~spikes@122.168.199.215] has joined #bitcoin-core-dev
05:34 -!- Expanse [sid146237@gateway/web/irccloud.com/x-pjogrjldxrhoipwr] has quit [Ping timeout: 264 seconds]
05:34 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-rfajnswdzctwffig] has joined #bitcoin-core-dev
05:36 -!- OxADADA_ is now known as OxADADA
05:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:41 -!- Expanse [sid146237@gateway/web/irccloud.com/x-qjpyohkgmbzvgobg] has joined #bitcoin-core-dev
05:47 < GitHub198> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/229a17ca915c...ab8586e6677a
05:47 < GitHub198> bitcoin/master 4521f00 Wladimir J. van der Laan: tests: add varints_bitpatterns test...
05:47 < GitHub198> bitcoin/master ab8586e Wladimir J. van der Laan: Merge #7849: tests: add varints_bitpatterns test...
05:47 < 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
05:54 -!- erasmospunk [~erasmospu@151.41.89.199] has quit [Remote host closed the connection]
05:55 < GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ab8586e6677a...97d0b9889f15
05:55 < GitHub183> bitcoin/master 7e91f63 Suhas Daftuar: Use txid as key in mapAlreadyAskedFor...
05:55 < GitHub183> bitcoin/master 97d0b98 Wladimir J. van der Laan: Merge #7862: Use txid as key in mapAlreadyAskedFor...
05:55 < 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
06:02 -!- erasmospunk [~erasmospu@151.41.89.199] has joined #bitcoin-core-dev
06:05 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 244 seconds]
06:06 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
06:11 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Ping timeout: 244 seconds]
06:12 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
06:14 < 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
06:15 -!- erasmosp_ [~erasmospu@151.41.89.199] has joined #bitcoin-core-dev
06:15 -!- cguida_ [~chris@162.216.46.162] has joined #bitcoin-core-dev
06:15 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
06:16 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
06:16 -!- ibrightly_ [sid113387@gateway/web/irccloud.com/x-orlblwaqzjnreyms] has joined #bitcoin-core-dev
06:17 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-uuthswencllsunig] has quit [Ping timeout: 276 seconds]
06:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 276 seconds]
06:17 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Ping timeout: 276 seconds]
06:17 -!- ibrightly_ is now known as ibrightly
06:17 -!- erasmospunk [~erasmospu@151.41.89.199] has quit [Ping timeout: 276 seconds]
06:17 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 276 seconds]
06:17 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has quit [Ping timeout: 276 seconds]
06:17 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Ping timeout: 276 seconds]
06:17 -!- cguida [~chris@162.216.46.162] has quit [Ping timeout: 276 seconds]
06:18 -!- jarret [~jarret@162.216.46.40] has quit [Ping timeout: 276 seconds]
06:18 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 276 seconds]
06:18 -!- cguida_ is now known as cguida
06:18 -!- roasbeef [~root@104.131.26.124] has joined #bitcoin-core-dev
06:18 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Ping timeout: 276 seconds]
06:18 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev
06:18 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has joined #bitcoin-core-dev
06:19 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
06:19 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev
06:20 -!- jarret [~jarret@162.216.46.40] has joined #bitcoin-core-dev
06:33 -!- ebfull [~sean@73.34.119.0] has quit [Ping timeout: 244 seconds]
06:35 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
06:41 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
06:46 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
06:47 < GitHub171> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/97d0b9889f15...491171f92954
06:47 < GitHub171> bitcoin/master 5eeb913 Pieter Wuille: Clean up lockorder data of destroyed mutexes...
06:47 < GitHub171> bitcoin/master 491171f Wladimir J. van der Laan: Merge #7846: Clean up lockorder data of destroyed mutexes...
06:47 < GitHub9> [bitcoin] laanwj closed pull request #7846: Clean up lockorder data of destroyed mutexes (master...cleanlocks) https://github.com/bitcoin/bitcoin/pull/7846
06:47 -!- Amnez777 [~Amnez777@37.157.216.178] has quit [Ping timeout: 264 seconds]
06:48 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has quit [Ping timeout: 264 seconds]
06:48 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 264 seconds]
06:48 -!- frankenm_ [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 264 seconds]
06:48 -!- fkhan_ [weechat@gateway/vpn/mullvad/x-jzbzzwxppbbjextx] has quit [Ping timeout: 264 seconds]
06:48 -!- crescendo [~mozart@unaffiliated/crescendo] has quit [Ping timeout: 264 seconds]
06:49 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 264 seconds]
06:49 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 264 seconds]
06:49 -!- sturles [~sturles@unaffiliated/sturles] has quit [Ping timeout: 264 seconds]
06:49 -!- da2ce7_mobile [~da2ce7@opentransactions/dev/da2ce7] has quit [Ping timeout: 264 seconds]
06:49 -!- kinlo [peter@unaffiliated/kinlo] has quit [Ping timeout: 264 seconds]
06:49 -!- kinlo [peter@unaffiliated/kinlo] has joined #bitcoin-core-dev
06:50 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
06:50 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev
06:50 -!- sturles [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev
06:50 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
06:51 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
06:53 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
06:54 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has joined #bitcoin-core-dev
06:54 -!- d_t [~textual@185.69.203.10] has quit [Ping timeout: 244 seconds]
06:55 -!- Amnez777 [~Amnez777@37.157.216.178] has joined #bitcoin-core-dev
06:56 -!- ryankung [~ryankung@219.133.170.82] has joined #bitcoin-core-dev
06:57 -!- da2ce7_mobile [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev
06:57 -!- Pasha is now known as Cory
07:01 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
07:01 -!- fkhan_ [weechat@gateway/vpn/mullvad/x-rrsmsophibitkpni] has joined #bitcoin-core-dev
07:04 -!- ryankung [~ryankung@219.133.170.82] has quit [Ping timeout: 244 seconds]
07:10 < GitHub48> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/491171f92954...d97101e5a84b
07:10 < GitHub48> bitcoin/master 62a6486 Pavel Janík: RPC: do not print ping info in getpeerinfo when no ping received yet, fix help
07:10 < GitHub48> bitcoin/master d97101e Wladimir J. van der Laan: Merge #7842: RPC: do not print minping time in getpeerinfo when no ping received yet...
07:10 < 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
07:12 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
07:12 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
07:13 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
07:13 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
07:15 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
07:16 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
07:24 -!- Schlorted [~Greybits@unaffiliated/greybits] has joined #bitcoin-core-dev
07:27 < GitHub86> [bitcoin] sipa opened pull request #7877: Change mapRelay to store CTransactions (master...relayctransaction) https://github.com/bitcoin/bitcoin/pull/7877
07:35 < GitHub101> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d97101e5a84b...430fffefaab6
07:35 < GitHub101> bitcoin/master 4f7c959 Jonas Schnelli: Refactor IsRBFOptIn, avoid exception
07:35 < GitHub101> bitcoin/master 430fffe Wladimir J. van der Laan: Merge #7812: Tiny refactor of `IsRBFOptIn`, avoid exception...
07:35 < 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
07:42 -!- laurentmt [~Thunderbi@3-133-190-109.isp.overthebox.ovh] has joined #bitcoin-core-dev
07:45 < jtimon> ping #7779
07:54 -!- laurentmt [~Thunderbi@3-133-190-109.isp.overthebox.ovh] has quit [Ping timeout: 244 seconds]
07:56 -!- laurentmt [~Thunderbi@3-133-190-109.isp.overthebox.ovh] has joined #bitcoin-core-dev
07:57 -!- johnwhitton_ [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton_]
08:01 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
08:01 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer]
08:03 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
08:04 -!- laurentmt [~Thunderbi@3-133-190-109.isp.overthebox.ovh] has quit [Ping timeout: 244 seconds]
08:10 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
08:13 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
08:15 -!- xiangfu [~xiangfu@60.10.71.37] has joined #bitcoin-core-dev
08:17 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
08:17 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
08:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
08:19 -!- spikeheadon [~spikes@122.168.199.215] has quit [Ping timeout: 244 seconds]
08:19 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
08:20 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
08:25 -!- xiangfu [~xiangfu@60.10.71.37] has quit [Remote host closed the connection]
08:47 < GitHub90> [bitcoin] laanwj closed pull request #7131: Add 'setblockmaxsize' RPC interface (master...setblockmaxsize) https://github.com/bitcoin/bitcoin/pull/7131
08:49 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
08:50 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
08:54 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
08:57 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
09:05 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
09:19 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
09:19 -!- murch [~murch@p4FE394A8.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
09:20 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Client Quit]
09:21 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-orlfnjdbxxpihaqu] has joined #bitcoin-core-dev
09:21 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
09:24 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
09:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
09:28 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
09:30 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
09:33 -!- zooko [~user@2601:281:8000:8387:8c61:7861:dd59:f2f9] has joined #bitcoin-core-dev
09:34 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
09:59 -!- Guest75512 is now known as gmaxwell
09:59 -!- gmaxwell [greg@mf4-xiph.osuosl.org] has quit [Changing host]
09:59 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev
10:02 -!- MarcoFalke [d9fe8461@gateway/web/cgi-irc/kiwiirc.com/ip.217.254.132.97] has joined #bitcoin-core-dev
10:17 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:18 -!- cryptocoder_ [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
10:18 -!- hsmiths2 [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
10:19 -!- erasmospunk [~erasmospu@151.41.89.199] has joined #bitcoin-core-dev
10:20 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 252 seconds]
10:20 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Ping timeout: 252 seconds]
10:20 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 252 seconds]
10:20 -!- Schlorted [~Greybits@unaffiliated/greybits] has quit [Ping timeout: 252 seconds]
10:20 -!- sturles [~sturles@unaffiliated/sturles] has quit [Ping timeout: 252 seconds]
10:20 -!- erasmosp_ [~erasmospu@151.41.89.199] has quit [Ping timeout: 252 seconds]
10:20 -!- cryptocoder_ is now known as cryptocoder
10:21 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 252 seconds]
10:21 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 252 seconds]
10:21 -!- jtimon [~quassel@18.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds]
10:21 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
10:21 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
10:21 -!- jtimon [~quassel@18.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
10:21 -!- sturles [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev
10:26 -!- cryptocoder_ [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
10:27 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Ping timeout: 276 seconds]
10:27 -!- cryptocoder_ is now known as cryptocoder
10:37 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
10:37 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
10:38 -!- Schlorted [~Greybits@unaffiliated/greybits] has joined #bitcoin-core-dev
10:48 -!- erasmosp_ [~erasmospu@151.41.89.199] has joined #bitcoin-core-dev
10:50 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 276 seconds]
10:50 -!- erasmospunk [~erasmospu@151.41.89.199] has quit [Ping timeout: 276 seconds]
10:51 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
10:51 -!- murch [~murch@p4FE394A8.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds]
10:51 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 276 seconds]
10:51 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
10:52 -!- pigeons is now known as Guest69947
10:53 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev
10:54 -!- murch [~murch@p4FE394A8.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:54 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
10:55 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
10:55 < OxADADA> we're using Kramdown for the bitcoin-core website, yes? GitHub is moving away from the other Markdown parsers.
10:55 < OxADADA> yes, we are using kramdown, we're good
10:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:01 < GitHub44> [bitcoin] MarcoFalke opened pull request #7878: [test] bctest.py: Revert faa41ee (master...Mf1604-bctestPy) https://github.com/bitcoin/bitcoin/pull/7878
11:09 -!- erasmosp_ [~erasmospu@151.41.89.199] has quit [Remote host closed the connection]
11:11 < jonasschnelli> Here is the comparison between reindex of current master vs wumpuses LMDB branch:
11:11 < jonasschnelli> http://pastebin.com/raw/evx62gak
11:12 < jonasschnelli> leveldb was 1.2842709773 faster
11:17 -!- MarcoFalke [d9fe8461@gateway/web/cgi-irc/kiwiirc.com/ip.217.254.132.97] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
11:19 < 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)?
11:20 < sipa> there is not even an rpc that can show the fee of a raw transaction :)
11:20 < sipa> oh, you mean the estimated necessary fee for a transaction?
11:20 -!- Guest69947 is now known as pigeons
11:20 < jonasschnelli> No. Forget about the example calculation above (its wrong).
11:20 < jonasschnelli> The absolute fee and the feerate would be nice.
11:20 < jonasschnelli> we should add that to decoderawtransaction
11:21 < sipa> we can't
11:21 < sipa> transactions don't have a "fee" field
11:21 < sipa> you need to know the input
11:21 < jonasschnelli> Lookup?
11:22 < sipa> decoderawtransaction decodes
11:22 < jonasschnelli> Thats true.
11:22 < sipa> it also doesn't tell you what scriptPubKeys were spent
11:22 < sipa> or what height the transaction is in
11:22 < sipa> furthermore, we generally *cannot* look that up
11:22 < jonasschnelli> Well, at least we could tell the estimate fee (size*estimatefee(2))
11:22 < sipa> because that information is no longer in the UTXO set
11:23 < jonasschnelli> Yes. Would only work for unspent inputs.
11:23 < sipa> right
11:23 < sipa> i guess that's still useful
11:23 < jonasschnelli> Hmm.. but can be confusing if the rawtx is not signed,... maybe estimating the signature size *duck*
11:27 < gmaxwell> showing an estimate fee there would be potentially dangerous when someone mistakes it for the actual fee.
11:29 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
11:31 < jonasschnelli> Yes. I think the nested command extension I have added to the GUI could be usefull for bitcoin-cli for such situations.
11:32 < jonasschnelli> estimatefee(2)*decoderawtransaction(<hex>)['size']
11:32 < jonasschnelli> missing a /1000
11:34 < 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.
11:34 < 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.
11:34 < jonasschnelli> Agree. decoderawtransaction(<hex>)['size'] is stupid
11:35 < jonasschnelli> Only makes sense if you also need other data form the call.
11:38 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
11:38 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
11:43 < sipa> gmaxwell: i guess it would be convenient past segwit
11:43 < sipa> to get vsize
11:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
12:00 < cfields> meeting?
12:00 < gmaxwell> Hi all.
12:00 < wumpus> I guess?
12:00 < sdaftuar> hello
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Apr 14 19:00:50 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < morcos> confidence inspiring wumpus
12:01 < btcdrak> gavel wont be attending due to last week's beating.
12:01 < cfields> heh
12:01 < gmaxwell> "If I have to."
12:01 < wumpus> topics?
12:01 < gmaxwell> Whats up with the 0.12.1 release? I haven't been paying attention to it.
12:01 < morcos> status of 12.1 
12:01 < btcdrak> 0.12.1 status
12:01 < wumpus> 0.12.1 is at rc2
12:02 < wumpus> haven't heard of any issues with it
12:02 < gmaxwell> There was a 0.12.1(rc) block mined in the last week.
12:02 < sipa> i suggest we go ahead with release?
12:02 < jonasschnelli> +1
12:02 < btcdrak> +10
12:02 < sipa> -11
12:03 < btcdrak> doh!
12:03 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 260 seconds]
12:03 < gmaxwell> +1i. 
12:03 < sipa> gmaxwell: interesting; block version 0x2..?
12:03 < sipa> but not classic
12:03 < Luke-Jr> we should release 0.12.1 when 0.12.1 is observed to be released.
12:04 < sipa> Luke-Jr is the first member of the club containing Luke-Jr as first member
12:04 < 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. :) 
12:04 < Luke-Jr> that sounds lonely.
12:04 < 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
12:04 < sipa> wumpus: ok
12:04 < wumpus> but if you insist
12:05 < sipa> topic suggestion: segwit and backports
12:05 < btcdrak> let's insist
12:05 < jonasschnelli> Yes. We should wait at least one week.
12:05 < gmaxwell> sipa: but at least thats just a one time event.
12:05 < 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. :)
12:05 < Luke-Jr> could start the gitian building now and wait the rest of the week to publish?
12:06 < jonasschnelli> the tag could be seen as "release"
12:06 < btcdrak> 1 business week is 5 days :)
12:06 < wumpus> good to hear a block would mined with 0.12.1 though, hadn't heard that yet 
12:06 < wumpus> s/would/was
12:06 < btcdrak> why not tag 0.12.1 we can build over the weekend and release on Monday?
12:07 < jonasschnelli> Why not tag on monday and build on monday?
12:07 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:07 < jonasschnelli> You don't need to handhold you bulder?
12:07 < sipa> wumpus decides
12:07 < gmaxwell> the building has latency.
12:07 < wumpus> you're too eager 
12:07 < btcdrak> gotta build, cfields needs to sign etc.
12:07 < gmaxwell> in the future we should figure out how to deseralize builds of the final release and publication of the tag.
12:08 < wumpus> huh
12:08 < jonasschnelli> we could agree on a commit and build that and tag later.
12:08 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds]
12:08 < 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.
12:08 < 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
12:08 < wumpus> is this still serious?
12:08 < cfields> fwiw, dropping the commit hash in the binary would create a few more options
12:08 < sipa> wumpus: no
12:09 < wumpus> ok...
12:09 < wumpus> next topic?
12:09 < jonasschnelli> [21:05:02]  <sipa>	topic suggestion: segwit and backports
12:09 < btcdrak> segwit backports
12:09 < wumpus> #topic segwit and backports
12:09 < sipa> so, segwit branch is currently on top of 0.12.1
12:09 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
12:10 < btcdrak> so you'd be forward porting it to master 
12:10 < sipa> with a set of backports from master and some PRs first
12:10 < Luke-Jr> it would be ideal if the same branch can merge into both 0.12 and master, but that seems unlikely for segwit
12:10 < sipa> i don't know what the best way forward is, but i think we're close to PRing it for bitcoin
12:10 < 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.
12:10 < Luke-Jr> gmaxwell: nice!
12:11 < cfields> sipa: woohoo!
12:11 < wumpus> gmaxwell:  "and then having binary days delayed is suboptimal." why don't you ever gitian-build? :p
12:11 < sipa> do we rebase on master, have that merged first, and then "magically" come up with a 0.12 backport? :D
12:11 < sipa> which happens to include the necessary backports
12:11 < btcdrak> sipa: I hear you are good at magic
12:12 < Luke-Jr> sipa: what's the current segwit branch?
12:12 < Luke-Jr> without segnet ideally
12:12 < sipa> Luke-Jr: segwit4 and segwit (the first is where i continuously rebase, the second i push to whenever there is something significant)
12:12 < 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
12:12 < sipa> Luke-Jr: they have segnet, though the commits for segnet are separate and can easily be skipped
12:13 < gmaxwell> wumpus: if you'd like me to do so, I will. (re gitian builds)
12:13 < sipa> that's anohter question: do we merge segnet?
12:13 < btcdrak> gmaxwell: yes please.
12:13 < wumpus> gmaxwell: I dont mind, but please don't complain if you're not involved okay :)
12:13 < btcdrak> sipa: do we really need segnet?
12:14 < sipa> btcdrak: i don't think so
12:14 < 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.
12:14 < sipa> that sounds fine to me
12:14 < 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
12:14 < btcdrak> morcos: no complaints
12:14 < morcos> We should just rip the bandaid off and get it in
12:14 < 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.
12:15 < morcos> And then every other PR out there can get conflicted once and be done with it
12:15 < btcdrak> in all fairness there has been so much testing and peer review and help from downstream consumers with segwit.
12:15 < sipa> ok, will PR soon
12:15 < 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.
12:15 < sipa> both master and 0.12
12:15 < btcdrak> super. jonasschnelli you should close your preview PR so it doesnt get confusing
12:15 < 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.
12:16 < jonasschnelli> Yes. Will close. Its pointing also to the wrong branch.
12:16 < btcdrak> gmaxwell: maybe we dont need to over complicate if the PR/backport will come soon.
12:16 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-core-dev
12:16 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Quit: johnwhitton]
12:18 < 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.
12:18 < sipa> that makes sense
12:20 < sipa> any other topics?
12:20 < wumpus> what about c++11 status?
12:20 < sipa> ack
12:20 < wumpus> #topic c++11 status
12:20  * sipa summons cfields
12:21 < cfields> wumpus: travis has enabled caching but only for flagged projects. I mailed this morning and asked for the flag.
12:21 < sipa> cfields: is that the final blocker?
12:21 < cfields> sipa: as far as i know, yes
12:21 < sipa> awesome
12:21 < wumpus> that was already the case right? open source projects needed a flag to support caching. But we need a new one now?
12:22 -!- Schlorted [~Greybits@unaffiliated/greybits] has quit [Remote host closed the connection]
12:22 < wumpus> hopefully theyll give it :)
12:22 < cfields> wumpus: no, for trusty
12:22 < cfields> sec..
12:22 < cfields> https://github.com/travis-ci/travis-scheduler/pull/14
12:23 < cfields> merged last week
12:23 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
12:23 < wumpus> great!
12:23 < sipa> how do we plan to proceed after that?
12:23 < wumpus> hopefully we can start supporting it this week then
12:23 < gmaxwell> would we be using C++11 in 0.13 then?
12:24 < 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
12:24 < wumpus> gmaxwell: that was the plan
12:24 < Luke-Jr> Travis is not willing to flag just any projects. We should try to avoid relying on it.
12:24 < gmaxwell> wumpus: good. :)
12:24 < 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...
12:25 < cfields> otherwise, I'm afraid it'll be endless PRs
12:25 < cfields> Luke-Jr: it's just a flag while it's in testing
12:25 < sipa> cfields: there are a couple of mechanic translations i think we'll want ayt some point
12:25 < wumpus> I created this in december, a bit optimistic maybe, but five months later :) https://github.com/bitcoin/bitcoin/pull/7165
12:25 < 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.
12:25 < gmaxwell> at least thats my intuition.
12:25 < sipa> cfields: BOOST_FOREACH and boost::thread are good examples
12:25 < wumpus> replacing boost is far from mechanical
12:26 < wumpus> well ok some parts
12:26 < cfields> sipa: yes, for sure. what I worry about it thousands of PRs that sprinkle in std::move all over the place.
12:26 < morcos> is there any downside to using c++11 in new code while not yet doing any modernization PR's?
12:26 < sipa> but for example: adding move constructors instead of swaps everywhere
12:26 < gmaxwell> in particular I think it's probably unwise to do many moderinization updates when non C++11 versions are still supported.
12:26 < 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?
12:26 < cfields> (and emplace, which would be significant in several places)
12:26 < BlueMatt> Start with only new code is C++11, then only boost-replacement, then revisit
12:26 < BlueMatt> ?
12:26 < gmaxwell> because that would vastly complicate backports.
12:26 < sipa> one option is building with c++11 and c++03 both for a while
12:26 < 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)
12:26 < wumpus> meh
12:26 < cfields> morcos: i think that would be my preference
12:26 < wumpus> we can already build with c++11 for quite a while, that's nothing new
12:27 < sipa> ok
12:27 < sipa> just not too actively replace things initially
12:27 < BlueMatt> I mean for 0.13 Id say dont actively replace anything unless its a big performance win
12:27 < Luke-Jr> at the very least, let's add something to configure that fails if C++11 is not supported?
12:27 < wumpus> we've never let refactors through too quickly
12:27 < wumpus> correctness is most imporant
12:28 < Luke-Jr> that way we get user reports
12:28 < gmaxwell> Matt has an upcoming PR that uses C++11 that it might be nice to not have to port to C++03. 
12:28 < wumpus> Luke-Jr: yes, see the pull I quoted
12:28 < wumpus> Luke-Jr: it fails without c++11 support
12:28 < BlueMatt> gmaxwell: for the tcp stuff I think it actually doesnt matter, I was just lazy...udp would be annoying to fix, I think
12:28 < cfields> wumpus: let's use a real example.. adding move ctors to our containers
12:28 < cfields> yea or nay?
12:28 < sipa> cfields: yay, please... but maybe not immediately
12:28 < BlueMatt> cfields: for 0.13, I'd vote only new code, maybe boost replacement, too
12:29 < wumpus> cfields: if it helps performance, absolute yay
12:29 -!- kangx [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has joined #bitcoin-core-dev
12:29 < sipa> (prevector specifically is unsafe to use for more complex types now)
12:29 < BlueMatt> but I'm always the annoyingly conservative one, sooooo
12:29 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
12:29 < wumpus> boost replacement is too late for 0.13
12:29 < sipa> wumpus: agree
12:29 < wumpus> too much work
12:29 < BlueMatt> wumpus: ehh, I meant partial-boost-replacement
12:29 < wumpus> we can do some minor things and use it in new code, but aiming to replace boost enitrely just won't work
12:29 < 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.
12:29 < sipa> just turning on c++11 may already give a performance improvement, because STL magically gets move constructors
12:30 < jonasschnelli> At least we could throw out boost::filesystem soon (there is no c++11 equivalent).
12:30 < 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
12:30 < wumpus> do a release from master
12:30 < wumpus> may work better with cfields' holiday too
12:30 < morcos> wumpus: but then not release segwit for 0.12?
12:30 < cfields> stupid inconvenient honeymoon...
12:30 < morcos> thats the issue right..  are we only going to support it on 0.13?
12:30 < sipa> cfields: priorities!
12:30 < jonasschnelli> heh!
12:30 < gmaxwell> morcos: I don't think we should do that.
12:31 < sipa> i think we should backport segwit to 0.12
12:31 < wumpus> (we have to change the release schedule a bit anyway)
12:31 < sipa> let's not push users too much
12:31 < btcdrak> if we release 0.13 we still have to backport to 0.12
12:31 < btcdrak> since we support this and prev version
12:31 < gmaxwell> wumpus: what kind of schedule change are you thinking of?
12:32 < gmaxwell> Can we talk about what notable features are still in flight that people are working on with an intent of targeting 0.13?
12:32 < btcdrak> maybe backport to 0.12 and release 0.13 early.
12:33 < morcos> whats the hurry to release 0.13 early in that case?   
12:33 < wumpus> yes was a bad idea
12:33 < btcdrak> This is the list of 0.13 milestones https://github.com/bitcoin/bitcoin/milestones/0.13.0
12:33 < wumpus> ntext topic
12:33 < phantomcircuit> jonasschnelli: was that benchmark of leveldb vs lmdb on a system with a hdd or ssd?
12:33 < jonasschnelli> ssd
12:33 < phantomcircuit> interesting
12:33 < jonasschnelli> (can be discussed after the meeting)
12:34 < gmaxwell> btcdrak: there are things people are working on that aren't PRs yet.
12:34 < 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
12:34 < 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?
12:35 < Luke-Jr> (and there's no reason it can't wait for 0.14 etc)
12:35 < wumpus> well the change we have to make in the 0.13 release schedule is to clear june - this works btter for cfields
12:35 < wumpus> but we can just as well postpone it to later, moving it ealier was just a stupid idea
12:35 < cfields> no reason to change just for me?
12:35 < 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.
12:35 < wumpus> well the rc cycle was exactly planned that
12:35 < wumpus> then*
12:36 < gmaxwell> wumpus: I dunno that its stupid. But it should be made with consideration.
12:36 < wumpus> can do that in july instead of june , no problem
12:36 < 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.
12:36 < wumpus> BlueMatt: release schedule 0.13: https://github.com/bitcoin/bitcoin/issues/7679
12:36 < 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.
12:36 < morcos> wumpus: yes i like the idea of pushing back 0.13 a bit
12:36 < sipa> gmaxwell: ack
12:36 < BlueMatt> gmaxwell: ACK
12:36 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 244 seconds]
12:37 < 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)
12:37 < 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
12:37 < BlueMatt> wumpus: ok, so release schedule stays as-is for now?
12:37 < wumpus> BlueMatt: I proposed moving the rc phase to july instead of june
12:37 < jonasschnelli> sdaftuar: good point.
12:37 < Luke-Jr> in talking about using C++11, we won't need GCC 5, right?
12:37 < Luke-Jr> because GCC 5 is not really a reasonable minimum yet
12:37 < BlueMatt> when does cfields gete back?
12:37 < morcos> wumpus: ack
12:38 < cfields> Luke-Jr: 4.8 should be fine, i think
12:38 < wumpus> no, we don't need gcc5, the features we should use of c++11 shoudl work in gcc4.8+
12:38 < Luke-Jr> k
12:38 < 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
12:38 < wumpus> otherwise we can't use trusty for building
12:38 < cfields> BlueMatt: july4ish
12:38 < wumpus> and that's the whole point
12:38 < sipa> that's clear, thank you
12:39 < cfields> BlueMatt: if it turns out to be too problematic, i can revisit the dates.
12:39 < 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.
12:39 < BlueMatt> cfields: lol, dont change honeymoon for us
12:39 < wumpus> cfields: no
12:39 < gmaxwell> Luke-Jr: https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
12:39 < morcos> cfields: you better hope your fiance doesnt read these logs
12:39 < jonasschnelli> haha
12:40 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
12:40 < cfields> heh
12:40 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
12:40 < BlueMatt> wumpus: ACK pushing 0.13 a month...gives a week or two for post-zurich things to make the feature freeze
12:40 < wumpus> sdaftuar: if we move the rc phase a month we can move the feature freeze with the same amount
12:40 < BlueMatt> wumpus: eg things that get reviewed in zurich can be cleaned up and merged before freeze
12:40 < wumpus> BlueMatt: right
12:40 < sdaftuar> wumpus: sounds good to me
12:41 < BlueMatt> ACKs on pushing a month?
12:41 < btcdrak> ACK
12:41 < wumpus> ack
12:41 < jonasschnelli> ack
12:41 < gmaxwell> ok
12:41 < Luke-Jr> I don't see any resolution to C++11's ABI issues in the github tracker - did that get resolved?
12:41 < morcos> ACK
12:41  * Luke-Jr not care on 0.13 schedule
12:41 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev
12:42 < wumpus> #action move 0.13 schedule a month forward
12:42 < cfields> Luke-Jr: what issues?
12:42 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Quit: johnwhitton]
12:42 < sipa> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/7165#issuecomment-165499462
12:42 < sipa> all known ABI issues result in link errors
12:43 < 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.
12:43 < wumpus> hah, c++14
12:43 < 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),
12:43 < wumpus> not looking forward to going through this again :(
12:43 < 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.
12:44 < BlueMatt> I think gmaxwell is more excited about tcp-smaller-block relay since his internet at home sucks
12:44 < 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.
12:44 < cfields> nice
12:44 < cfields> BlueMatt: you have a branch somewhere?
12:44 < 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 :)
12:45 < 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
12:45 < wumpus> cfields: how does it make sense that they will build with c++14 by default?!
12:45 < 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
12:45 < cfields> wumpus: i suppose because it should all be forward compat, in theory
12:45 < sipa> wumpus: i think c++14 has less impact on standard libraries
12:45 < cfields> BlueMatt: thanks
12:46 < sipa> and is much more incremental than c++11 was
12:46 < BlueMatt> cfields: if you want to tackle the udp-wip changing to libevent I'd owe you :)
12:46 < cfields> yes, c++14 as i see it is kinda a c++11 fixup
12:46 < wumpus> ok...
12:46 < Luke-Jr> cfields: IIRC, binaries (incl libraries) compiled with C++11 mode are incomptible with libraries compiled with C++98 mode.
12:46 < sipa> c++14 finally has a solution for the exponentially-sized error messages
12:46 < Luke-Jr> sipa: ok
12:46 < cfields> Luke-Jr: that has nothing to do with how we compile though. That'll be the case either way.
12:47 < gmaxwell> BlueMatt: mostly trying to avoid bleeding out over load increases permitted by segwit. :)
12:47 < wumpus> sipa: nice!
12:47 < cfields> BlueMatt: heh yes, we should sync up some
12:47 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
12:47 < Luke-Jr> cfields: ? our dependencies are compiled with C++98 in almost all cases today
12:47 < wumpus> anyhow any other meeting topics?
12:47 < kanzure> MAST bip status?
12:48 < gmaxwell> lol. way too premature for discussion here.
12:48 < btcdrak> kanzure: it got published BIP114
12:48 < 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.
12:48 < wumpus> Luke-Jr: cfields let's leave the small implementation details about the c++11 switch to after the meeting
12:48 < cfields> ack
12:48 < Luke-Jr> cfields: we do not build our dependencies typically.
12:48 < Luke-Jr> wumpus: k
12:49 < wumpus> I'm sure we'll get it to work somehow
12:49 < wumpus> #topic MAST bip status
12:49 < kanzure> no no, it was sufficiently NACKed
12:50 < sipa> i haven't looked at it yet
12:50 < instagibbs> https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki < fwiw
12:50 < wumpus> #link https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki 
12:51 < Luke-Jr> possible topic?: using SHA256d for segwit
12:52 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Quit: johnwhitton]
12:52 < wumpus> sha256d?
12:52 < 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
12:53 < sipa> wumpus: background: p2wsh scriptPubKeys contain a SHA256 (not double SHA256) of the witness program
12:53 < paveljanik> double sha256
12:53 < sipa> which is incompatible with the "P2SH^2" scheme that greg proposed a while ago
12:53 < wumpus> oh right
12:53 < wumpus> it would be consistent
12:53 < 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.
12:54 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
12:54 < gmaxwell> And consistency, I suppose.
12:54 < sipa> ... which interacts with the discussion of addresses for native segwit
12:54 < Luke-Jr> gmaxwell: there's no address types for bare segwit yet
12:54 < sipa> Luke-Jr: i do plan on proposing one 
12:54 < sipa> (though not immediately)
12:55 < Luke-Jr> yes, my point is that we have an opportunity to avoid breaking compatibility
12:55 < gmaxwell> we'd purposefully moved them out to avoid shedpainting and address-type-deployment issues from harming segwit consensus code deployment.
12:55 < phantomcircuit> gmaxwell: sha256d also prevents length extention attacks although i dont see how that's applicable here at all
12:55 < gmaxwell> Luke-Jr: I think that nativesegwit of that initial type is not likely to see long term use, see also that MAST bip.
12:55 < Luke-Jr> sipa: am I incorrect in assuming adjusting downstream code for this would be super trivial?
12:56 < sipa> Luke-Jr: probably, but we also don't have a way to deploy P2SH^2 easily
12:56 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Client Quit]
12:56 < Luke-Jr> gmaxwell: yes, but I think sipa wants an address format that works for all segwit outputs, regardless of version
12:57 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
12:57 < Luke-Jr> sipa: that's not something we need to bundle with making it possible
12:57 < gmaxwell> we should close the meeting and continue the discussion.
12:57 < sipa> ok
12:57 < gmaxwell> no resolution to this will happen this instant.
12:58 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
12:58 < sipa> #shutdown -h now meeting
12:59 < jonasschnelli> sudo!
12:59 < wumpus> #endmeeting
12:59 < lightningbot> Meeting ended Thu Apr 14 19:59:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:59 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.html
12:59 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.txt
12:59 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-14-19.00.log.html
12:59 < paveljanik> jonasschnelli, no need for sudo once you have # ;-)
12:59 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
12:59 < jonasschnelli> nerds! oO
12:59 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Client Quit]
12:59 < jtimon> meeting?
12:59 < gmaxwell> So, wrt p2sh^2. That got proposed eons ago and I think it's unlikely to ever get implemented.
13:00 < jonasschnelli> jtimon: hahaha
13:00 < gmaxwell> jtimon: an hour ago.
13:00 < jtimon> oh...
13:00 < phantomcircuit> timezones strike again
13:00 < jtimon> well, read the logs I guess
13:00 < btcdrak> jtimons needs to run an ntp daemon 
13:00 < kanzure> this is why we should abolish time zones
13:00 < Luke-Jr> gmaxwell: isn't the only major hold-up the backward compat issue?
13:00 < Luke-Jr> kanzure: tonal time! :D
13:00 < kanzure> i would be willing to accept tonal time if it means no more time zones
13:00 < paveljanik> meeting bot should be modified to ping people beforehand :-)
13:01 < 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". :)
13:01 < gmaxwell> Luke-Jr: no, well it requires yet another kind of witness data in transactions.
13:01 < sipa> Luke-Jr: plus that it's easily bypassable, and we could end up encouraging people to send to miners directly
13:01 < jtimon> phantomcircuit: I would share last week it was a 22:00, but it may may that I forgot about my last mistake
13:01 < Luke-Jr> gmaxwell: that's pretty simple now with segwit
13:01 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
13:01 < gmaxwell> the pairing crypto based scheme I came up with didn't have those issues but it's slow.
13:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:01 < jtimon> jonasschnelli: that would be indeed useful
13:01 < Luke-Jr> sipa: that assumes miners are willing to cooperate in the spam
13:01 < Luke-Jr> actively
13:02 < sipa> Luke-Jr: why wouldn't they, if people want to pay
13:02 < Luke-Jr> at the very least, such miners would likely opt to charge higher fees (I hope)
13:02 < jtimon> never mind much, I will eventually adapt to this without putting it in google calendar, you'll see
13:02 < sipa> p2sh^2 is also incompatible with forward compatible address types
13:03 < gmaxwell> sipa: I dunno, thats kind of an argument against any non-stanardness. Dust limits have been effective.
13:03 < sipa> gmaxwell: fair enough
13:03 < Luke-Jr> not necessarily? if all future address types are p2sh^2
13:03 < gmaxwell> But yes, it would be incompatible with address types that change the top hashing scheme.
13:03 < wumpus> jtimon: date -u , if it shows thursday 19:00-20:00 it's time for the meeting :)
13: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
13:04 < sipa> then it can be compatible
13:04 < 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.
13:04 < gmaxwell> No but we can be a bit more future robust than p2sh was.
13:04 < gmaxwell> There is a greater archectural question around the pace of script changes.
13:04 -!- ebfull [~sean@73.34.119.0] has quit [Ping timeout: 260 seconds]
13:05 < 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.
13:05 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
13:05 < CodeShark> how is simply encoding the scriptPubKey not fully general?
13:06 < sipa> CodeShark: it doesn't cover P2SH^2
13:06 < Luke-Jr> gmaxwell: hopefully all scripts will be inside the witness
13:06 < sipa> CodeShark: but apary from that, yes
13:06 < sipa> Luke-Jr: the witness version number needs to be outside
13:06 < CodeShark> what's P2SH^2?
13:06 < Luke-Jr> kanzure: http://176.9.18.83:5984/buddy-clock/_design/site/_list/show/by_tz btw
13:06 < Luke-Jr> sipa: yes, but that doesn't interfere with p2sh^2
13:07 < 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)
13:07 < instagibbs> can we get the post on p2sh^2? I read it like 3 years ago, forgot the details
13:07 < instagibbs> oh ok
13:07 < sipa> CodeShark: this guarantees that the data in the output is a hash, and not data storage
13: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).
13:08 < gmaxwell> A practice which is a major accounting nusance for many parties.
13:08 < sipa> b.i will of course publish all the preimages they see in the network
13:08 < CodeShark> so no more shakespeare in the blockchain? :( https://www.smartbit.com.au/tx/8f64d2b7a762767e3870c4aee95f8c7b5439cf02cf7d7e5d99b6e39967ecada8
13:08 < sipa> *ducks*
13:09 < gmaxwell> CodeShark: not in the UTXO set, of course that stuff could still end up in witnesses.
13:09 < instagibbs> sipa, sigh, you are of course correct
13:09 < instagibbs> or just captured by sybil anti-laundering services
13:09 < gmaxwell> sipa: I wouldn't be so sure.
13:09 -!- cguida [~chris@162.216.46.162] has quit [Quit: cguida]
13:10 < 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)
13:10 < sipa> very minor, and possibly something that can't be maintained for future witness script version anyway
13:10 < Luke-Jr> nah, addresses are either p2sh or p2wsh, not both.
13:11 < sipa> Luke-Jr: scripts, not addresses
13:11 < sipa> but i agree it's minor
13:11 < wumpus>  * [new tag]         v0.12.1 -> v0.12.1
13:11 < Luke-Jr> I don't follow. If it's used in a p2sh address, you don't need to index the script for p2wsh..?
13:12 < sipa> Luke-Jr: you have an index from Hash160 -> script for known scripts
13:12 < sipa> Luke-Jr: that can be used for matching both P2SH and P2WSH
13:12 < Luke-Jr> but you don't need scripts for p2wsh in that index
13:13 < sipa> perhaps it's better that it's a separate index
13:13 < sipa> maybe
13:13 < Luke-Jr> oh, you mean just having two different indexes at all, even if non-overlapping
13:14 < sipa> well you need an index anyway for p2wsh scripts
13:14 < sipa> the question is whether it can be the same one or not :)
13:14  * sipa afk
13:18 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
13:19 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
13:20 < 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
13:21 < CodeShark> this would give us flexibility to apply other hash functions or transformations later on
13:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
13:22 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
13:22 < CodeShark> but I would like to avoid special cases
13:22 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
13:22 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 252 seconds]
13:29 -!- zooko [~user@2601:281:8000:8387:8c61:7861:dd59:f2f9] has quit [Ping timeout: 268 seconds]
13:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:39 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
13:40 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
13:51 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
13:51 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
13:54 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Quit: johnwhitton]
13:55 -!- cguida [~chris@162.216.46.19] has joined #bitcoin-core-dev
13:58 -!- erasmospunk [~erasmospu@151.41.89.199] has joined #bitcoin-core-dev
14:00 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Quit: Page closed]
14:05 -!- cguida [~chris@162.216.46.19] has quit [Quit: cguida]
14:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
14:21 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
14:27 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
14:28 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit [Ping timeout: 260 seconds]
14:39 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
14:39 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
14:40 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has quit [Read error: Connection reset by peer]
14:40 -!- muuqwaul [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
14:42 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Quit: johnwhitton]
14:43 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
14:47 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Client Quit]
14:52 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Ping timeout: 268 seconds]
14:53 -!- ryan-c [~ryan@srv1.turboslow.net] has quit [Ping timeout: 250 seconds]
14:53 -!- kangx [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has quit [Quit: Page closed]
14:53 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 268 seconds]
14:54 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 268 seconds]
14:55 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 250 seconds]
14:56 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
14:56 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev
14:56 -!- pigeons is now known as Guest46972
14:56 -!- ryan-c [~ryan@srv1.turboslow.net] has joined #bitcoin-core-dev
14:58 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
14:59 -!- Guest46972 is now known as pigeons
15:00 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
15:00 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Ping timeout: 268 seconds]
15:04 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 250 seconds]
15:05 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev
15:08 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 244 seconds]
15:08 -!- zooko [~user@2601:281:8000:8387:8c61:7861:dd59:f2f9] has joined #bitcoin-core-dev
15:09 -!- murch [~murch@p4FE394A8.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
15:10 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving]
15:12 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
15:13 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Quit: johnwhitton]
15:18 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 250 seconds]
15:22 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
15:23 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
15:24 -!- erasmospunk [~erasmospu@151.41.89.199] has quit [Remote host closed the connection]
15:24 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
15:26 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Client Quit]
15:26 -!- erasmospunk [~erasmospu@151.41.89.199] has joined #bitcoin-core-dev
15:27 -!- johnwhitton [~johnwhitt@128.177.113.106] has joined #bitcoin-core-dev
15:28 -!- johnwhitton [~johnwhitt@128.177.113.106] has quit [Client Quit]
15:29 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
15:31 -!- erasmospunk [~erasmospu@151.41.89.199] has quit [Ping timeout: 260 seconds]
15:31 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Ping timeout: 268 seconds]
15:35 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
15:39 -!- isis [~isis@abulafia.patternsinthevoid.net] has joined #bitcoin-core-dev
15:54 -!- Cory [~C@unaffiliated/cory] has quit []
15:57 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
16:01 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Ping timeout: 244 seconds]
16:09 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has left #bitcoin-core-dev ["Verlassend"]
16:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:58 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
17:13 < jtimon> date -u
17:20 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160315153207]]
17:21 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
17:26 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
17:26 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
17:28 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has quit [Quit: johnwhitton]
17:45 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
17:46 -!- johnwhitton [~johnwhitt@c-71-202-223-50.hsd1.ca.comcast.net] has left #bitcoin-core-dev []
17:52 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
17:52 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Client Quit]
17:52 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
18:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:06 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
18:06 < fanquake> Is there going to be a 0.11.3 release at the same time as 0.12.1 ?
18:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:28 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-fzyeslfagfxmzrdy] has quit [Quit: Connection closed for inactivity]
18:30 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has quit [Read error: Connection reset by peer]
18:31 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has joined #bitcoin-core-dev
18:33 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-orlfnjdbxxpihaqu] has quit [Quit: Connection closed for inactivity]
18:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
19:00 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has quit [Read error: Connection reset by peer]
19:01 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has joined #bitcoin-core-dev
19:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:16 -!- gijensen [~gijensen@gijensen.xyz] has quit [Quit: ZNC - http://znc.in]
19:18 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev
19:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:22 -!- gijensen [~gijensen@gijensen.xyz] has quit [Client Quit]
19:25 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 252 seconds]
19:26 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 252 seconds]
19:26 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
19:27 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev
19:33 -!- fanquake1 [~Adium@125.253.101.232] has joined #bitcoin-core-dev
19:33 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Ping timeout: 244 seconds]
19:37 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Ping timeout: 276 seconds]
19:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:43 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:44 < cfields> gitian builders: 0.12.1 sigs are up
19:46 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
19:48 < cfields> gmaxwell: you might get your wish, we got 5 matches pretty quickly for this one :)
19:48 < fanquake1> cfields What's the wish?
19:49 < cfields> fanquake1: tag/release same day
19:54 < fanquake1> cfields That'd be nice. Have pushed my signed sigs up, hopefully we get some matches.
19:55 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev
19:56 < cfields> fanquake1: matches mine :)
19:58 < achow101> doing my builds right now
20:03 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
20:07 < cfields> achow101: matched, thanks
20:11 < fanquake1> cfields while your around, are we doing a 0.11.3 release?
20:13 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
20:14 < cfields> fanquake1: i'm not sure what the resolution was there, it was debated because of the difficulty in safely backporting the new stuff. It was discussed in last week's meeting (or the week before?)
20:16 < cfields> fanquake1: i suspect it'll depend on demand
20:17 < fanquake1> cfields No worries. Was just curious as to wether I'd need to create any more sigs.
20:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
20:22 -!- earlest [~denetrabu@2601:45:4002:d800:f94d:5271:6e9d:7e7e] has joined #bitcoin-core-dev
20:24 -!- gijensen [~gijensen@gijensen.xyz] has quit [Quit: ZNC - http://znc.in]
20:24 -!- PRab_ [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
20:24 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev
20:25 -!- ebfull [~sean@73.34.119.0] has quit [Ping timeout: 264 seconds]
20:25 -!- fanquake1 [~Adium@125.253.101.232] has quit [Ping timeout: 250 seconds]
20:26 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Ping timeout: 250 seconds]
20:26 -!- pavel_ [~paveljani@79.98.72.216] has joined #bitcoin-core-dev
20:26 -!- PRab_ is now known as PRab
20:26 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
20:27 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
20:27 -!- kinlo_ [peter@unaffiliated/kinlo] has joined #bitcoin-core-dev
20:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
20:30 -!- ibrightly_ [sid113387@gateway/web/irccloud.com/x-aprjoyskefevsgea] has joined #bitcoin-core-dev
20:30 -!- ryan`c [~ryan@srv1.turboslow.net] has joined #bitcoin-core-dev
20:31 -!- gijensen [~gijensen@gijensen.xyz] has quit [Quit: ZNC - http://znc.in]
20:32 -!- Lightsword_ [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev
20:32 -!- Netsplit *.net <-> *.split quits: Cory, Lightsword, ibrightly, ryan-c, kinlo, muuqwaul, paveljanik
20:32 -!- kinlo_ is now known as kinlo
20:32 -!- ryan`c is now known as ryan-c
20:33 -!- Lightsword_ is now known as Lightsword
20:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:33 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev
20:33 -!- ibrightly_ is now known as ibrightly
20:33 -!- hsmiths2 [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Read error: Connection reset by peer]
20:34 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:34 -!- Pasha is now known as Cory
20:36 -!- gijensen [~gijensen@gijensen.xyz] has quit [Client Quit]
20:37 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 260 seconds]
20:38 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev
20:39 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
20:42 -!- eragmus [sid136308@gateway/web/irccloud.com/x-cmtwggarufikczxy] has quit [Read error: Connection reset by peer]
20:42 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-njxqwbvzhrnhssgd] has quit [Read error: Connection reset by peer]
20:42 -!- CyrusV [~cyrus@unaffiliated/cyrusv] has quit [Ping timeout: 264 seconds]
20:44 -!- eragmus [sid136308@gateway/web/irccloud.com/x-sciirkqweebnkzbp] has joined #bitcoin-core-dev
20:44 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-jqnqksoltlpbaott] has joined #bitcoin-core-dev
20:48 -!- CyrusV [~cyrus@unaffiliated/cyrusv] has joined #bitcoin-core-dev
20:49 -!- zooko [~user@2601:281:8000:8387:8c61:7861:dd59:f2f9] has quit [Ping timeout: 250 seconds]
20:51 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
21:00 -!- lejitz [~lejitz@cpe-72-181-158-116.tx.res.rr.com] has joined #bitcoin-core-dev
21:01 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
21:02 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
21:05 -!- lejitz [~lejitz@cpe-72-181-158-116.tx.res.rr.com] has quit [Quit: Quit]
21:10 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
21:21 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
21:24 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-gnunauwchcswqbjo] has joined #bitcoin-core-dev
22:01 -!- pavel_ [~paveljani@79.98.72.216] has quit [Quit: Leaving]
22:01 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
22:08 -!- JackH [~Jack@79-73-189-103.dynamic.dsl.as9105.com] has quit [Ping timeout: 276 seconds]
22:18 -!- frankenmint [~frankenmi@174.25.22.102] has joined #bitcoin-core-dev
22:19 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:24 -!- frankenmint [~frankenmi@174.25.22.102] has quit [Remote host closed the connection]
22:25 -!- PRab_ [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
22:26 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has quit [Ping timeout: 264 seconds]
22:26 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 264 seconds]
22:27 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Ping timeout: 264 seconds]
22:27 -!- pigeons [~pigeons@94.242.209.214] has quit [Ping timeout: 264 seconds]
22:27 -!- PRab_ is now known as PRab
22:27 -!- hsmiths [~hsmiths@cpe-76-174-26-91.socal.res.rr.com] has joined #bitcoin-core-dev
22:28 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-jqnqksoltlpbaott] has quit [Ping timeout: 264 seconds]
22:28 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 264 seconds]
22:28 -!- kinlo [peter@unaffiliated/kinlo] has quit [Ping timeout: 264 seconds]
22:29 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
22:29 -!- kinlo [peter@unaffiliated/kinlo] has joined #bitcoin-core-dev
22:29 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
22:29 -!- pigeons is now known as Guest11294
22:32 -!- Guest11294 is now known as pigeons
22:32 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-pefnyjlaeodntlur] has joined #bitcoin-core-dev
22:34 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
22:36 -!- Pasha is now known as Cory
22:40 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving]
22:41 -!- cryptocoder_ [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has joined #bitcoin-core-dev
22:43 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
22:43 -!- cryptocoder [~cryptocod@cpe-76-90-140-31.socal.res.rr.com] has quit [Ping timeout: 244 seconds]
22:43 -!- cryptocoder_ is now known as cryptocoder
22:52 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
23:00 < GitHub199> [bitcoin] laanwj closed pull request #6215: add bip32 pub key serialization (master...2015/06/extkey_ser) https://github.com/bitcoin/bitcoin/pull/6215
23:00 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has quit [Read error: Connection reset by peer]
23:00 -!- dermoth_ [~thomas@dial-216-221-42-131.mtl.aei.ca] has joined #bitcoin-core-dev
23:02 < GitHub74> [bitcoin] laanwj closed pull request #6030: Avoid counting failed connect attempts when probably offline. (master...addrman_offline_attempts) https://github.com/bitcoin/bitcoin/pull/6030
23:06 < wumpus> github bot is malfunctioning, I merged #6215 didn't close it
23:28 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-gnunauwchcswqbjo] has quit [Quit: Connection closed for inactivity]
23:41 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 260 seconds]
23:42 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
23:56 -!- PRab_ [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
23:58 < GitHub45> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/cabba24a5bde...bbd210d9275a
23:58 < GitHub45> bitcoin/master dc4ec6d Cory Fields: depends: create a hostid and buildid and add option for salts...
23:58 < GitHub45> bitcoin/master fe740f1 Cory Fields: depends: fix fallback downloads...
23:58 < GitHub45> bitcoin/master bb717f4 Cory Fields: depends: fix "unexpected operator" error during "make download"
23:58 < GitHub111> [bitcoin] laanwj closed pull request #7809: depends: some base fixes/changes (master...depends-updates) https://github.com/bitcoin/bitcoin/pull/7809