<bitcoin-git>
[bitcoin] JeremyRand opened pull request #31206: doc: Use relative hyperlinks in release-process.md (master...doc-release-process-relative-links) https://github.com/bitcoin/bitcoin/pull/31206
<bitcoin-git>
[bitcoin] Abdulkbk opened pull request #31205: Improve lockunspent validation for vout (master...improve-lockunspent-validation) https://github.com/bitcoin/bitcoin/pull/31205
2024-11-02
<bitcoin-git>
qa-assets/main 41a2769 maflcko: Merge pull request #211 from marcofleon/main
<bitcoin-git>
qa-assets/main ae7fb7d marcofleon: Add inputs for txdownloadman txdownloadman_impl and clusterlin_depgraph_sim
<bitcoin-git>
[bitcoin] fanquake merged pull request #31187: ci: Do not error on unused-member-function in test each commit (master...2024-10-unused-methods-CI) https://github.com/bitcoin/bitcoin/pull/31187
<bitcoin-git>
bitcoin/master 54d07dd Sergi Delgado Segura: ci: Do not error on unused-member-function in test each commit
<bitcoin-git>
bitcoin/master 4a0251c merge-script: Merge bitcoin/bitcoin#31187: ci: Do not error on unused-member-function in...
<bitcoin-git>
[gui-qml] pablomartin4btc opened pull request #430: Allow IPv6 in Proxy settings and moving validation out from the UI into the model/ interface (main...qml-ipaddress-allow-ipv6) https://github.com/bitcoin-core/gui-qml/pull/430
<bitcoin-git>
[bitcoin] brunoerg opened pull request #31203: fuzz: fix `implicit-integer-sign-change` in wallet_create_transaction (master...2024-11-fuzz-fix-create-transaction) https://github.com/bitcoin/bitcoin/pull/31203
2024-10-31
<bitcoin-git>
[bitcoin] darosior opened pull request #31198: init: warn, don't error, when '-upnp' is set (master...2024_upnp_unbreak_gui) https://github.com/bitcoin/bitcoin/pull/31198
<cfields>
jonatack: the wgs are for Bitcoin Core the software project. Those are a different thing...
<josie>
personally, i think there should be an important distinction between BIPs (broader bitcoin ecosystem) and bitcoin core (implementation). if you are interested in running a bips irc channel / or a wg, id be happy to join tho, as im interested in both
<sipa>
that also seems like something that deserves discussion from a wider group than just bitcoin core contributors
<josie>
theres also a lot of interest outside of bitcoin core in implementing silent payments so we'll also be running a discord (ew) for other dev teams (bdk, ledger, rust-bitcoin, bitshala, electrs, etc) with the help of some folks from the bitcoin design community
<josie>
after that, ill be working on rebasing all of the bitcoin core PRs with help from novo__ (hes been working on a receiving PR with labels support for the bitcoin core wallet)
<gribble>
https://github.com/bitcoin/bitcoin/issues/1519 | GUI: change language selection format to "language - country (locale name)" by Diapolo · Pull Request #1519 · bitcoin/bitcoin · GitHub
<josie>
for silent payments, the focus is still the libsecp256k1 PR (bitcoin-core/secp256k1#1519)
<josie>
the main focus for us will be reproducibility, auditability, and determinism. once we have that nailed down, we will actually start using this to benchmark some existing PRs in bitcoin core
<dergoegge>
No real update today but i've created a irc channel: #bitcoin-core-fuzzing
<bitcoin-git>
[qa-assets] murchandamus opened pull request #210: Add fuzz corpus for wallet_create_transaction (main...Add-wallet_create_transaction) https://github.com/bitcoin-core/qa-assets/pull/210
<bitcoin-git>
[bitcoin] achow101 merged pull request #31166: key: clear out secret data in `DecodeExtKey` (master...202410-key-clear_out_secret_data_in_xprv_parser) https://github.com/bitcoin/bitcoin/pull/31166
<bitcoin-git>
bitcoin/master 559a8dd Sebastian Falbesoner: key: clear out secret data in `DecodeExtKey`
<bitcoin-git>
bitcoin/master 02be3dc Ava Chow: Merge bitcoin/bitcoin#31166: key: clear out secret data in `DecodeExtKey`
<pinheadmz>
settings set target.source-map build/src/src/ <path/to/...>/bitcoin/src/
<bitcoin-git>
[bitcoin] sr-gi opened pull request #31187: ci: Do not error on unused-member-function in test each commit (master...2024-10-unused-methods-CI) https://github.com/bitcoin/bitcoin/pull/31187
<jb55>
yeah may be subtle ram issue. will check. bitcoin is great at detecting subtle hw issues ... in the meantime I may try zfs snapshotting and hope it doesn't use too much extra space
<laanwj>
dviola: what kind of font issue? does it happen with self-compiled bitcoin-qt (i'd assume so, if you're using wayland backend) or with the binaries from the site?
<dviola>
bitcoin-qt is the only thing causing this issue on wayland for me
<dviola>
hebasto: just out of curiosity, do you happen to know if there is anything that could be causing the font issue with Qt5 bitcoin-qt? I noticed there are a few patches being removed/added in your branch and was wondering if those could have something to do with it
<bitcoin-git>
bitcoin/master af91834 glozow: [refactor] move ValidationInterface functions to TxDownloadManager
<bitcoin-git>
bitcoin/master f6c860e glozow: [doc] fix typo in m_lazy_recent_confirmed_transactions doc
<bitcoin-git>
[bitcoin] ismaelsadeeq opened pull request #31179: RPC: Add reserve member function to `UniValue` and use it in `getblock` RPC (master...10-2024-add-reserve-to-univalue) https://github.com/bitcoin/bitcoin/pull/31179
<dviola>
hebasto: hi, I just tested your branch on linux: https://github.com/hebasto/bitcoin/tree/240928-qt6 -- great work! I don't want to be pushy but is #30997 long way from being merged? I ask because Qt6 fixes a problem for me on Wayland so it would be nice to know, thanks! :-)
<bitcoin-git>
[bitcoin] stickies-v closed pull request #31149: tinyformat: enforce compile-time checks for format string literals (master...2024-10/remove-string-format-overload) https://github.com/bitcoin/bitcoin/pull/31149
<bitcoin-git>
[bitcoin] polespinasa opened pull request #31177: rpc, cli: return "verificationprogress" of 1 when up to date (master...verificationProgress) https://github.com/bitcoin/bitcoin/pull/31177
<bitcoin-git>
[bitcoin] hebasto opened pull request #31176: [POC] ci: Test cross-built Windows executables on Windows natively (master...241029-ci-win) https://github.com/bitcoin/bitcoin/pull/31176
<gmaxwell>
At the time bitcoin changed to the current model it was something like a 20x increase in validation speed. Though because the performance has a log(n) component, as the utxo set has grown the advantage shrinks.
<gmaxwell>
darosior: so for example, say as a whole bitcoin users decide to adopt a hardfork where miners can take coins but *only* take coins with some class of provably unspendable pubkeys. Your code isn't updated enough to know anything about that. But you're also not checking that. So you're potentially vulnerable but to maybe a narrower set of attack.
<gribble>
https://github.com/bitcoin/bitcoin/issues/30039 | dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate by maciejsszmigiero · Pull Request #30039 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/30039 | dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate by maciejsszmigiero · Pull Request #30039 · bitcoin/bitcoin · GitHub
<bitcoin-git>
[gui-qml] hebasto merged pull request #427: Introduce Signal Based Navigation Model to have Self-Contained Pages (main...contain-pages) https://github.com/bitcoin-core/gui-qml/pull/427
<bitcoin-git>
gui-qml/main 02a3b25 jarolrod: qml: use signal based navigation in settings with subpages
<bitcoin-git>
gui-qml/main fad9bd7 jarolrod: qml: signal based navigation in onboarding
<bitcoin-git>
gui-qml/main a77c7f1 jarolrod: qml: use signal based navigation in CreateWallet pages, introduce wizard
<achow101>
"Note that for blocks below the milestone (see below for terminology), Libbitcoin will skip transaction validation (besides checking they were properly committed, i.e. no malleation of either transactions or witnesses). This is in my opinion a similar threat model to Bitcoin Core’s -assumevalid." <-- that seems to be quite different?
2024-10-25
<bitcoin-git>
[bitcoin] darosior opened pull request #31157: Cleanups to port mapping module post UPnP dropt (master...2410_cleanups_post_upnp_drop) https://github.com/bitcoin/bitcoin/pull/31157
<bitcoin-git>
[bitcoin] mzumsande opened pull request #31156: test: Don't enforce BIP94 on regtest unless specified by arg (master...202410_bip94_arg) https://github.com/bitcoin/bitcoin/pull/31156
<laanwj>
jb55: likely a corrupt utxo set, running bitcoin with -reindex-chainstate will rebuild it
<bitcoin-git>
[gui-qml] jarolrod opened pull request #427: Introduce Signal Based Navigation Model to have Self-Contained Pages (main...contain-pages) https://github.com/bitcoin-core/gui-qml/pull/427
<bitcoin-git>
[bitcoin] jonatack closed pull request #31135: rpc, cli: return "verificationprogress" of 1 when up to date (master...2024-10-verification-progress) https://github.com/bitcoin/bitcoin/pull/31135
<gmaxwell>
I don't think it matters to me if there is some process seperation thing going on (though the latency of the extra serialization round trip might be unfortunate, but thats a benchmarking question). Just that you know it ought to be pratical to mine bitcoin in 'lottery mode' without depending on a trusted third party... and by pratical I mean without the side quest through broken mazes of
<BlueMatt[m]>
<laanwj> "if that isn't important, and one..." <- I think it’s both: IMO it’s a useful hedge for Bitcoin if the mining protocol people use is trivially moved to running over the wire (with cryptographic authentication), but also that no one is going to use it in the short term- it might suddenly become important overnight at some point but it’s hopefully not soon.
<sipa>
but also, this doesn't need to be set in stone, and the fact that it is making progress at all is far better than the opposite; the outcome could be miners/Sv2 stacks implementing this IPC mechanism directly; it could be a Sv2 sidecar binary built from and shipped with bitcoin core; it could even be something like that for some time, but eventually merged back directly
<sipa>
gmaxwell: FWIW, my view is that whatever we end up with is something that gets tested as part of Bitcoin Core's release process
<bitcoin-git>
[bitcoin] fanquake merged pull request #31148: ci: display logs of failed unit tests automatically (master...2024_ci_test_output) https://github.com/bitcoin/bitcoin/pull/31148
<gmaxwell>
except a p2pkh address, etc. So why would people using one instead of writing their mining infrastrcture against the bitcoin core IPC, skipping a step, source of failures, source of latency?
<bitcoin-git>
[bitcoin] maflcko opened pull request #31150: util: Treat Assume as Assert when evaluating at compile-time (master...2410-assume-stronger) https://github.com/bitcoin/bitcoin/pull/31150
<laanwj>
we'd like to document it for people that want to use it in an inter-process way on the same machine but not use the bitcoin core tool, for some reason
<BlueMatt[m]>
I also can't say I'm super jazzed about the entire bitcoin ecosystem having to support capnproto, but hey whatever, not really a huge deal (is it trivial to write a parser for it?)
<sipa>
i would have preferred sv2 directly in bitcoin-core-the-bitcoind-binary, but i understand the objections many contributors have raised; i think for supporting the mining ecosystem, having an external binary/process that implements sv2 that speaks this IPC, and talks the well-defined Sv2 protocol, and is released-with, and tested-against every version for bitcoind
<laanwj>
that's where Sv2 comes in, as a standard that goes beyond bitcoin core
<BlueMatt[m]>
achow101: right, like i mentioned in the original wall of text, I didn't weigh in particularly on that decision because that's a bitcoin core decision, not mine. however, it sounds like now the interface intends to be something that is stable/maintained.
<sipa>
BlueMatt[m]: my personal view is that i'd like a maintained sv2 implementation as part of the bitcoin core organization, and part of its releases, tested against bitcoin... whether or not that's built from the same codebase, whether or not that's written in the same language
<BlueMatt[m]>
achow101: that's somewhat nonsensical - if bitcoin core is defining a new protocol for work provisioning, there's no reason to have a different one
<achow101>
my recollection is that the sv2 stuff would still live under "Bitcoin Core" but not in the main repo
<BlueMatt[m]>
Finally, it’s worth noting that getblocktemplate actually has a BIP, but for some reason this new work isn’t even standardized anywhere, which strikes me as strange given Bitcoin core will definitely not be the not server for this so we really can’t just say “the interface is what Bitcoin Core provides”.
<BlueMatt[m]>
It seems that Bitcoin Core took a principled position that the remote-ability of this protocol doesn’t matter (which is a reasonable decision, the remote-ability of work-providing is a somewhat speculative feature, but one I think is worth having a decade down the line), but I’m not really sure why no one who’s spent time on mining work protocols was even consulted on such a major decision. Further, the fact that the one major
<BlueMatt[m]>
The second goal you can not - if it’s less efficient coming out of Bitcoin Core, no amount of proxying is going to fix that.
<BlueMatt[m]>
The first goal, of course, you can build with a proxy, though to do so now you're back to having to have two daemons to maintain and two protocols which is gonna limit adoption substantially. Ideally the protocol wouldn't be so trivially DoSable so that we can make it public by just using netcat or something which trivially wraps a local connection and provides cryptographic authentication (assuming Bitcoin Core doesn't provide that in
<BlueMatt[m]>
The whole point of the Sv2 JD server stuff was (a) to be remote-able (TCP + cryptographically authenticated) and (b) to be "push-based" ie let Bitcoin Core decide when to create new block templates and let it immediately push templates when it wants to do so (possibly even before updating the mempool by predicting the next block's contents in advance or in a parallel thread that can run without cs_main). This new protocol is neither,
<BlueMatt[m]>
So I’m really quite confused here, somehow we’ve ended up with Bitcoin Core NIHing a new work providing protocol, except without any of the features of the Sv2-defined one, which is borderline worse than getblocktemplate and where no one who works on mining stuff was consulted on the design of the new protocol.
<bitcoin-git>
[bitcoin] stickies-v opened pull request #31149: tinyformat: enforce compile-time checks for format string literals (master...2024-10/remove-string-format-overload) https://github.com/bitcoin/bitcoin/pull/31149
<gribble>
https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
<bitcoin-git>
[bitcoin] fanquake merged pull request #31141: doc: Make list of targets in depends README consistent (master...2024-10-depends-platforms) https://github.com/bitcoin/bitcoin/pull/31141
<bitcoin-git>
bitcoin/master 68f29b2 merge-script: Merge bitcoin/bitcoin#31141: doc: Make list of targets in depends README c...
<bitcoin-git>
bitcoin/master a0c9595 laanwj: doc: Make list of targets in depends README consistent
<bitcoin-git>
[bitcoin] l0rinc opened pull request #31144: optimization: pack util::Xor into 64 bit chunks instead of doing it byte-by-byte (master...l0rinc/optimize-xor) https://github.com/bitcoin/bitcoin/pull/31144