< bitcoin-git>
[bitcoin] fanquake merged pull request #22436: build: use aarch64 Clang if cross-compiling for darwin on aarch64 (master...arm64_macos_cross_clang) https://github.com/bitcoin/bitcoin/pull/22436
< bitcoin-git>
bitcoin/master 5c8820b fanquake: Merge bitcoin/bitcoin#22436: build: use aarch64 Clang if cross-compiling f...
< bitcoin-git>
bitcoin/master 54c7754 fanquake: build: use aarch64 Clang if cross-compiling for darwin on aarch64
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #22498: Check that CAddrMan::m_key is not null after deserialize (master...2107-addrmanKeyZero) https://github.com/bitcoin/bitcoin/pull/22498
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22455: addrman: detect on-disk corrupted nNew and nTried during unserialization (master...addrman_detect_negative) https://github.com/bitcoin/bitcoin/pull/22455
< bitcoin-git>
[bitcoin] achow101 opened pull request #22492: wallet: Reorder locks in dumpwallet to avoid lock order assertion (master...dumpwallet-lock-order) https://github.com/bitcoin/bitcoin/pull/22492
< roconnor>
hopefully the build of Bitcoin is independent of which version of guix you are using? Or maybe the specific bootstrap data is tied to guix versions, and that is what you are worried about?
< sipa>
so it's not very appealing to see them diverge further if more feature are added to miniscript, independently of bitcoin core's script code
< sipa>
and testing it is effectively dependent on being able to use bitcoin core's scripting engine
< sipa>
the miniscript c++ repository is currently somewhat in limbo; it works, but it heavily depends on code copied from bitcoin core
< michaelfolkson>
"I'd very much want to see it further along in integrating into Bitcoin Core" <- That sounded to me like you'd rather Miniscript was merged into Core before it supported Taproot
< sipa>
if integrated into bitcoin core, it'd be also easy to e.g. produce test sets using fuzzing, which could be tested in other implementations
< sipa>
and the Bitcoin Core wallet does support taproot scripts by the way, just only very limited ones (effectively just "<pubkey> OP_CHECKSIG")
< MarcoFalke>
> [09:43] <vasild> MarcoFalke: do you think that the fuzzer inputs from #22450 should be collected and added to bitcoin-core/qa-assets ?
< bitcoin-git>
[bitcoin] vasild opened pull request #22468: addrman: don't overwrite addr_info when resetting I2P ports (master...reset_i2p_ports_no_overwrite_pos) https://github.com/bitcoin/bitcoin/pull/22468
< vasild>
jnewbery: https://github.com/bitcoin/bitcoin/issues/22450#issuecomment-880602891 is a 3rd issue, I have not confirmed it yet, but read the comment: yes, it looks like it can cause a corruption, but again that is a 3rd distinct problem. I suspect it may be resolved by just removing "addr_info.GetPort() == I2P_SAM31_PORT"
< fanquake>
Guix is also a much more likely pathway to fully bootstrapable Bitcoin Core builds that what gitian could ever provide.
< fanquake>
These are just two very practical benefits that using Guix provides (there are more), which ultimately all boil down to us being in much greater control of our release build environment. Something I am very happy about, and I think makes a lot of sense for a project like Bitcoin Core.
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
< fanquake>
This means that as you use newer versions of glibc, the number of "workarounds" you need to maintain backwards compatibility pile up, get continually more complicated, and even start to leak out of Bitcoin Core code, and into our dependency system. See all the PRs linked in this comment: https://github.com/bitcoin/bitcoin/pull/22418#issuecomment-876379846.
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22381 | guix: Test security-check sanity before performing them (with macOS) by fanquake · Pull Request #22381 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] hebasto closed pull request #22456: [WIP] build: Use specific cross-compilers instead of multilib one (master...210715-multilib) https://github.com/bitcoin/bitcoin/pull/22456
< BlueMatt>
jonatack: I mean have y'all bothered to ask if people *are* vaccinated? In my experience among bitcoin *developers* its like 100%. among bitcoin twitter users its much different.
< laanwj>
we're getting even closer, the last PRs are nearly ready for merge https://github.com/bitcoin/bitcoin/milestone/47 , after which we should tag rc1 imo, but some last-minute issue came up while fuzzing addrman serialization (#22450)
< bitcoin-git>
[bitcoin] hebasto opened pull request #22456: [WIP] build: Use specific cross-compilers instead of multilib one (master...210715-multilib) https://github.com/bitcoin/bitcoin/pull/22456
< bitcoin-git>
[bitcoin] vasild opened pull request #22455: addrman: detect on-disk corrupted nNew and nTried during unserialization (master...addrman_detect_negative) https://github.com/bitcoin/bitcoin/pull/22455
< sipa>
and it's unrelated to the development of the bitcoin core software
< Bilnon>
what gets to me the most with acronyms like "uPoW" is how much these people take for granted the proof-of-work scheme used in bitcoin, like that useful proofs of work could be integrated at all without converting the entire system to a PoS system,
< Bilnon>
I dont know how these idiot get their papers published, this is a terrible idea written by morons who clearly cant grasp even the basic concepts of bitcoin
< bitcoin-git>
[bitcoin] jonatack opened pull request #22447: test: whitelist rpc_rawtransaction peers to speed up tests (master...speed-up-rpc_rawtransaction-test) https://github.com/bitcoin/bitcoin/pull/22447
< bitcoin-git>
[bitcoin] hebasto opened pull request #22446: test: Fix wallet_listdescriptors.py if bdb is not compiled (master...210714-desc) https://github.com/bitcoin/bitcoin/pull/22446
< bitcoin-git>
[bitcoin] sriramdvt opened pull request #22445: fuzz: Move implementations of non-template fuzz helpers from util.h to util.cpp (master...fuzz_move) https://github.com/bitcoin/bitcoin/pull/22445
< roconnor>
[Monday, June 28, 2021] [10:07:08 AM EDT] <real_or_random> https://github.com/bitcoin-core/secp256k1/pull/959 :O this had a red cirrus run (due to failed randomness tests), which scared me of for a second...
< bitcoin-git>
[bitcoin] fanquake opened pull request #22436: build: use aarch64 Clang if cross-compiling for darwin on aarch64 (master...arm64_macos_cross_clang) https://github.com/bitcoin/bitcoin/pull/22436
< laanwj>
if you want to fork bitcoin core, go ahead, i don't think it would be bad to have more projects at all, you'll also discover soon enough that maintaining a project like this is difficult