--- Day changed Thu Jul 28 2016
00:03 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
00:07 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds]
00:08 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:14 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
00:16 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
00:24 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
00:31 < wumpus> jonasschnelli: I don't think that will work; you just moved settings.value(strSettingsVersionKey)  to the end
00:32 < wumpus> jonasschnelli: what do you have against what I suggested there? settingsVersion = settings.contains(strSettingsVersionKey) ? settings.value(strSettingsVersionKey) : 0;   upfront, then use then from there on
00:32 < wumpus> also saves calls to settings.value()
00:34 -!- AaronvanW [~ewout@145.97.231.198] has joined #bitcoin-core-dev
00:34 -!- AaronvanW [~ewout@145.97.231.198] has quit [Changing host]
00:34 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:35 < GitHub154> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4d4970fe530a...c24b50ec168e
00:35 < GitHub154> bitcoin/master d3af342 Kaz Wesley: prepend license statement to indirectmap...
00:35 < GitHub154> bitcoin/master c24b50e Wladimir J. van der Laan: Merge #8414: prepend license statement to indirectmap.h...
00:35 < GitHub100> [bitcoin] laanwj closed pull request #8414: prepend license statement to indirectmap.h (master...indirectmap-license) https://github.com/bitcoin/bitcoin/pull/8414
00:35 < wumpus> by regarding the absence of strSettingsVersionKey as settings version 0, it will do exactly what you want
00:51 < GitHub90> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c24b50ec168e...64d660a43fb8
00:51 < GitHub90> bitcoin/master 38c4c8b Jorge Timón: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock
00:51 < GitHub90> bitcoin/master 64d660a Wladimir J. van der Laan: Merge #8348: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock...
00:51 < GitHub120> [bitcoin] laanwj closed pull request #8348: Trivial: Segwit: Don't call IsWitnessEnabled from ContextualCheckBlock (master...0.12.99-consensus-segwit) https://github.com/bitcoin/bitcoin/pull/8348
01:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:11 < GitHub159> [bitcoin] shinradev closed pull request #8415: Update tor.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8415
01:11 < jonasschnelli> wumpus: Ah. Sorry. Didn't got your suggestion. But right, makes more sense.
01:11 < jonasschnelli> Let me change it
01:12 < wumpus> thanks :)
01:13 < jonasschnelli> Yes. Much cleaner...
01:17 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
01:19 < jonasschnelli> wumpus: updated and tested. https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R446
01:37 -!- cdecker [2e8c34b6@gateway/web/cgi-irc/kiwiirc.com/ip.46.140.52.182] has joined #bitcoin-core-dev
01:39 -!- xiangfu [~xiangfu@58.135.95.141] has quit [Ping timeout: 258 seconds]
01:39 < wumpus> jonasschnelli: you removed the check for nDatabaseCache==100 itself :)
01:39 < jonasschnelli> looking...
01:39 < wumpus> jonasschnelli: now it will always change the value to the default on an upgrade even if the user changed it
01:40 -!- xiangfu [~xiangfu@58.135.95.141] has joined #bitcoin-core-dev
01:41 < jonasschnelli> damit. I should focus on one thing at the time. Thanks wumpus. What would we (I!) do without you...
01:41 < wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache")  && settings.value(strSettingsVersionKey).toInt() == 100) 
01:41 -!- cdecker [2e8c34b6@gateway/web/cgi-irc/kiwiirc.com/ip.46.140.52.182] has quit [Client Quit]
01:42 < wumpus> eh that's wrong
01:42 -!- cdecker [2e8c34b6@gateway/web/cgi-irc/kiwiirc.com/ip.46.140.52.182] has joined #bitcoin-core-dev
01:42 < wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache")  && settings.value("nDatabaseCache").toInt() == 100) 
01:42 < jonasschnelli> wumpus: that should be better: https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R447 right?
01:43 < wumpus> now I was confusing the settings names... this seems so trivial, but actually it's trivial to accidentally mess up
01:43 < jonasschnelli> yes. Needs to focus to get this right...
01:43 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
01:45 < wumpus> which is difficult with the heat
01:46 < wumpus> my plan is to at least test 8371 today
01:47 < wumpus> jonasschnelli: yes so if (settingsVersion < 130000 && settingsVersion == 100) also doesn't work, it makes the same confusion I did. We need to look at nDatabaseCache here :)
01:47 < jonasschnelli> hah. To dump...
01:48 < jonasschnelli> if (settingsVersion < 130000 && settings.contains("nDatabaseCache") && settings.value("nDatabaseCache"))?
01:48 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
01:48 < jonasschnelli> .toInt() == 100 at the end
01:48 < wumpus> if (settingsVersion < 130000 && settings.contains("nDatabaseCache") && settings.value("nDatabaseCache").toInt()==100)
01:49 < wumpus> yes I think so
01:51 < wumpus> or toLongLong() as we seem to provide it as qint64
01:56 < jonasschnelli> Yes. Probably better,... though I don't expect machines with that much RAM. :)
01:57 < wumpus> I don't either, but I'm not certain how qt handled type conflicts there. If it works with toInt() that's good enough :)
01:57 < jonasschnelli> Changed it to toLongLong() https://github.com/bitcoin/bitcoin/pull/8407/files#diff-bd81cc35fa9249ec9e6a2ace6d3a4d59R447
02:09 < wumpus> awesome
02:14 < wumpus> looks good to me now
02:15 < wumpus> going to test
02:29 < GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/64d660a43fb8...30a87c0747a1
02:29 < GitHub189> bitcoin/master 893f379 Jonas Schnelli: [Qt] Add dbcache migration path
02:29 < GitHub189> bitcoin/master 30a87c0 Wladimir J. van der Laan: Merge #8407: [Qt] Add dbcache migration path...
02:29 < GitHub169> [bitcoin] laanwj closed pull request #8407: [Qt] Add dbcache migration path (master...2016/07/qt_dbcache) https://github.com/bitcoin/bitcoin/pull/8407
02:30 < jonasschnelli> Should probably merge fine into 0.13
02:30 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ulntmevbgnxwhzxf] has joined #bitcoin-core-dev
02:30 < wumpus> yep
02:30 < GitHub153> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/45eba4b1e0658639bb92730723b987f05e171529
02:30 < GitHub153> bitcoin/0.13 45eba4b Jonas Schnelli: [Qt] Add dbcache migration path...
02:41 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
02:42 -!- cdecker [2e8c34b6@gateway/web/cgi-irc/kiwiirc.com/ip.46.140.52.182] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
02:43 -!- cdecker [2e8c34b6@gateway/web/cgi-irc/kiwiirc.com/ip.46.140.52.182] has joined #bitcoin-core-dev
02:45 < jonasschnelli> wumpus: thanks for testing, just changed the font and added the 2nd info text: https://github.com/bitcoin/bitcoin/pull/8371
02:48 < wumpus> okay thanks for updating, will re-test again soon, now looking at 8389
02:49 < wumpus> you've certainly been solving many 0.13.0rc1 issues quickly, where would we be without you
02:53 < wumpus> looking for more review for: Prevent fingerprinting, disk-DoS with compact blocks #8408
02:54 < jonasschnelli> Yes. 8389 is more important
02:54 < jonasschnelli> Looking at 8408
02:59 < jonasschnelli> 8408 makes sense. Props to sdaftuar! It needs extrem focus to find these issues...
02:59 < wumpus> yes these are very sneaky, good to have them discovered and fixed before the release
03:04 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
03:04 -!- YOU-JI [~youyouyou@FL1-125-195-16-249.chb.mesh.ad.jp] has joined #bitcoin-core-dev
03:06 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
03:08 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
03:12 < wumpus> ooh, regtest has the same RPC default port as testnet. I only discover this now
03:13 < jonasschnelli> wasn't aware of that...
03:13 < jonasschnelli> Ah. Just the p2p port is differnt...
03:13 < wumpus> me neither. Never tried to start a regtest node on the same host that was running a testnet node before
03:14 < wumpus> it gives you: "Error: Unable to start HTTP server. See debug log for details." (where the log indeed contains details about failed binding)
03:14 < wumpus> not a big issue just passing rpcport now, but I think it would make sense to bump that port number
03:16 < wumpus> I get a "Warning: Error reading wallet.dat! All keys read correctly, but transaction data or address book entries might be missing or incorrect." with #8389, not sure why
03:17 < wumpus> after that it just continues
03:18 < wumpus> this is an old-fashioned, pre-HD wallet
03:18 < jonasschnelli> let me have a look
03:19 < jonasschnelli> wumpus: hmm.. that error should not be related to 8389 i guess
03:19 < wumpus> let me see if it happens without
03:19 < wumpus> maybe it's just a corrupted wallet, that's possible
03:20 < wumpus> oops happens without #8408 too
03:20 < wumpus> eh without 8389 I mean
03:20 < jonasschnelli> hmm... this error means you had an error during ReadKeyValue() but not for a key
03:21 < wumpus> moving wallet out of the way, creating a new non-HD wallet
03:21 < jonasschnelli> I think your wallet.dat has a key that your current code cannot understand
03:21 < jonasschnelli> yes. Maybe do a clean start
03:22 < wumpus> that works fine, also after restarting bitcoind with that wallet
03:22 < wumpus> so it was something specific to the previous wallet, maybe it was corrupted in some older testing. Ok, phew
03:23 < wumpus> I've saved that wallet, might take a look at what key confused it later
03:27 < wumpus> huh: dumpwallet result: cTjHTNHECpYNvFsJ2QXGVaDqbX8gX625S45Errqjy44oRHxPEzMc 2011-02-02T21:16:42Z hdmaster=1 # addr=mzUm95ZQPCVhGyPcJ3CvYwARBBQKX7efdR
03:28 < wumpus> the date is wrong, and the key stayed the same before and after encryption
03:29 < jonasschnelli> hmm... that's wrong. Let me retest. Maybe we have a rebase issue here...
03:29 < jonasschnelli> Did you test with master? or 0.13?
03:29 < wumpus> 0.13 (as that's what the pull is against)
03:29 < jonasschnelli> Okay. Will do also.
03:30 < jonasschnelli> We should implement the dumpwallet test as you mentioned in that issue yesterday.
03:35 < wumpus> jonasschnelli: see https://github.com/bitcoin/bitcoin/pull/8389 for details on what I did
03:36  * jonasschnelli is looking...
03:36 < jonasschnelli> there is on inactivehdmaster....
03:36 < jonasschnelli> s/on/no
03:37 < jonasschnelli> hmm...
03:37 < wumpus> indeed, there is no inactivehdmaster, and the hdmaster didn't change
03:37  * jonasschnelli is still building 8389 on top of 0.13
03:44 < jonasschnelli> wumpus: I'm running the same steps but get a clean/correct 2nd dump
03:44 < jonasschnelli> Do you have the "Warning: Error reading wallet.dat! " in your log at the 2nd start of bitcoind?
03:45 < jonasschnelli> We definitively need a RPC test for this...
03:45 < jonasschnelli> going to write one now
03:45 < wumpus> oh shit - I've been testing without #8389 merged
03:46 < wumpus> I unmerged it because of testing the error message, then forgot to apply it again
03:46 < wumpus> is this the expected output for pre-8389?
03:47 < wumpus> LOL yes it is, look at http://www.hastebin.com/rugovalaqi.diff - it generates the same key again for the same hdkeypath
03:47 < wumpus> going to retry with actually the right code, sorry
03:48 < jonasschnelli> okay.. no problem. Better an mistake during testing then a mistake in the code.
03:49 < jonasschnelli> But anyways,.. going to write a dumpwallet test
03:49 < wumpus> yes, we need one anyway
03:53 -!- Giszmo [~leo@ppp-83-171-168-238.dynamic.mnet-online.de] has joined #bitcoin-core-dev
03:55 < wumpus> trying to update my post to a tested ACK but I get pink unicorns
03:56 < wumpus> BTW: unrelated to any of the HD changes, but I wonder why is a key generated with label="" at initial wallet initialization?
03:56 < wumpus> I'm fairly sure it's always been the case, but it doesn't seem necessary
03:58 < jonasschnelli> wumpus: During initial wallet created it always generate a first address... luke-jr once explained to my why this is necessary..
04:00 < GitHub72> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/30a87c0747a1...806b9e7570a2
04:00 < GitHub72> bitcoin/master e37b16a Daniel Cousens: transaction: clarify witness branches
04:00 < GitHub72> bitcoin/master 806b9e7 Wladimir J. van der Laan: Merge #8332: semi trivial: clarify witness branches in transaction.h serialization...
04:00 < GitHub10> [bitcoin] laanwj closed pull request #8332: semi trivial: clarify witness branches in transaction.h serialization (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8332
04:00 < wumpus> curious
04:03 < wumpus> created an issue https://github.com/bitcoin/bitcoin/issues/8416 (not relevant for 0.13, but now that we're slowly starting to commit to removing old wallet cruft)
04:04 < jonasschnelli> I could imaging some function might run into problems if there are 0 receiving addresses...
04:04 < jonasschnelli> Need to remove the default key and run all the RPC tests
04:04 < wumpus> yes it's definitely something that requires extensive testing
04:04 < wumpus> which is probably why no one ever dared remove that code :)
04:06 < jonasschnelli> heh. Indeed
04:07 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
04:10 < GitHub88> [bitcoin] laanwj pushed 3 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/45eba4b1e065...c3c82c48d9d7
04:10 < GitHub76> [bitcoin] laanwj closed pull request #8389: [0.13] Create a new HD seed after encrypting the wallet (0.13...2016/07/hd_enc) https://github.com/bitcoin/bitcoin/pull/8389
04:10 < GitHub88> bitcoin/0.13 f142c11 Jonas Schnelli: [0.13] Create a new HD seed after encrypting the wallet
04:10 < GitHub88> bitcoin/0.13 de45c06 Jonas Schnelli: [Wallet] Add CKeyMetadata record for HDMasterKey(s), factor out HD key generation
04:10 < GitHub88> bitcoin/0.13 c3c82c4 Wladimir J. van der Laan: Merge #8389: [0.13] Create a new HD seed after encrypting the wallet...
04:11 < jonasschnelli> reminder: 8389 needs an "up-port" (my mistake)
04:13 < wumpus> seems to apply cleanly to master, apart from the release-notes change which we can ignore there
04:15 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:23 < GitHub54> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/2266b43e3317a889b9150e614169acda50383bf5
04:23 < GitHub54> bitcoin/master 2266b43 Jonas Schnelli: Port from 0.13: Create a new HD seed after encrypting the wallet...
04:25 -!- btcfan [~btcfan@93-33-55-139.ip43.fastwebnet.it] has quit []
04:28 < wumpus> ok that leaves https://github.com/bitcoin/bitcoin/pull/8408 and we can roll rc2!
04:33 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
04:41 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: Textual IRC Client: www.textualapp.com]
04:54 < instagibbs> \o/
04:54 < GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2266b43e3317...133c727cc4f7
04:54 < GitHub124> bitcoin/master fbc6070 Thomas Snider: [trivial] Switched constants to sizeof()
04:54 < GitHub124> bitcoin/master 133c727 Wladimir J. van der Laan: Merge #8321: [trivial] Switched constants to sizeof()...
04:54 < GitHub32> [bitcoin] laanwj closed pull request #8321: [trivial] Switched constants to sizeof() (master...tjps_cleanups) https://github.com/bitcoin/bitcoin/pull/8321
05:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:22 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
05:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
05:24 -!- anu0 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev
05:28 -!- anu1 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 252 seconds]
05:42 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:42 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds]
05:51 -!- DongSwanson [2ea5fb94@gateway/web/freenode/ip.46.165.251.148] has quit [Quit: Page closed]
06:02 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
06:02 -!- YOU-JI [~youyouyou@FL1-125-195-16-249.chb.mesh.ad.jp] has quit [Quit: Leaving...]
06:07 < GitHub44> [bitcoin] jonasschnelli opened pull request #8417: [QA] Add walletdump RPC test (including HD- & encryption-tests) (master...2016/07/dump_test) https://github.com/bitcoin/bitcoin/pull/8417
06:47 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds]
06:47 -!- cryptapus_ [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev
06:47 -!- cryptapus_ [~cryptapus@jupiter.osmus.org] has quit [Changing host]
06:47 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:47 -!- cryptapus_ is now known as cryptapus_afk
07:05 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
07:20 -!- molz [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
07:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:39 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:03 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
08:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
08:23 -!- aj [aj@cerulean.erisian.com.au] has quit [Ping timeout: 260 seconds]
08:24 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Remote host closed the connection]
08:24 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 250 seconds]
08:24 -!- aj [~aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
08:25 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
08:29 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
08:29 -!- aj [~aj@cerulean.erisian.com.au] has quit [Ping timeout: 258 seconds]
08:29 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev
08:31 -!- aalex__ [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer]
08:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:41 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Ping timeout: 250 seconds]
08:41 -!- lightningbot [~supybot@cerulean.erisian.com.au] has joined #bitcoin-core-dev
08:41 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
08:52 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
08:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 250 seconds]
09:07 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 240 seconds]
09:09 -!- Pasha [~C@unaffiliated/cory] has joined #bitcoin-core-dev
09:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
09:16 -!- Pasha is now known as Cory
09:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:21 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 276 seconds]
09:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:38 -!- achow101 [~achow101@pool-108-16-238-51.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
09:39 -!- achow101 [~achow101@pool-108-16-238-51.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
09:44 < jonasschnelli> cfields: https://github.com/bitcoin/bitcoin/pull/8135
09:44 < jonasschnelli> Is this still required? Lost track of the osx based deployment process...
09:44 < jonasschnelli> If not, I can close the PR
09:45 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
09:45 < cfields> jonasschnelli: let me take another look. pretty sure i walked away from that one to think on it a bit. all solutions are ugly :\
09:45 < jonasschnelli> heh.. sure.. I don't really care. I think deploying (dmging) on OSX is not something we need to support.
09:46 < jonasschnelli> Depends/gitian based deployment should be sufficient IMO
09:46 < cfields> jonasschnelli: iirc macports/brew use it though
09:46 < jonasschnelli> Ah. Okay. that could be...
09:47 < jonasschnelli> Yes. Not sure if 8135 fixes it completly... I know it worked on my local mac when I tested it a couple of weeks ago
09:47 < cfields> jonasschnelli: what do you think of just pulling the ~3 python libs directly into support/macdeploy?
09:47 < cfields> i believe we patch them all already
09:48 < cfields> (until upstream merges the fixes, that is)
09:48 < jonasschnelli> Or pull in a script that downloads and patches them?
09:48 < jonasschnelli> I don't want to blow up our code base...
09:49 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 244 seconds]
09:50 < cfields> ok. thinking on it. i'll ack/pr something either way so we can move on
09:51 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: gtg gaming]
09:52 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
09:52 < cfields> jonasschnelli: hmm, now that i think about it, macports/brew only use the .app and not the dmg. how about for osx we stop there, and only linux/gitian creates the dmg?
09:56 < cfields> yes, they just use 'make appbundle'. so that works for me if it's ok by you
10:01 < jonasschnelli> cfields: yes. I think this would make sense.
10:01 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:01 < jonasschnelli> You don't need a dmg if you selfcompile
10:01 < jonasschnelli> Only if you want to distribute... Which we should not encourage over non gitian
10:03 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 244 seconds]
10:10 < cfields> right
10:16 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
10:26 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
10:37 < jtimon> is there any tutorial for monkies like me to do the gitian builds for a given release?
10:39 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:40 < sipa> jtimon: https://github.com/bitcoin/bitcoin/blob/0.13/doc/gitian-building.md
10:42 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Disconnected by services]
10:43 -!- Guyver2_ is now known as Guyver2
10:45 -!- BitcoinErrorLog [~bitcoiner@c-98-231-56-138.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
10:45 -!- BitcoinErrorLog [~bitcoiner@c-98-231-56-138.hsd1.fl.comcast.net] has quit [Client Quit]
10:47 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
10:47 < jtimon> sipa: awesome, thanks
10:48 < jtimon> looks very complete
10:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
11:00 -!- adiabat [~tx@159.203.193.74] has quit [Ping timeout: 240 seconds]
11:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:10 < GitHub99> [bitcoin] sdaftuar opened pull request #8418: Add tests for compact blocks (master...cb-testing) https://github.com/bitcoin/bitcoin/pull/8418
11:19 < instagibbs> jtimon, I was able to walk through it fine.
11:23 < jtimon> instagibbs: cool, I'm not planning on doing it today, but I would like to start doing it. Hopefully starting with 0.13's release
11:26 < sipa> it takes a while :)
11:26 < sipa> i went through it again for 0.13.0rc1
11:29 -!- netzin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
11:30 -!- netzin [~netsin@unaffiliated/jiggalator] has quit [Remote host closed the connection]
11:34 -!- netzin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
11:34 < GitHub152> [bitcoin] sdaftuar opened pull request #8419: Enable size accounting in mining unit tests (master...fix-mining-tests) https://github.com/bitcoin/bitcoin/pull/8419
11:34 -!- netzin is now known as nets1n
11:35 < sdaftuar> sipa: i am having a hard time parsing your comment in #8408
11:39 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 276 seconds]
11:39 < sipa> sdaftuar: in general, peers should not send getblocktxn for anything near the tip
11:39 < sipa> *anything not near the tip
11:39 < sdaftuar> right, agreed
11:40 < sdaftuar> are you suggesting that we disconnect for old blocks as wel?
11:40 < sdaftuar> rather than not disconnect for unknown blocks?
11:40 < sipa> if they do, they're either confused (and they're better off with us disconnecting them, or they'll wait long before timing out) or trying to do something nasty (in which case we're better off disconnecting them)
11:40 < sipa> the question is whether there are no cases under which this can happen accidentally
11:41 < sdaftuar> i assumed naively that this could happen on testnet
11:41 < sdaftuar> ie without much rigorous thought
11:41 < sdaftuar> mostly i guess i was comparing the handling of getblocktxn to how we handle getdata requests
11:42 < sdaftuar> where we silently ignore unknown, and non-main-chain old blocks
11:43 < sipa> ok, in that case let's follow the same approach
11:43 < sipa> i think there is a lot of behaviour that's ad hoc and hard to reason about there, but at least that follows existing tested code
11:44 < sipa> but perhaps we should rethink this in a bigger rework-block-sync-logic in the future...
11:44 < sdaftuar> fyi i did add a test in #8418 that catches the behaviors corrected in #8408
11:44 < sdaftuar> but 8418 is so much code that i didn't think it necessarily made sense as a bugfix PR for 0.13.0
11:44 < sipa> agree
11:45 < sipa> wait; 8418 has no changed behaviour, apart from what is already in 8408?
11:45 < sipa> i assume
11:45 < sdaftuar> it has one changed behavior, the new command line option -bip9params
11:45 < sdaftuar> i needed a way to turn off segwit on regtest
11:45 < sipa> sure sure
11:45 < sipa> i mean it should no impact on anything in mainnet
11:46 < sdaftuar> yes, agreed.  it's a lot of testing code, plus something that should be regtest-only
11:46 < sdaftuar> assuming i didn't screw up :)
11:48  * luke-jr won't be able to make the meeting today
11:50 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
12:00  * jonasschnelli rings the bell
12:00 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
12:00 < jtimon> ready
12:00 < cfields> thanks, here
12:00 < sipa> present
12:00 < instagibbs> pre-zent
12:01 < wumpus> #startmeeting
12:01 < lightningbot> Meeting started Thu Jul 28 19:01:03 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01 < kanzure> greetings
12:01 < wumpus> topc suggestions?
12:01 < jtimon> proposed topic eliminate ISM (NicolasDorier's #8391)
12:02 < luke-jr> about to board flight..
12:02 < wumpus> rc2 is very near being tagged, https://github.com/bitcoin/bitcoin/milestone/20, could use some extra review for https://github.com/bitcoin/bitcoin/pull/8408
12:02 < wumpus> but that's the only remaining pull tagged 0.13 left
12:02 < luke-jr> wumpus: releadse notes still need to not recommend/opressure bad policy
12:03 < wumpus> luke-jr: ok
12:03 < luke-jr> tag applicable pr pls
12:03 < jtimon> wumpus: shouldn't #8412 be in 0.13?
12:03 < wumpus> but I guess people don't agree on what 'bad policy' is
12:03 < kanzure> also about to board a flight in a bit
12:03 < luke-jr> wumpus: …
12:03 < gmaxwell> luke-jr: don't elipises wumpus.
12:03 < jonasschnelli> I think it should
12:03 < jonasschnelli> (8412)
12:04 < jonasschnelli> I'll tag it
12:04 < jtimon> in fact, I think it should go in 0.12.2 if there's going to be one
12:04 < wumpus> I'm fine with 8412, hadn't heard of it before
12:04 < jtimon> wumpus: yeah, just created it yesterday
12:04 < sipa> 8412 seems harmless and silly not to include
12:04 < jonasschnelli> It's a inconsequence with no risk attached to it (IMO)
12:05 < wumpus> seems we agree
12:05 < jtimon> great
12:05 < luke-jr> the current release nites recommends and undisputably bad policy. if there is controversy it shouldnt recommend anything
12:05 < wumpus> luke-jr: do you have a proposed update to the release notes?
12:05 < gmaxwell> RE 8412: why are we adding flags for long locked in network features?
12:05 < cfields> sdaftuar: any clues where to poke at #8096? Do you still think that's a blocker for release, or calling it a fluke?
12:06 < luke-jr> wumpus: yes, the pr is open for a week now
12:06 < cfields> err.. sorry for topic drift. we can pick that up later.
12:06 < jtimon> what is the "bad policy"? what am I missing?
12:06 < gmaxwell> okay never mind, I didn't look at the patch initially, I thought it was GBT rather than libconsensus.
12:06 < wumpus> luke-jr: the only PR I know of also changes quite some code
12:06 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8388/
12:07 < jonasschnelli> Yes. Its not an release not only PR
12:07 < morcos> luke-jr: i don't understand why we need to change anything now.  segwit is not released.  using blockmaxcost is fine for 0.13
12:07 < gmaxwell> s/not/note/
12:07 < luke-jr> jtimon: blockmaxweight rsther than blockmaxsize
12:07 < morcos> uh, or weight
12:07 < jonasschnelli> gmaxwell: thanks. :)
12:07 < luke-jr> wumpus: because people were insisting the code had to change to remove the recommencaation
12:08 < gmaxwell> I think it's foolish that we're still releasing with settings that don't reflect the near ubiquitious network usage.
12:08 < sipa> luke-jr: we shouldn't be relying on miners picking safe policy that only harms themselves
12:08 < jtimon> gmaxwell: on that note, agree with sipa that we should decouple the consensus flags bit poisitions from the script flags', but that's only for master
12:08 < sipa> luke-jr: if we're not fine with larger blocks, we shouldn't do segwit as-is
12:09 < morcos> sipa: agreed
12:09 < morcos> where we is the big we
12:09 < sipa> in practice, nearly every miner will set the max block size and weight to the maximum allowed value
12:09 < sipa> morcos: yes!
12:09 < luke-jr> sipa: we cannot stop segwit for better or worse
12:09 < gmaxwell> Asking miners to produce blocks smaller than the network technically allows is a failed policy, in nay case, as we've seen. The default has been 750k-- but go look at the chain, no 750k blocks to be seen. :P
12:09 < luke-jr> and hopefully in some monthhs larger blocks WILL vbe fine
12:10 < luke-jr> sipa: prqactice is tbd
12:10 < sipa> luke-jr: 'fine' is not a boolean
12:10 < luke-jr> i need to board…
12:10 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
12:10 < wumpus> gmaxwell: on the other hand, miners not dumbly using the default settings is great, it's exactly what should be happening
12:10 < gmaxwell> luke-jr: well nothing special will happen because you aren't here. :P go board, we can talk later.
12:10 < morcos> i think it would be fine to include an explanation of the difference in the release notes without making a judgement about whether or not you should want to have blocks with size smaller than what might be created if you only limited by weight
12:10 < luke-jr> bbl
12:11 -!- I_DID_LSD_ON_A_P [54376f2e@gateway/web/cgi-irc/kiwiirc.com/ip.84.55.111.46] has joined #bitcoin-core-dev
12:11 < jtimon> the way I see it, the default is stupid to kind of force miners not to use the default (and to avoid being changing some defaults all the time)
12:11 < morcos> if we don't recommend using size but explain why the option exists, then i also see no reason to cache size, if some people want to use it, its ok if its calc'ed on the fly (as current code does)_
12:12 < jtimon> so the issue is that weight has a bigger default than size had?
12:12 < wumpus> jtimon: yes, I thought that was the point
12:12 < wumpus> jtimon: otherwise it's back to 'devs decide the values'
12:12 < btcdrak> sorry I am late. #8412 should be included.
12:12 < jtimon> yeah, and people asking to increase op_return size and shit
12:13 < gmaxwell> IMO we should just make the defaults the maximums. Doing otherwise is thereatics, we know that users will immediately set them to the largest allowed values. And the few that wouldn't will happily manually reduce them.
12:13 < jtimon> re #8412 should I open the PR to 0.13 then?
12:13 < gmaxwell> this argument specifically applies to the 'max weight/size' things because we have expirence there with how they will be set in practice.
12:14 < sipa> jtimon: 8412 will backport trivially, no need for backport PR
12:14 < gmaxwell> (also, FWIW, the income difference between 750k size and maximum is non-trivial).
12:15 < jtimon> no strong opinion, it seems natural to take the oportunity of moving from size to weight to change the default to something more used, but I will complain when somebody asks to change it later
12:15 < wumpus> I really don't like to go back to discussing what defaults to use, e.g. we've had tons of pull requests to change the default block size and we've always used the reasoning explained by jtimon to hold them off
12:15 < wumpus> but indeed, no strong opinion either
12:16 < jtimon> if we want to set a lower default to "force people" not to use defaults there, that's fine with me as well
12:16 < sipa> the current 0.13 code does not change any defaults
12:16 < morcos> wumpus: i suppose the confusion is that now that we have 2 options, its totally non-intuitive how to se tthem given they have non max defaults
12:16 < jtimon> sipa: then what's the problem again?
12:16 < sipa> and the release notes explain the difference, and that only using weight is faster
12:16 < wumpus> yes, what is the problem then?
12:16 < sipa> i think the code and notes in 0.13 are fine
12:17 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
12:17 < gmaxwell> The notes don't seem to inform me how to set it to the maximum.
12:18 < gmaxwell> which is what 99% of the users are going to want to do, as it's what they currently do.
12:18 < sipa> ok, let's fix that in the --help message?
12:18 < gmaxwell> They won't read that. They'll read the release notes with greater odds than --help.
12:18 < wumpus> if it's what they currently do ,then why would the default even matter? they override it already.
12:18 < gmaxwell> (otherwise they wouldn't know of the maxweight option at all)
12:18 < sipa> i assume they'll read neither
12:19 < sdaftuar> (Note that for mainnet, in this release, the equivalent parameter for -blockmaxweight would be four times the desired -blockmaxsize. See BIP 141 for additional details.)
12:19 < morcos> you need to know how to set the limits to max, and also not have the code to unnecessary extra serialization
12:19 < gmaxwell> The default doesn't matter, except it forces people to override, which they'll likely get wrong now that it's been made more complicated.
12:19 < wumpus> in any case the help message and release notes should be clear, if they are missing information that needs to be added
12:20 -!- yep [4db69c33@gateway/web/freenode/ip.77.182.156.51] has joined #bitcoin-core-dev
12:20 < gmaxwell> E.g. you'll read that release note and then change your maxsize to maxweight, and then be surprised when their blocks are 250k. :P
12:20 < achow101> why not just set it to the max? I can't see any reason why users would complain about that given that that is what they are going to do anyways
12:21 < gmaxwell> achow101: that was the argument I was making before. wumpus correctly notes that going and debating defaults again isn't great.
12:21 < jtimon> gmaxwell: ok, so you want to just clarify how to select the max block size in the --help because now it's more complicated than before and add something to the release notes?
12:21 < gmaxwell> In particular luke will go on a public attack campaign, and some are trying to avoid it.
12:21 < wumpus> because we should not be in the business of determining what values miners should use, we've always tried to avoid that, for good reason
12:21 < gmaxwell> (because he sees a kind of principled position arising from setting a more correct default which no one uses)
12:22 < gmaxwell> wumpus: not at question of should, it's a question of 'does', and forcing people to set settings which are now somewhat complex due to the new option is a bit unfortunate.
12:22 < wumpus> if you want to inform people how to set the maximum, then adding how to do so in the release notes makes sense
12:22 < gmaxwell> yes, I can make a PR that explains how to do that.
12:22 < wumpus> gmaxwell: we've been there; this really feels like deja vu
12:23 < wumpus> so to be clear: the current 0.13 defaults will cause miners to do something else than create 750kb blocks, as was the case for 0.12?
12:23 < gmaxwell> No, the defaults are functionally equal to 0.12's.
12:23 < sdaftuar> wumpus: no, that is not the case.
12:24 < wumpus> ok, good then
12:24 < morcos>  i think the release notes are accurate and relatively comprehensive enough right now.  unfortunately, i think the logic that exists is complicated enough that miners will make mistakes and either create smaller blocks than they meant to or slow down their mining computation
12:24 < gmaxwell> the default maxweight is 3 million, which, with no witness txn is exactly equal to 750k maxsize.
12:24 < jtimon> I really don't understand luke-jr's issue if the defaults are untouched
12:25 < morcos> i'm not sure what the solution to that is other than explaining exactly what you should do if you want to mine max size blocks, which might be seen as a recommendation
12:25 < wumpus> explaining in the release notes and documentation is exactly the right thing to do
12:25 < gmaxwell> jtimon: because a maxweight of 3m allows for a 3mb block in future versions with segwit activated and he doesn't want miners being instructed to use maxweight.
12:25 < instagibbs> jtimon, theoretical size max would be 3MB I think
12:25 < wumpus> so people understand what is being done
12:25 < wumpus> instead of saying 'this is too complicated for you, just follow the defaults'
12:26 < gmaxwell> wumpus: 'just follow the defaults' was never my position.
12:26 < jtimon> gmaxwell: why do miners need to be instructed about maxweight before activation? (not that I'm against informing people beforehand)
12:26 < gmaxwell> Rather, we have defaults that match AFAICT what _no one_ wants, meaning that there is no one who can go "oh what the defaults want is already what I want, so I don't have to screw with anything."
12:26 < wumpus> gmaxwell: I know, but that's what would effectively happen if the defaults are just the maximum which everyone uses
12:26 < morcos> gmaxwell: exactly
12:27 < wumpus> gmaxwell: people will start using the defaults, and be recommended using the defaults, which makes us in charge of determining the values. Next release there will be 20 pulls again of people that want to change the default to their favourite value, to lead others into using it
12:27 < morcos> jtimon: they need to be informed because we kept blockmaxsize as an option, but it is slower to calculate (by unknown amount)
12:27 < gmaxwell> jtimon: because he believes its establishing a bad set of practices which will hold over. I think he's right that it will hold over.. but only slightly, people are also going to immediately crank to maximum. I think luke realizes this too, but is adopting a principled position of not supporting something he thinks is bad even if it is inevitable.
12:28 < jtimon> ok, so imagining what most are doing and assuming they don't touch their configuration for now and don't do anything about weigh (ie use the default), everything will be fine, right?
12:28 < gmaxwell> And he think it is bad until compactblock deployment has proven that miners producing larger blocks is okay.
12:28 < jtimon> morcos: I see
12:28 < wumpus> hence, I really think defaults discussion is a waste of time, it just creates more of the same
12:29 < gmaxwell> instead we get worse discussions because we have setting which actively trip up users.
12:29 < sipa> i think we can just leave defaults as they are now
12:29 < gmaxwell> Sorry, wumpus, the software doesn't exist to save us from discussion, it exists to serve its users.
12:29 < wumpus> that's what we've learned from previous messing around with defaults, I don't understand why you've certainly changed your mind about this
12:29 < gmaxwell> I agree that we can leave them.
12:29 < instagibbs> ack for leaving as-is 
12:29 < jtimon> mhmm, if they were creating bigger blocks, they will keep doing so, and if they were using the default, they will keep doing so
12:29 < gmaxwell> But we need instructions for setting them to maximum, because as is people will screw it up and produce 250k blocks (and if you care about complaining: they'll accuse us of being sneaky)
12:30 < wumpus> gmaxwell: where did I claim that the software exists to save us from discussion!??
12:30 < wumpus> gmaxwell: wtf is this
12:30 < jtimon> if they move to weigh because it's cheaper but still use the default, the size is the same
12:30 < morcos> I think the lesson to be learned here is we make the code too complicated by trying to be all things to all people.  For policy (not consensus) related decisions, i don't think we need to be able to support every possible thing.   We waste so much time trying to shoehorn in things like priority and maxsize, while simultaneously trying to make the code more efficient
12:30 < sipa> agree
12:31 < gmaxwell> wumpus: I'm sorry, thats what I'm reading out of your position on the defaults. I feel like you're basically arguing that we should have setting we know are bad and don't match usage, because it allows to refuse to discuss the defaults.
12:31 < Eliel_> Well, you could always just make the mining part refuse to function unless the user manually sets the required config values :P
12:31 < gmaxwell> I think thats an argument that we should make the software objectively worse in order to avoid debates over what is better.
12:32 < gmaxwell> I apologize for reading so much into it.
12:32 < Eliel_> as in, no dfaults
12:32 < jtimon> anyway, it seems this is mostly an issue for luke-jr, so I don't see the point in keeping discussing it while he is on a plane
12:32 < achow101> Eliel_: it's not very user friendly though
12:32 < sipa> how about we leave things as is, and in the future (whenever that may be) we find a way to simplify the options (back to one argument, for example)
12:32 < sdaftuar> ACK simplifying in the future
12:32 < morcos> sipa: i think thats the best we're going to get at this point
12:32 < sipa> that can 1) solve the problem of inadvisable defaults
12:32 < gmaxwell> But we really do need to have instructions on doing what people will do. And when we write those luke will complain because it will be arguable that we are endorsing those settings. Cannot escape the drama. :)
12:33 < wumpus> Eliel_: yes, that has been suggested before
12:33 < sipa> and 2) by changing things at the same time as simplifying the logic, it is not necessarily a recommendation
12:33 < achow101> gmaxwell: just tell him to suck it up  and deal with it
12:33 < Eliel_> achow101: that depends... if the error message comes with a link to a good instructional document, it might actually be a pretty good result.
12:33 < gmaxwell> luke only insisted we have the size option because compactblocks is not yet deployed, and if relay network isn't working, orphaning is highly related to size.
12:33 < gmaxwell> It didn't seem like it was worth debating.
12:33 < morcos> gmaxwell: i'd argue we can leave the release notes as is (which luke might still object to) and then just use other channels to explain to people very simply how they can create max blocks if they want.  simple.  set -blockmaxweight=4000000 and dont' set blockmaxsize at all
12:33 < wumpus> Eliel_: it may be better than setting silly defaults, but there was never agreement to do it
12:34 < gmaxwell> morcos: I can agree with that too.
12:34 < jtimon> gmaxwell: maybe overkill instructions with all the options (keep using the default in a more efficient way (ie not using maxsize) and do what most poeple do) is enough for luke-jr?
12:34 < Eliel_> wumpus: that's pretty much my reasoning behind the suggestion.
12:34 < Eliel_> if you can't set defaults the way most people want them, don't set any.
12:34 < morcos> I'm also fine with that suggestion
12:35 < gmaxwell> luke argued for that for years.
12:35 < Eliel_> and about user friendliness... do you really want to allow people to mine without understanding what they're doing?
12:35 < wumpus> Eliel_: the thing is that people disagree deeply over these setings
12:35 < jtimon> other topics?
12:36 < wumpus> #topic eliminate ISM (NicolasDorier's #8391)
12:36 < gmaxwell> Eliel_: absolutely.
12:36 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
12:36 < gmaxwell> Eliel_: participants in the network should be avoiding judgement, they're not in charge of the system because they participate.. and not because they have some theoretical technical ability to censor varrious behaviors.
12:37 < kanzure> i need to leave. i would like to request that folks send me topic suggestions for my wishlist for the upcoming gathering. not end of the world if it doesn't happen, but having a few thoughts prepared is worthwhile.
12:37 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
12:37 < wumpus> ping jtimon
12:37 < jtimon> this is quite important for other libconsensus refactors, the sooner it is merged the easy it will be to PR other changes, I would really appreciate fast review, test and merge of #8391
12:38 < jtimon> I would say it's the most important libconsensus' PR opened right now
12:38 < wumpus> I think we already agreed removing ISM was a good thing lastm eeting, is there more to discuss about it?
12:39 < jtimon> wumpus: well, I hope not, but that's why I bring it up (apart from asking for review)
12:39 < wumpus> yes it does need more review/testing
12:39 < wumpus> #action review https://github.com/bitcoin/bitcoin/pull/8391
12:39 < jtimon> thanks
12:39 < cfields> next topic suggestion: boost threads/sync replacement for master
12:40 < wumpus> #topic boost threads/sync replacement for master
12:40 < jtimon> and of course nacks and nits always the sooner the better
12:40 < cfields> https://github.com/bitcoin/bitcoin/pull/8023
12:40 < cfields> is nowish a good time to start pushing for that?
12:40 < wumpus> sounds good to me
12:41 < gmaxwell> neat.
12:41 < cfields> ok. it's a drop-in replacement for interruptible boost threads/condvars. preferred to switch chunks at a time, or all in one go?
12:41 < jtimon> cfields: since it's disruptive, the "refactor window" seems like the perfect time for it, no?
12:41 < wumpus> what about your network refactor? seems we should start merging for that as well?
12:42 < wumpus> cfields: what would 'chunks at a time' mean, using two potentially conflicting thread libraries?
12:42 < cfields> wumpus: yea, review/acks of 2 outstanding PRs would be a big help...
12:42 < jtimon> oh, #8023 is not disruptive at all
12:42 < cfields> sec for numbers
12:42 < wumpus> cfields: can you post the links? ok
12:42 < NicolasDorier> I'm back.
12:43 < NicolasDorier> for removing ISM
12:43 < wumpus> welcome back
12:43 < NicolasDorier> I synched nodes successfully
12:43 < NicolasDorier> so basically, it needs some review from other people, but should be good
12:43 < cfields> #8128 and #8085
12:43 < btcdrak> NicolasDorier: ok I'll run a full sync this weekend
12:43 < wumpus> #action review+test https://github.com/bitcoin/bitcoin/pull/8128 Net: Turn net structures into dumb storage classes
12:44 < cfields> #8085 is a beast to rebase. I have it done locally, but I'm waiting for #8128 to go in before rebasing again and pushing
12:44 < sipa> i tried switching some subset of the code to std::thread before, and it was impossible... you need to change it everywhere at once
12:44 < wumpus> #action review+test https://github.com/bitcoin/bitcoin/pull/8085 p2p: Begin encapsulation
12:44 < cfields> ok, I'll approach it as one big change then
12:45 < wumpus> yes it probably makes most sense to do it all as once, it's painful but at least it should be a one time pain then
12:46 < NicolasDorier> question: what you call "refactor windows" what is it ? 
12:46 < cfields> ok. iirc there are 1/2 pre-reqs left for boost-specific usage, then basically a search/replace. I'll go back through my notes and do pulls for the pre-reqs.
12:47 < wumpus> NicolasDorier: well the best time for larger changes in 0.14 is now, as there's still some months to go before the release and there is enough time to address problems that come up
12:48 < wumpus> e.g. you wouldn't want to switch the thread library a few days before release
12:48 < NicolasDorier> ok nice to know, as I'm working around libconsensus... will go a bit quicker so
12:48 < NicolasDorier> oh
12:49 < NicolasDorier> about https://github.com/bitcoin/bitcoin/pull/8259 when will it be merged for 0.13 ?
12:49 < jtimon> re ISM (sorry for not saying it earlier), thoughts on https://github.com/jtimon/bitcoin/commit/273e27bd0c086f5ba20cebc2f5ec9e24f9d79015 ? independently on adding it to the PR or leave it for later
12:49 < sipa> NicolasDorier: we'll need to backport that to 0.13 before segwit
12:50 < NicolasDorier> ok
12:51 < wumpus> NicolasDorier: it's not even merged for master yet, after it is it can be backported
12:51 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
12:51 < wumpus> I'll add a "needs backport" label
12:51 < NicolasDorier> ok no prob
12:52 < sipa> NicolasDorier: thanks for the reminder on that btw
12:52 < wumpus> seems to need some more review too
12:52 < NicolasDorier> jtimon: I'd like to see it go personally, but I don't know the reason why bip34Hash was here in the first place
12:52 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
12:52 < sipa> jtimon: i vaguely remember there were ugly interactions between the cache code that avoids some database operation, bip30 and bip34... but i don't remember the details
12:52 < wumpus> #action review https://github.com/bitcoin/bitcoin/pull/8259 Hash Cache
12:53 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
12:53 < jtimon> uff, #8259 is ultra disruptive to consensus branch, should review...
12:53 < NicolasDorier> jtimon: yes, I was asking because as part of our work on libconsensus, we'll need to be fixed on that
12:54 < jtimon> yep, you agreed on #8346 first, right?
12:54 < sipa> jtimon: 8259 will need backport to 0.13
12:55 < NicolasDorier> yes
12:56 < wumpus> ok, any final topics?
12:57 < jtimon> sipa: damm, and #8346 cannot be backported because it's a refactor, "refactor winwow interlocking", before a release it's really the worse time to make refactors, but I repeated this many times...
12:57 < wumpus> no, refactors will not be backported, that is too risky
12:58 < jtimon> wumpus: then having the "refactor window" precisely when we're backporting more stuff is a bad idea
12:58 < sipa> it's fine, we'll find a solution for that
12:58 < wumpus> well wait until after the release then jtimon
12:58 < wumpus> hopefully rc2 will be the last
12:58 < wumpus> that'd mean the release can be next week or so
12:58 < jtimon> wumpus: if that still counts as "refactor window" I'm happy, I know when they start but I don't have a clear idea on when they finish
12:58 < sipa> wumpus: the issue is that 8346 won't be backported to 0.13, but 8259 will be, thus 8259 can't be based on that refactor
12:59 < sipa> but i don't think it's a big issue
12:59 < wumpus> sipa: yes, moving the refactor window to after the 0.13.0 release won't help for that
12:59 < sipa> sometimes code needs non-trivial backports
12:59 < sipa> so be it
12:59 < wumpus> yes
13:00 < wumpus> it's still trivial compared to backporting to 0.12
13:00 < sipa> DOING
13:00 < wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Jul 28 20:00:26 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-28-19.01.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-28-19.01.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-28-19.01.log.html
13:00 < sipa> DOH-ING
13:01 < jtimon> but in this case means that my alternative refactor to checkinputs will never get reviewed or merged...(even if it's way way older than #8259), so my best option is to rewrite it as nits ot #8259 I guess...
13:01 < gmaxwell> DOOIINNGGG
13:01 -!- thokon00 [~thokon00@unaffiliated/thokon00] has joined #bitcoin-core-dev
13:01 < jonasschnelli> sipa: time for your Pokemon walk. :P
13:01 < sdaftuar> cfields: regarding #8096, i don't think i've seen that error since i first reported it.
13:01 < jtimon> haha
13:01 < wumpus> :P
13:02 < NicolasDorier> jtimon: my 8259 in fact date back in march :D
13:02 < cfields> sdaftuar: ok. I tried to investigate, but I couldn't even find a good starting point
13:02 < NicolasDorier> I needed to refactor and reopen the issue several time
13:02 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
13:02 < NicolasDorier> I mean rebase
13:02 < sdaftuar> i recall having no idea what could have happened :)  i just fired up a script to run that test until failure, hopefully i'll get something i can debug
13:02 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has left #bitcoin-core-dev []
13:02 < NicolasDorier> (the first time 8259 was created was on sipa's branch before the merge :p)
13:03 < jtimon> well, my approach is as old as #6061
13:03 < cfields> sdaftuar: only thing I could think of is to add an assert(!empty()) at the beginning so at least we'll be able to tell if it was already empty, if we end up seeing another crash
13:03 < wumpus> sdaftuar: cfields: in any case, the question was whether that should be a blocker; I don't think a rare test failure should qualify as a release blocker unless you strongly suspect it to be a deeper problem
13:03 < sdaftuar> wumpus: i agree that it shouldn't be a blocker
13:03 < jtimon> that was a "please don't do too much stuff at a time" PR for my approach
13:04 < cfields> wumpus: i have no reason to suspect it's a major problem, i just don't like that we can't explain it :)
13:04 < wumpus> sdaftuar: thanks, removing the milestone then
13:05 < jtimon> NicolasDorier: last attempt to move in my direction: https://github.com/bitcoin/bitcoin/pull/6445
13:05 < wumpus> cfields: yes I agree an unexplainable problem is slightly worrying
13:07 < jtimon> it seems it was never the time until now, that it's too late because 8259 needs to be backported but #8346 can't, not your fault...
13:07 < jtimon> should I close #8346 then?
13:07 < jtimon> ping btcdrak
13:08 < NicolasDorier> I don't think it should be closed, we'll just merge later
13:08 < wumpus> jtimon: I agree that it's annoying
13:08 < btcdrak> jtimon: leave it open
13:08 < sipa> jtimon: leave it open
13:08 < jtimon> NicolasDorier: oh, it's not disruptive to your approach, cool
13:08 < wumpus> it has quite a lot of utACKs so just should be merged?
13:09 < NicolasDorier> fine for me
13:09 < jtimon> I thought it would interfere with #8259, sorry
13:09 < sipa> it would, but so be it
13:09 < sipa> sorry for bringing it uo
13:10 < jtimon> never be sorry for bringing things up, that's what I need
13:11 < NicolasDorier> I've rebased 8259 10 times, I guess I'll support an 11 th time :D
13:11 < NicolasDorier> I've nothing to do today anyway :^p
13:11 < jtimon> sipa: if you allow me to be honest, I feel you're some times "too polite" with me as a reviewer. Nits and nacks the sooner the better!
13:11 < jtimon> anyway, I should review 8259 before continuing talking about it, sorry
13:14 -!- schmidty [~schmidty@unaffiliated/schmidty] has quit [Ping timeout: 276 seconds]
13:19 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
13:19 -!- thokon00 [~thokon00@unaffiliated/thokon00] has left #bitcoin-core-dev []
13:19 < jtimon> NicolasDorier: no harm in squashing #8259 at this point I think?
13:22 -!- nets1n [~netsin@unaffiliated/jiggalator] has quit []
13:24 -!- anu1 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev
13:27 -!- ArthurNumbanumba [~ArthurNum@h247079.upc-h.chello.nl] has quit [Ping timeout: 240 seconds]
13:27 -!- anu0 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 250 seconds]
13:33 -!- Giszmo [~leo@ppp-83-171-168-238.dynamic.mnet-online.de] has quit [Ping timeout: 258 seconds]
13:37 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
13:41 < NicolasDorier> jtimon: yes I'll squash. Will do it after changing stuff that need to change because of #8346.
13:41 -!- Giszmo [~leo@ppp-83-171-168-238.dynamic.mnet-online.de] has joined #bitcoin-core-dev
13:41 < NicolasDorier> actually I think that 8346 will make it shorter to review in fact
13:42 < NicolasDorier> because a method which needed the hash cache is not called anymore.
13:43 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving]
13:44 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Ping timeout: 260 seconds]
13:45 < jtimon> cool
13:45 < jtimon> keep the old version for the backport though
13:46 < jtimon> rebase -i addict suggestion: and then try to rebase the old version on top of the new one and see what happens
13:47 < jtimon> nothing to commit is complete success
13:48 < jtimon> no, wait, forget the defintion of success, that's wrong
13:48 -!- windsok [~windsok@45.63.59.8] has quit [Read error: Connection reset by peer]
13:48 < NicolasDorier> In fact in https://github.com/bitcoin/bitcoin/pull/8259/files#diff-ca74c4b28865382863b8fe7633a85cd6L740 the hashCacheMap was not even use...
13:49 < NicolasDorier> used
13:49 < NicolasDorier> because it does not run the scripts
13:49 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev
13:50 -!- cryptapus_afk is now known as cryptapus_
13:50 < jtimon> not sure I understand what you just said
13:50 -!- cryptapus_ is now known as cryptapus
13:54 < NicolasDorier> jtimon: in the common piece of code we are touching between #8259 and #8346, I was passing a hashCacheMap as parameter to CheckInput. But it was not even used inside CheckInput because fCheckScript is false.
13:55 < jtimon> oh, yeah, I see, was extending on the comment that it will be shorter for master than for 0.13
13:56 < jtimon> in fact, you can remove the fCheckScript parameter "for free" in the same commit, as now all callers use false. That's for master, not for 0.13
13:57 < jtimon> sorry, now all callers use true
13:58 < NicolasDorier> oh that's cool
13:59 < jtimon> or your life would be easier if you just backported both #8259 and #8346 instead of only one plus the differences of doing it in a different order, and would make people "forwardporting" stuff easier too, but that would be "cheating" by some defintion I am yet to unterstand
14:02 < jtimon> that's ancient coolness that's been ready to pick up for long
14:04 < jtimon> but what I really want to do is always call checkTxInputs way before checkInputs (before noone else calculates txFees in that function [ie ConnectBlock and AcceptToMemoryPool])
14:05 < jtimon> and remove some redundant calculations while helping with encapsulation
14:05 < jtimon> then divide the remaining checkinputs, one multi-thread and one plain simple
14:06 < jtimon> of course there's many ways to do this
14:08 < jtimon> the first version of verifyblock can be single threaded, we don't even have to expose it in libconsensus yet, just having it would be great (we can also expose it in rpc with the storage dependencies I guess, but not sure how useful that would be)
14:10 < jtimon> when we figure out how to expose multi-threading, storage and caches, we can expose verifyblock in libconsensus, but that sounds too long term and that's why I was focusing on maybe exposing verifyheader or verifytx or getflags or whatever was ready first
14:10 < jtimon> but I agree that just complete an internal verifyblock would be great
14:10 -!- cryptapus is now known as cryptapus_afk
14:12 < jtimon> and I'm focusing on that now, like you, there's still some stuff I need to move up in my branch because it was about completing verifytx, but it's not needed for completing verifyblock (ie moving things out of contextualcheckblock() )
14:13 < jtimon> btw, for trivial consensus stuff #8413 is also opened
14:17 < bsm117532> ls
14:19 -!- yep [4db69c33@gateway/web/freenode/ip.77.182.156.51] has quit [Quit: Page closed]
14:19 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
14:19 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
14:21 < jtimon>  bsm117532:
14:21 < jtimon>  drwxrwxr-x 23 jt jt     12288 jul 28 05:27 .
14:21 < jtimon>  drwxrwxr-x 12 jt jt      4096 jul 28 05:24 ..
14:25 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:26 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-csjodsspivzyrwkg] has left #bitcoin-core-dev []
14:28 < bsm117532> [ whereis my brain?
14:32 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-csjodsspivzyrwkg] has joined #bitcoin-core-dev
14:37 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection]
14:37 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev
14:38 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
14:44 < jtimon> bsm117532: in your brain and some other parts of your body, but wrong channel again
14:45 < bsm117532> bash: [: missing `]'
14:46 -!- goatpig [56f74bcf@gateway/web/freenode/ip.86.247.75.207] has joined #bitcoin-core-dev
14:51 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Ping timeout: 260 seconds]
14:54 -!- netzin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
14:54 -!- netzin is now known as nets1n
14:54 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
15:06 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Ping timeout: 250 seconds]
15:20 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
15:39 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
15:49 -!- nets1n [~netsin@unaffiliated/jiggalator] has quit [Remote host closed the connection]
15:51 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:52 < jtimon> updated #8346
15:58 < cfields> sdaftuar: heh: i just forced a crash in PruneBlockIndexCandidates
15:58 < cfields> not the same crash, but I suspect it's something similar
15:59 < GitHub106> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/133c727cc4f7...ad087638ee48
15:59 < GitHub106> bitcoin/master d12b732 Jorge Timón: libconsensus: Expose a flag for BIP112...
15:59 < GitHub106> bitcoin/master ad08763 Pieter Wuille: Merge #8412: libconsensus: Expose a flag for BIP112...
15:59 < GitHub127> [bitcoin] sipa closed pull request #8412: libconsensus: Expose a flag for BIP112 (master...0.13-consensus-bip112-flag) https://github.com/bitcoin/bitcoin/pull/8412
16:00 < cfields> sdaftuar: http://pastebin.com/raw/CnV5HSUP. ctrl+c during startup. 
16:02 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
16:06 < jtimon> illumination moment: there was a translation error in the way I was saying "for free": some times I meant "gratiously" I think
16:07 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Client Quit]
16:14 < jtimon> I wonder why native english speaker don't have some achronym for G.R.A.T.I.S. meaning something completely different yet...
16:14 < GitHub140> [bitcoin] theuni opened pull request #8421: httpserver: drop boost (#8023 dependency) (master...http-thread) https://github.com/bitcoin/bitcoin/pull/8421
16:15 -!- cdecker [2e8c34b6@gateway/web/cgi-irc/kiwiirc.com/ip.46.140.52.182] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
16:19 < GitHub133> [bitcoin] sipa pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/8360d5b37dd4d8248da0552de40e5ea1d17f51eb
16:19 < GitHub133> bitcoin/0.13 8360d5b Jorge Timón: libconsensus: Expose a flag for BIP112...
16:20 < sipa> NicolasDorier: i think you misunderstand my suggestion
16:20 < NicolasDorier> mh maybe
16:22 < NicolasDorier> sipa: my point is that lazily calculating the mid state hashes is not worth the added complexity. The only saving is for transaction having no SIGHASH_ALL.
16:22 < NicolasDorier> if a CachedHashes are not read only, then I need to protect read and write with a lock
16:23 < sipa> NicolasDorier: but you solve that by having two CachedHashes
16:23 < sipa> one that's being used inside the computation and modified, and then only copying from the locked map beforehand, and merging back afterwards
16:24 < sipa> your code already does this correctly
16:24 < NicolasDorier> oh I see as part of the TrySet ?
16:24 < sipa> yes
16:24 < sipa> TrySet would merge
16:24 < NicolasDorier> ah ok yes indeed this is simple
16:25 < NicolasDorier> will do that thanks
16:25 < NicolasDorier> I'm a bit too used to everything is a pointer from C# world I forgot I was just using a copy
16:25 < NicolasDorier> for the computation
16:25 < sipa> it also has the advantage of making signature agregation easier later :)
16:27 < NicolasDorier> got it
16:27 < sipa> also, i'd not touch sigcache.h
16:27 < sipa> this is not signature caching
16:29 < NicolasDorier> ok will create a new file for it
16:29 < sipa> thanks
16:47 < jtimon> SIGHASH_ALL is the main.cpp of sighashes
16:49 < jtimon> at some point SIGHASH_ALL should be deprecated, and at some point main.cpp should be non-existent (not probably most users won't agree with this [yet])
16:51 < jtimon> btw, when I talk about "users", the non-existing CPolicy interface is the way I would like to talk with them, with CRandomPolicy on my side to defent some concerns future users may have
16:54 < jtimon> but to be completely honest, when I think about "users" I'm just thinking about me-and-or-potential-future-me's, at least r/btc got that right
17:04 -!- nets1n [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
17:04 -!- nets1n [~netsin@unaffiliated/jiggalator] has quit [Remote host closed the connection]
17:04 -!- nets1n [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
17:17 < cfields> NicolasDorier: hmm, I hadn't seen your hash cache stuff yet
17:18 < cfields> I had been working on something very similar for the purpose of making the sigcache lock free
17:18 < cfields> (after seeing morcos's numbers and discussing with jeremyrubin)
17:19 < NicolasDorier> cfields: why is it so important to be lock free ?
17:19 < cfields> I was going to wait to discuss with Jeremy since it was his idea, but I suppose I should push it up now for discussion. It'd be a shame if we collided with eachother and missed out on the possible speedup
17:19 < cfields> NicolasDorier: it's not, but morcos reported very significant lock contention with 16 cores. and it's not actually necessary to lock it
17:20 < NicolasDorier> for the cached hash make, the lock is tacken very briefly for a lookup in a map
17:20 < cfields> NicolasDorier: sec, I'll push up my (not-fully-vetted) work
17:20 < NicolasDorier> cached hash map
17:20 < NicolasDorier> ok
17:25 < cfields> NicolasDorier: https://github.com/theuni/bitcoin/tree/sigcache-speedup
17:26 < cfields> NicolasDorier: much of it is quite similar to your work :)
17:27 < cfields> NicolasDorier: if i can convince morcos to bench that and there's no real improvement, I'll drop it. Otherwise, we might want to merge approaches a bit
17:28 < sipa> alternatively, for just this, we can just comoute the 3 cached hashes before doing any validation
17:28 < NicolasDorier> oh cool I'll take a look, in my PR I have a benchmark code if you need
17:28 < sipa> and then not have any locking at all
17:28 < NicolasDorier> we can compare easily
17:29 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 276 seconds]
17:30 < cfields> that also has the advantage of making the sigcache usable by libbitcoinconsensus in a way that's thread-friendly, but I'm not sure how necessary/desirable that is
17:31 < NicolasDorier> cfields: are we talkign about the same thing ? I was talking about midhash caches of segwit, not sig cache in fact 
17:31 < cfields> NicolasDorier: that's great. Sorry for not poking at it further before chiming in, making dinner atm. I'll review yours more carefully tomorrow
17:31 < NicolasDorier> looking at your PR you are on the sig cache
17:32 < cfields> NicolasDorier: yes, we're talking about different things. But I think we may want to approach them the same way.
17:33 < NicolasDorier> ah yes indeed I'll check that. 
17:34 < cfields> like I said, I just took a quick glimpse and wanted to push it up for discussion before it was too late. I'll have a good look at the hash cache tomorrow :)
17:35 < cfields> bbl
17:35 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ulntmevbgnxwhzxf] has quit [Quit: Connection closed for inactivity]
17:36 < NicolasDorier> cool thanks !
17:39 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
17:44 -!- nets1n [~netsin@unaffiliated/jiggalator] has quit [Remote host closed the connection]
17:45 -!- Giszmo [~leo@ppp-83-171-168-238.dynamic.mnet-online.de] has quit [Quit: Leaving.]
17:47 < morcos> NicolasDorier: cfields: jeremyrubin: I'm happy to bench anything. 
17:47 < morcos> What I've been working with so far is just a very small change to sigcache that does the erases at the end of block validation (since thats the only thing we need the lock for) and i'm using a boost lock free queue for that
17:48 < morcos> of course it would be easy'ish to make a custom version
17:49 < morcos> jeremy has been hard at work at removing the locking from checkqueue.  i know at least that the time to finish connecting all the transactions (and populating the checkqueue) is much slower due to lock contention..  so its a guess that possibly there is a lot of improvement in the actual validation too
17:49 < morcos> cfields, if your code is ready i'm happy to try that out tomorrow
17:50 < morcos> i've combined this with an approach to keep an always hot CCoinsViewCache on top of pcoinstip instead of creating a new view in ConnectBlock.  This both saves a lot of copying if things are already in pcoinstip and serves to keep things loaded from disk.
17:51 < morcos> I do this by running CreateNewBlock once every 30 seconds.  and then pulling into that hot cache the inputs that would be needed to validate that block
17:53 < morcos> I think this makes it unnecessary to ever have a dbcache bigger than about 300M (although you need up to about 150M additional for the hot cache, but some of that memory you would have been using anyway in block validation)
17:55 < CodeShark> there seems to be a phishing attack going on where you get an email that seems to come from xapo and you can get 10 bitcoins immediately if you download and install a wallet
17:55 < CodeShark> where by wallet, I mean malware
17:55 < morcos> cfields: here is what i have been using: https://github.com/morcos/bitcoin/commit/3e8a10aa78a8a84a44eca9350178ecf7c308c21c
17:57 < NicolasDorier> morcos: is there some kind of free lock map so I can get rid of lock in my hash cache map ?
17:58 < NicolasDorier> ah also, those cache objects might find their way in libconsensus, we'll be able to reference boost ?
17:58 < morcos> NicolasDorier: i don't think boost is the right end decision, and i think lock free coding is beyond the level i feel very comfortable doing myself
17:58 < morcos> so thats why i'm offering to test other peoples implementations
17:59 < morcos> but my goal here is to optimize current bitcoin core performance
17:59 < morcos> how we make that work with libconsensus is a bit of a separate issue
18:00 < morcos> without seeing a design document or us all agreeing on a roadmap for libconsensus, i don't feel able to help with that.  i've been saying that for a long time now.  i think its a worthy goal, but approaching piecemeal like this is frustrating.
18:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
18:04 < cfields> morcos: mine's a little different....
18:05 < cfields> morcos: jeremy made the observation that we only ever work with the sigcache from one thread at a time. ignoring the fact that _that_ thread spawns threads that trample on eachother
18:05 < cfields> so the idea is for each of the workers to return what they would have cached, then batch cache/uncache after each block
18:06 < morcos> cfields: thats what that commit i showed you does
18:06 < cfields> rather, the workers return a list of cache hits/misses. the caller can then add the misses and optionally purge the hits (as in the case of connecting a real block)
18:06 < morcos> you dont' actually cache anything in validation
18:06 < morcos> its only uncaching
18:07 < morcos> you dont' add misses in validation
18:07 < morcos> only in ATMP, which isn't multithreaded
18:07 < morcos> although good to make that work so we can make ATMP multi threaded
18:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
18:07 < morcos> anyway, is that branch you have something thats ready to be tested
18:07 < morcos> thats easy enough for me to do
18:08 < morcos> got to go, will be online tomorrow
18:09 < cfields> morcos: hmm, ok, I'll reread when I'm not preoccupied. I just saw it setting from get()
18:09 < cfields> morcos: that'd be great, thanks. I'll read yours more carefully along with NicolasDorier's
18:10 < NicolasDorier> cfields: wait tomorrow for reviewing my PR, I'm changing some stuff I got from sipa's feedback
18:15 < cfields> NicolasDorier: roger
18:16 < cfields> morcos: ah, heh, the diff threw me off
18:27 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
18:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
18:42 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 265 seconds]
18:56 -!- nets1n [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
18:57 < GitHub165> [bitcoin] NicolasDorier opened pull request #8422: Cache hashes (master...cachedhashes2) https://github.com/bitcoin/bitcoin/pull/8422
18:58 < GitHub146> [bitcoin] NicolasDorier closed pull request #8259: Hash Cache (master...cachedhashes) https://github.com/bitcoin/bitcoin/pull/8259
18:58 < NicolasDorier> cfields: when you feel like reviewing cached hashes : https://github.com/bitcoin/bitcoin/pull/8422 
19:00 -!- a87ry5 [~a87ry5@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev
19:01 -!- nets1n [~netsin@unaffiliated/jiggalator] has quit [Ping timeout: 240 seconds]
19:02 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
19:08 -!- nets1n [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
19:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:12 -!- a87ry5 [~a87ry5@cpe-158-222-198-108.nyc.res.rr.com] has quit [Read error: Connection reset by peer]
19:13 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
19:26 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 244 seconds]
19:29 -!- nets1n [~netsin@unaffiliated/jiggalator] has quit []
19:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
19:38 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
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:52 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 264 seconds]
20:00 < GitHub111> [bitcoin] fanquake opened pull request #8423: [depends] expat 2.2.0, ccache 3.2.7 (master...expat-ccache-jul) https://github.com/bitcoin/bitcoin/pull/8423
20:01 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev
20:01 < fanquake> morning
20:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:21 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
20:23 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds]
20:24 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
20:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:38 -!- fanquake [~Adium@unaffiliated/fanquake] has left #bitcoin-core-dev []
20:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:44 -!- goatpig [56f74bcf@gateway/web/freenode/ip.86.247.75.207] has quit [Quit: Page closed]
20:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:59 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
21:00 -!- d_t [~textual@185.69.203.10] has quit [Max SendQ exceeded]
21:00 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
21:02 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving]
21:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:24 -!- anu0 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev
21:28 -!- anu1 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 265 seconds]
21:41 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
21:42 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
21:43 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
21:47 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:48 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:55 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:09 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
22:13 < luke-jr> jtimon: the issue is entirely giving bad advice to miners. regardless of what they might or might not configure in the end, we should not give bad advice
22:13 < luke-jr> (btw, I see no reason the performance "hit" of using maxsize would be greater than the performance hit of using 0.13 over 0.12..)
22:14 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
22:22 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]
22:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:40 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
22:51 -!- LeMiner2 [LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer]
22:52 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev
23:06 < GitHub151> [bitcoin] PrinceofOrange opened pull request #8424: merge (0.8...master) https://github.com/bitcoin/bitcoin/pull/8424
23:08 < GitHub87> [bitcoin] laanwj closed pull request #8424: merge (0.8...master) https://github.com/bitcoin/bitcoin/pull/8424
23:09 < luke-jr> O.o
23:12 < wumpus> yes that's the only possible response - this seems deliberate spammyness, not merely an accident
23:21 < GitHub182> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ad087638ee48...842bf8d2c5af
23:21 < GitHub182> bitcoin/master 1de2a46 Suhas Daftuar: Ignore GETBLOCKTXN requests for unknown blocks...
23:21 < GitHub182> bitcoin/master 1d06e49 Suhas Daftuar: Ignore CMPCTBLOCK messages for pruned blocks...
23:21 < GitHub182> bitcoin/master 842bf8d Wladimir J. van der Laan: Merge #8408: Prevent fingerprinting, disk-DoS with compact blocks...
23:21 < GitHub16> [bitcoin] laanwj closed pull request #8408: Prevent fingerprinting, disk-DoS with compact blocks (master...cb-misbehaving) https://github.com/bitcoin/bitcoin/pull/8408
23:28 < GitHub2> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/b7e201181bcc0f6328e0a499803f1dbb2c2dbd28
23:28 < GitHub2> bitcoin/0.13 b7e2011 Suhas Daftuar: Prevent fingerprinting, disk-DoS with compact blocks...
23:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:40 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:41 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
23:44 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]