1 2018-06-06 02:49:34	0|MarcoFalke|FYI, I have assigned all non-mergeable open pulls to a new label "Needs rebase"
  2 2018-06-06 02:49:41	0|MarcoFalke|Makes it easier to sort
  3 2018-06-06 02:49:44	0|MarcoFalke|e.g. https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aopen+label%3A%22Needs+rebase%22
  4 2018-06-06 05:36:06	0|bitcoin-git|[13bitcoin] 15lucash-dev opened pull request #13404: [tests] speed up of tx_validationcache_tests by reusing of CTransaction. (06master...06speedup-tx_validationcache_tests) 02https://github.com/bitcoin/bitcoin/pull/13404
  5 2018-06-06 08:32:13	0|wumpus|MarcoFalke: I hope that happens automatically? otherwise, it sounds like a nightmare to keep it up to date
  6 2018-06-06 08:32:51	0|wumpus|MarcoFalke: also, it's already possible to use bitcoinacks.com to keep track of that
  7 2018-06-06 11:33:14	0|wumpus|how are things with 0.16.0rc1? do we have anything that needs to be backported for rc2? I haven't heard any reports of bugs at least.
  8 2018-06-06 11:34:25	0|wumpus|if not, we should do a very fast rc2 for the translations issue and then tag final
  9 2018-06-06 11:34:28	0|wumpus|eh, 0.16.1 obvs
 10 2018-06-06 11:59:20	0|bitcoin-git|[13bitcoin] 15ken2812221 opened pull request #13406: travis: Add make step so that travis can build all executables for Mac. (06master...06travis_make_mac) 02https://github.com/bitcoin/bitcoin/pull/13406
 11 2018-06-06 13:17:50	0|bitcoin-git|13bitcoin/06master 149d6c9db 15Ben Woosley: lint: Add linter to error on #include <*.cpp>...
 12 2018-06-06 13:17:50	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a589f536b5e1...e4082d59f53d
 13 2018-06-06 13:17:51	0|bitcoin-git|13bitcoin/06master 14e4082d5 15MarcoFalke: Merge #13301: lint: Add linter to error on #include <*.cpp>...
 14 2018-06-06 13:18:44	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13301: lint: Add linter to error on #include <*.cpp> (06master...06lint-include-cpp) 02https://github.com/bitcoin/bitcoin/pull/13301
 15 2018-06-06 14:14:45	0|jamesob_|anyone willing to trade reviews for #13168?
 16 2018-06-06 14:14:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/13168 | Thread names in logs and deadlock debug tools (take 2) by jamesob · Pull Request #13168 · bitcoin/bitcoin · GitHub
 17 2018-06-06 14:25:36	0|ryanzim|https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh says:
 18 2018-06-06 14:25:38	0|ryanzim|> The HASH160 of the pubkey in witness must match the witness program.
 19 2018-06-06 14:26:28	0|ryanzim|This seems to imply that the witness program is HASH160(pubkey), when it's actually HASH160(SHA256(pubkey))
 20 2018-06-06 14:26:34	0|ryanzim|Shouldn't this be clarified?
 21 2018-06-06 14:30:00	0|ryanzim|Ah, sorry; doing a little more research; seems I was confusing HASH160 and ripemd160; nvm
 22 2018-06-06 15:48:01	0|promag|Currently there is a DbEnv can reference multiple Db instances right?
 23 2018-06-06 15:48:15	0|promag|s/there is//
 24 2018-06-06 15:51:26	0|promag|Also, BerkeleyDatabase::Flush calls BerkeleyEnvironment::Flush, is there a reason to keep it like that?
 25 2018-06-06 15:56:56	0|promag|so that when unloading a wallet all wallets wouldn't have to be flushed
 26 2018-06-06 16:00:29	0|bitcoin-git|[13bitcoin] 15eudisd closed pull request #13373: Qt: Update Wallet Encryption Titles To Better Describe Process (06master...06feature/bitcoin-#13245) 02https://github.com/bitcoin/bitcoin/pull/13373
 27 2018-06-06 16:06:08	0|promag|jnewbery: yes there is a couple of things to fix
 28 2018-06-06 16:06:17	0|promag|jnewbery: one is as follow
 29 2018-06-06 16:06:35	0|promag|bitcoind -regtest -debug -wallet=w1 -wallet=w2
 30 2018-06-06 16:06:53	0|promag|bitcoin-cli -regtest unloadwallet w1
 31 2018-06-06 16:07:12	0|promag|bitcoin-cli -regtest -rpcwallet=w2 getwalletinfo
 32 2018-06-06 16:07:21	0|promag|see above questions
 33 2018-06-06 16:54:06	0|MarcoFalke|wumpus: I know it is on bitcoinacks.com, but I don't like the idea to switch back and forth between websites when you could have it all in one place
 34 2018-06-06 16:54:24	0|MarcoFalke|And yes, will be automated in the future
 35 2018-06-06 16:55:08	0|MarcoFalke|ACK on the quick rc2
 36 2018-06-06 17:22:43	0|bitcoin-git|[13bitcoin] 15skeees opened pull request #13407: [refactor, move-only-ish] Refactor mempool accept/reject logic (06master...06atmp-p2p-refactor) 02https://github.com/bitcoin/bitcoin/pull/13407
 37 2018-06-06 17:30:27	0|cfields|sipa: did you happen to bench sha2 with sse41 + avx?
 38 2018-06-06 17:36:53	0|sipa|cfields: ah, forgot about that, good idea
 39 2018-06-06 17:37:12	0|sipa|cfields: feel like fixing the proliferation of various crypto libs in the makefile?
 40 2018-06-06 17:37:38	0|cfields|sipa: sure thing, will PR
 41 2018-06-06 17:47:51	0|sipa|cfields: sse41 2.9ms, sse41 (compiled with -mavx) 2.0ms, avx2 1.1ms
 42 2018-06-06 17:47:59	0|sipa|that's a very significant improvement...
 43 2018-06-06 17:48:34	0|cfields|sipa: yep, same result on the aws instance I just fired up
 44 2018-06-06 17:50:31	0|cfields|sipa: the current avx2 path falls back to sse41 for single transforms, right? So presumably that benefits as well?
 45 2018-06-06 17:50:46	0|sipa|yup
 46 2018-06-06 17:50:57	0|sipa|cfields: ah, no
 47 2018-06-06 17:51:07	0|sipa|it falls back to sse41 for 4 elements
 48 2018-06-06 17:51:32	0|sipa|there is also an asm sse4 single implementation... but that's not using intrinsics, so won't benefit from -mavx
 49 2018-06-06 17:52:20	0|cfields|ah yes, ok
 50 2018-06-06 17:53:49	0|sipa|we should try to convert that sse4 asm code to intrinsics, though
 51 2018-06-06 17:53:54	0|cfields|so, how do you want to move forward? Seems to me it makes sense to compile different bundles, where all contents are built with the flags
 52 2018-06-06 17:55:21	0|sipa|i guess we can compile the same source file twice, with a different -D specific to that build, which changes the namespace name?
 53 2018-06-06 17:56:14	0|cfields|so for ex, libbitcoin_crypto-avx.a is sha256.cpp, sha256_sse41.cpp, etc. Just built with the avx flags...
 54 2018-06-06 17:56:20	0|cfields|right
 55 2018-06-06 17:57:57	0|cfields|ok. how about: I'll do the simple build changes, we can get shani and power8 in, then we can redo the structure
 56 2018-06-06 17:58:11	0|sipa|sounds good
 57 2018-06-06 17:58:24	0|cfields|ok, thanks for testing
 58 2018-06-06 18:01:34	0|sipa|cfields: these numbers are on an 7th gen i7 CPU
 59 2018-06-06 18:02:19	0|sipa|i'll also try on ryzen
 60 2018-06-06 18:03:43	0|cfields|ok. based on the other tests, I'd be perfectly happy with no-change there :)
 61 2018-06-06 18:05:49	0|gmaxwell|should figure out what AVX instruction's its substituting in...
 62 2018-06-06 18:07:01	0|sipa|gmaxwell: my assumption is that it's just using the higher 128 bits of the 256 registers as extra register space
 63 2018-06-06 18:07:35	0|cfields|gmaxwell: I did asm dumps of Round() split out, but don't speak enough asm to know what I'm looking at
 64 2018-06-06 18:07:40	0|cfields|I can paste those if you'd like
 65 2018-06-06 18:08:56	0|cfields|anything less focused than Round got too messy
 66 2018-06-06 18:12:10	0|sipa|cfields: on Ryzen: sse41 2.8ms, sse41 w/ -mavx 2.2ms, avx2 2.1ms
 67 2018-06-06 18:12:28	0|cfields|woohoo!
 68 2018-06-06 18:12:40	0|sipa|(Ryzen actually only has 4-way parallel arithmetic, so avx2 doesn't have that much of a gain)
 69 2018-06-06 18:12:47	0|cfields|interesting that it's almost the same as avx2
 70 2018-06-06 18:12:48	0|cfields|ah
 71 2018-06-06 18:14:03	0|jarthur|Yep, it's practically just "API compatible" with AVX2.
 72 2018-06-06 18:14:19	0|sipa|well it also gives you 256-bit registers
 73 2018-06-06 18:14:49	0|sipa|but i guess those exist at AVX already
 74 2018-06-06 18:16:34	0|jarthur|sipa: gmaxwell mentioned that zen might be able to do parallel sha-ni runs if each step is loaded up side by side. Do you know if anyone has played with that yet? I volunteered at some point but didn't get around to it.
 75 2018-06-06 18:17:36	0|sipa|jarthur: yup, 2-way SHA-NI is faster than 1-way on my system
 76 2018-06-06 18:17:48	0|jarthur|nice! Is that code in your branch atm?
 77 2018-06-06 18:17:51	0|sipa|yup
 78 2018-06-06 18:17:55	0|jarthur|rockin
 79 2018-06-06 18:18:09	0|sipa|(not quite 2x - the implementation needs 10 registers-ish, so 2-way needs 20, while there are only 16 addressable ones, resulting in spills)
 80 2018-06-06 18:18:36	0|sipa|IIRC it took a benchmark from 0.83ms to 0.61ms by doing the 2-way
 81 2018-06-06 18:18:59	0|jarthur|that's significant in bitcoin land
 82 2018-06-06 18:20:20	0|sipa|jarthur: https://github.com/sipa/bitcoin/blob/bb80ab25963f56cad9bb560e59c77d40f351901b/src/crypto/sha256_shani.cpp#L151
 83 2018-06-06 18:20:34	0|sipa|it just calls every round function twice in a row
 84 2018-06-06 18:21:37	0|jarthur|Thanks. Looks nice and clean with those inlines.
 85 2018-06-06 18:53:22	0|sipa|who is DrahtBot?
 86 2018-06-06 19:06:28	0|wumpus|sipa: MarcoFalke's bot
 87 2018-06-06 19:06:52	0|sipa|ah, nice
 88 2018-06-06 19:06:54	0|MarcoFalke|[ ] I'm not a robot
 89 2018-06-06 19:07:25	0|sipa|oh, i meant "who is running Drahtbot"
 90 2018-06-06 19:07:31	0|sipa|i did realize it was a bot :)
 91 2018-06-06 19:07:51	0|sipa|how does it figure out conflicts?
 92 2018-06-06 19:07:58	0|sipa|does it try every combination of 2 PRs?
 93 2018-06-06 19:16:51	0|MarcoFalke|sipa: Yes, rn. I might implement a smart solution when I have time. Though, the compute overhead is trivial compared to the latency by the github api for now...
 94 2018-06-06 19:25:27	0|MarcoFalke|> i did realize it was a bot :)
 95 2018-06-06 19:25:34	0|MarcoFalke|Thanks for the compliment :)
 96 2018-06-06 19:27:26	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #13408: crypto: cleanup sha256 build (06master...06sha2-cleanup) 02https://github.com/bitcoin/bitcoin/pull/13408
 97 2018-06-06 19:27:36	0|cfields|sipa: ^^
 98 2018-06-06 19:32:19	0|sipa|cfields: i'd rather keep the explicit -D... in the makefile for the arch specific crypto libs
 99 2018-06-06 19:32:42	0|sipa|rather than rely on config.h
100 2018-06-06 19:33:13	0|cfields|sipa: for what reason? We're already relying on config.h for endian/swap
101 2018-06-06 19:33:53	0|sipa|cfields: because different libs may be compiled with different flags
102 2018-06-06 19:34:02	0|sipa|(expecting the avx/sse4 split)
103 2018-06-06 19:35:57	0|cfields|sipa: hmm, I had a different approach in mind. But sure, I'll revert that and we can sha256 it out when we get there.
104 2018-06-06 19:38:12	0|jamesob|wumpus: how much more review does a bench-only change like #13219 need?
105 2018-06-06 19:38:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/13219 | bench: Add block assemble benchmark by MarcoFalke · Pull Request #13219 · bitcoin/bitcoin · GitHub
106 2018-06-06 19:39:39	0|MarcoFalke|jamesob: I guess it is fine, but just covered/hidden by a ton of other open pull requests.
107 2018-06-06 19:51:38	0|sipa|cfields: if you have a different idea, sure
108 2018-06-06 21:26:05	0|cfields|sipa: https://github.com/theuni/bitcoin/commits/sha2-libs
109 2018-06-06 21:26:31	0|cfields|that has the libs split out, rebuilt for each isn set, and adds avx
110 2018-06-06 21:27:35	0|cfields|and yea, i see your point now, we need to pass in a flag for the namespace
111 2018-06-06 21:45:13	0|jarthur|sipa cfields, are we going down the direction that optimal instruction set would be picked at runtime, and default b86_64 build would have the lot of them compiled?
112 2018-06-06 21:45:46	0|cfields|jarthur: yes. that's already the case, we're just diving deeper.
113 2018-06-06 21:49:52	0|jarthur|thanks