<Davidbak>
in `randomenv.cpp` a `memory_cleanse` is done (https://github.com/bitcoin/bitcoin/blame/master/src/randomenv.cpp#L92) for a vector full of Windows performance data. Why? (It doesn't seem security related to me, so I'm wondering about the philosophy. Note that at line 87 just above the vector is resized without cleansing the soon-to-be-freed data.)
<bitcoin-git>
[bitcoin] theuni opened pull request #23282: build: remove build stubs for external leveldb (master...no_external_leveldb) https://github.com/bitcoin/bitcoin/pull/23282
<bitcoin-git>
[bitcoin] theStack opened pull request #23281: test: check that bumpfee RPC fails for txs with descendants in mempool (master...202110-test-bumpfee_test_descendant_in_mempool) https://github.com/bitcoin/bitcoin/pull/23281
<shiza>
We should just report the problem to the packager, that's all. Whenever Bitcoin is important, they'll assign it to a packager handling less packages, and chance for sloppy upgrades will be smaller.
<luke-jr>
if LevelDB has a bug, that bug must NOT be fixed for Bitcoin.
<luke-jr>
shiza: LevelDB is consensus-critical code for Bitcoin. If it's being maintained without care for consensus, then it's not safe.
<luke-jr>
if they did, ordinary leveldb version bumps would not affect their bitcoin packages
<luke-jr>
Talkless: we've told distros time and time again, they can't just treat Bitcoin consensus deps like normal deps :/
<bitcoin-git>
[bitcoin] dongcarl opened pull request #23280: init: Coalesce Chainstate loading sequence between {,non-}unittest codepaths (master...2021-09-kernel-lib-v3) https://github.com/bitcoin/bitcoin/pull/23280
<bitcoin-git>
[bitcoin] laanwj merged pull request #23093: Add ability to flush keypool and always flush when upgrading non-HD to HD (master...202109_keypoolrefill) https://github.com/bitcoin/bitcoin/pull/23093
<bitcoin-git>
[bitcoin] fanquake opened pull request #23275: [22.x] Add historical & clean out 22.0 rel notess (22.x...clean_out_rel_notess) https://github.com/bitcoin/bitcoin/pull/23275
<gribble>
https://github.com/bitcoin/bitcoin/issues/23093 | Add ability to flush keypool and always flush when upgrading non-HD to HD by meshcollider · Pull Request #23093 · bitcoin/bitcoin · GitHub
2021-10-13
<bitcoin-git>
[bitcoin] hebasto closed pull request #22764: build: Include qt sources for parsing with extract_strings.py (master...210821-translation) https://github.com/bitcoin/bitcoin/pull/22764
<bitcoin-git>
[bitcoin] stratospher opened pull request #23271: crypto: Fix K1/K2 use in the comments in ChaCha20-Poly1305 AEAD (master...fix-k1-k2) https://github.com/bitcoin/bitcoin/pull/23271
<bitcoin-git>
[gui] laanwj opened pull request #454: qt: Use only Qt translation primitives in GUI code (master...2021-10-qt-use-at-translation) https://github.com/bitcoin-core/gui/pull/454
<bitcoin-git>
bitcoin/master 610a8a8 Carl Dong: test-*-check: Pass in *FLAGS and compile with them
<bitcoin-git>
bitcoin/master 8242ae2 fanquake: scripts: only parse the binary once in symbol-check.py
<bitcoin-git>
bitcoin/master 309eac9 fanquake: scripts: use LIEF for ELF checks in symbol-check.py
<bitcoin-git>
[bitcoin] laanwj merged pull request #23253: bitcoin-tx: Reject non-integral and out of range int strings (master...2110-utilTxSeqId) https://github.com/bitcoin/bitcoin/pull/23253
<bitcoin-git>
bitcoin/master 38fd709 fanquake: build: make --enable-werror just -Werror
<bitcoin-git>
bitcoin/master 39872f5 fanquake: Merge bitcoin/bitcoin#23149: build: make --enable-werror just -Werror
<sipa>
the same is true for other cryptographic constructs (e.g. ECDSA signatures contain big-endian serialized numbers, but from bitcoin's perspective, they're just byte arrays)
<sipa>
bitcoin historically treated all byte arrays as little-endian numbers
<Davidbak>
one more comment: i especially find the endianness issue funny for bitcoin because in addition to the usual on-the-wire format vs. internal representation issues you typically get bitcoin also has - for some unknown historical reason? - the issue of people _visualizing_ addresses/hashes/etc differently than the internal representation - how the heck did _that_ happen?
<Davidbak>
Huh. So the mainframe guys wanting to run bitcoin core on big iron might run into incompatibilities, eh?
<sipa>
davidbak: well, yes, i'm not lying when i say you and i, on our home desktop systems, on different linux distributions, with different versions of everything, will very realistically succeed in producing bit for bit identical bitcoin core binaries if you run the guix-based build system
<Davidbak>
how does the bitcoin build system give you that?
<fanquake>
There may be multiple solutions, but Bitcoin Core has had a solution to this problem for ~10 years now, and Guix is a good next step.
<Davidbak>
i do get all this - and plenty of people are working on reproducible builds, not just bitcoin - and it still isn't available out-of-the-box without work
<sipa>
bitcoin core contributors have contributed patches to various building/system tools to make sure nothing breaks the reproducibility
<Davidbak>
well reproducible builds are good for many reasons, bitcoin obviously depends on that for trust (and reliability of the consensus) but over the years there _have_ been other tools developed, that have gained traction in the overall C++ community, that address that well. As a newbie I AM NOT COMING IN AND CRITICIZING or saying "Why aren't you doing thing in this obvious better way, you old fogies!?" - but as a very long
<sipa>
for bitcoin core we really want reproducibility, because of the view that maintainers should be trusted the least amount possible
2021-10-12
<sipa>
also, this discussion is perhaps more appropriate for #bitcoin-core-builds
<sipa>
so it lets bitcoin core's build script (the contrib/guix/guix-build) instantiate an exactly specified build environment, with exact versions of compilers, dependencies, everything
<Davidbak>
ah! my use case wasn't _running_ bitcoin core (i've got _that_ set up) but building - a container that had all tools + dependencies would be sweet ...
<Davidbak>
speaking of which - is there a container already set up for building bitcoin core? I didn't spot anything like that at github.com/bitcoin or github.com/bitcoin-core
<Davidbak>
ok! that's the validation I wanted (because setting up GPG on my system might lead to running down a rathole I'd rather not do at the moment when I'm keen on getting the bitcoin core build running)
<bitcoin-git>
[bitcoin] brunoerg opened pull request #23267: test: bip125-replaceable in listsinceblock (master...2021-10-test-bip125-listsinceblock) https://github.com/bitcoin/bitcoin/pull/23267
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #23213: rest: Return error when header count is not integral (master...2110-restInt) https://github.com/bitcoin/bitcoin/pull/23213
<Guest99100>
michaelfolkson Thanks for the reply. I have noticed the Bitcoin-core-dev channel as well, though I have worked my way from old to new chats (Currently in 2015). Do you have any idea when the core team 'officially' switched from bitcoin-dev ti butcoin-core-dev?
<michaelfolkson>
Guest99100: I can't help with your missing logs but I'd recommend looking at the #bitcoin-core-dev log archives too if you haven't already. I suspect a lot of consensus discussions were on that channel as the separation between Core as an implementation and the protocol was potentially less understood/less recognized 5-6 years ago
<Guest99100>
Hi, I'm looking for someone to help me dig up old bitcoin-dev archives. I'm analyzing consensus change events in Bitcoin for a research project, and have realized that there is an important gap in the IRC logs that I'm looking at. The missing samples are mainly 2015-07-03, 2015-07-04 and 2015-07-05. I've gathered chat-logs in this period from
<bitcoin-git>
[bitcoin] hebasto closed pull request #20544: build: Do not repeat warning names in -Werror=... options (master...201202-werror) https://github.com/bitcoin/bitcoin/pull/20544
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #23253: bitcoin-tx: Reject non-integral and out of range sequence ids (master...2110-utilTxSeqId) https://github.com/bitcoin/bitcoin/pull/23253
<bitcoin-git>
[bitcoin] dougEfresh opened pull request #23249: util: ParseByteUnits - Parse a string with a suffix unit (master...util-parsebyteunit) https://github.com/bitcoin/bitcoin/pull/23249
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #22794: test: Verify if wallet is compiled in rpc_invalid_address_message.py test (master...split_invalid_address_message_test) https://github.com/bitcoin/bitcoin/pull/22794
<Davidbak>
ok. luke-jr - is "good first issues" still considered a good way to onboard to bitcoin-core development? And with or without the "PR Club" for getting tips?
<Davidbak>
I'm looking around after reading the "how to get involved" information - which points to "good first issue" issues. And one of the first ones there is #18222 - https://github.com/bitcoin/bitcoin/issues/18822
<bitcoin-git>
[bitcoin] theuni opened pull request #23226: c++20: Opt-in to modeling view and borrowed_range for Span (master...borrowed-span) https://github.com/bitcoin/bitcoin/pull/23226
2021-10-07
<jeremyrubin>
counterpoint, not getting segwit would have been pretty bad for bitcoin overall, no? should we let 'bullies' who don't want bitcoin to progress to roadblock the rest of the network? if we can't get an important upgrade in the face of bad actors, that sounds bad for bitcoin...
<jeremyrubin>
many changes to bitcoin core affect the consensus code
<jeremyrubin>
i think that leads to the way that we do soft forks for bitcoin being no more unsafe than other changes we make
<jeremyrubin>
tbh soft forks aren't particularly more or less dangerous than other changes we make to bitcoin
<michaelfolkson>
lightlike: I'm not sure whether the only way you get peer review is by marking it as "high priority for review" and a "blocker" on Bitcoin Core
<bitcoin-git>
[bitcoin] jonatack opened pull request #23223: Add NoLockLoggingTestingSetup to test utilities, use in checkqueue_tests (master...alleviate-checkqueue-tests-contention-logging) https://github.com/bitcoin/bitcoin/pull/23223
<bitcoin-git>
[bitcoin] jonatack opened pull request #23219: p2p: remove unneeded CNetAddr vector in LookupSubNet() and update/tidy up (master...LookupSubNet-todo-fix) https://github.com/bitcoin/bitcoin/pull/23219
<bitcoin-git>
[bitcoin] laanwj merged pull request #23196: util: Make syscall sandbox compilable with kernel 4.4.0 (master...2021-10-syscall-sandbox2) https://github.com/bitcoin/bitcoin/pull/23196
<bitcoin-git>
bitcoin/master 6334ff7 W. J. van der Laan: Merge bitcoin/bitcoin#23196: util: Make syscall sandbox compilable with ke...
<bitcoin-git>
[bitcoin] hebasto opened pull request #23217: [DO NOT MERGE] ci: Test required resources for native Windows tasks (master...211007-mem) https://github.com/bitcoin/bitcoin/pull/23217
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #23216: clang-format: Set BraceWrapping:AfterControlStatement:MultiLine (master...2110-srcFormat) https://github.com/bitcoin/bitcoin/pull/23216
<bitcoin-git>
[bitcoin] fanquake merged pull request #22890: doc: Replace a link to Qt precompiled binaries with compile instructions (master...210904-msvc) https://github.com/bitcoin/bitcoin/pull/22890
<bitcoin-git>
bitcoin/master c4139f0 Hennadii Stepanov: doc: Replace a link to Qt precompiled binaries with compile instructions
<bitcoin-git>
bitcoin/master 5e42f2a Hennadii Stepanov: build: Make <QtBaseDir> default name Qt and VS versions agnostic
<bitcoin-git>
bitcoin/master 6bc4398 Hennadii Stepanov: doc: Suggest using jom instead of nmake