< bitcoin-git>
[bitcoin] fanquake closed pull request #19068: build: Use a zip instead of dmg for macOS releases (master...macdeploy_zip_instead_of_dmg) https://github.com/bitcoin/bitcoin/pull/19068
< jonasschnelli>
it's a short description of the "new" AEAD.
< jonasschnelli>
Tell me if you think it misses something (or edit the gist)
< wumpus>
didn't the fuzzers use to be one binary? i did prefer that approach for organizational reasons but we don't really want to go back and forth on this
< wumpus>
ah right so the point of difference is how to select the sub-fuzzer? say, a command line argument would be good, but not 'base it on the first bytes of the stream'
< sipa>
exactly
< wumpus>
okay :)
< sipa>
jonasschnelli: i think you've missed a part of the discussion
< sipa>
jonasschnelli: the idea was using chacha output itself to select the next key, which can be done super frequently as it is basically free (we were thinking ebery 4 KiB)
< sipa>
i forget now where that discussion was...
< jonasschnelli>
Ah. I see.
< jonasschnelli>
I remember seeing that...
< jonasschnelli>
I’ll update the gist
< wumpus>
achow101: i was slightly surprised to see low-level bdb parsing code in #18836, what's the reason we can't call out to say, `db_dump` instead?
< wumpus>
i don't really object to it, i guess the tests are controllable enough for this to work, i'm a litle bit worried about edge cases getting in the way here (resulting in debugging work for the tests instead of bitcoind itself)
< wumpus>
(and really not sure this is something to hold up one of the last PRs before the split-off on, but okay, I'm just wondering)
< jonasschnelli>
sipa: if the new key is just ChaCha output of the existing key-stream (and not hashing it with the session-ID [an ECDH-secret->hashed output]), wouldn't the construct be more prone to attacks on extracting the current ChaCha key?
< sipa>
jonasschnelli: i'm not sure that's a concern
< bitcoin-git>
[bitcoin] practicalswift opened pull request #20383: Avoid signed integer overflow and invalid integer negation when loading malformed mempool.dat files (master...signed-integer-malformed-mempool-dat-and-rpc) https://github.com/bitcoin/bitcoin/pull/20383
< achow101>
wumpus: I wasn' sure how to ensure that db_dump could be called. If you don't install bdb to the system, it won't be on the path. if you used the db4_install.sh script, it would be in some other dir. in depends builds, it would be in wherever the depends stuff is installed
< achow101>
then there's also the thing where people may have different bdb versions installed. e.g. db_dump for me is for 5.3, for 4.8 I have db4.8_dump
< achow101>
luke-jr: it only effects people building with msvc, which is very few
< * luke-jr>
shrugs
< wumpus>
achow101: ok, yes, sure, that would be some configuration difficulty
< achow101>
after #19137, the test could be rewritten to use the wallet tool
< jonatack>
a couple shout-outs: (a) my go-to chain for quick manual testing is now signet, because it has the fastest startup time by far (thanks kallewoof and aj!) and (b) bitcoinbuilds runs super quickly now since a couple days (thanks jonasschnelli!)
< bitcoin-git>
[bitcoin] mjdietzx opened pull request #20385: test: run mempool_spend_coinbase.py even with wallet disabled (master...mempool-tests-to-miniwallet) https://github.com/bitcoin/bitcoin/pull/20385
< luke-jr>
ugh, who made/reviewed the terrible API we have for createwallet? -.-