< bitcoin-git>
[bitcoin] bliotti opened pull request #19205: script: previous_release.sh rewritten in python (master...previous-release-py) https://github.com/bitcoin/bitcoin/pull/19205
< phantomcircuit>
currently the ScanForWalletTransactions function handles keypool TopUp implicitly, since it's checking every output with the Solver, i'd like to have the wallet set a flag when the keypool has been topped up and just do the entire scan again until it's not topping up anymore
< phantomcircuit>
for the current logic this wouldn't be good, but using block filter indexes with per node siphash parameters it wouldn't be that bad
< phantomcircuit>
doing this would make handling having different sets of filters much easier, that way i can just as the chain implementation for blocks it thinks match against a list of script pubkeys
< phantomcircuit>
instead of having all the chain walking logic in the wallet
< phantomcircuit>
MarcoFalke, ^ any opinion?
< phantomcircuit>
also i noticed that absolutely everything that calls ScanForWalletTransactions looks up the block hash by height just before calling it
< sipa>
phantomcircuit: if it's through CChain, that's O(1) thankfully
< phantomcircuit>
sipa, yeah just saying there's no reason for it to have the weird block_hash/block_height dual argument
< sipa>
ah
< phantomcircuit>
it also simplifies the handling of the reorg stuff if the first block can't be a reorg
< luke-jr>
trying to think of a case where you'd want to use a non-main-chain block, but can't :/
< bitcoin-git>
bitcoin/master 3e44210 Rod Vagg: Expose txinwitness for coinbase in JSON form
< bitcoin-git>
bitcoin/master 34645c4 Rod Vagg: Test txinwitness is accessible on coinbase vin
< bitcoin-git>
bitcoin/master 297466b MarcoFalke: Merge #18826: Expose txinwitness for coinbase in JSON form from RPC
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18826: Expose txinwitness for coinbase in JSON form from RPC (master...rvagg/txinwitness-for-coinbase) https://github.com/bitcoin/bitcoin/pull/18826
< bitcoin-git>
[bitcoin] hebasto opened pull request #19213: refactor: Replace RecursiveMutex with Mutex in Get{Data,Blocks}Dir() (master...200608-path-mx) https://github.com/bitcoin/bitcoin/pull/19213
< harding>
wumpus: FYI, I've heard from someone that they can't verify the releases because they have "weak-digest sha1" in their gpg.conf (based on a recommendation they heard from petertodd) and the release signing key is self-signed using sha1. I explained the situation to them, but long-term I think that's a reasonable option for people to be setting and so maybe it's time to update the release key to use a stronger digest.
< bitcoin-git>
[bitcoin] sipa opened pull request #19214: Auto-detect SHA256 implementation in benchmarks (master...202006_hw_sha_bench) https://github.com/bitcoin/bitcoin/pull/19214
< wumpus>
harding: sure, do you perhaps know how to do this?
< harding>
wumpus: I tried doing it several years ago, but I couldn't figure out how and ended up just creating a new key. :-(
< wumpus>
hmm generating a new release keys seems much worse
< harding>
wumpus: yeah, agreed. You can still sign the new release keys with the old release keys to create a clear trust path, but it's probably worth waiting to see if anyone reading this knows a way to just upgrade the existing key.
< wumpus>
looks like it should just be "gpg --cert-digest-algo sha512 --expert --edit-key", then "sign", going to try...
< harding>
wumpus: if that works and if you figured it out from just reading the manual page or doing a quick web search, I'm going to have hang my head in shame because I know I spent more than an hour researching this a couple years ago.
< phantomcircuit>
sipa, no idea why the auto detect is actually slower
< phantomcircuit>
definitely running a gcc old enough that the asm should beat the naive implementation significantly
< sipa>
phantomcircuit: if you run bitcoind, what gets reported in debug.log?
< sipa>
(it tells you which implementation is selected)
< sipa>
in one of the first output lines
< sipa>
2020-03-15T20:46:14.743702Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
< phantomcircuit>
Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
< sipa>
any particular configure flags or CXXFLAGS?
< harding>
wumpus: did you upload to keyserver.ubuntu.com? I still get a failure after running --refresh-keys from there.
< wumpus>
"gpg --fingerprint --check-sigs 0x90C8019E36C2E964" does show two self-signatures
< wumpus>
of course it doesn't show the algorithm used
< phantomcircuit>
i mean i just did `git clean -fdx && git checkout master && ./autogen.sh && ./configure --with-incompatible-bdb --without-gui && make -j4 && ./src/bench/bench_bitcoin --filter='(SHA256|Merkle).*'` and got the same result for master
< phantomcircuit>
which i see as b1b173994406158e5faa3c83b113da9d971ac104
< harding>
wumpus: ah, now it works for me and my friend also says it works. Thanks!
< harding>
(I had to request the specific key with --refresh-keys)
< phantomcircuit>
i'll clear ccache as well lets try this agian...
< wumpus>
"You can validate signatures are using non-SHA1 by using gpg --list-packets < SIGFILE, and checking that digest algo (aka hash algorithm) is not "2" (SHA1). For SHA512, you'd want "10" (see RFC4880 section 9.4 for details): " of course list-packets, of course
< sipa>
haha
< harding>
haha
< wumpus>
harding: great! thanks for checking
< sipa>
the gpg binary format is not too hard
< sipa>
it's probably easier to learn to read a hexdump than to learn gpg's command line options
< wumpus>
:-)
< sipa>
i have edited gpg files using hd, head & tail
< sipa>
phantomcircuit: i'm baffled
< phantomcircuit>
it's gonna end up being some insane ccache issue except my original master benchmark is before i had even checked out the pr
< phantomcircuit>
i swear i didn't mix them up either
< phantomcircuit>
i mean that's still kind of unreasonably fast for the naive implementation but at least they're in the right ratio?
< sipa>
that looks more reasonable
< sipa>
phantomcircuit: well whatever glitch happened on your CPU, if you figure it out you may want to inform intel that naive SHA256 code can beat a AVX2 parallel one :)
< phantomcircuit>
the weird thing is that i did the master benchmark before i checked out the pr
< phantomcircuit>
i checked my shell history to confirm that too
< phantomcircuit>
sipa, oh do any of the other benchmarks maybe end up calling something that would call the auto detect?
< sipa>
phantomcircuit: i don't think so
< phantomcircuit>
i'd like to basically start over on ScanForWalletTransactions and split it into a call to a chain interface method that returns a list of candidate blocks and logic to (optionally, but by default) rescan if anything in the keypool changed
< phantomcircuit>
as it stands the scanning logic can miss transactions if you use keypool keys out of order
< phantomcircuit>
(i doubt that's ever actually happened to anybody though)
< sipa>
phantomcircuit: how does that interact with work to make rescanning of all wallets happen simultaneously?
< phantomcircuit>
is there a pr or an issue describing the strategy for that? (i don't see any reason it would be incompatible)
< sipa>
no idea; just vaguely heard in mentioned
< luke-jr>
wumpus: did you manage to re-self-sign without SHA1?
< luke-jr>
wumpus: I did it a few years ago - maybe I can look up how I did it
< bitcoin-git>
[bitcoin] achow101 opened pull request #19215: psbt: Include and allow both non_witness_utxo and witness_utxo for segwit inputs (master...psbt-segwit-fixes) https://github.com/bitcoin/bitcoin/pull/19215