--- Day changed Mon Jun 11 2018 00:05 < bitcoin-git> [bitcoin] kallewoof opened pull request #13430: use IsBlockPruned() where appropriate (master...use-isblockpruned) https://github.com/bitcoin/bitcoin/pull/13430 00:16 < bitcoin-git> [bitcoin] kallewoof opened pull request #13431: validation: update pindexState for check level < 3 (master...verifydb_pindexstate_lvl0-2) https://github.com/bitcoin/bitcoin/pull/13431 00:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:25 -!- bitconne1 [~conner@136.24.175.89] has quit [Ping timeout: 256 seconds] 00:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 00:29 -!- ren0v0 [~ren0v0@host213-122-101-73.range213-122.btcentralplus.com] has quit [Quit: cya!] 00:31 -!- jimpo [~jimpo@ec2-34-211-143-113.us-west-2.compute.amazonaws.com] has joined #bitcoin-core-dev 00:32 -!- Sentineo [~Undefined@unaffiliated/sentineo] has quit [Quit: leaving] 00:37 -!- marc_pango [~marc_pang@111.198.237.144] has quit [Quit: WeeChat 2.0.1] 00:58 -!- ccdle12 [3eff661a@gateway/web/freenode/ip.62.255.102.26] has joined #bitcoin-core-dev 01:06 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 01:06 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 01:06 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 256 seconds] 01:11 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 01:17 -!- grafcaps [~haroldbr@50.90.83.229] has joined #bitcoin-core-dev 01:19 -!- Krellan [~Krellan@2601:640:4000:9258:18ab:eec7:63e:b0fa] has quit [Ping timeout: 276 seconds] 01:21 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 248 seconds] 01:30 -!- laurentmt [~Thunderbi@185.94.189.189] has joined #bitcoin-core-dev 01:30 -!- promag [~promag@77.91.207.131] has joined #bitcoin-core-dev 01:34 -!- Krellan [~Krellan@2601:640:4000:9258:1d44:9573:bead:302c] has joined #bitcoin-core-dev 01:35 -!- sturles [~sturles@unaffiliated/sturles] has quit [Ping timeout: 260 seconds] 01:38 -!- ren0v0 [~ren0v0@host213-122-101-73.range213-122.btcentralplus.com] has joined #bitcoin-core-dev 01:39 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:44 -!- sturles [~sturles@ulrik.uio.no] has joined #bitcoin-core-dev 01:44 -!- sturles [~sturles@ulrik.uio.no] has quit [Changing host] 01:44 -!- sturles [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev 01:45 -!- timothy [~tredaelli@redhat/timothy] has quit [Ping timeout: 256 seconds] 01:45 -!- drizztbsd [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:55 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 01:56 -!- promag [~promag@77.91.207.131] has quit [Ping timeout: 264 seconds] 01:59 < ossifrage> FYI, bitcoin-qt from the head I built today won't start if you have "daemon=0" in the config file, so you can't use the same config for either bitcoind or bitcoin-qt 02:00 < ossifrage> Seems like bitcoin-qt should ignore this option? 02:01 < bitcoin-git> [bitcoin] ken2812221 opened pull request #13434: Set default CFLAGS, CXXFLAGS to empty (master...enable_debug) https://github.com/bitcoin/bitcoin/pull/13434 02:06 < provoostenator> ossifrage: probably caused by 13112. Another problem is disablewallet=1 will prevent a launch if you compile bitcoind without wallet. It probably needs to be relaxed slightly. 02:06 < provoostenator> #13112 02:06 < gribble> https://github.com/bitcoin/bitcoin/issues/13112 | Throw an error for unknown args by achow101 · Pull Request #13112 · bitcoin/bitcoin · GitHub 02:11 < bitcoin-git> [bitcoin] ken2812221 closed pull request #13434: Set default CFLAGS, CXXFLAGS to empty (master...enable_debug) https://github.com/bitcoin/bitcoin/pull/13434 02:20 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 02:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 02:31 < wumpus> rc2 executables up https://bitcoincore.org/bin/bitcoin-core-0.16.1/test.rc2/, sorry for the delay 02:32 -!- laurentmt [~Thunderbi@185.94.189.189] has quit [Quit: laurentmt] 02:36 -!- murrayn [~dafuq@unaffiliated/murrayn] has quit [Quit: Adios mofos] 02:45 -!- murrayn [~dafuq@S01061cabc0b054b3.ok.shawcable.net] has joined #bitcoin-core-dev 02:45 -!- murrayn [~dafuq@S01061cabc0b054b3.ok.shawcable.net] has quit [Changing host] 02:45 -!- murrayn [~dafuq@unaffiliated/murrayn] has joined #bitcoin-core-dev 02:47 < bitcoin-git> [bitcoin] Empact opened pull request #13435: When build fails due to lib missing, indicate which one (master...lib-missing) https://github.com/bitcoin/bitcoin/pull/13435 02:48 < kallewoof> Regarding #13434, shouldn't --enable-debug automatically do --disable-maintainer-mode? Currently --enable-debug is useless at least on macs, as it still generates optimized code so lldb barfs. 02:48 < gribble> https://github.com/bitcoin/bitcoin/issues/13434 | Set default CFLAGS, CXXFLAGS to empty by ken2812221 · Pull Request #13434 · bitcoin/bitcoin · GitHub 03:04 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 03:05 -!- grafcaps [~haroldbr@50.90.83.229] has joined #bitcoin-core-dev 03:09 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 240 seconds] 03:32 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 03:40 -!- Krellan [~Krellan@2601:640:4000:9258:1d44:9573:bead:302c] has quit [Read error: Connection reset by peer] 03:41 -!- Krellan [~Krellan@2601:640:4000:9258:1d44:9573:bead:302c] has joined #bitcoin-core-dev 03:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:55 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds] 04:03 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 264 seconds] 04:08 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 04:09 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-core-dev 04:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 04:21 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 04:25 < wumpus> kallewoof: maintainer mode affects optimization? 04:27 < wumpus> provoostenator: I think that one makes sense, if you compile without wallet the program has no way to know about wallet options, so will reject them 04:27 < wumpus> provoostenator: the alternative would be to move knowledge of wallet options into the core, that'd be even worse 04:28 < rafalcpp> wumpus: I wonder how githubmerge could support git submodules. The submodules are linked by sha1 which is useless. 04:28 < rafalcpp> perhaps we should recursivly calculate our tree-sha512 of a submodule, and that checksum will be placed as data (next to blobs) of the tree of parent 04:28 < provoostenator> Not full knowledge, just any option that disables these features, like upnp=0, disablewallet=1. That way if you forget to leave them out of compilation, those features don't just turn themselves on. 04:29 < wumpus> hmm okay that sounds better at least 04:29 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 248 seconds] 04:30 < wumpus> rafalcpp: sounds like a lot of hassle, indeed 04:31 * rafalcpp spanks Torvalds to have git move to sha512 nativly 04:31 < wumpus> agree 04:33 < wumpus> I think he keeps insisting that 'commit hashes are not a security feature', fair enough, but many people need a way to authenticate repositories securely 04:33 < rafalcpp> yeap 04:33 < wumpus> and the commit hash is the weakest link in that 04:41 < rafalcpp> someone should ask him does he again want CIA to if (uid = 0) ... him like they did old CVS, but this time with false sense of security 04:42 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 04:43 < wumpus> well it's open source so someone that cares should do it,instead of trying to convince Linus, that's how these things work. I wish I had the energy and time. 04:47 < wumpus> whoa is bitcoinacks correct here https://bitcoinacks.com/?flt1_closed_empty=1&flt0_merged_empty=1&sort=7 none of the open PRs that are non high priority for review have any ACK/NACKs? or is it glitching somehow 04:54 < wumpus> nm, got the sorting wrong, phew 04:57 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 04:58 < rafalcpp> that Tree-SHA512 format, is something that bitcoin invented, or is it strictly based on some agreed upon convention? (ordering and format of data that is the material to be hashed)? 04:58 < wumpus> it's something that was invented for our script AFAIK 05:01 -!- pergaminho [~Cleber@201.47.91.172] has joined #bitcoin-core-dev 05:01 -!- pergaminho [~Cleber@201.47.91.172] has quit [Read error: Connection reset by peer] 05:02 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 276 seconds] 05:06 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 05:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.4] 05:11 -!- Kvaciral [~Kvaciral@5ED6B9A2.cm-7-7c.dynamic.ziggo.nl] has quit [Quit: leaving] 05:11 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 276 seconds] 05:13 -!- grafcaps [~haroldbr@50.90.83.229] has joined #bitcoin-core-dev 05:19 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 276 seconds] 05:21 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/56f69360dc98...6e249e46789f 05:21 < bitcoin-git> bitcoin/master cbede7d Sjors Provoost: [qt] OptionsDialog: add prune setting 05:21 < bitcoin-git> bitcoin/master 6e249e4 Wladimir J. van der Laan: Merge #13043: [qt] OptionsDialog: add prune setting... 05:22 < bitcoin-git> [bitcoin] laanwj closed pull request #13043: [qt] OptionsDialog: add prune setting (master...2018/04/qt-prune) https://github.com/bitcoin/bitcoin/pull/13043 05:26 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 05:34 < promag> wumpus: are you available for merges? 05:39 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6e249e46789f...531a0337ca93 05:39 < bitcoin-git> bitcoin/master fa6edfe MarcoFalke: qa: Remove portseed_offset from test runner 05:39 < bitcoin-git> bitcoin/master 531a033 Wladimir J. van der Laan: Merge #13421: qa: Remove portseed_offset from test runner... 05:39 < bitcoin-git> [bitcoin] laanwj closed pull request #13421: qa: Remove portseed_offset from test runner (master...Mf1806-qaPortseedOffset) https://github.com/bitcoin/bitcoin/pull/13421 05:43 -!- Aaronvan_ is now known as AaronvanW 05:44 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 05:45 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/531a0337ca93...70a03c635b73 05:45 < bitcoin-git> bitcoin/master f68049d Cory Fields: crypto: cleanup sha256 build... 05:45 < bitcoin-git> bitcoin/master 70a03c6 Wladimir J. van der Laan: Merge #13408: crypto: cleanup sha256 build... 05:45 < bitcoin-git> [bitcoin] laanwj closed pull request #13408: crypto: cleanup sha256 build (master...sha2-cleanup) https://github.com/bitcoin/bitcoin/pull/13408 05:49 -!- bitconner [~conner@136.24.175.89] has joined #bitcoin-core-dev 06:00 -!- str4d [~str4d@27.110.123.91] has quit [Ping timeout: 248 seconds] 06:01 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:05 -!- drizztbsd is now known as timothy 06:07 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70a03c635b73...26c93edf1de9 06:07 < bitcoin-git> bitcoin/master a426098 practicalswift: Fix compiler warnings emitted when compiling under stock OpenBSD 6.3 06:07 < bitcoin-git> bitcoin/master 26c93ed Wladimir J. van der Laan: Merge #13294: Fix compiler warnings emitted when compiling under stock OpenBSD 6.3... 06:08 < bitcoin-git> [bitcoin] laanwj closed pull request #13294: Fix compiler warnings emitted when compiling under stock OpenBSD 6.3 (master...openbsd-warnings) https://github.com/bitcoin/bitcoin/pull/13294 06:14 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 260 seconds] 06:21 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/26c93edf1de9...3f0f39415bd7 06:21 < bitcoin-git> bitcoin/master 8160817 John Newbery: [wallet] [rpc] Remove getlabeladdress RPC... 06:21 < bitcoin-git> bitcoin/master 67e0e04 John Newbery: [wallet] [docs] Update release notes for removing `getlabeladdress` 06:21 < bitcoin-git> bitcoin/master 3f0f394 Wladimir J. van der Laan: Merge #13060: [wallet] [rpc] Remove getlabeladdress RPC... 06:21 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has quit [Remote host closed the connection] 06:22 < bitcoin-git> [bitcoin] laanwj closed pull request #13060: [wallet] [rpc] Remove getlabeladdress RPC (master...remove_getlabeladdress) https://github.com/bitcoin/bitcoin/pull/13060 06:22 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has joined #bitcoin-core-dev 06:52 < wumpus> promag: yes 06:53 -!- Tralfaz [~none@103.254.153.99] has joined #bitcoin-core-dev 07:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 07:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:16 < promag> wumpus: #12151 07:16 < gribble> https://github.com/bitcoin/bitcoin/issues/12151 | rpc: Remove cs_main lock from blockToJSON and blockheaderToJSON by promag · Pull Request #12151 · bitcoin/bitcoin · GitHub 07:17 < promag> or #13160 07:17 < gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub 07:18 < MarcoFalke> promag: #12151 was just pushed, imo not ready for merge 07:18 < gribble> https://github.com/bitcoin/bitcoin/issues/12151 | rpc: Remove cs_main lock from blockToJSON and blockheaderToJSON by promag · Pull Request #12151 · bitcoin/bitcoin · GitHub 07:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 07:20 < wumpus> thanks, I'll have a look at those 07:20 < promag> MarcoFalke: right, should be re-ack 07:21 < promag> MarcoFalke: if you can take a look at 13160 too 07:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:26 < bitcoin-git> [bitcoin] laanwj pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/3f0f39415bd7...43ae5ee9e4c2 07:26 < bitcoin-git> bitcoin/master b9ef21d Karl-Johan Alm: mempool: Add explicit max_descendants... 07:26 < bitcoin-git> bitcoin/master 46847d6 Karl-Johan Alm: mempool: Fix max descendants check... 07:26 < bitcoin-git> bitcoin/master 475a385 Karl-Johan Alm: Add GetTransactionAncestry to CTxMemPool for general purpose chain limit checking 07:27 < bitcoin-git> [bitcoin] laanwj closed pull request #12634: [refactor] Make TransactionWithinChainLimit more flexible (master...txmempool-chain-limit-value) https://github.com/bitcoin/bitcoin/pull/12634 07:32 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.4] 07:37 -!- JackH [~laptop@host-80-47-82-205.as13285.net] has joined #bitcoin-core-dev 07:48 < wumpus> #13160 has only my utACK 07:48 < gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub 07:48 < wumpus> I don't think that's enough for a change in behavior like that 07:49 < wumpus> even though code-wise it's very simple to review 07:51 -!- goatpig [56f75200@gateway/web/freenode/ip.86.247.82.0] has joined #bitcoin-core-dev 07:52 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 240 seconds] 07:53 -!- StopAndDecrypt [~StopAndDe@c-73-215-253-208.hsd1.nj.comcast.net] has joined #bitcoin-core-dev 07:53 -!- StopAndDecrypt [~StopAndDe@c-73-215-253-208.hsd1.nj.comcast.net] has quit [Changing host] 07:53 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev 07:53 -!- Tralfaz [~none@103.254.153.99] has quit [Quit: Leaving] 07:54 -!- Krellan [~Krellan@2601:640:4000:9258:1d44:9573:bead:302c] has quit [Read error: Connection reset by peer] 07:55 -!- Krellan [~Krellan@2601:640:4000:9258:1d44:9573:bead:302c] has joined #bitcoin-core-dev 07:57 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Remote host closed the connection] 07:57 -!- StopAndDecrypt [~StopAndDe@c-73-215-253-208.hsd1.nj.comcast.net] has joined #bitcoin-core-dev 07:57 -!- StopAndDecrypt [~StopAndDe@c-73-215-253-208.hsd1.nj.comcast.net] has quit [Changing host] 07:57 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev 08:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:05 -!- laurentmt [~Thunderbi@185.94.189.189] has joined #bitcoin-core-dev 08:06 -!- grafcaps [~haroldbr@50.90.83.229] has joined #bitcoin-core-dev 08:10 < sipa> MarcoFalke: you mentioned that fetching PR information from github was the bottleneck for drahtbot? are you using the git interface for PRs? 08:11 < MarcoFalke> I do. But I also need to get the open pull requests and metadata for them. 08:12 < sipa> hmm 08:13 < ken2812221> Hi all. In order to fix #13103, is it allowed to add additional functions and methods like #13426 for Windows, and add macros for other OS? (The first and second commits) 08:13 < gribble> https://github.com/bitcoin/bitcoin/issues/13103 | Invalid wallet path with Chinese characters in windows · Issue #13103 · bitcoin/bitcoin · GitHub 08:13 < gribble> https://github.com/bitcoin/bitcoin/issues/13426 | [WIP, bugfix] Add u8path and u8string to boost to fix #13103 by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub 08:14 < ken2812221> additional function and method in boost header 08:14 < MarcoFalke> And the "Needs rebase" task of DrahtBot is purely based on the api 08:15 < MarcoFalke> Since GitHub hasn't yet disclosed which merge tool they use 08:19 < sipa> MarcoFalke: seems reasonablw that it's pretty much vanilla git 08:19 < sipa> as our merge tool compares the local merge with the github merge 08:19 -!- laurentmt [~Thunderbi@185.94.189.189] has quit [Quit: laurentmt] 08:20 < sipa> and afaik never failed for noticing a differencw 08:20 < MarcoFalke> They advertise as merge conflict when one of the files got moved 08:20 < MarcoFalke> vanilla git doen't afaict 08:21 < sipa> hmm 08:32 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 264 seconds] 08:37 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-dev 08:53 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds] 08:56 -!- grafcaps [~haroldbr@107.147.175.194] has joined #bitcoin-core-dev 08:57 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 09:01 < echeveria> https://pastebin.com/Ar8cT76q 09:01 < echeveria> bitcoind seems to get very sad sometimes if you have a low maxconnections 09:01 < ryanofsky> i have a hacky script that checks for merge conflicts reasonably quickly with "git diff | git apply" https://github.com/ryanofsky/home/blob/master/src/pr.sh#L558 09:02 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 09:04 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 265 seconds] 09:05 -!- Krellan [~Krellan@2601:640:4000:9258:1d44:9573:bead:302c] has quit [Ping timeout: 245 seconds] 09:08 -!- Krellan [~Krellan@2601:640:4000:9258:1d44:9573:bead:302c] has joined #bitcoin-core-dev 09:10 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 250 seconds] 09:10 -!- grafcaps [~haroldbr@107.147.175.194] has quit [Ping timeout: 268 seconds] 09:10 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 09:12 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 09:18 < promag> wumpus: I can't reproduce #13111 failures locally 09:18 < gribble> https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub 09:18 < promag> should retry travis job? 09:26 -!- grafcaps [~haroldbr@104.137.194.255] has joined #bitcoin-core-dev 09:27 < bitcoin-git> [bitcoin] ken2812221 closed pull request #13107: Fix Windows locale problem (master...win-enc) https://github.com/bitcoin/bitcoin/pull/13107 09:30 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 260 seconds] 09:31 -!- ccdle12 [3eff661a@gateway/web/freenode/ip.62.255.102.26] has quit [Ping timeout: 260 seconds] 09:33 -!- grafcaps [~haroldbr@104.137.194.255] has joined #bitcoin-core-dev 09:46 -!- Purple7 [6d982803@gateway/web/freenode/ip.109.152.40.3] has joined #bitcoin-core-dev 09:47 < Purple7> Hi everyone :) 09:48 < Purple7> can someone here help me create a bitcoin script. I just installed Bitcoin core node and have tried bitcoin-cli commands 09:48 < echeveria> I don't know what you imagine bitcoin script to be capable of. 09:48 < Purple7> I want to create a script but not sure how to create one and how to run one 09:48 < wumpus> promag: I had some segfaults locally with it, but seems hard to reproduce 09:48 < Purple7> to carry out transactions 09:48 < echeveria> Purple7: lets do this in #bitcoin. 09:49 < promag> wumpus: yes I think I can reproduce now 09:50 < Purple7> Thanks echeveria 09:50 < Purple7> :) 09:50 < promag> wumpus: delete regtest folder, launch, then rpc stop 09:51 < promag> looks like that way always segfaults 09:54 < Chris_Stewart_5> Is there any ordering required for the rpcport config option? We are seeing behavior where it is being read if passed in as a command line arg but not being recogonized inside of a bitcoin.conf file 09:54 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 09:54 -!- Purple7 [6d982803@gateway/web/freenode/ip.109.152.40.3] has quit [Ping timeout: 260 seconds] 09:56 < Chris_Stewart_5> we are reading other config options from the bitcoin.conf file 09:56 < Chris_Stewart_5> just not rpcport it seems 09:56 < sipa> Chris_Stewart_5: what version of the code? 09:57 < Chris_Stewart_5> 0.16.0 09:57 < wumpus> rpcport should work fine in the bitcoin.conf, I've had it in there for ages 09:57 < wumpus> note that master has per-network config sections, but 0.16 does not 09:58 < Chris_Stewart_5> yeah it is pretty bizzare. We are reading other options like daemon=1 in the conf file. Just not the rpcport for some reason 09:58 < wumpus> are you really sure? as said, I have a setup myself that uses that 09:58 < Chris_Stewart_5> just a sec, I'm double checking he didn't compile from master 09:59 < Chris_Stewart_5> nvm, he is on 0.16.99. 10:00 < sipa> how do you observe it's not using rpcport? 10:00 < wumpus> ok on master you need to put it in a network-specific section, this is described in the doc/release-notes.md 10:00 < sipa> wumpus: oh! 10:01 -!- Rebo [~Rebo@cable-94-139-26-12.cust.telecolumbus.net] has joined #bitcoin-core-dev 10:01 < wumpus> it should also warn in the log 10:02 < sipa> wumpus: nothing here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.md 10:02 < Chris_Stewart_5> basically it was always binding to 18433 if we set rpcport via the command line 10:03 < Chris_Stewart_5> unless we set it via the command line* sorry 10:04 < provoostenator> Anyone else noticed bitcoin-cli crashing on macOS 10.13.5? I had to recompile. It's quite possible I did something stupid unrelated, but seeing c-lightning and random Github projects struggling with macOS 10.13.5, thought I'd check... 10:05 < provoostenator> What's stranger - and why I initially assume I did something else wrong: it didn't happen immediately after the upgrade but a few days later, so it may have been a homebrew or xcode update. 10:07 < wumpus> sipa: release-notes-pr12823.md apparently 10:07 < sipa> oh, i forgot we added pr-specific files 10:08 < wumpus> it does make things harder to find 10:09 < sipa> wumpus: any opinion about converting the existing sse4 assembly code (which was in 0.16) into intrinsics based code? 10:10 < sipa> downside: possibly a bit slower (i've seen up to 4% slower) and compiler dependent 10:10 < sipa> upside: more easily reusable, readable, and works on 32-bit systems 10:14 < promag> wumpus: found the problem, will push a fix in a separate commit for now 10:18 < echeveria> yeah, that's a weird one. I have hardcoded `connect` peers but it doesn't sync. 10:21 < echeveria> random peers, syncs perfectly, hardcoded it doesn't sync, even with the same peers. 10:33 < wumpus> sipa: no strong opinion on that; 32 bit x86 is very rare so I wouldn't do it for that, given that it's also 4% slower, "do nothing" sounds like a good option to me 10:33 -!- Krellan [~Krellan@2601:640:4000:9258:1d44:9573:bead:302c] has quit [Remote host closed the connection] 10:35 < gmaxwell> 22:50:10 < gmaxwell> sipa: you created a 32-byte version of the specialized 1-way SSE4 asm? 10:35 < sipa> gmaxwell: no, not specialized 10:36 < sipa> we just have a benchmark for SHA256 with 32-byte inputs, and that benchmark shows a slowdown when going from asm-based 1-way SSE4 to intrin-based 1-way SSE4 10:39 -!- JackH_ [~laptop@host-80-47-84-227.as13285.net] has joined #bitcoin-core-dev 10:40 < sipa> gmaxwell: also, the speedup from the 1-way SSE4 is pretty neat: it does the expansion for rounds X+16...X+19 in SSE registers simultaneously, interleaved with an otherwise totally ordinary implementation for rounds X..X+3 10:40 -!- JackH [~laptop@host-80-47-82-205.as13285.net] has quit [Ping timeout: 276 seconds] 10:43 < wumpus> I wonder, is anyone using 32-bit x86 for bitcoin nodes? the last 32-bit-only x86 CPU was sold in 2008 or so, 10 years ago now 10:43 < sipa> wumpus: ah, but those don't even have SSE4 :) 10:44 < sipa> the only use for SSE4 in 32-bit mode is people running a 32-bit binary on 64-bit hardware 10:44 < wumpus> too bad we don't have statistics how much those get downloaded 10:44 < wumpus> right 10:44 < sipa> my goal in converting to intrinsics was making it reusable for specialized 32-byte or 64-byte inputs; we can leave the original untouched of course, and only have intrinsics based versions for the specialized versions 10:46 < wumpus> for that it certainly makes sense, easier to specialize code w/ intrinsics than manual register allocation 10:48 -!- JackH_ [~laptop@host-80-47-84-227.as13285.net] has quit [Quit: Leaving] 10:48 < sipa> i also wonder what to do about CI for special hardware 10:48 -!- JackH [~laptop@host-80-47-84-227.as13285.net] has joined #bitcoin-core-dev 10:48 < sipa> SHA-NI is unlikely to be available on any Travis system 10:48 < sipa> and POWER9 would surprise me even more :D 10:51 < luke-jr> test these things more carefully when they change? 10:51 < wumpus> it's the same case as platforms such as FreeBSD and OpenBSD, we'll have to rely on people regularly compilng and testing master with them 10:51 < luke-jr> well, at least the platform-specific stuff in this case is isolated 10:52 < sipa> i'm also going to extend the self-test code for these 10:52 < sipa> so at least it will fail at startup rather than arbitrarily 10:52 < wumpus> it's notrealistic to have CI for all OS/architecture combinations, not even all OSes and architectures separately 10:53 < wumpus> I still have a PR open to run travis on at least one bigendian platform, but even that seems untenable 10:53 < luke-jr> maybe if someone were to volunteer to maintain a CI system for us that does all that, but yeah, probably not with Travis 10:53 < wumpus> it's not realistic to do that for every PR, sure, some daily cron job would work 11:01 < MarcoFalke> Apparently we have some jenkins running somewhere, maybe jamesob can see if that would work with FreeBSD/OpenBSD 11:01 < MarcoFalke> SHA-NI and POWER9 should already be tested by devs regularly, no? 11:03 -!- satwo [~textual@2602:306:378a:6fb0:1d8c:f086:2bae:1295] has joined #bitcoin-core-dev 11:03 < gmaxwell> with jenkins it would be as simple as adding a ssh key on a host and telling jenkins to use it as a remote. I guess travis doesn't have a similar facility for non-travis build hosts? 11:04 < jamesob> gmaxwell: travis is limited to execution on their infra AFAICT 11:04 < MarcoFalke> I think so as well ^ 11:05 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 11:06 < gmaxwell> in any case, I assume jenkins hosts will have sha-ni sometime, for now we'll just have to count on developers (lol, pieter is the only person I know with it right now.) catching it. 11:06 < wumpus> in theory it's possible to ssh out from travis, but that sounds horribly fragile 11:06 < wumpus> (also, key management is a problem) 11:07 < gmaxwell> for jenkins the integration is super nice, it's not just 'sshing out' but once you give jenkins access it does all the stuff to properly use it as a build host automagically. (wow, java actually useful for something) 11:08 < wumpus> right, that sounds better 11:10 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #13437: wallet: Erase wtxOrderd wtx pointer on removeprunedfunds (master...Mf1806-walletPrunedFundsSegfault) https://github.com/bitcoin/bitcoin/pull/13437 11:10 < luke-jr> MarcoFalke: I should be moving my development to my POWER9 system in this next week 11:10 < MarcoFalke> luke-jr: Good to hear 11:10 < MarcoFalke> Also BlueMatt switched to POWER9 11:11 < cfields> sipa: fwiw, I now fully understand the 1way sha2 optims for sse4/avx. I started working on the intrinsics over the weekend 11:11 < sipa> cfields: too late :) 11:11 < cfields> sipa: just thought I'd mention in case you were also looking at it 11:11 < cfields> oh? 11:11 < cfields> heh, did I miss a PR? 11:11 < sipa> cfields: i have intrinsics based 1-way sse4 working 11:11 < sipa> not PRed yet 11:12 < sipa> sorry, didn't know you were planning to work on it so soon as well 11:12 < cfields> sipa: no worries. Now I can pick yours apart :p 11:13 < BlueMatt> yea, POWER9 should get pretty good testing, sdaftuar and I have already been using it for some time now 11:13 < provoostenator> cfields: or work on #13401 11:13 < gribble> https://github.com/bitcoin/bitcoin/issues/13401 | ARMv8 sha2 support · Issue #13401 · bitcoin/bitcoin · GitHub 11:13 < provoostenator> :-) 11:13 < BlueMatt> and I think we might be getting a shared test box on it soonish if people want to get an ssh key to have access to it 11:15 < gmaxwell> sipa: would the 1-way sha2 be more efficient for longer inputs if it processed more blocks at once? 11:15 < gmaxwell> (e.g. could it be expanding the next group) 11:18 < sipa> gmaxwell: hmm, yes! 11:18 < cfields> sipa: did you include the lane duplication optim for quicker rotates? 11:19 < sipa> cfields: i literally translated the asm code instruction per instruction to intrinsics 11:19 < sipa> and then restructured it into functions that make sense 11:19 < provoostenator> What does "1-way" mean in the context of a SHA256 hash? 11:19 < cfields> sipa: ah, I think some of that will pessimize avx though, no? 11:19 < cfields> I guess I'll wait to see it 11:20 < gmaxwell> provoostenator: computing one hash at a time, as opposted to concurrently computing many hashes. 11:20 < sipa> cfields: recompiling this code with -mavx gains virtually no advantage 11:20 < sipa> provoostenator: say you have 8 64-byte vectors, and want to independently compute the 8 32-byte hashes of those 11:20 < sipa> provoostenator: we have a specialized function that does that 11:21 < sipa> that's 8-way 11:21 < cfields> sipa: hmm, that's really surprising. 11:21 < provoostenator> Ah ok, so that's useful if you're able to do some of the validation stuff in parallel? 11:22 < sipa> provoostenator: it's currently used (in master) for merkle tree root computations 11:26 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/43ae5ee9e4c2...7c32b414b632 11:26 < bitcoin-git> bitcoin/master 906bee8 practicalswift: Use bracket syntax includes ("#include ") 11:26 < bitcoin-git> bitcoin/master 6d10f43 practicalswift: Enforce the use of bracket syntax includes ("#include ") 11:26 < bitcoin-git> bitcoin/master 16e3cd3 practicalswift: Clarify include recommendation 11:26 < gmaxwell> in theory we could also use them for hashing a bunch of transactions at once, but handling the variable length stuff is slightly gnarly. 11:26 < provoostenator> sipa: why not in script validation? Not worth it or still on todo lists? 11:26 < cfields> sipa: no clue if it's still state-of-the-art, but this is what I was using as a basis for understanding/implementing multi-block speedup: https://eprint.iacr.org/2012/067.pdf 11:26 < bitcoin-git> [bitcoin] laanwj closed pull request #13230: Simplify include analysis by enforcing the developer guide's include syntax (master...bracket-syntax-includes) https://github.com/bitcoin/bitcoin/pull/13230 11:26 < cfields> gmaxwell: ^^ 11:27 < sipa> provoostenator: todo list 11:27 < gmaxwell> provoostenator: yes, it could be done, but it requires having things aranged so there are multiple messages to hash all ready to hash at once. 11:27 < gmaxwell> So easiest was hashtrees, since that all gets computed at once. 11:27 < provoostenator> Right now script validation can is done in parallel on _multiple_ cpu's, rather than on a single one? 11:28 < cfields> (ofc that's separate from the per-block optimizations) 11:28 < cfields> provoostenator: yes 11:30 < provoostenator> But if you verify e.g. 8 scripts in parallel on the same core to take advantage of that 256 optimzation, I guess the risk is that these cores are just sitting there waiting for these 8 threads to be ready? 11:30 < provoostenator> If they're not otherwise identical. 11:31 < provoostenator> But 1-way doesn't change anything 11:33 < gmaxwell> provoostenator: using n-at-a-time hashing requires restructing code so that it actually has n things to hash available at a time. Script validation doesn't work that way today and would need significant overhalls to make use of it. 11:35 -!- ExtraCrispy [~ExtraCris@185.9.18.150] has quit [Ping timeout: 256 seconds] 11:45 -!- Rebo [~Rebo@cable-94-139-26-12.cust.telecolumbus.net] has quit [] 11:59 < cfields> sipa: would you be ok with a separate avx-optimized version of those intrinsics if the speedup was as significant as before? 12:00 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-core-dev 12:00 -!- jhfrontz [~Adium@c-73-23-68-28.hsd1.fl.comcast.net] has quit [Quit: Leaving.] 12:01 -!- jhfrontz [~Adium@c-73-23-68-28.hsd1.fl.comcast.net] has joined #bitcoin-core-dev 12:03 < sipa> cfields: the avx speedup is for the 4-way sse4, not the 1-way sse4 code 12:03 < sipa> cfields: and yes 12:04 -!- ^nix [~alex@188.242.8.198] has joined #bitcoin-core-dev 12:04 < cfields> sipa: there are definitely 1way speedups due to non-destructive xor's 12:05 -!- dariusmaximus [~dario@12.8.180.242] has joined #bitcoin-core-dev 12:07 < sipa> cfields: ah, the compiler may not be smart enough to use those? 12:07 < cfields> sipa: I really would've expected it to, since there's not a separate intrinsic for them 12:07 < cfields> it might be how the other registers are setup, though 12:08 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:09 < cfields> the sigma1 implementation for sse4, for example, duplicates data in 2 registers so that it can do quicker but destructive rotates. Avx doesn't need to do that, so the duplication is strictly a slowdown. 12:09 < sipa> cfields: i'll cleanup my code and PR 12:10 < cfields> ok 12:10 < bitcoin-git> [bitcoin] sipa opened pull request #13438: Improve coverage of SHA256 SelfTest code (master...201806_selftestsha) https://github.com/bitcoin/bitcoin/pull/13438 12:11 < cfields> sipa: thanks for that :) 12:12 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #13395: rpc: Avoid "duplicate" return value for invalid submitblock (master...Mf1806-rpcMiningSubmitblock) https://github.com/bitcoin/bitcoin/pull/13395 12:17 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 12:22 < provoostenator> Any other live metrics I should collect on my slow pruned AWS node? https://github.com/bitcoin/bitcoin/pull/12404#issuecomment-396356384 12:24 < gmaxwell> cfields: so somewhere intel has published sse4/avx/avx2 code (which is where our 1-way sse4 comes from) when we previously benchmarked the avx code we found that it was a couple percent faster on intel but a lot slower on AMD. 12:24 < gmaxwell> cfields: I don't see any problem with having a seperate AVX version but we would need to deal with not choosing it on AMD somehow, if its slower there. 12:25 < cfields> gmaxwell: do you mean intel's modified Sigma0/Sigma1 ? 12:25 < gmaxwell> I don't know what optimizations it had inside it, IIRC it was the same code intel submitted for the linux kernel (the kernel can realistically benchmark to decide what code to use, not as reasonable for us) 12:25 < cfields> if so, yea, most of the code I've found in the wild opts out of those for that reason 12:26 < cfields> gmaxwell: I'm guessing it's what I PR'd, which we closed for that reason :( 12:26 < gmaxwell> for us we could decide to use some AVX version that was faster on intel by string matching the cpu version and only using it on intel chips. But if it's only a couple percent it might not be worth it. 12:27 < gmaxwell> ESP since anything with AVX is pretty quick regardless. 12:28 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #13439: rpc: Avoid "duplicate" return value for invalid submitblock (master...2018-06-marcos-submitblock-fix) https://github.com/bitcoin/bitcoin/pull/13439 12:28 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Max SendQ exceeded] 12:28 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 12:31 < cfields> gmaxwell: agreed. I'd rather avoid per-vendor optims unless it's really really significant 12:31 < cfields> might be harder to avoid that if we get into arm, though 12:32 < gmaxwell> for arm it's more worth it... 12:32 < gmaxwell> even a small percantage change is a large absolute time there. 12:35 < cfields> fair point. 12:35 < cfields> gmaxwell: #13400 is what I was referencing, btw. Hopefully that's the same one as the kernel discussion you had in mind. 12:35 < gribble> https://github.com/bitcoin/bitcoin/issues/13400 | sha256: small speedup for sse4 path. by theuni · Pull Request #13400 · bitcoin/bitcoin · GitHub 12:35 < gmaxwell> cfields: I guess for AVX ... Intel x86_64 cpus with AVX but without AVX2 or SHA-NI are _very_ common. I'd guess they outnumber all other kinds in our deployment by a large margin. 12:36 -!- bitconner [~conner@136.24.175.89] has quit [Ping timeout: 264 seconds] 12:37 < cfields> huh, I figured my Sandy Bridge was the outlier 12:40 < gmaxwell> AVX2 is only haswell and later on intel, and the xeons lag desktops in microarch by a couple years. 12:55 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 12:58 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 264 seconds] 12:58 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev 13:15 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 13:19 -!- OS-11936 [~OS-11936-@cpe-71-68-48-149.carolina.res.rr.com] has joined #bitcoin-core-dev 13:20 -!- OS-11936 [~OS-11936-@cpe-71-68-48-149.carolina.res.rr.com] has quit [Client Quit] 13:22 -!- str4d [~str4d@27.110.123.91] has quit [Ping timeout: 276 seconds] 13:24 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #13440: qa: Log as utf-8 (master...Mf1806-qaLogUtf8) https://github.com/bitcoin/bitcoin/pull/13440 13:37 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 13:37 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 13:41 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 13:49 -!- edgar_ [56542a46@gateway/web/freenode/ip.86.84.42.70] has joined #bitcoin-core-dev 13:53 < edgar_> hello 13:54 -!- edgar_ [56542a46@gateway/web/freenode/ip.86.84.42.70] has left #bitcoin-core-dev [] 14:02 -!- gloata [5fa3c312@gateway/web/freenode/ip.95.163.195.18] has quit [Ping timeout: 260 seconds] 14:12 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 14:23 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 14:23 -!- ^nix [~alex@188.242.8.198] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 14:25 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 14:28 < bitcoin-git> [bitcoin] achow101 opened pull request #13441: Prevent shared conf files from failing with different available options in different binaries (master...gargs-disabled-options) https://github.com/bitcoin/bitcoin/pull/13441 14:28 < achow101> ossifrage: provoostenator: ^ that PR should fix the problem with the options 14:30 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 14:36 -!- CubicEarths [~cubiceart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 14:43 -!- satwo [~textual@2602:306:378a:6fb0:1d8c:f086:2bae:1295] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 14:53 -!- timothy [~tredaelli@redhat/timothy] has quit [Read error: Connection reset by peer] 15:05 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 15:11 -!- Guest99396 is now known as Guest47913 15:12 -!- Guest47913 is now known as eenoch 15:13 -!- eenoch is now known as Guest25972 15:13 -!- Guest25972 is now known as Guest47913 15:17 -!- Guest47913 [~eenoch@unaffiliated/eenoch] has quit [Quit: leaving] 15:17 -!- eenoch_ [~eenoch@unaffiliated/eenoch] has joined #bitcoin-core-dev 15:25 -!- Sinclair6 [sinclair6@gateway/vpn/privateinternetaccess/sinclair6] has joined #bitcoin-core-dev 15:42 -!- snickerfritz [~snickerfr@184.75.213.134] has joined #bitcoin-core-dev 15:42 -!- snickerfritz [~snickerfr@184.75.213.134] has quit [Changing host] 15:42 -!- snickerfritz [~snickerfr@unaffiliated/snickerfritz] has joined #bitcoin-core-dev 15:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 16:09 < sipa> gmaxwell: got it faster than the asm version now 16:09 < sipa> 3.68 ms vs 3.77 ms 16:09 < sipa> on i7 16:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:35 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 16:37 < bitcoin-git> [bitcoin] sipa opened pull request #13442: Convert the 1-way SSE4 SHA256 code from asm to intrinsics (master...201806_sse4intrin) https://github.com/bitcoin/bitcoin/pull/13442 16:37 < cfields> sipa: nice 16:38 < cfields> sipa: and it looks like it should be friendlier to avx now. Was that purposeful, or nice side-effect? 16:38 < sipa> cfields: i don't know why or how 16:38 < sipa> elaborate please :) 16:40 < sipa> cfields: it's crazy how much the compiler affects things, though 16:40 < sipa> in one place changing a constant from const to static const made it 10% slower 16:40 < sipa> in another place changing it from static const to const made it 3% slower 16:40 < cfields> sipa: yea, I was going to ask you if the ordering really matters, I assume the compiler will reorder as it sees fit 16:40 < cfields> huh 16:40 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 16:41 < sipa> generally reordering seems to have only a marginal affect, to none at all 16:41 < sipa> changing the types of constants and variables has a large affect 16:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 16:42 < cfields> interesting, I would've thought the interleaving timing was the crucial part 16:42 < sipa> (the trick with Ws, as opposed to just keeping it as a __m128i and extracting the elements from it, does have a different) 16:42 < sipa> oh, the interleaving is absolutely crucial 16:42 < cfields> ...I guess it probably is, but you have to fight the compiler to get there first 16:42 < sipa> but the compiler reorders things anyway 16:42 < sipa> regardless of how you write it... to an extent 16:43 < cfields> sipa: by avx-friendly, I mean that you pass variables in which may or may not be overwritten, based on what instructions are available 16:43 < cfields> for example: XTMP0 = Palignr(X3, X2, 4); 16:44 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 16:44 < sipa> cfields: heh, SSA transformation will destroy that 16:44 < sipa> don't assume the compiler will map every variable to a single register all of the time 16:45 < cfields> ofc, I just mean that it has the option with avx 16:45 < sipa> even if you write things in a A = f(A, B) form everywhere, the compiler may still store the resulting A in a different register than the source A 16:45 < sipa> yes, but the way the code is written shouldn't affect that at all 16:45 < sipa> the SSA transform will effectively turn every assignment to a variable into a new variable, from the compiler's perspective 16:46 < cfields> I see 16:48 < sipa> with -msse4.1: 3.68ms 16:48 < sipa> with -mavx: 3.54ms 16:49 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Ping timeout: 256 seconds] 16:49 < cfields> sipa: huh, odd. I get a massive speedup with avx 16:50 < cfields> SHA256D64_1024, 20, 7400, 123.736, 0.000835992, 0.000836151, 0.000836061 16:50 < cfields> SHA256D64_1024, 20, 7400, 73.563, 0.000496887, 0.000497227, 0.000497053 16:53 < sipa> cfields: oh, i was looking at the SHA256 benchmark 17:00 -!- nmnkgl [~nmnkgl@c-73-189-35-88.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 17:02 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Quit: drexl] 17:05 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 17:08 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-dev 17:10 -!- booyah [~bb@193.25.1.157] has quit [Ping timeout: 256 seconds] 17:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 17:15 -!- gillian [319680dd@gateway/web/freenode/ip.49.150.128.221] has joined #bitcoin-core-dev 17:16 -!- gillian is now known as Guest97188 17:24 < sipa> cfields: clang does not like my code :( 17:24 < cfields> sipa: yea, needs a few little fixups... 17:24 < cfields> just template the param, and move the alignof() to the front of the definition 17:25 < cfields> (I assume you knew that, just verifying that it makes clang happy :) 17:27 < sipa> or just get rid of those helper functions 17:27 < sipa> they don't give much abstraction anyway :) 17:31 < cfields> heh 17:32 < cfields> sipa: this includes the optim from #13400. Was that intended? 17:32 < gribble> https://github.com/bitcoin/bitcoin/issues/13400 | sha256: small speedup for sse4 path. by theuni · Pull Request #13400 · bitcoin/bitcoin · GitHub 17:33 < sipa> oh? 17:33 < sipa> no 17:33 < sipa> i don't see that 17:34 < cfields> looking again, maybe order has me confused. 17:39 -!- Guest97188 [319680dd@gateway/web/freenode/ip.49.150.128.221] has left #bitcoin-core-dev [] 17:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 18:06 < phantomcircuit> sipa, the only caller of CCoinsViewDB::BatchWrite seems to be CCoinsViewCache::Flush which calls clear() on cacheCoins after 18:06 < phantomcircuit> but BatchWrite is erasing each entry itself from cacheCoins passed by reference it seems 18:07 < cfields> sipa: https://pastebin.com/raw/H5rV4kM5 18:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 18:40 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 240 seconds] 18:50 < sipa> phantomcircuit: correct 18:51 < sipa> it's also potentially creating new entries in the parent cache 18:51 < sipa> so to compensate for that memory usage, it also erases on the fly from the other one 18:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 18:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:53 < gmaxwell> sipa: now that you've done intrensics you should be able to specialize the 64byte double sha2 18:53 < gmaxwell> pretty easily? 18:53 < phantomcircuit> sipa, right i see the pr, it's trying to avoid peak memory usage effectively being doubled by caching things twice 18:54 < gmaxwell> (at least the 32-byte specialized version should get heavy use... because of all the places we use double sha2...) 18:55 < sipa> gmaxwell: yup, one thing at a time 18:55 < phantomcircuit> does std::unordered_map::clear() even do anything on an empty map? 18:55 < sipa> no 18:56 < phantomcircuit> ok so that call in Flush() is effectively a noop but makes it clear that it's empty i guess 19:04 -!- grafcaps [~haroldbr@50.90.83.229] has joined #bitcoin-core-dev 19:07 -!- snickerfritz [~snickerfr@unaffiliated/snickerfritz] has quit [Quit: Leaving] 19:10 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 19:31 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 260 seconds] 19:39 < cfields> sipa: hmm, come to think about it, the slowdown occured on AMD when Round() was done on SIMD instructions. Maybe it doesn't pay the same price on integers? 19:40 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev 19:41 < cfields> Sigma0/Sigma1, that is. 19:42 < sipa> what slowdown? 19:44 < cfields> sipa: nm, I'll comment on the PR 20:09 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 260 seconds] 20:14 < sipa> cfields: fixed, hopefully 20:15 < sipa> cfields: the new Round function in https://github.com/theuni/bitcoin/commit/d69a5164f914c6c2945d8f32134faa0da87795f5 makes the benchmark go from 3.68 ms to 4.16 ms 20:18 < cfields> sipa: Mind giving https://github.com/theuni/bitcoin/commit/4ee6fbb8b7525988783030eb0799bbc7293d50a0 a try? That's a little less dumb, doesn't force a dependency. 20:18 < sipa> (for me, on i7-7) 20:18 < sipa> sure 20:18 < cfields> sipa: I'm mostly curious to see if it's quicker on AMD. 20:19 < sipa> i'll try the different versions on a Ryzen system too if you want 20:20 < sipa> then again, on those systems we'll likely use SHA-NI instead :) 20:20 < cfields> heh, right 20:20 < cfields> you see what I'm getting at though, right? 20:25 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev 20:30 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 264 seconds] 20:56 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 20:57 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 20:59 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev 21:04 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 276 seconds] 21:14 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has joined #bitcoin-core-dev 21:19 -!- bitconner [~conner@64-71-8-130.static.wiline.com] has quit [Ping timeout: 260 seconds] 21:37 -!- goatpig [56f75200@gateway/web/freenode/ip.86.247.82.0] has quit [Ping timeout: 260 seconds] 21:39 < sipa> cfields: yeah, i'll benchmark on other systems 21:40 -!- jojeyh [~delphi@2602:306:b8b6:b970:49d7:a276:ad07:b8a7] has joined #bitcoin-core-dev 21:49 < bitcoin-git> [bitcoin] lucash-dev opened pull request #13443: Removed unused == operator from CMutableTransaction. (master...remove-CMutableTransaction-equals) https://github.com/bitcoin/bitcoin/pull/13443 23:01 < bitcoin-git> [bitcoin] edsgerlin opened pull request #13444: depends: bump openssl to 1.0.2o (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13444 23:26 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 23:28 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev