--- Day changed Mon Feb 20 2017 00:01 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:05 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:08 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds] 00:14 < cannon-c> Default RBF would make fee increase for faster processing easier for the non-tech savvy. I see lots of 00:14 < cannon-c> questions referring how to get transactions unstuck, most wallets that are not core, are difficult for non-technical to resend transaction. 00:16 < cannon-c> But I believe should notify users that RBF is set, with easily accessible ability to uncheck. Just my opinion 00:17 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 00:17 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 00:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 00:18 < cannon-c> Wouldn't RBF fee increase in lieu of sending new transaction that is stuck, prevent transaction ID from changing? If so I see how RBF would be great advantage 00:23 -!- pavel_ [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 00:23 -!- pavel_ [~paveljani@79.98.72.176] has quit [Client Quit] 00:24 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.7] 00:24 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 00:24 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 240 seconds] 00:25 -!- [Author] [~Author]@2401:a400:3200:5600:bad:d09:15:90d] has quit [Ping timeout: 252 seconds] 00:30 < gmaxwell> wumpus: fwiw, I believe several other wallets are producing OO rbf (electrum and green address) 00:30 < gmaxwell> wumpus: also, you can always bump your way out of flagging, which should reduce the issue. 00:31 < gmaxwell> jonasschnelli: I think we should hear feedback for how things go for bumpfee users in 0.14.x 00:31 < jonasschnelli> I think OO rbf should be the default and optionally, if you want to pay a 0-conf merchant, you may want to switch it of. 00:31 < jonasschnelli> *off 00:32 < gmaxwell> jonasschnelli: I think bumping it off is somewhat superior to switching it off, unless you're really sure you want it off. 00:32 < gmaxwell> rationale: even if the rx side will ignore the unconfirmed tx with it off, it might just confirm right away. 00:39 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev 00:39 -!- juscamarena_ [~justin@47.148.176.74] has joined #bitcoin-core-dev 00:39 -!- juscamarena_ [~justin@47.148.176.74] has quit [Remote host closed the connection] 00:55 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 00:58 < wumpus> gmaxwell: okay that would be a good argument to enable it by default on master now, at least 00:58 < jonasschnelli> 0.14.0rc1 sync against random peers 00:58 < jonasschnelli> 2017-02-19 20:25:48 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 version=0x00000001 log2_work=33.000022 tx=2 date='2009-01-09 02:54:25' progress=0.000000 cache=0.0MiB(1tx) 00:58 < jonasschnelli> 2017-02-19 23:06:26 UpdateTip: new best=000000000000000002204d1e9885416bfef39a2259a48a3eb5d36b6e8e21fad7 height=453816 version=0x20000002 log2_work=86.006491 tx=197951144 date='2017-02-19 23:00:41' progress=0.999994 cache=4096.3MiB(7229926tx) warning='2 of last 100 blocks have unexpected version' 00:59 < wumpus> is it syncing or stuck? 00:59 < jonasschnelli> No.. it's fast. :) 00:59 < gmaxwell> 453816 is currentish. 00:59 < wumpus> ooh! great.I thought you were worried about the version warning 00:59 < jonasschnelli> 453816 was at 2017-02-19 23:06:26 01:00 < gmaxwell> that is with increased dbcache, obviously. 01:00 < jonasschnelli> 7GB cache. yes. 01:00 < wumpus> oh only 7GB cache :-) 01:00 < gmaxwell> a little cheating there because it has never flushed at all. :P 01:00 < jonasschnelli> Almost same sync-times then we has with 0.13.0 but more blocks. :) 01:01 < wumpus> yes seems the bottleneck now is really i/o for the utxo database 01:01 < gmaxwell> well, sipa has code that makes it ~33% faster. 01:01 < sipa> last week gmaxwell and i tried to sync a 0.7.2 node from scratch, with -connect to a fast new node 01:01 < jonasschnelli> flush takes only a couple of seconds on that machine.. so neglectable 01:01 < gmaxwell> jonasschnelli: flush of the utxo cache, with 4gb in is not going to take a couple seconds. 01:01 < gmaxwell> try a minute. 01:02 < wumpus> but yes with database in RAM or on a SSD it's surprisingly fast 01:02 < jonasschnelli> I'll measure my shutdown now... 01:02 < gmaxwell> also, part of the time is hidden in the next start up. 01:02 < wumpus> too bad that that doesn't help my odroid64 :-) 01:02 < sipa> jonasschnelli: flushing means that every subsequent spend from an out-of-cache tx afterwards needs a read from disk and deserialization 01:02 < jonasschnelli> Maybe 15s 01:03 < jonasschnelli> I'm using a 1GB/s SSD 01:03 < sipa> so the slowdown is partially in later entries 01:03 < wumpus> yes it's not the flushing itself, as in writing, that poses a bottleneck with leveldb. leveldb is very fast with writing. It's that the flush empties the entire db 01:03 < wumpus> +cache 01:04 < jonasschnelli> https://0bin.net/paste/RdqE7Qkd8uMcew8H#o5kz3c7fBGijX2ZXzJ4d8fAozAN0h5IAQvaD8gwaeRz 01:04 < sipa> half of the time is constructing the batch for leveldb to write 01:04 < wumpus> well, sipa has code that makes it ~33% faster.<- that's good news! how? 01:04 < sipa> wumpus: per txout caching 01:05 < wumpus> sipa: ah nice 01:05 < gmaxwell> It unfortunately increases the size of the utxo database on disk somewhat. 01:05 < sipa> and undo data 01:05 < wumpus> by how much? 01:05 < gmaxwell> Less than double. I think it's a clear win. 01:06 < gmaxwell> Basically the keys get repeated.. leveldb has some compaction of that, but its not perfect. 01:06 < wumpus> could anything be gained by compressing undo data? 01:06 < gmaxwell> and the undo data is only slightly larger. 01:06 < wumpus> as you say "repeated", compression seems obvs answer 01:06 < sipa> undo data is already compressed pretty well 01:06 < wumpus> ok 01:07 < gmaxwell> well we can reduce the size of all blocks by ~27% using different stuff, I don't think we've looked to shrink undo data much more than it alread is. 01:07 < sipa> but the size increase on the chainstate should be investigated more carefully 01:07 < sipa> if it increases significantly, it may not be a win for systems with slow disks 01:07 < wumpus> true, undo data is deleted together with the blocks on pruning 01:07 < wumpus> chainstate growth is much more worrying 01:07 < sipa> yes :( 01:07 < gmaxwell> also, I'm sure now we have enough improvements that the sse2-sha256 will be more of a speedup, I think jonasschnelli benchmarked 5% in IBD time, and that was before assumevalid. 01:08 < gmaxwell> wumpus: well the growth, whatever it is, should be roughly a constant factor. 01:08 < jonasschnelli> Yes. IBD is not much of a difference... 01:08 < jonasschnelli> with wumpuses sse2 01:08 < wumpus> 5% is pretty nice 01:08 < jonasschnelli> Yes. Sure. 01:08 < gmaxwell> jonasschnelli: I think 5% isn't bad. y'all expect too much from optimizations. And on top of assume valid and that 33% gain that 5% will be much larger. 01:08 < sipa> oh, so... we were unable to get 0.7.2 to sync past some block in 2015 01:09 < jonasschnelli> But I think it's great for nodes running in sync. 01:09 < wumpus> compound growth, heh 01:09 < gmaxwell> even with massively increased locks. 01:09 < wumpus> all those 5% and 3% stacked on top of each other do count 01:09 < gmaxwell> In libsecp256k1 we celebrate 1% improvements. 01:10 < jonasschnelli> We often focus on IBD improvments,... they are great. Boiling hot water quick is great,... but keeping it warm with low amount of energy also counts. :) 01:11 < sipa> well IBD time is a biased proxy for block validation time 01:11 < sipa> and it keeps users happy 01:11 < sipa> many of the improvements to IBD time do matter for single node validation... except assumevalid, though we get sigcache in return 01:12 -!- moli_ [~molly@unaffiliated/molly] has quit [Remote host closed the connection] 01:12 < jonasschnelli> Yes. That's true. But sse2 5% in IBD may results in 10-15% during in-sync state because of lesser IO. My Pine64 (RPi clone) would really love that. 01:13 < jonasschnelli> (and it actually has SHA256 NI) 01:13 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 01:17 < bitcoin-git> [bitcoin] fanquake closed pull request #9808: Master (master...master) https://github.com/bitcoin/bitcoin/pull/9808 01:18 < jonasschnelli> wumpus: since we have 0.14 now branched off, we could try to make a little step towards refactoring out BDB. Maybe check #9143? 01:18 < gribble> https://github.com/bitcoin/bitcoin/issues/9143 | Refactor ZapWalletTxes to avoid layer violations by jonasschnelli · Pull Request #9143 · bitcoin/bitcoin · GitHub 01:21 -!- cbits [~cbits@47.148.176.74] has joined #bitcoin-core-dev 01:23 -!- harrymm [~wayne@104.207.83.33] has quit [Ping timeout: 240 seconds] 01:25 < cbits> @jonasschnelli I'm in the camp that rbf should either be set by default with a checkbox to unset it per transaction, or entirely off in the settings. Or the other option, of having it not set by default, but you get the behavior I first described if you set rbf on. 01:26 < cbits> Electrum currently makes you set rbf on for every transaction even after making the option visible in the settings. Which imo is annoying. Should be default. 01:27 < jonasschnelli> cbits: I think the GUI can handle RBF pretty well. I see more potential in improving the RPC API. 01:27 < jonasschnelli> The gui will very likely have https://github.com/bitcoin/bitcoin/pull/9697 in 0.15. 01:27 < jonasschnelli> And a per-tx-opt-in checkbox 01:27 < jonasschnelli> And, the GUI offers user verification before sending (to inform better about the RBF state). 01:28 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 01:30 < cbits> jonasschnelli: nice. Didn't see that pull. I'll check it out. 01:33 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 01:34 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:38 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 01:39 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 01:40 < jonasschnelli> I'm setting up a new gitian machine... but facing an error with the vm sudoers config: 01:40 < jonasschnelli> https://0bin.net/paste/V1mMAN3IRN2c1lSE#Xuff715O4aijc+o9h04ohmF145+fRrXqojsb11jDxmy 01:40 < jonasschnelli> Any idea how to fix that? 01:41 < jonasschnelli> It seems that the prompt breaks the make-base-vm process 01:46 -!- harrymm [~wayne@104.207.83.10] has joined #bitcoin-core-dev 01:46 < wumpus> strange 01:47 < wumpus> is this a sudo issue in the VM or the host machine? confusing 01:47 < wumpus> looks something *on* the vm, so changing sudoers won't help you either 01:50 < jonasschnelli> Yes. Seems to be on the VM. 01:50 < jonasschnelli> I'm using make-base-vm on a non-VM host. Using -KVM 01:50 < wumpus> I created a new base image twice yesterday - no issues 01:51 < wumpus> this is kvm or lxc? 01:52 < jonasschnelli> KVM 01:52 < wumpus> okay what I tried is LXC 01:52 < jonasschnelli> Just tried LXC and seems to have worked.. 01:55 < wumpus> the upgrader should probably be passed some kind of silent/don't prompt flag for the KVM image build 01:57 < jonasschnelli> After using LXC, the base image was named "base-trusty-amd64" instead of "base-trusty-amd64.qcow2"... renamed and trying to gbuild now 01:58 -!- Victor_sueca is now known as Victorsueca 01:59 -!- city22 [~textual@211.94.117.2] has joined #bitcoin-core-dev 02:04 < wumpus> jonasschnelli: that is the correct naming 02:04 < wumpus> lxc image is not a qcow 02:04 < jonasschnelli> ah... I guess I need to set USE_LXC 02:13 < wumpus> yep 02:13 -!- city22 [~textual@211.94.117.2] has quit [Ping timeout: 268 seconds] 02:16 < jonasschnelli> libexec/config-bootstrap-fixup: line 15: target-bin/bootstrap-fixup.in: No such file or directory 02:20 < wumpus> never seen that one before 02:22 -!- whphhg [whphhg@gateway/vpn/mullvad/x-kvdknxbekxbjviqq] has quit [Quit: Leaving] 02:24 < wumpus> not sure if KVM will work at all in my setup, but will try making a KVM image 02:36 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 02:40 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 240 seconds] 02:43 -!- city22 [~textual@210.13.244.130] has joined #bitcoin-core-dev 02:46 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 268 seconds] 02:50 < wumpus> jonasschnelli: I get the same error as you 02:50 < wumpus> making an issue 02:57 -!- cbits [~cbits@47.148.176.74] has quit [Ping timeout: 240 seconds] 03:00 -!- city22 [~textual@210.13.244.130] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 03:00 < wumpus> https://github.com/devrandom/gitian-builder/issues/144 03:01 < wumpus> would be nice if we could resolve this before final 03:12 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 03:20 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 03:29 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev 03:30 -!- goksinen [~goksinen@2604:2000:c591:8400:3420:31fb:5538:73fd] has joined #bitcoin-core-dev 03:34 -!- goksinen [~goksinen@2604:2000:c591:8400:3420:31fb:5538:73fd] has quit [Ping timeout: 240 seconds] 03:36 -!- [Author] [~Author]@2401:a400:3200:5600:bad:d09:15:90d] has joined #bitcoin-core-dev 03:42 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 03:56 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed] 04:03 < bitcoin-git> [bitcoin] GCarneiroA opened pull request #9809: Master (0.10...master) https://github.com/bitcoin/bitcoin/pull/9809 04:04 < bitcoin-git> [bitcoin] fanquake closed pull request #9809: Master (0.10...master) https://github.com/bitcoin/bitcoin/pull/9809 04:05 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Ping timeout: 264 seconds] 04:11 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev 04:24 -!- goksinen [~goksinen@2604:2000:c591:8400:3420:31fb:5538:73fd] has joined #bitcoin-core-dev 04:28 -!- goksinen [~goksinen@2604:2000:c591:8400:3420:31fb:5538:73fd] has quit [Ping timeout: 240 seconds] 04:33 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer] 04:33 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 04:36 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 04:45 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev 04:45 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host] 04:45 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 05:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 05:26 -!- OptMate [~OptMate@109.101.149.61] has joined #bitcoin-core-dev 05:28 -!- OptMate [~OptMate@109.101.149.61] has quit [Client Quit] 05:28 -!- OptMate [~OptMate@109.101.149.61] has joined #bitcoin-core-dev 05:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 05:48 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 05:50 < achow101> jonasschnelli: that's an issue with vmbuilder. see https://bugs.launchpad.net/vmbuilder/+bug/1659952 05:51 < jonasschnelli> achow101: Nice! thanks. You should probably report that also here -> https://github.com/devrandom/gitian-builder/issues/144 05:51 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 05:52 -!- OptMate [~OptMate@109.101.149.61] has quit [] 06:03 -!- city22 [~textual@221.220.178.53] has joined #bitcoin-core-dev 06:07 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 06:21 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds] 06:28 -!- city22 [~textual@221.220.178.53] has quit [Max SendQ exceeded] 06:30 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 06:31 -!- chjj [~chjj@unaffiliated/chjj] has quit [Client Quit] 06:31 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 06:32 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 260 seconds] 06:33 -!- Alina-malina [~Alina-mal@37.157.216.152] has joined #bitcoin-core-dev 06:37 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 06:40 -!- Alina-malina_ [~Alina-mal@37.157.216.146] has joined #bitcoin-core-dev 06:40 -!- Alina-malina [~Alina-mal@37.157.216.152] has quit [Ping timeout: 260 seconds] 06:42 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds] 06:42 -!- goksinen [~goksinen@2604:2000:f64b:c700:3067:a1ec:ec57:e5c6] has joined #bitcoin-core-dev 06:43 -!- Alina-malina_ [~Alina-mal@37.157.216.146] has quit [Changing host] 06:43 -!- Alina-malina_ [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 06:47 -!- goksinen [~goksinen@2604:2000:f64b:c700:3067:a1ec:ec57:e5c6] has quit [Ping timeout: 240 seconds] 06:48 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 240 seconds] 06:49 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving] 06:49 -!- harrymm [~wayne@104.207.83.10] has quit [Ping timeout: 255 seconds] 06:53 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 06:59 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 06:59 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 07:00 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 07:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 07:06 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev 07:09 -!- harrymm [~wayne@191.96.49.91] has joined #bitcoin-core-dev 07:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 07:20 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 07:25 < paveljanik> anyone running Windows here? 07:25 < paveljanik> can you please try loading mempool.dat? 07:26 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 268 seconds] 07:35 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 07:35 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 07:36 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 07:37 -!- goksinen [~goksinen@2604:2000:f64b:c700:3067:a1ec:ec57:e5c6] has joined #bitcoin-core-dev 07:41 -!- goksinen [~goksinen@2604:2000:f64b:c700:3067:a1ec:ec57:e5c6] has quit [Ping timeout: 240 seconds] 08:00 -!- goksinen [~goksinen@2604:2000:f64b:c700:3067:a1ec:ec57:e5c6] has joined #bitcoin-core-dev 08:04 -!- goksinen [~goksinen@2604:2000:f64b:c700:3067:a1ec:ec57:e5c6] has quit [Ping timeout: 240 seconds] 08:25 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 08:26 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/390a39bb5cf4...1a9fd5cb9d13 08:26 < bitcoin-git> bitcoin/master 9adb694 Luke Dashjr: Qt/Intro: Move sizeWarningLabel text into C++ code 08:26 < bitcoin-git> bitcoin/master 50c5657 Luke Dashjr: Qt/Intro: Storage shouldn't grow significantly with pruning enabled 08:26 < bitcoin-git> bitcoin/master f6d18f5 Luke Dashjr: Qt/Intro: Explain a bit more what will happen first time 08:27 < bitcoin-git> [bitcoin] laanwj closed pull request #9724: Qt/Intro: Add explanation of IBD process (master...intro_explain) https://github.com/bitcoin/bitcoin/pull/9724 08:29 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1a9fd5cb9d13...7ca2f542708b 08:29 < bitcoin-git> bitcoin/master 1bfe6b4 Mitchell Cash: Use package name variable inside $(package)_file_name variable 08:29 < bitcoin-git> bitcoin/master 7ca2f54 Wladimir J. van der Laan: Merge #9794: Minor update to qrencode package builder... 08:30 < bitcoin-git> [bitcoin] laanwj closed pull request #9794: Minor update to qrencode package builder (master...minor_depends_fix) https://github.com/bitcoin/bitcoin/pull/9794 08:30 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7ca2f542708b...2dad02232af1 08:30 < bitcoin-git> bitcoin/master ec1267f Russell Yanofsky: [wallet] Remove importmulti always-true check... 08:30 < bitcoin-git> bitcoin/master 2dad022 Wladimir J. van der Laan: Merge #9760: [wallet] Remove importmulti always-true check... 08:30 < bitcoin-git> [bitcoin] laanwj closed pull request #9760: [wallet] Remove importmulti always-true check (master...pr/multitaut) https://github.com/bitcoin/bitcoin/pull/9760 08:32 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/2dad02232af1...aa791e29114f 08:32 < bitcoin-git> bitcoin/master 9fc7f0b Luke Dashjr: Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates 08:32 < bitcoin-git> bitcoin/master 279f944 Luke Dashjr: QA: Test GBT size/weight limit values 08:32 < bitcoin-git> bitcoin/master aa791e2 Wladimir J. van der Laan: Merge #9619: Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates... 08:32 < bitcoin-git> [bitcoin] laanwj closed pull request #9619: Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates (master...bugfix_gbt_presw) https://github.com/bitcoin/bitcoin/pull/9619 08:36 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/40c754cb38cd...861cb0c83db0 08:36 < bitcoin-git> bitcoin/0.14 6552729 Luke Dashjr: Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates... 08:36 < bitcoin-git> bitcoin/0.14 861cb0c Luke Dashjr: QA: Test GBT size/weight limit values... 08:46 -!- goksinen [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 08:50 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/aa791e29114f...7639d38f14b1 08:50 < bitcoin-git> bitcoin/master 13f6085 Wladimir J. van der Laan: netbase: Make InterruptibleRecv return an error code instead of bool 08:50 < bitcoin-git> bitcoin/master 3ddfe29 Wladimir J. van der Laan: netbase: Do not print an error on connection timeouts through proxy... 08:50 < bitcoin-git> bitcoin/master 7639d38 Wladimir J. van der Laan: Merge #9726: netbase: Do not print an error on connection timeouts through proxy... 08:50 < bitcoin-git> [bitcoin] laanwj closed pull request #9726: netbase: Do not print an error on connection timeouts through proxy (master...2017_02_intr_recv_error) https://github.com/bitcoin/bitcoin/pull/9726 08:58 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds] 09:00 -!- kyletorpey [49d88f0a@gateway/web/freenode/ip.73.216.143.10] has joined #bitcoin-core-dev 09:02 < paveljanik> sipa, wumpus: #9810 - any idea (seems to be crlf on serialization ;-)? 09:02 < gribble> https://github.com/bitcoin/bitcoin/issues/9810 | 0.14 not loading mempool.dat? · Issue #9810 · bitcoin/bitcoin · GitHub 09:03 < paveljanik> binary on write? 09:03 < paveljanik> Windows... 09:03 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev 09:04 < wumpus> that could be the explanation, good catch! how is the file opened? 09:04 < wumpus> if its opened in text (instead of binary) mode, windows will convert \n to \r\n 09:06 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 09:06 < paveljanik> it is written with "w" and opened with "r" 09:06 < wumpus> that should be "wb" and "rb" 09:06 < wumpus> so you've found the issue, congrats 09:07 < paveljanik> Hmm, this reminds me: zerocoin was missing =, we are missing b ;-) 09:07 < paveljanik> we should congrat to the reporter! 09:07 -!- eenoch_ [~eenoch@unaffiliated/eenoch] has joined #bitcoin-core-dev 09:07 < wumpus> I mean you've found the probable solution 09:08 < paveljanik> but really: any dev with Windows to really test this? 09:08 -!- Alina-malina_ is now known as Alina-malina 09:08 < wumpus> are you going to make a PR? 09:08 -!- cryptapus is now known as cryptapus_afk 09:08 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:08 < paveljanik> for master and you'll backport? 09:09 < wumpus> yes 09:09 -!- cryptapus_afk is now known as cryptapus 09:09 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds] 09:09 -!- OfficialLeibniz [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 09:09 -!- eenoch [~eenoch@unaffiliated/eenoch] has quit [Ping timeout: 240 seconds] 09:09 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 240 seconds] 09:09 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 240 seconds] 09:09 -!- murchandamus [~murchghos@ghostdub.de] has quit [Ping timeout: 240 seconds] 09:09 < paveljanik> give me a few minutes 09:09 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev 09:09 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 09:09 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev 09:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 259 seconds] 09:11 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 09:11 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev 09:13 -!- OfficialLeibniz [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 09:15 < bitcoin-git> [bitcoin] paveljanik opened pull request #9813: Read/write mempool.dat as a binary. (master...20170220_mempool_binary) https://github.com/bitcoin/bitcoin/pull/9813 09:25 < wumpus> paveljanik: thanks 09:25 < paveljanik> you're welcome! 09:27 < paveljanik> we use "w" for PID and log 09:28 < paveljanik> and in tests 09:28 < paveljanik> all "text" files 09:32 -!- bsm117532 [~mcelrath@135.84.167.210] has joined #bitcoin-core-dev 09:32 < cfields> windows users who ran rc1 will need to delete mempool.dat. Not sure if that 09:32 < cfields> 's worth adding to the release notes or not 09:34 < paveljanik> it is auto fixed at the first exit? 09:34 < paveljanik> by saving the new file... 09:34 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 09:35 -!- kyletorpey [49d88f0a@gateway/web/freenode/ip.73.216.143.10] has quit [Ping timeout: 260 seconds] 09:36 < cfields> ah, right. 09:39 < wumpus> for text files it makes sense not to add 'b', otherwise you cannot open it in notepad 09:50 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 09:53 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving] 09:55 -!- cryptapus is now known as cryptapus_afk 09:59 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 10:03 < achow101> paveljanik: I can test on windows, as soon as I my windows node finishes syncing 10:03 < paveljanik> achow101, great! 10:13 < achow101> if only we could figure out how to make cross compiling work on xenial... cross compiling for windows is such a pain now 10:19 -!- jamoes [~cretwich@104.193.170-247.PUBLIC.monkeybrains.net] has joined #bitcoin-core-dev 10:23 < sipa> achow101: what fails? 10:23 < achow101> sipa: https://github.com/bitcoin/bitcoin/projects/1 10:23 < achow101> still unresolved 10:25 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 10:25 -!- jamoes [~cretwich@104.193.170-247.PUBLIC.monkeybrains.net] has quit [Remote host closed the connection] 10:26 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:29 -!- jamoes [~cretwich@104.193.170-247.PUBLIC.monkeybrains.net] has joined #bitcoin-core-dev 10:29 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev 10:31 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 268 seconds] 10:33 < achow101> paveljanik: your fix didn't work for me on ubuntu 16.04 10:34 < paveljanik> achow101, on Ubuntu? 10:34 < paveljanik> you have tried the provided mempool.dat? 10:34 < paveljanik> My fix fixes save on Windows... 10:35 < achow101> oh, it was windows specific? I am testing on both ubuntu and windows, just waiting for windows to finish building 10:35 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 268 seconds] 10:37 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection] 10:38 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev 10:46 < achow101> paveljanik: for some reason I had to delete the mempool.dats before it would work properly 10:46 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection] 10:48 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev 10:50 -!- murchandamus [~murchghos@ghostdub.de] has quit [Remote host closed the connection] 10:50 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 10:50 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:51 < paveljanik> yes, this is probably caused by the issue fixed ;-) 10:51 -!- isle2983 [~isle2983@162.216.46.162] has quit [Read error: Connection reset by peer] 10:51 < paveljanik> achow101, can you please try again with the master-saved mempool.dat? 10:52 < paveljanik> and then run fixed tree with the old mempool.dat? 10:52 < paveljanik> it won't use it. But at exit, it should rewrite it and then on the new start it should use it. 10:53 -!- murchandamus [~murchghos@ghostdub.de] has joined #bitcoin-core-dev 10:57 -!- harrymm [~wayne@191.96.49.91] has quit [Ping timeout: 260 seconds] 11:03 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 268 seconds] 11:08 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 11:09 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 11:13 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 268 seconds] 11:16 < achow101> ok, it looks like it does rewrite the old one and actually uses it 11:17 -!- harrymm [~wayne@104.207.83.8] has joined #bitcoin-core-dev 11:26 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 11:32 -!- isle2983 [~isle2983@162.216.46.162] has joined #bitcoin-core-dev 11:52 -!- harrymm [~wayne@104.207.83.8] has quit [Ping timeout: 268 seconds] 11:53 -!- kyletorpey [47b0e374@gateway/web/freenode/ip.71.176.227.116] has joined #bitcoin-core-dev 11:59 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds] 12:08 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 12:12 < paveljanik> achow101, perfect! 12:13 -!- harrymm [~wayne@104.222.140.117] has joined #bitcoin-core-dev 12:15 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 12:26 -!- handlex [~handlex@189.74.9.113] has joined #bitcoin-core-dev 12:28 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: ZZZzzz…] 12:35 -!- handlex [~handlex@189.74.9.113] has quit [Ping timeout: 255 seconds] 12:37 < BlueMatt> what am I missing? why are we going out of our way to prefer data() over &v[0]? 12:37 < BlueMatt> I mean its more readable, sure, but I dont believe it is safer in any measurable way? 12:38 < BlueMatt> or, maybe I'm missing in docs...is it that data() is defined for 0-length vectors (though not dereferenceable - it can return any garbage it wants), but &[0] is not? 12:43 < gwillen> BlueMatt: I believe &[0] should be defined for zero-length vectors, it's legal to take a pointer to the slot right after the end of an array (this is what e.g. a .end() iterator is) 12:43 < gwillen> see the _second_ (not accepted) answer which quotes the standard: http://stackoverflow.com/questions/988158/take-the-address-of-a-one-past-the-end-array-element-via-subscript-legal-by-the 12:43 < midnightmagic> huh, that's interesting. I've been fighting with almost that exact same thing. 12:43 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 12:44 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 12:44 < BlueMatt> gwillen: hmm? I mean that doesnt inherintly mean C++ allows it as well? 12:45 < sipa> BlueMatt: vect[0] is a reference to non-existing data if vector is empty, which is illegal 12:45 < sipa> you can have a pointer to non-existing data, but not a reference 12:45 < BlueMatt> ahh, ok, so it is illegal in C++ but not C? 12:45 < gwillen> sipa: but &foo[0] is a pointer, not a reference 12:45 < BlueMatt> (well, vector but not array) 12:46 < gwillen> and a pointer to one past the end is definitely legal 12:46 < sipa> gwillen: &foo[0] = &(foo[0]) 12:46 < sipa> that's taking the address of a reference to non-existing data 12:46 < BlueMatt> sipa: see stackoverflow link from gwillen, it sppears to be legal in C 12:46 < gwillen> do you believe it's different in C++ with a vector than in C with an array? 12:46 < sipa> C doesn't have references 12:46 -!- OfficialLeibniz [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 12:46 < sipa> the question doesn't apply 12:46 < gwillen> right 12:47 < sipa> a[b] in C is just syntactic sugar for *(a+b) 12:47 < gwillen> but in C that construction would appear to actually dereference an invalid pointer, but the standard gives it a pass 12:47 < gwillen> and explicity says that if you do &foo[x] it turns into foo+x and does not dereference 12:47 < sipa> well that's about arrays 12:47 * gwillen nods 12:47 < sipa> which are defined by the language 12:47 < BlueMatt> mmm, ok 12:48 < gwillen> well, it actually also says this pass applies to the * operator as well, and &(*foo) does not dereference either, which is slightly more general 12:48 < sipa> but vector is a standard library class, where vect[x] is an operator that returns a reference to a vector element 12:48 < gwillen> but I suppose that would be hard to spec for user-defined operators 12:48 * gwillen nod 12:48 < sipa> which is just impossible to do if there are no elements 12:50 < sipa> for example, a vector implementation (and in practice does) contains a pointer to the first element of the data 12:50 < sipa> but initializes it to nullptr if there are no elements allocated 12:50 < sipa> vect[0] would then be implemented as a dereference of nullptr 12:51 * gwillen no 12:51 < sipa> so forcing vect[0] to be valid for empty vectors would outlaw the obviously simplest implementation 12:51 < gwillen> nod* 12:51 < BlueMatt> yea, ok 12:51 < sipa> whereas array[0] is simply a reference to the element 1 past the array... not nullptr 12:52 < gwillen> right 12:52 < sipa> actually, i believe that C and/or C++ require every object to have non-zero allocation space 12:52 < sipa> otherwise alias detection is nearly impossible 12:56 < luke-jr> hmm 12:57 < luke-jr> &foo[0] actually called operator[] in C++, rather than just being (foo+0)? 12:57 < sipa> for vectors, yes 12:57 < luke-jr> I guess it would have to :x 12:57 < sipa> for arrays i don't know 12:57 < luke-jr> a shame, &foo[0] looks nicer XD 12:58 < sipa> also, (foo+0) for a vector would be nonsense... you can't add 0 to a vector 12:58 < luke-jr> ☺ 13:01 < sipa> FATAL: ThreadSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_deadlock_detector1.cc:122 "((len)) > ((0U))" (0x0, 0x0) 13:01 < sipa> #0 (libtsan.so.0+0x00000007c0d3) 13:01 < gribble> https://github.com/bitcoin/bitcoin/issues/0 | HTTP Error 404: Not Found 13:01 < sipa> #1 (libtsan.so.0+0x00000007c0db) 13:01 < gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub 13:01 < sipa> #2 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (libtsan.so.0+0x000000081303) 13:01 < gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub 13:01 < sipa> much sad 13:02 < sipa> assertion failure inside tsan :( 13:03 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 13:05 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 13:15 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 13:17 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 13:23 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 268 seconds] 13:42 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 13:42 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 13:50 < BlueMatt> god damnit gribble 13:51 < sipa> indeed! 13:51 < btcdrak> issue 0 as well lol 13:57 -!- harrymm [~wayne@104.222.140.117] has quit [Ping timeout: 260 seconds] 14:00 -!- Guest42592 [~schmidty@unaffiliated/schmidty] has joined #bitcoin-core-dev 14:04 < BlueMatt> should we mention somewhere in the release notes that 0.14 has mega-super-amazing-faster block relay? 14:07 < sipa> there is an issue about that by cory i think 14:07 < sipa> or a pr 14:08 < BlueMatt> ok, good...I often dont read release-notes stuff :/ 14:08 < BlueMatt> I suppose I'm a bad contributor :/ 14:13 -!- harrymm [~wayne@104.222.140.17] has joined #bitcoin-core-dev 14:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds] 14:58 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 15:06 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:07 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 15:43 -!- roidster [~chatzilla@71-93-192-198.dhcp.whtr.ca.charter.com] has joined #bitcoin-core-dev 15:43 -!- roidster is now known as Guest47564 15:44 -!- Guest47564 is now known as roidster 15:50 < gmaxwell> BlueMatt: you should measure it. 15:50 < BlueMatt> gmaxwell: which part? 15:52 < gmaxwell> preferably the mega-super-amazing parts. 15:53 < BlueMatt> fast-relay: we have good measurements for how long validation takes 15:53 < BlueMatt> you win by that much :) 15:54 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 16:00 -!- cbits [~cbits@2607:f380:a61:650:6d5a:9d64:8e96:3e30] has joined #bitcoin-core-dev 16:04 -!- cbits [~cbits@2607:f380:a61:650:6d5a:9d64:8e96:3e30] has quit [Ping timeout: 240 seconds] 16:14 -!- IRCFrEAK [~gk.1wm.su@2a03:4a80:3:43d:43d:ce30:c9ed:f2a1] has joined #bitcoin-core-dev 16:14 -!- IRCFrEAK [~gk.1wm.su@2a03:4a80:3:43d:43d:ce30:c9ed:f2a1] has left #bitcoin-core-dev [] 16:15 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 245 seconds] 16:18 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 16:18 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 16:20 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 16:55 < gmaxwell> cfields: I'd like to see the vla warning go in ( #9789 ) -- but it really should be a warning, as we just encountered a fails in one compiler but not another. 16:55 < gribble> https://github.com/bitcoin/bitcoin/issues/9789 | build: disallow variable length arrays by theuni · Pull Request #9789 · bitcoin/bitcoin · GitHub 16:56 < gmaxwell> BlueMatt: We're making too many changes with the network without good data on their improvements. The recent ones have been such obviously clear wins that it's okay-- but if we do not get good ways of benchmarking these things running constantly, we're going to eventually make dumb decisions. As a bonus, we'll be able to describe our improvements in ways more specific than mega-super-amazing. :) 16:56 < cfields> gmaxwell: ok. i thought on that a good bit after you raised the objection, and ultimately i agree 16:57 < cfields> gmaxwell: speaking of which, i'm futzing with gnuplot atm :) 16:57 < BlueMatt> gmaxwell: talk to jnewbery :) 16:58 < BlueMatt> (he's working on using the simulation framework stuff to build benchmark CI, and I told him he should set up mini-networks with simulated latency and benchmark that, too) 16:58 < cfields> gmaxwell: plotting out a few different data sets wrt ibd sync between 0.13/0.14 16:58 < gmaxwell> cfields: sweet. 16:58 < gmaxwell> title "Mega-super-amazing performance" 17:30 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.7] 17:32 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 17:32 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 17:46 -!- dodomojo [~goksinen@2604:2000:c591:8400:ce3:dabf:4e7f:3707] has joined #bitcoin-core-dev 18:04 -!- jtimon [~quassel@2607:fb90:9ca0:3f30:ab1:3438:e506:a446] has joined #bitcoin-core-dev 18:15 -!- jtimon [~quassel@2607:fb90:9ca0:3f30:ab1:3438:e506:a446] has quit [Ping timeout: 240 seconds] 18:15 -!- jtimon [~quassel@2607:fb90:9d06:813b:d6c4:69d8:89fb:d68f] has joined #bitcoin-core-dev 18:32 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection] 18:33 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 18:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mhokbajobrvljjxd] has quit [Quit: Connection closed for inactivity] 18:45 -!- jtimon [~quassel@2607:fb90:9d06:813b:d6c4:69d8:89fb:d68f] has quit [Remote host closed the connection] 19:00 -!- dermoth [~thomas@dsl-216-221-55-141.mtl.contact.net] has quit [Read error: Connection reset by peer] 19:00 -!- dermoth [~thomas@dsl-216-221-55-141.mtl.contact.net] has joined #bitcoin-core-dev 19:23 -!- dodomojo [~goksinen@2604:2000:c591:8400:ce3:dabf:4e7f:3707] has quit [Remote host closed the connection] 19:31 -!- roidster [~chatzilla@71-93-192-198.dhcp.whtr.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]] 19:36 -!- dodomojo [~goksinen@2604:2000:c591:8400:e0a9:9322:d8f8:1261] has joined #bitcoin-core-dev 19:53 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 20:18 -!- dodomojo [~goksinen@2604:2000:c591:8400:e0a9:9322:d8f8:1261] has quit [Remote host closed the connection] 20:20 -!- dodomojo [~goksinen@2604:2000:c591:8400:4d40:d78a:5784:833b] has joined #bitcoin-core-dev 20:21 -!- dodomojo [~goksinen@2604:2000:c591:8400:4d40:d78a:5784:833b] has quit [Remote host closed the connection] 20:23 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 240 seconds] 20:27 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev 20:53 -!- chris2000 [~chris2000@p5DCB5CCB.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 20:57 -!- chris200_ [~chris2000@p5DCB50F5.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 21:27 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 22:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 22:12 < cfields> gmaxwell: https://i.imgur.com/8M3wPM4.png 22:13 < cfields> i got tired of arguing with gnuplot over the x axis :\ 22:14 < cfields> (it's linear) 22:14 < gmaxwell> set xdata time 22:14 < gmaxwell> set timefmt "%s" ? 22:15 < cfields> gmaxwell: it's real timestamps, not scaled down to 0. So it wants to show crazy-high second-values 22:15 < gmaxwell> it's a neat graph though it really hides a lot of the other improvements on 0.14 since it only goes to 295k 22:15 < sipa> cfields: so subtract the lowest timestamp? 22:16 < gmaxwell> using 1:($2-constant) with lines 22:16 < cfields> gmaxwell: well the 295k is where the checkpoint kicks in in 0.14. I'd prefer to see a separate graph syncing blocks 0 to 100,000 or so without checkpoints/assumevalid 22:16 < cfields> *in 0.13, sorry 22:17 < gmaxwell> it's not just that, the behavior of the blockchain is quite different in the last two years than the first two. :) 22:17 < sipa> i think it's a neat graph 22:17 < sipa> it doesn't show everything, but it's hard to put everything in one graph without misrepresenting one thing or another 22:18 < cfields> gmaxwell: very much so. Clearly 0.14 benefits most from the improved short bursts in the early blocks 22:19 < cfields> but yes, i'd like to do another where validation is forced for all 22:23 < gmaxwell> It would be nice to have a general figure reflecting user expirence for the release note. "With default settings syncing has been reduced from X hours to Y hours on a quad-core system from another local 0.14 node." 22:25 < cfields> gmaxwell: agreed. I have figures for 0.14->0.14 on an ec2 4xcpu, 8gb ram. It's ~3hrs. 0.13.2->0.13.2 was taking too long and i got impatent, wanting to run other tests :( 22:25 < cfields> i can fire that one up again tomorrow and just let it go 22:26 < cfields> (that was dbcache=4000, blocksonly=1, listen=0, disablewallet=1) 22:26 < gmaxwell> ec2 is really IO starved normally no? 22:27 < cfields> *impatient. That was a dangerous typo :) 22:29 < cfields> gmaxwell: unsure. I figured it was representative of how lots of nodes are run, so good data point 22:29 < cfields> no clue how true that is 22:32 < gmaxwell> I'm pretty sure any customization of dbcache limits it to representing <5% of nodes. 22:33 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 22:33 < cfields> mm, good point 22:36 < jeremyrubin> Hey I have an idea... 22:36 < jeremyrubin> what if during validating sync 22:37 < jeremyrubin> hmmm nevermind... let me read more 22:43 * luke-jr discovers GCC 4.9 doesn't actually support all C++11 >_< 22:43 -!- yahtoo [~myyao@219.135.155.120] has joined #bitcoin-core-dev 22:44 < cfields> luke-jr: atomic shared_ptr ? 22:44 < luke-jr> cfields: std::align 22:45 < cfields> huh, i wasn't aware of std::align. Only alignof/alignas 22:53 -!- kyletorpey [47b0e374@gateway/web/freenode/ip.71.176.227.116] has quit [Ping timeout: 260 seconds] 23:02 < gmaxwell> ... idiot fake nodes, I have one connected to me that continually sends verack messages instead of pongs. 23:04 < sipa> lol 23:05 < luke-jr> XD 23:05 < sipa> Ḧello! speed v 70012?- sure, i can speak 70012 - have you heard about tx ab315fa5118? - sure i can speak 70012! 23:07 < gmaxwell> "It says ack, right in the name." 23:08 < cfields> heh 23:08 < luke-jr> gmaxwell: verack 23:08 < cfields> makes sense, i think. From the laziest possible implementor's perspective 23:08 < cfields> pretty sure we never penalized dupe veracks 23:09 < sipa> i thought we did 23:09 < cfields> so if you don't feel like coding an extra 3 lines, just always reply with verack. ship it! 23:09 < gmaxwell> yea, if your goal is just to record inv traffic; 'anytime you get anything send this canned verack' is the absolute minimum to make the protocol go. 23:10 < luke-jr> gmaxwell: why wait until you get something? XD 23:10 < cfields> sipa: doesn't look like it. Unless there's something subtle 23:12 < sipa> we do penalize duplicate version, right? 23:12 < cfields> both, now 23:12 < gmaxwell> I don't think we peanalize duplicate verack now, do we? 23:13 -!- yahtoo [~myyao@219.135.155.120] has quit [Quit: Leaving] 23:13 < luke-jr> gmaxwell: verack 23:14 < cfields> hmm, i guess not. Could've sworn that went in 23:21 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 23:39 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jljakbxkxrhbqyyv] has joined #bitcoin-core-dev 23:42 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:43 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 23:43 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 23:47 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds] 23:50 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 255 seconds]