< bitcoin-git>
[bitcoin] laanwj merged pull request #20267: Disable and fix tests for when BDB is not compiled (master...tests-opt-sqlite-bdb) https://github.com/bitcoin/bitcoin/pull/20267
< bitcoin-git>
bitcoin/master 3641597 Andrew Chow: tests: Don't make any wallets unless wallet is required
< bitcoin-git>
bitcoin/master b9b88f5 Andrew Chow: Skip legacy wallet reliant tests if BDB is not compiled
< bitcoin-git>
bitcoin/master 6f36242 Andrew Chow: tests: Set descriptors default based on compilation
< bitcoin-git>
[bitcoin] WillyTheCat opened pull request #21086: ResetBlockFailureFlags did not remove the invalidity flag in other chain (master...master) https://github.com/bitcoin/bitcoin/pull/21086
< bitcoin-git>
[bitcoin] Saibato opened pull request #21085: test: enable self.chain = 'main' to work in python bitcoin test framework (master...mainettests) https://github.com/bitcoin/bitcoin/pull/21085
< bitcoin-git>
[bitcoin] laanwj merged pull request #20646: doc: refer to BIPs 339/155 in feature negotiation (master...signet-keep-post-verack-sendaddrv2-peers) https://github.com/bitcoin/bitcoin/pull/20646
< bitcoin-git>
bitcoin/master 3931732 Wladimir J. van der Laan: Merge #20646: doc: refer to BIPs 339/155 in feature negotiation
< bitcoin-git>
bitcoin/master e1e6714 Jon Atack: doc: refer to BIPs 339/155 in feature negotiation
< sipa>
you're right of course that using the same key in schnorr and ecdsa should be discouraged (i personally expect it is not less secure than just ecdsa with that key, but i also don't think anyone has formally analyzed this)... but in the context of bitcoin script signing, this advice is sort of preempted by the fact that you shouldn't be reusing keys _at all_ for whatever purpose
< bitcoin-git>
[bitcoin] brunoerg opened pull request #21084: test: fix timeout decrease in feature_assumevalid (master...fix-timeout-assumevalid) https://github.com/bitcoin/bitcoin/pull/21084
< bitcoin-git>
[bitcoin] achow101 opened pull request #21083: wallet: Avoid requesting fee rates multiple times during coin selection (master...createtx-same-feerate) https://github.com/bitcoin/bitcoin/pull/21083
< gribble>
https://github.com/bitcoin/bitcoin/issues/20962 | Alter the ChaCha20Poly1305@Bitcoin AEAD to the new specification by jonasschnelli · Pull Request #20962 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #21080: fuzz: Configure check for main function (take 2) (master...2101-fuzzTake2) https://github.com/bitcoin/bitcoin/pull/21080
< jnewbery>
it's nice that we can export all the metadata into bitcoin-gh-metadata, but it's only moderately useful until there are other bug trackers/review platforms that can import it and reconstruct all of the cross-references.
< wumpus>
"works offline: in a plane or under the sea? Keep reading and writing bugs!" is nice, sure we can do this sort of by cloning bitcoin-gh-metadata but only in one way
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20715: util: Add ArgsManager::GetCommand() and use it in bitcoin-wallet (master...2012-argsCmd) https://github.com/bitcoin/bitcoin/pull/20715
< bitcoin-git>
bitcoin/master 7777105 MarcoFalke: refactor: Move all command dependend checks to ExecuteWalletToolFunc
< bitcoin-git>
[bitcoin] fanquake opened pull request #21078: guix: only download sources for hosts being built (master...guix_selective_download) https://github.com/bitcoin/bitcoin/pull/21078
< bitcoin-git>
[bitcoin] fanquake merged pull request #21065: build: make macOS HOST in download-osx generic (master...correct_host_download_osx) https://github.com/bitcoin/bitcoin/pull/21065
< bitcoin-git>
bitcoin/master 5f18080 fanquake: Merge #21065: build: make macOS HOST in download-osx generic
< bitcoin-git>
bitcoin/master f22a3ec fanquake: build: make macOS HOST in download-osx generic
< jonatack>
sorry, the irc channel is #bitcoin-core-pr-reviews
< jonatack>
hi cguida, thanks for having a look. the review club IRC channel is ##bitcoin-core-pr-reviews. would you like to open a pull request with your proposed edits here? at https://github.com/bitcoin-core-review-club/website
< sdaftuar>
cguida: #bitcoin-core-pr-reviews seems like the appropriate channel to comment, as i believe that's where the original discussion would have happened (and that's the irc home of the pr review club)
< luke-jr>
bitcoin-core/leveldb branch bitcoin-fork-new might be best to rename over bitcoin-fork or soemthing?
< bitcoin-git>
[bitcoin] Saibato opened pull request #21073: wallet: check when create wallets for the reserved name "wallets" (master...sanitycheck) https://github.com/bitcoin/bitcoin/pull/21073
< ghost43>
luke-jr: I have "rpcbind=0.0.0.0:8332" in bitcoin.conf, and passing "-rpcallowip=::/0" on CLI. it is all part of a non-trivial docker setup; so it is not actually exposed to the internet
< sanket1729>
Where libsecp256k1 library is built in bitcoin core build process? I can't find it in src/.libs
< miketwenty1>
Between Noon and 5 pm EST on March 30th (Tuesday).. There will be a remote speaking opportunity for a bitcoin core developer at a "Open Source 101" event. The idea would be someone who can explain about how the project is maintained, how people can contribute, why it's important, etc. Less about the bitcoin tech and more about the project and contribution to the project. I imagine history would also be a very interesting piece
< bitcoin-git>
[bitcoin] practicalswift opened pull request #21068: Add GitHub Codespaces integration to allow for easy onboarding of future generations of contributors (master...github-codespaces) https://github.com/bitcoin/bitcoin/pull/21068
< bitcoin-git>
[bitcoin] cdecker opened pull request #21056: rpc: Add a `-rpcwaittimeout` parameter to limit time spent waiting (master...rpcwait-timeout) https://github.com/bitcoin/bitcoin/pull/21056
< bitcoin-git>
[bitcoin] dongcarl opened pull request #21055: [Bundle 3/n] Prune remaining g_chainman usage in validation functions (master...2020-09-reduce-validation-ccsactiveglobal-usage) https://github.com/bitcoin/bitcoin/pull/21055
< bitcoin-git>
[bitcoin] theStack opened pull request #21053: rpc, test: document {previous,next}blockhash as optional (master...2021-rpc-test-document-previousnextblockhash-as-optional) https://github.com/bitcoin/bitcoin/pull/21053
< bitcoin-git>
[bitcoin] laanwj merged pull request #21026: doc: Document use of make-tag script to make tags (master...2021-01-make-tag) https://github.com/bitcoin/bitcoin/pull/21026
< bitcoin-git>
bitcoin/master 56fcf93 Wladimir J. van der Laan: Merge #21026: doc: Document use of make-tag script to make tags
< bitcoin-git>
bitcoin/master cc30dfb Wladimir J. van der Laan: doc: Document use of make-tag script to make tags
< bitcoin-git>
[gui] hebasto closed pull request #87: Choose monospaced font in C++ code rather in `*.ui` file (master...200910-mono) https://github.com/bitcoin-core/gui/pull/87
< bitcoin-git>
[gui] hebasto opened pull request #207: scripted-diff: Use Courier New as tabular figures font in Overview page (master...210201-mono) https://github.com/bitcoin-core/gui/pull/207
< bitcoin-git>
[bitcoin] laanwj merged pull request #20749: [Bundle 1/n] Prune g_chainman usage related to ::LookupBlockIndex (master...2020-09-libbitcoinruntime-v4) https://github.com/bitcoin/bitcoin/pull/20749
< bitcoin-git>
bitcoin/master eae54e6 Carl Dong: scripted-diff: Use BlockManager::LookupBlockIndex
< bitcoin-git>
bitcoin/master 15d20f4 Carl Dong: validation: Move LookupBlockIndex to BlockManager
< bitcoin-git>
bitcoin/master f92dc65 Carl Dong: validation: Guard the active_chainstate with cs_main
< bitcoin-git>
[bitcoin] practicalswift opened pull request #21041: log: Move "Pre-allocating up to position 0x[…] in […].dat" log message to debug category (master...pre-allocation-up-to-position-0xff-in-foo.dat) https://github.com/bitcoin/bitcoin/pull/21041
< Talkless>
Would "getwhitepaper [directory]" RPC for retrieving bitcoin.pdf (using https://bitcoinhackers.org/@jb55/105595146491662406 technique, working for pruned nodes) be considered "waste of reviewer time" ? :)
< bitcoin-git>
[gui] hebasto opened pull request #205: Save/restore TransactionView and recentRequestsView tables column sizes (master...210131-header) https://github.com/bitcoin-core/gui/pull/205
< dongcarl>
sipa: This is also why we can't just use the bitcoin-core package currently in Guix :-)
< sipa>
dongcarl: so is it fair to say that guix (and the binaries it builds) are all living in their own little world, and are unconventional in that they're all built to live the... but what we want for the bitcoin core release builds isn't so much building something that lives there, but using the guix-world stuff to build a "normal" binary?
< dongcarl>
roconnor: Right, nix and guix binaries both share this trait of doing the -rpath and setting a weird dynamic linker. Both these behaviours are thoroughly reverted in the Bitcoin Core guix build
< bitcoin-git>
[bitcoin] laanwj opened pull request #21026: doc: Document use of make-tag script to make tags (master...2021-01-make-tag) https://github.com/bitcoin/bitcoin/pull/21026
< luke-jr>
MarcoFalke: aha, it was a libevent dep for just bitcoin-tx builds
< warren>
There is a way however for users to opt-out of automatic distro upgrades. The .rpm distributed by bitcoincore.org would be identical to the package distributed by Fedora except the Epoch number is higher. That way the Fedora package will never be seen as "newer". It retains the property desired by Bitcoin Core project that nobody is forced into automatic upgrades.
< wumpus>
luke-jr: otoh if the guix trusted base is compromised so will the bitcoin core binaries
< aj>
MarcoFalke: bitcoin's not going in stream/rhel, surely
< warren>
1) Bitcoin Core switch to Guix for release builds (when possible ... Guix is missing some of the architectures?) I believe we want a replacement for what Gitian used to do including exporting a particular tag from git, naming and versioning the output tarballs, anything else?
< warren>
I will not be able to stop them from distributing not-deterministic Bitcoin Core for much longer.
< warren>
A bit concerning to me is Fedora is again approaching possible packaging and distribution of Bitcoin Core. While the openssl-based risk is now eliminated, I now intend to package Guix for Fedora and use that to make binary identical builds. I think I can handle the Fedora specific parts of this. But Guix for Bitcoin Core releases is still missing a few parts of what Gitian used to do?
< ariard>
but yeah libmultiprocess should be moved under bitcoin-core
< aj>
re 19160, it needs rebase? also is there any roadmap for libmultiprocessing, it's out of tree, but seems pretty bitcoin specific? has it really been reviewed much?
< warren>
Suggested Topic: A bit concerning to me is Fedora is again approaching possible packaging and distribution of Bitcoin Core. While the openssl-based risk is now eliminated, I now intend to package Guix for Fedora and use that to make binary identical builds. I think I can handle the Fedora specific parts of this. But Guix for Bitcoin Core releases is still missing a few parts of what Gitian used to do?