12018-06-11T00:17:20 * luke-jr is not very surprised
22018-06-11T00:18:49 *** drexl has quit IRC
32018-06-11T00:22:17 *** AaronvanW has quit IRC
42018-06-11T00:23:43 *** AaronvanW has joined #bitcoin-core-dev
52018-06-11T00:27:57 *** AaronvanW has quit IRC
62018-06-11T00:38:24 *** Chris_Stewart_5 has quit IRC
72018-06-11T00:38:48 *** justanotheruser has quit IRC
82018-06-11T00:55:25 *** justanotheruser has joined #bitcoin-core-dev
92018-06-11T01:00:12 *** richbd has joined #bitcoin-core-dev
102018-06-11T01:04:18 *** richbd has quit IRC
112018-06-11T01:22:26 *** booyah has quit IRC
122018-06-11T01:24:28 *** AaronvanW has joined #bitcoin-core-dev
132018-06-11T01:30:21 *** AaronvanW has quit IRC
142018-06-11T01:39:54 *** nullptr| has joined #bitcoin-core-dev
152018-06-11T01:46:35 *** nullptr| has quit IRC
162018-06-11T01:47:57 *** nullptr| has joined #bitcoin-core-dev
172018-06-11T01:54:55 *** nullptr| has quit IRC
182018-06-11T01:59:55 *** nullptr| has joined #bitcoin-core-dev
192018-06-11T02:00:05 *** Krellan has quit IRC
202018-06-11T02:00:56 *** Krellan has joined #bitcoin-core-dev
212018-06-11T02:04:14 <echeveria> 2018-06-11 02:03:03.384975 Verifying last 3 blocks at level 3
222018-06-11T02:04:14 <echeveria> 2018-06-11 02:03:23.676793 No coin database inconsistencies in last 4 blocks (6564 transactions)
232018-06-11T02:04:18 <echeveria> off by one?
242018-06-11T02:23:02 *** d9b4bef9 has quit IRC
252018-06-11T02:24:15 *** d9b4bef9 has joined #bitcoin-core-dev
262018-06-11T02:34:35 <sipa> echeveria: possibly!
272018-06-11T02:40:47 *** marc_pango has joined #bitcoin-core-dev
282018-06-11T02:42:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
292018-06-11T02:45:05 *** Sinclair6 has quit IRC
302018-06-11T03:03:32 *** justanotheruser has quit IRC
312018-06-11T03:04:20 *** Chris_Stewart_5 has quit IRC
322018-06-11T03:21:33 *** ula has quit IRC
332018-06-11T03:27:01 *** AaronvanW has joined #bitcoin-core-dev
342018-06-11T03:31:13 *** AaronvanW has quit IRC
352018-06-11T04:01:51 *** grafcaps has quit IRC
362018-06-11T04:05:42 *** justanotheruser has joined #bitcoin-core-dev
372018-06-11T04:08:09 *** Krellan has quit IRC
382018-06-11T04:09:02 *** Krellan has joined #bitcoin-core-dev
392018-06-11T04:14:45 *** grafcaps has joined #bitcoin-core-dev
402018-06-11T04:18:57 <kallewoof> Looks like it checks one more block than suggested. `if (pindex->nHeight < chainActive.Height()-nCheckDepth) break;` should probably be `<=`.
412018-06-11T04:20:25 *** Emcy has quit IRC
422018-06-11T04:36:03 *** Empact has quit IRC
432018-06-11T04:45:17 *** Empact has joined #bitcoin-core-dev
442018-06-11T04:46:52 *** nullptr| has quit IRC
452018-06-11T04:52:00 <sipa> kallewoof: agree
462018-06-11T04:53:40 *** nullptr| has joined #bitcoin-core-dev
472018-06-11T05:21:02 *** grafcaps has quit IRC
482018-06-11T05:27:49 *** AaronvanW has joined #bitcoin-core-dev
492018-06-11T05:28:49 <bitcoin-git> [bitcoin] kallewoof opened pull request #13428: validation: check the specified number of blocks (off-by-one) (master...validation-off-by-one) https://github.com/bitcoin/bitcoin/pull/13428
502018-06-11T05:29:04 <bitcoin-git> [bitcoin] Empact opened pull request #13429: Return the script type from Solver (master...solver-return) https://github.com/bitcoin/bitcoin/pull/13429
512018-06-11T05:29:08 *** victorSN has quit IRC
522018-06-11T05:29:08 *** rockhouse has quit IRC
532018-06-11T05:32:30 *** AaronvanW has quit IRC
542018-06-11T05:50:11 <gmaxwell> sipa: you created a 32-byte version of the specialized 1-way SSE4 asm?
552018-06-11T06:07:58 *** Emcy has joined #bitcoin-core-dev
562018-06-11T06:49:24 *** bitconne1 has joined #bitcoin-core-dev
572018-06-11T06:52:05 *** bitconner has quit IRC
582018-06-11T06:52:57 *** jimpo has quit IRC
592018-06-11T06:55:33 *** rockhouse has joined #bitcoin-core-dev
602018-06-11T06:55:37 *** victorSN has joined #bitcoin-core-dev
612018-06-11T06:56:00 *** rockhouse has quit IRC
622018-06-11T06:56:00 *** rockhouse has joined #bitcoin-core-dev
632018-06-11T07:05:36 <bitcoin-git> [bitcoin] kallewoof opened pull request #13430: use IsBlockPruned() where appropriate (master...use-isblockpruned) https://github.com/bitcoin/bitcoin/pull/13430
642018-06-11T07:16:46 <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
652018-06-11T07:24:28 *** AaronvanW has joined #bitcoin-core-dev
662018-06-11T07:25:50 *** bitconne1 has quit IRC
672018-06-11T07:29:11 *** AaronvanW has quit IRC
682018-06-11T07:29:22 *** ren0v0 has quit IRC
692018-06-11T07:31:17 *** jimpo has joined #bitcoin-core-dev
702018-06-11T07:32:45 *** Sentineo has quit IRC
712018-06-11T07:37:48 *** marc_pango has quit IRC
722018-06-11T07:58:18 *** ccdle12 has joined #bitcoin-core-dev
732018-06-11T08:06:09 *** bitconner has joined #bitcoin-core-dev
742018-06-11T08:06:15 *** setpill has joined #bitcoin-core-dev
752018-06-11T08:06:45 *** BashCo has quit IRC
762018-06-11T08:11:13 *** BashCo has joined #bitcoin-core-dev
772018-06-11T08:17:10 *** grafcaps has joined #bitcoin-core-dev
782018-06-11T08:19:54 *** Krellan has quit IRC
792018-06-11T08:21:21 *** grafcaps has quit IRC
802018-06-11T08:30:39 *** laurentmt has joined #bitcoin-core-dev
812018-06-11T08:30:58 *** promag has joined #bitcoin-core-dev
822018-06-11T08:34:20 *** Krellan has joined #bitcoin-core-dev
832018-06-11T08:35:05 *** sturles has quit IRC
842018-06-11T08:38:04 *** ren0v0 has joined #bitcoin-core-dev
852018-06-11T08:39:30 *** timothy has joined #bitcoin-core-dev
862018-06-11T08:44:31 *** sturles has joined #bitcoin-core-dev
872018-06-11T08:44:32 *** sturles has joined #bitcoin-core-dev
882018-06-11T08:45:51 *** timothy has quit IRC
892018-06-11T08:45:57 *** drizztbsd has joined #bitcoin-core-dev
902018-06-11T08:55:33 *** rafalcpp has joined #bitcoin-core-dev
912018-06-11T08:56:46 *** promag has quit IRC
922018-06-11T08:59:09 <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
932018-06-11T09:00:43 <ossifrage> Seems like bitcoin-qt should ignore this option?
942018-06-11T09:01:52 <bitcoin-git> [bitcoin] ken2812221 opened pull request #13434: Set default CFLAGS, CXXFLAGS to empty (master...enable_debug) https://github.com/bitcoin/bitcoin/pull/13434
952018-06-11T09:06:33 <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.
962018-06-11T09:06:45 <provoostenator> #13112
972018-06-11T09:06:51 <gribble> https://github.com/bitcoin/bitcoin/issues/13112 | Throw an error for unknown args by achow101 · Pull Request #13112 · bitcoin/bitcoin · GitHub
982018-06-11T09:11:29 <bitcoin-git> [bitcoin] ken2812221 closed pull request #13434: Set default CFLAGS, CXXFLAGS to empty (master...enable_debug) https://github.com/bitcoin/bitcoin/pull/13434
992018-06-11T09:20:21 *** promag has joined #bitcoin-core-dev
1002018-06-11T09:25:19 *** AaronvanW has joined #bitcoin-core-dev
1012018-06-11T09:29:58 *** AaronvanW has quit IRC
1022018-06-11T09:31:23 <wumpus> rc2 executables up https://bitcoincore.org/bin/bitcoin-core-0.16.1/test.rc2/, sorry for the delay
1032018-06-11T09:32:11 *** laurentmt has quit IRC
1042018-06-11T09:36:37 *** murrayn has quit IRC
1052018-06-11T09:45:31 *** murrayn has joined #bitcoin-core-dev
1062018-06-11T09:45:31 *** murrayn has joined #bitcoin-core-dev
1072018-06-11T09:47:45 <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
1082018-06-11T09:48:41 <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.
1092018-06-11T09:48:43 <gribble> https://github.com/bitcoin/bitcoin/issues/13434 | Set default CFLAGS, CXXFLAGS to empty by ken2812221 · Pull Request #13434 · bitcoin/bitcoin · GitHub
1102018-06-11T10:04:12 *** promag has quit IRC
1112018-06-11T10:05:23 *** grafcaps has joined #bitcoin-core-dev
1122018-06-11T10:09:27 *** grafcaps has quit IRC
1132018-06-11T10:32:45 *** promag has joined #bitcoin-core-dev
1142018-06-11T10:40:29 *** Krellan has quit IRC
1152018-06-11T10:41:14 *** Krellan has joined #bitcoin-core-dev
1162018-06-11T10:48:57 *** AaronvanW has joined #bitcoin-core-dev
1172018-06-11T10:55:09 *** Aaronvan_ has joined #bitcoin-core-dev
1182018-06-11T10:58:20 *** AaronvanW has quit IRC
1192018-06-11T11:03:58 *** owowo has quit IRC
1202018-06-11T11:08:23 *** owowo has joined #bitcoin-core-dev
1212018-06-11T11:09:32 *** str4d has joined #bitcoin-core-dev
1222018-06-11T11:12:24 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1232018-06-11T11:21:31 *** promag has quit IRC
1242018-06-11T11:25:35 <wumpus> kallewoof: maintainer mode affects optimization?
1252018-06-11T11:27:11 <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
1262018-06-11T11:27:31 <wumpus> provoostenator: the alternative would be to move knowledge of wallet options into the core, that'd be even worse
1272018-06-11T11:28:11 <rafalcpp> wumpus: I wonder how githubmerge could support git submodules. The submodules are linked by sha1 which is useless.
1282018-06-11T11:28:49 <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
1292018-06-11T11:28:57 <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.
1302018-06-11T11:29:18 <wumpus> hmm okay that sounds better at least
1312018-06-11T11:29:37 *** bitconner has quit IRC
1322018-06-11T11:30:34 <wumpus> rafalcpp: sounds like a lot of hassle, indeed
1332018-06-11T11:31:27 * rafalcpp spanks Torvalds to have git move to sha512 nativly
1342018-06-11T11:31:50 <wumpus> agree
1352018-06-11T11:33:03 <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
1362018-06-11T11:33:15 <rafalcpp> yeap
1372018-06-11T11:33:16 <wumpus> and the commit hash is the weakest link in that
1382018-06-11T11:41:44 <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
1392018-06-11T11:42:59 *** promag has joined #bitcoin-core-dev
1402018-06-11T11:43:58 <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.
1412018-06-11T11:47:59 <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
1422018-06-11T11:54:10 <wumpus> nm, got the sorting wrong, phew
1432018-06-11T11:57:50 *** bitconner has joined #bitcoin-core-dev
1442018-06-11T11:58:09 <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)?
1452018-06-11T11:58:37 <wumpus> it's something that was invented for our script AFAIK
1462018-06-11T12:01:37 *** pergaminho has joined #bitcoin-core-dev
1472018-06-11T12:01:54 *** pergaminho has quit IRC
1482018-06-11T12:02:50 *** bitconner has quit IRC
1492018-06-11T12:06:52 *** bitconner has joined #bitcoin-core-dev
1502018-06-11T12:08:38 *** Chris_Stewart_5 has quit IRC
1512018-06-11T12:11:54 *** Kvaciral has quit IRC
1522018-06-11T12:11:56 *** bitconner has quit IRC
1532018-06-11T12:13:56 *** grafcaps has joined #bitcoin-core-dev
1542018-06-11T12:19:11 *** grafcaps has quit IRC
1552018-06-11T12:21:56 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/56f69360dc98...6e249e46789f
1562018-06-11T12:21:56 <bitcoin-git> bitcoin/master cbede7d Sjors Provoost: [qt] OptionsDialog: add prune setting
1572018-06-11T12:21:57 <bitcoin-git> bitcoin/master 6e249e4 Wladimir J. van der Laan: Merge #13043: [qt] OptionsDialog: add prune setting...
1582018-06-11T12:22:35 <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
1592018-06-11T12:26:22 *** Guyver2 has joined #bitcoin-core-dev
1602018-06-11T12:34:19 <promag> wumpus: are you available for merges?
1612018-06-11T12:39:08 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6e249e46789f...531a0337ca93
1622018-06-11T12:39:08 <bitcoin-git> bitcoin/master fa6edfe MarcoFalke: qa: Remove portseed_offset from test runner
1632018-06-11T12:39:09 <bitcoin-git> bitcoin/master 531a033 Wladimir J. van der Laan: Merge #13421: qa: Remove portseed_offset from test runner...
1642018-06-11T12:39:53 <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
1652018-06-11T12:43:50 *** Aaronvan_ is now known as AaronvanW
1662018-06-11T12:44:15 *** SopaXorzTaker has joined #bitcoin-core-dev
1672018-06-11T12:45:01 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/531a0337ca93...70a03c635b73
1682018-06-11T12:45:01 <bitcoin-git> bitcoin/master f68049d Cory Fields: crypto: cleanup sha256 build...
1692018-06-11T12:45:01 <bitcoin-git> bitcoin/master 70a03c6 Wladimir J. van der Laan: Merge #13408: crypto: cleanup sha256 build...
1702018-06-11T12:45:46 <bitcoin-git> [bitcoin] laanwj closed pull request #13408: crypto: cleanup sha256 build (master...sha2-cleanup) https://github.com/bitcoin/bitcoin/pull/13408
1712018-06-11T12:49:56 *** bitconner has joined #bitcoin-core-dev
1722018-06-11T13:00:17 *** str4d has quit IRC
1732018-06-11T13:01:02 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1742018-06-11T13:05:50 *** drizztbsd is now known as timothy
1752018-06-11T13:07:15 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70a03c635b73...26c93edf1de9
1762018-06-11T13:07:15 <bitcoin-git> bitcoin/master a426098 practicalswift: Fix compiler warnings emitted when compiling under stock OpenBSD 6.3
1772018-06-11T13:07:16 <bitcoin-git> bitcoin/master 26c93ed Wladimir J. van der Laan: Merge #13294: Fix compiler warnings emitted when compiling under stock OpenBSD 6.3...
1782018-06-11T13:08:03 <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
1792018-06-11T13:14:30 *** rafalcpp has quit IRC
1802018-06-11T13:21:52 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/26c93edf1de9...3f0f39415bd7
1812018-06-11T13:21:53 <bitcoin-git> bitcoin/master 8160817 John Newbery: [wallet] [rpc] Remove getlabeladdress RPC...
1822018-06-11T13:21:54 <bitcoin-git> bitcoin/master 67e0e04 John Newbery: [wallet] [docs] Update release notes for removing `getlabeladdress`
1832018-06-11T13:21:54 <bitcoin-git> bitcoin/master 3f0f394 Wladimir J. van der Laan: Merge #13060: [wallet] [rpc] Remove getlabeladdress RPC...
1842018-06-11T13:21:56 *** ExtraCrispy has quit IRC
1852018-06-11T13:22:30 <bitcoin-git> [bitcoin] laanwj closed pull request #13060: [wallet] [rpc] Remove getlabeladdress RPC (master...remove_getlabeladdress) https://github.com/bitcoin/bitcoin/pull/13060
1862018-06-11T13:22:31 *** ExtraCrispy has joined #bitcoin-core-dev
1872018-06-11T13:52:45 <wumpus> promag: yes
1882018-06-11T13:53:31 *** Tralfaz has joined #bitcoin-core-dev
1892018-06-11T14:04:41 *** AaronvanW has quit IRC
1902018-06-11T14:15:01 *** AaronvanW has joined #bitcoin-core-dev
1912018-06-11T14:16:12 <promag> wumpus: #12151
1922018-06-11T14:16:15 <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
1932018-06-11T14:17:21 <promag> or #13160
1942018-06-11T14:17:23 <gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
1952018-06-11T14:18:49 <MarcoFalke> promag: #12151 was just pushed, imo not ready for merge
1962018-06-11T14:18:51 <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
1972018-06-11T14:19:35 *** AaronvanW has quit IRC
1982018-06-11T14:20:09 <wumpus> thanks, I'll have a look at those
1992018-06-11T14:20:36 <promag> MarcoFalke: right, should be re-ack
2002018-06-11T14:21:39 <promag> MarcoFalke: if you can take a look at 13160 too
2012018-06-11T14:24:57 *** AaronvanW has joined #bitcoin-core-dev
2022018-06-11T14:26:35 <bitcoin-git> [bitcoin] laanwj pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/3f0f39415bd7...43ae5ee9e4c2
2032018-06-11T14:26:36 <bitcoin-git> bitcoin/master b9ef21d Karl-Johan Alm: mempool: Add explicit max_descendants...
2042018-06-11T14:26:36 <bitcoin-git> bitcoin/master 46847d6 Karl-Johan Alm: mempool: Fix max descendants check...
2052018-06-11T14:26:37 <bitcoin-git> bitcoin/master 475a385 Karl-Johan Alm: Add GetTransactionAncestry to CTxMemPool for general purpose chain limit checking
2062018-06-11T14:27:07 <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
2072018-06-11T14:32:17 *** Chris_Stewart_5 has quit IRC
2082018-06-11T14:37:04 *** JackH has joined #bitcoin-core-dev
2092018-06-11T14:48:30 <wumpus> #13160 has only my utACK
2102018-06-11T14:48:34 <gribble> https://github.com/bitcoin/bitcoin/issues/13160 | wallet: Unlock spent outputs by promag · Pull Request #13160 · bitcoin/bitcoin · GitHub
2112018-06-11T14:48:45 <wumpus> I don't think that's enough for a change in behavior like that
2122018-06-11T14:49:02 <wumpus> even though code-wise it's very simple to review
2132018-06-11T14:51:29 *** goatpig has joined #bitcoin-core-dev
2142018-06-11T14:52:35 *** StopAndDecrypt has quit IRC
2152018-06-11T14:53:25 *** StopAndDecrypt has joined #bitcoin-core-dev
2162018-06-11T14:53:35 *** StopAndDecrypt has quit IRC
2172018-06-11T14:53:35 *** StopAndDecrypt has joined #bitcoin-core-dev
2182018-06-11T14:53:58 *** Tralfaz has quit IRC
2192018-06-11T14:54:40 *** Krellan has quit IRC
2202018-06-11T14:55:24 *** Krellan has joined #bitcoin-core-dev
2212018-06-11T14:57:05 *** StopAndDecrypt has quit IRC
2222018-06-11T14:57:25 *** StopAndDecrypt has joined #bitcoin-core-dev
2232018-06-11T14:57:34 *** StopAndDecrypt has quit IRC
2242018-06-11T14:57:34 *** StopAndDecrypt has joined #bitcoin-core-dev
2252018-06-11T15:00:56 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2262018-06-11T15:05:11 *** laurentmt has joined #bitcoin-core-dev
2272018-06-11T15:06:29 *** grafcaps has joined #bitcoin-core-dev
2282018-06-11T15:10:09 <sipa> MarcoFalke: you mentioned that fetching PR information from github was the bottleneck for drahtbot? are you using the git interface for PRs?
2292018-06-11T15:11:01 <MarcoFalke> I do. But I also need to get the open pull requests and metadata for them.
2302018-06-11T15:12:40 <sipa> hmm
2312018-06-11T15:13:30 <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)
2322018-06-11T15:13:32 <gribble> https://github.com/bitcoin/bitcoin/issues/13103 | Invalid wallet path with Chinese characters in windows · Issue #13103 · bitcoin/bitcoin · GitHub
2332018-06-11T15:13:33 <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
2342018-06-11T15:14:29 <ken2812221> additional function and method in boost header
2352018-06-11T15:14:34 <MarcoFalke> And the "Needs rebase" task of DrahtBot is purely based on the api
2362018-06-11T15:15:17 <MarcoFalke> Since GitHub hasn't yet disclosed which merge tool they use
2372018-06-11T15:19:29 <sipa> MarcoFalke: seems reasonablw that it's pretty much vanilla git
2382018-06-11T15:19:49 <sipa> as our merge tool compares the local merge with the github merge
2392018-06-11T15:19:52 *** laurentmt has quit IRC
2402018-06-11T15:20:06 <sipa> and afaik never failed for noticing a differencw
2412018-06-11T15:20:28 <MarcoFalke> They advertise as merge conflict when one of the files got moved
2422018-06-11T15:20:37 <MarcoFalke> vanilla git doen't afaict
2432018-06-11T15:21:13 <sipa> hmm
2442018-06-11T15:32:46 *** grafcaps has quit IRC
2452018-06-11T15:37:06 *** booyah has joined #bitcoin-core-dev
2462018-06-11T15:53:06 *** owowo has quit IRC
2472018-06-11T15:56:53 *** grafcaps has joined #bitcoin-core-dev
2482018-06-11T15:57:47 *** owowo has joined #bitcoin-core-dev
2492018-06-11T16:01:32 <echeveria> https://pastebin.com/Ar8cT76q
2502018-06-11T16:01:45 <echeveria> bitcoind seems to get very sad sometimes if you have a low maxconnections
2512018-06-11T16:01:45 <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
2522018-06-11T16:02:03 *** tryphe has joined #bitcoin-core-dev
2532018-06-11T16:04:52 *** tryphe_ has quit IRC
2542018-06-11T16:05:40 *** Krellan has quit IRC
2552018-06-11T16:08:53 *** Krellan has joined #bitcoin-core-dev
2562018-06-11T16:10:11 *** ghost43 has quit IRC
2572018-06-11T16:10:38 *** grafcaps has quit IRC
2582018-06-11T16:10:54 *** ghost43 has joined #bitcoin-core-dev
2592018-06-11T16:12:55 *** setpill has quit IRC
2602018-06-11T16:18:19 <promag> wumpus: I can't reproduce #13111 failures locally
2612018-06-11T16:18:22 <gribble> https://github.com/bitcoin/bitcoin/issues/13111 | Add unloadwallet RPC by promag · Pull Request #13111 · bitcoin/bitcoin · GitHub
2622018-06-11T16:18:37 <promag> should retry travis job?
2632018-06-11T16:26:14 *** grafcaps has joined #bitcoin-core-dev
2642018-06-11T16:27:09 <bitcoin-git> [bitcoin] ken2812221 closed pull request #13107: Fix Windows locale problem (master...win-enc) https://github.com/bitcoin/bitcoin/pull/13107
2652018-06-11T16:30:30 *** grafcaps has quit IRC
2662018-06-11T16:31:30 *** ccdle12 has quit IRC
2672018-06-11T16:33:15 *** grafcaps has joined #bitcoin-core-dev
2682018-06-11T16:46:20 *** Purple7 has joined #bitcoin-core-dev
2692018-06-11T16:47:13 <Purple7> Hi everyone :)
2702018-06-11T16:48:06 <Purple7> can someone here help me create a bitcoin script. I just installed Bitcoin core node and have tried bitcoin-cli commands
2712018-06-11T16:48:23 <echeveria> I don't know what you imagine bitcoin script to be capable of.
2722018-06-11T16:48:30 <Purple7> I want to create a script but not sure how to create one and how to run one
2732018-06-11T16:48:32 <wumpus> promag: I had some segfaults locally with it, but seems hard to reproduce
2742018-06-11T16:48:41 <Purple7> to carry out transactions
2752018-06-11T16:48:45 <echeveria> Purple7: lets do this in #bitcoin.
2762018-06-11T16:50:00 <promag> wumpus: yes I think I can reproduce now
2772018-06-11T16:50:13 <Purple7> Thanks echeveria
2782018-06-11T16:50:14 <Purple7> :)
2792018-06-11T16:50:40 <promag> wumpus: delete regtest folder, launch, then rpc stop
2802018-06-11T16:51:02 <promag> looks like that way always segfaults
2812018-06-11T16:54:06 <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
2822018-06-11T16:54:33 *** nmnkgl has joined #bitcoin-core-dev
2832018-06-11T16:54:50 *** Purple7 has quit IRC
2842018-06-11T16:56:20 <Chris_Stewart_5> we are reading other config options from the bitcoin.conf file
2852018-06-11T16:56:25 <Chris_Stewart_5> just not rpcport it seems
2862018-06-11T16:56:58 <sipa> Chris_Stewart_5: what version of the code?
2872018-06-11T16:57:04 <Chris_Stewart_5> 0.16.0
2882018-06-11T16:57:22 <wumpus> rpcport should work fine in the bitcoin.conf, I've had it in there for ages
2892018-06-11T16:57:54 <wumpus> note that master has per-network config sections, but 0.16 does not
2902018-06-11T16:58:01 <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
2912018-06-11T16:58:30 <wumpus> are you really sure? as said, I have a setup myself that uses that
2922018-06-11T16:58:49 <Chris_Stewart_5> just a sec, I'm double checking he didn't compile from master
2932018-06-11T16:59:47 <Chris_Stewart_5> nvm, he is on 0.16.99.
2942018-06-11T17:00:41 <sipa> how do you observe it's not using rpcport?
2952018-06-11T17:00:46 <wumpus> ok on master you need to put it in a network-specific section, this is described in the doc/release-notes.md
2962018-06-11T17:00:54 <sipa> wumpus: oh!
2972018-06-11T17:01:02 *** Rebo has joined #bitcoin-core-dev
2982018-06-11T17:01:06 <wumpus> it should also warn in the log
2992018-06-11T17:02:33 <sipa> wumpus: nothing here: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.md
3002018-06-11T17:02:36 <Chris_Stewart_5> basically it was always binding to 18433 if we set rpcport via the command line
3012018-06-11T17:03:03 <Chris_Stewart_5> unless we set it via the command line* sorry
3022018-06-11T17:04:23 <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...
3032018-06-11T17:05:59 <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.
3042018-06-11T17:07:12 <wumpus> sipa: release-notes-pr12823.md apparently
3052018-06-11T17:07:34 <sipa> oh, i forgot we added pr-specific files
3062018-06-11T17:08:13 <wumpus> it does make things harder to find
3072018-06-11T17:09:54 <sipa> wumpus: any opinion about converting the existing sse4 assembly code (which was in 0.16) into intrinsics based code?
3082018-06-11T17:10:13 <sipa> downside: possibly a bit slower (i've seen up to 4% slower) and compiler dependent
3092018-06-11T17:10:27 <sipa> upside: more easily reusable, readable, and works on 32-bit systems
3102018-06-11T17:14:18 <promag> wumpus: found the problem, will push a fix in a separate commit for now
3112018-06-11T17:18:45 <echeveria> yeah, that's a weird one. I have hardcoded `connect` peers but it doesn't sync.
3122018-06-11T17:21:12 <echeveria> random peers, syncs perfectly, hardcoded it doesn't sync, even with the same peers.
3132018-06-11T17:33:03 <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
3142018-06-11T17:33:39 *** Krellan has quit IRC
3152018-06-11T17:35:04 <gmaxwell> 22:50:10 < gmaxwell> sipa: you created a 32-byte version of the specialized 1-way SSE4 asm?
3162018-06-11T17:35:35 <sipa> gmaxwell: no, not specialized
3172018-06-11T17:36:20 <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
3182018-06-11T17:39:11 *** JackH_ has joined #bitcoin-core-dev
3192018-06-11T17:40:31 <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
3202018-06-11T17:40:51 *** JackH has quit IRC
3212018-06-11T17:43:23 <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
3222018-06-11T17:43:46 <sipa> wumpus: ah, but those don't even have SSE4 :)
3232018-06-11T17:44:04 <sipa> the only use for SSE4 in 32-bit mode is people running a 32-bit binary on 64-bit hardware
3242018-06-11T17:44:05 <wumpus> too bad we don't have statistics how much those get downloaded
3252018-06-11T17:44:26 <wumpus> right
3262018-06-11T17:44:59 <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
3272018-06-11T17:46:56 <wumpus> for that it certainly makes sense, easier to specialize code w/ intrinsics than manual register allocation
3282018-06-11T17:48:21 *** JackH_ has quit IRC
3292018-06-11T17:48:33 <sipa> i also wonder what to do about CI for special hardware
3302018-06-11T17:48:42 *** JackH has joined #bitcoin-core-dev
3312018-06-11T17:48:43 <sipa> SHA-NI is unlikely to be available on any Travis system
3322018-06-11T17:48:59 <sipa> and POWER9 would surprise me even more :D
3332018-06-11T17:51:21 <luke-jr> test these things more carefully when they change?
3342018-06-11T17:51:34 <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
3352018-06-11T17:51:51 <luke-jr> well, at least the platform-specific stuff in this case is isolated
3362018-06-11T17:52:04 <sipa> i'm also going to extend the self-test code for these
3372018-06-11T17:52:18 <sipa> so at least it will fail at startup rather than arbitrarily
3382018-06-11T17:52:43 <wumpus> it's notrealistic to have CI for all OS/architecture combinations, not even all OSes and architectures separately
3392018-06-11T17:53:23 <wumpus> I still have a PR open to run travis on at least one bigendian platform, but even that seems untenable
3402018-06-11T17:53:26 <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
3412018-06-11T17:53:45 <wumpus> it's not realistic to do that for every PR, sure, some daily cron job would work
3422018-06-11T18:01:17 <MarcoFalke> Apparently we have some jenkins running somewhere, maybe jamesob can see if that would work with FreeBSD/OpenBSD
3432018-06-11T18:01:32 <MarcoFalke> SHA-NI and POWER9 should already be tested by devs regularly, no?
3442018-06-11T18:03:07 *** satwo has joined #bitcoin-core-dev
3452018-06-11T18:03:34 <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?
3462018-06-11T18:04:19 <jamesob> gmaxwell: travis is limited to execution on their infra AFAICT
3472018-06-11T18:04:32 <MarcoFalke> I think so as well ^
3482018-06-11T18:05:13 *** drexl has joined #bitcoin-core-dev
3492018-06-11T18:06:03 <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.
3502018-06-11T18:06:09 <wumpus> in theory it's possible to ssh out from travis, but that sounds horribly fragile
3512018-06-11T18:06:19 <wumpus> (also, key management is a problem)
3522018-06-11T18:07:02 <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)
3532018-06-11T18:08:32 <wumpus> right, that sounds better
3542018-06-11T18:10:04 <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
3552018-06-11T18:10:06 <luke-jr> MarcoFalke: I should be moving my development to my POWER9 system in this next week
3562018-06-11T18:10:22 <MarcoFalke> luke-jr: Good to hear
3572018-06-11T18:10:34 <MarcoFalke> Also BlueMatt switched to POWER9
3582018-06-11T18:11:12 <cfields> sipa: fwiw, I now fully understand the 1way sha2 optims for sse4/avx. I started working on the intrinsics over the weekend
3592018-06-11T18:11:28 <sipa> cfields: too late :)
3602018-06-11T18:11:30 <cfields> sipa: just thought I'd mention in case you were also looking at it
3612018-06-11T18:11:42 <cfields> oh?
3622018-06-11T18:11:52 <cfields> heh, did I miss a PR?
3632018-06-11T18:11:54 <sipa> cfields: i have intrinsics based 1-way sse4 working
3642018-06-11T18:11:56 <sipa> not PRed yet
3652018-06-11T18:12:28 <sipa> sorry, didn't know you were planning to work on it so soon as well
3662018-06-11T18:12:47 <cfields> sipa: no worries. Now I can pick yours apart :p
3672018-06-11T18:13:32 <BlueMatt> yea, POWER9 should get pretty good testing, sdaftuar and I have already been using it for some time now
3682018-06-11T18:13:37 <provoostenator> cfields: or work on #13401
3692018-06-11T18:13:38 <gribble> https://github.com/bitcoin/bitcoin/issues/13401 | ARMv8 sha2 support · Issue #13401 · bitcoin/bitcoin · GitHub
3702018-06-11T18:13:40 <provoostenator> :-)
3712018-06-11T18:13:51 <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
3722018-06-11T18:15:33 <gmaxwell> sipa: would the 1-way sha2 be more efficient for longer inputs if it processed more blocks at once?
3732018-06-11T18:15:48 <gmaxwell> (e.g. could it be expanding the next group)
3742018-06-11T18:18:36 <sipa> gmaxwell: hmm, yes!
3752018-06-11T18:18:38 <cfields> sipa: did you include the lane duplication optim for quicker rotates?
3762018-06-11T18:19:03 <sipa> cfields: i literally translated the asm code instruction per instruction to intrinsics
3772018-06-11T18:19:15 <sipa> and then restructured it into functions that make sense
3782018-06-11T18:19:23 <provoostenator> What does "1-way" mean in the context of a SHA256 hash?
3792018-06-11T18:19:34 <cfields> sipa: ah, I think some of that will pessimize avx though, no?
3802018-06-11T18:19:40 <cfields> I guess I'll wait to see it
3812018-06-11T18:20:01 <gmaxwell> provoostenator: computing one hash at a time, as opposted to concurrently computing many hashes.
3822018-06-11T18:20:20 <sipa> cfields: recompiling this code with -mavx gains virtually no advantage
3832018-06-11T18:20:52 <sipa> provoostenator: say you have 8 64-byte vectors, and want to independently compute the 8 32-byte hashes of those
3842018-06-11T18:20:59 <sipa> provoostenator: we have a specialized function that does that
3852018-06-11T18:21:07 <sipa> that's 8-way
3862018-06-11T18:21:38 <cfields> sipa: hmm, that's really surprising.
3872018-06-11T18:21:44 <provoostenator> Ah ok, so that's useful if you're able to do some of the validation stuff in parallel?
3882018-06-11T18:22:59 <sipa> provoostenator: it's currently used (in master) for merkle tree root computations
3892018-06-11T18:26:09 <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/43ae5ee9e4c2...7c32b414b632
3902018-06-11T18:26:10 <bitcoin-git> bitcoin/master 906bee8 practicalswift: Use bracket syntax includes ("#include <foo.h>")
3912018-06-11T18:26:10 <bitcoin-git> bitcoin/master 6d10f43 practicalswift: Enforce the use of bracket syntax includes ("#include <foo.h>")
3922018-06-11T18:26:11 <bitcoin-git> bitcoin/master 16e3cd3 practicalswift: Clarify include recommendation
3932018-06-11T18:26:40 <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.
3942018-06-11T18:26:43 <provoostenator> sipa: why not in script validation? Not worth it or still on todo lists?
3952018-06-11T18:26:46 <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
3962018-06-11T18:26:50 <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
3972018-06-11T18:26:56 <cfields> gmaxwell: ^^
3982018-06-11T18:27:07 <sipa> provoostenator: todo list
3992018-06-11T18:27:31 <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.
4002018-06-11T18:27:49 <gmaxwell> So easiest was hashtrees, since that all gets computed at once.
4012018-06-11T18:27:54 <provoostenator> Right now script validation can is done in parallel on _multiple_ cpu's, rather than on a single one?
4022018-06-11T18:28:33 <cfields> (ofc that's separate from the per-block optimizations)
4032018-06-11T18:28:45 <cfields> provoostenator: yes
4042018-06-11T18:30:23 <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?
4052018-06-11T18:30:50 <provoostenator> If they're not otherwise identical.
4062018-06-11T18:31:10 <provoostenator> But 1-way doesn't change anything
4072018-06-11T18:33: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.
4082018-06-11T18:35:04 *** ExtraCrispy has quit IRC
4092018-06-11T18:45:45 *** Rebo has quit IRC
4102018-06-11T18:59:15 <cfields> sipa: would you be ok with a separate avx-optimized version of those intrinsics if the speedup was as significant as before?
4112018-06-11T19:00:39 *** str4d has joined #bitcoin-core-dev
4122018-06-11T19:00:43 *** jhfrontz has quit IRC
4132018-06-11T19:01:02 *** jhfrontz has joined #bitcoin-core-dev
4142018-06-11T19:03:46 <sipa> cfields: the avx speedup is for the 4-way sse4, not the 1-way sse4 code
4152018-06-11T19:03:49 <sipa> cfields: and yes
4162018-06-11T19:04:07 *** ^nix has joined #bitcoin-core-dev
4172018-06-11T19:04:28 <cfields> sipa: there are definitely 1way speedups due to non-destructive xor's
4182018-06-11T19:05:10 *** dariusmaximus has joined #bitcoin-core-dev
4192018-06-11T19:07:03 <sipa> cfields: ah, the compiler may not be smart enough to use those?
4202018-06-11T19:07:32 <cfields> sipa: I really would've expected it to, since there's not a separate intrinsic for them
4212018-06-11T19:07:41 <cfields> it might be how the other registers are setup, though
4222018-06-11T19:08:43 *** SopaXorzTaker has quit IRC
4232018-06-11T19:09:07 <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.
4242018-06-11T19:09:47 <sipa> cfields: i'll cleanup my code and PR
4252018-06-11T19:10:38 <cfields> ok
4262018-06-11T19:10:52 <bitcoin-git> [bitcoin] sipa opened pull request #13438: Improve coverage of SHA256 SelfTest code (master...201806_selftestsha) https://github.com/bitcoin/bitcoin/pull/13438
4272018-06-11T19:11:32 <cfields> sipa: thanks for that :)
4282018-06-11T19:12:17 <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
4292018-06-11T19:17:45 *** nmnkgl has quit IRC
4302018-06-11T19:22:02 <provoostenator> Any other live metrics I should collect on my slow pruned AWS node? https://github.com/bitcoin/bitcoin/pull/12404#issuecomment-396356384
4312018-06-11T19:24:17 <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.
4322018-06-11T19:24:54 <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.
4332018-06-11T19:25:05 <cfields> gmaxwell: do you mean intel's modified Sigma0/Sigma1 ?
4342018-06-11T19:25:43 <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)
4352018-06-11T19:25:46 <cfields> if so, yea, most of the code I've found in the wild opts out of those for that reason
4362018-06-11T19:26:15 <cfields> gmaxwell: I'm guessing it's what I PR'd, which we closed for that reason :(
4372018-06-11T19:26:57 <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.
4382018-06-11T19:27:10 <gmaxwell> ESP since anything with AVX is pretty quick regardless.
4392018-06-11T19:28:03 <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
4402018-06-11T19:28:43 *** ghost43 has quit IRC
4412018-06-11T19:28:58 *** ghost43 has joined #bitcoin-core-dev
4422018-06-11T19:31:23 <cfields> gmaxwell: agreed. I'd rather avoid per-vendor optims unless it's really really significant
4432018-06-11T19:31:37 <cfields> might be harder to avoid that if we get into arm, though
4442018-06-11T19:32:06 <gmaxwell> for arm it's more worth it...
4452018-06-11T19:32:26 <gmaxwell> even a small percantage change is a large absolute time there.
4462018-06-11T19:35:01 <cfields> fair point.
4472018-06-11T19:35:19 <cfields> gmaxwell: #13400 is what I was referencing, btw. Hopefully that's the same one as the kernel discussion you had in mind.
4482018-06-11T19:35:21 <gribble> https://github.com/bitcoin/bitcoin/issues/13400 | sha256: small speedup for sse4 path. by theuni · Pull Request #13400 · bitcoin/bitcoin · GitHub
4492018-06-11T19:35:30 <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.
4502018-06-11T19:36:22 *** bitconner has quit IRC
4512018-06-11T19:37:37 <cfields> huh, I figured my Sandy Bridge was the outlier
4522018-06-11T19:40:23 <gmaxwell> AVX2 is only haswell and later on intel, and the xeons lag desktops in microarch by a couple years.
4532018-06-11T19:56:00 *** tryphe_ has joined #bitcoin-core-dev
4542018-06-11T19:58:34 *** tryphe has quit IRC
4552018-06-11T19:58:43 *** bitconner has joined #bitcoin-core-dev
4562018-06-11T20:15:22 *** nmnkgl has joined #bitcoin-core-dev
4572018-06-11T20:19:29 *** OS-11936 has joined #bitcoin-core-dev
4582018-06-11T20:20:07 *** OS-11936 has quit IRC
4592018-06-11T20:22:47 *** str4d has quit IRC
4602018-06-11T20:24:27 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #13440: qa: Log as utf-8 (master...Mf1806-qaLogUtf8) https://github.com/bitcoin/bitcoin/pull/13440
4612018-06-11T20:37:10 *** Cheeseo has joined #bitcoin-core-dev
4622018-06-11T20:37:13 *** Krellan has joined #bitcoin-core-dev
4632018-06-11T20:41:37 *** Krellan has quit IRC
4642018-06-11T20:49:00 *** edgar_ has joined #bitcoin-core-dev
4652018-06-11T20:53:45 <edgar_> hello
4662018-06-11T20:54:12 *** edgar_ has left #bitcoin-core-dev
4672018-06-11T21:02:10 *** gloata has quit IRC
4682018-06-11T21:12:22 *** Cheeseo has quit IRC
4692018-06-11T21:23:29 *** CubicEarths has quit IRC
4702018-06-11T21:23:54 *** ^nix has quit IRC
4712018-06-11T21:25:39 *** CubicEarths has joined #bitcoin-core-dev
4722018-06-11T21:28:02 <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
4732018-06-11T21:28:38 <achow101> ossifrage: provoostenator: ^ that PR should fix the problem with the options
4742018-06-11T21:30:50 *** CubicEarths has quit IRC
4752018-06-11T21:36:43 *** CubicEarths has joined #bitcoin-core-dev
4762018-06-11T21:43:16 *** satwo has quit IRC
4772018-06-11T21:53:36 *** timothy has quit IRC
4782018-06-11T22:05:18 *** Guyver2 has quit IRC
4792018-06-11T22:11:44 *** Guest99396 is now known as Guest47913
4802018-06-11T22:12:59 *** Guest47913 is now known as eenoch
4812018-06-11T22:13:29 *** eenoch is now known as Guest25972
4822018-06-11T22:13:44 *** Guest25972 is now known as Guest47913
4832018-06-11T22:17:31 *** Guest47913 has quit IRC
4842018-06-11T22:17:46 *** eenoch_ has joined #bitcoin-core-dev
4852018-06-11T22:25:50 *** Sinclair6 has joined #bitcoin-core-dev
4862018-06-11T22:42:35 *** snickerfritz has joined #bitcoin-core-dev
4872018-06-11T22:42:35 *** snickerfritz has quit IRC
4882018-06-11T22:42:35 *** snickerfritz has joined #bitcoin-core-dev
4892018-06-11T22:53:29 *** AaronvanW has quit IRC
4902018-06-11T23:04:11 *** AaronvanW has joined #bitcoin-core-dev
4912018-06-11T23:08:55 *** AaronvanW has quit IRC
4922018-06-11T23:09:18 <sipa> gmaxwell: got it faster than the asm version now
4932018-06-11T23:09:29 <sipa> 3.68 ms vs 3.77 ms
4942018-06-11T23:09:34 <sipa> on i7
4952018-06-11T23:20:17 *** AaronvanW has joined #bitcoin-core-dev
4962018-06-11T23:35:12 *** promag has quit IRC
4972018-06-11T23:37:00 <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
4982018-06-11T23:37:50 <cfields> sipa: nice
4992018-06-11T23:38:32 <cfields> sipa: and it looks like it should be friendlier to avx now. Was that purposeful, or nice side-effect?
5002018-06-11T23:38:45 <sipa> cfields: i don't know why or how
5012018-06-11T23:38:50 <sipa> elaborate please :)
5022018-06-11T23:40:08 <sipa> cfields: it's crazy how much the compiler affects things, though
5032018-06-11T23:40:19 <sipa> in one place changing a constant from const to static const made it 10% slower
5042018-06-11T23:40:33 <sipa> in another place changing it from static const to const made it 3% slower
5052018-06-11T23:40:42 <cfields> sipa: yea, I was going to ask you if the ordering really matters, I assume the compiler will reorder as it sees fit
5062018-06-11T23:40:54 <cfields> huh
5072018-06-11T23:40:54 *** Victorsueca has quit IRC
5082018-06-11T23:41:36 <sipa> generally reordering seems to have only a marginal affect, to none at all
5092018-06-11T23:41:45 <sipa> changing the types of constants and variables has a large affect
5102018-06-11T23:42:04 *** Victorsueca has joined #bitcoin-core-dev
5112018-06-11T23:42:08 <cfields> interesting, I would've thought the interleaving timing was the crucial part
5122018-06-11T23:42:12 <sipa> (the trick with Ws, as opposed to just keeping it as a __m128i and extracting the elements from it, does have a different)
5132018-06-11T23:42:25 <sipa> oh, the interleaving is absolutely crucial
5142018-06-11T23:42:27 <cfields> ...I guess it probably is, but you have to fight the compiler to get there first
5152018-06-11T23:42:31 <sipa> but the compiler reorders things anyway
5162018-06-11T23:42:40 <sipa> regardless of how you write it... to an extent
5172018-06-11T23:43:45 <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
5182018-06-11T23:43:51 <cfields> for example: XTMP0 = Palignr(X3, X2, 4);
5192018-06-11T23:44:19 *** Krellan has joined #bitcoin-core-dev
5202018-06-11T23:44:23 <sipa> cfields: heh, SSA transformation will destroy that
5212018-06-11T23:44:40 <sipa> don't assume the compiler will map every variable to a single register all of the time
5222018-06-11T23:45:02 <cfields> ofc, I just mean that it has the option with avx
5232018-06-11T23:45:08 <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
5242018-06-11T23:45:17 <sipa> yes, but the way the code is written shouldn't affect that at all
5252018-06-11T23:45:43 <sipa> the SSA transform will effectively turn every assignment to a variable into a new variable, from the compiler's perspective
5262018-06-11T23:46:31 <cfields> I see
5272018-06-11T23:48:49 <sipa> with -msse4.1: 3.68ms
5282018-06-11T23:48:56 <sipa> with -mavx: 3.54ms
5292018-06-11T23:49:00 *** Krellan has quit IRC
5302018-06-11T23:49:56 <cfields> sipa: huh, odd. I get a massive speedup with avx
5312018-06-11T23:50:10 <cfields> SHA256D64_1024, 20, 7400, 123.736, 0.000835992, 0.000836151, 0.000836061
5322018-06-11T23:50:20 <cfields> SHA256D64_1024, 20, 7400, 73.563, 0.000496887, 0.000497227, 0.000497053
5332018-06-11T23:53:57 <sipa> cfields: oh, i was looking at the SHA256 benchmark