< bitcoin-git> [bitcoin] practicalswift opened pull request #16143: tests: Mark unit test blockfilter_index_initial_sync as non-deterministic (master...non-determinism-in-blockfilter_index_initial_sync) https://github.com/bitcoin/bitcoin/pull/16143
< jonasschnelli> sipa: you once wrote some thoughts on an authentication scheme on top of the v2 encryption,... can't find that gist or link anymore. Still available?
< sipa> jonasschnelli: yes, we'll discuss the next days
< jonasschnelli> ack
< bitcoin-git> [bitcoin] mrwhythat opened pull request #16144: wallet: do not encrypt wallets with disabled private keys (master...encrypt-watchonly) https://github.com/bitcoin/bitcoin/pull/16144
< bitcoin-git> [bitcoin] promag opened pull request #16145: gui: Prevent idle sleep if in macos while in IBD (master...2019-06-prevent-idle-sleep-ibd) https://github.com/bitcoin/bitcoin/pull/16145
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d3a1c2502bb1...51858c57f0e2
< bitcoin-git> bitcoin/master 6f7f141 JeremyRand: Add riscv64 to outputs list in release-process.md
< bitcoin-git> bitcoin/master 51858c5 MarcoFalke: Merge #16139: Docs: Add riscv64 to outputs list in release-process.md
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #16139: Docs: Add riscv64 to outputs list in release-process.md (master...doc-release-process-riscv) https://github.com/bitcoin/bitcoin/pull/16139
< jeremyrubin> Minor resource usage question: for a good number of use cases, our SHA256 hashes really have no length extension vulnerabilities. Should we add a custom SHA256 hasher which doesn't add any padding? there are a number of use cases where this can reduce hashing by 1/2. E.g.: taggedhash in Taproot, both branches are 32 bytes, so we end up needing to hash two buffers, even though it's always 64 bytes. Or in ScriptCache lookups,
< jeremyrubin> the hash computed is salted and not publicly visible, so there's no real point in including 8 bytes of length info.
< jeremyrubin> this is, to be clear, a minor change similar to https://github.com/bitcoin/bitcoin/pull/13204 which is ultimately hard to benchmark an improvement on.
< jeremyrubin> There's also the compatibility burden of downstream projects having to add a new hash function if this were to be added.
< jeremyrubin> But I just thought it was worth mentioning for consideration
< sipa> jeremyrubin: yeah, i considered that for taproot as well
< sipa> but ultimately decided against it because of compatibility issues
< sipa> and for fixed-length data you can actually write a specialized version of sha256 that avoids a significant part of the last compression function run
< jeremyrubin> interesting, makes sense too.
< jeremyrubin> ultimately happens outside of validation though for taproot as well if the txn is seen before.
< jeremyrubin> Would be higher impact (and no compat issues) for the scriptcaches
< sipa> note that we have a SHA256D64 functions for specialized double-SHA256 of 64-byte input
< sipa> we can create similar ones of neede
< sipa> d