<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 f6c860e glozow: [doc] fix typo in m_lazy_recent_confirmed_transactions doc
<bitcoin-git>
bitcoin/master af91834 glozow: [refactor] move ValidationInterface functions to TxDownloadManager
<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 fad9bd7 jarolrod: qml: signal based navigation in onboarding
<bitcoin-git>
gui-qml/main 02a3b25 jarolrod: qml: use signal based navigation in settings with subpages
<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 a0c9595 laanwj: doc: Make list of targets in depends README consistent
<bitcoin-git>
bitcoin/master 68f29b2 merge-script: Merge bitcoin/bitcoin#31141: doc: Make list of targets in depends README c...
<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
<bitcoin-git>
[bitcoin] danielabrozzoni closed pull request #31065: rest: Support transaction broadcast in REST interface (master...20241008_rest_broadcast) https://github.com/bitcoin/bitcoin/pull/31065
<sipa>
is there anything else i need to do to make bitcoin core "find" the libmultiprocess, that you know?
<bitcoin-git>
[bitcoin] mzumsande opened pull request #31142: test: fix intermittent failure in p2p_seednode.py, don't connect to random IPs (master...202410_seednode_error) https://github.com/bitcoin/bitcoin/pull/31142
<bitcoin-git>
[bitcoin] laanwj opened pull request #31141: doc: Make list of targets in depends README consistent (master...2024-10-depends-platforms) https://github.com/bitcoin/bitcoin/pull/31141
<zzz123>
i want bitcoin to be the global reserve currency but if i keep finding loads of dos exploits it isn't practical
<zzz123>
the only thing suboptimal is the fact that pinging faster than you can pong crashes bitcoin on recommended spec machines
2024-10-22
<bitcoin-git>
[bitcoin] jonatack opened 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
<bitcoin-git>
[bitcoin] andrewtoth closed pull request #31102: Don't wipe coins cache when full and instead evict LRU clean entries (master...prune-cache) https://github.com/bitcoin/bitcoin/pull/31102
<gribble>
https://github.com/bitcoin/bitcoin/issues/31133 | net: Tor service target port collides when running multiple nodes, making bitcoind error out · Issue #31133 · bitcoin/bitcoin · GitHub
<bitcoin-git>
[bitcoin] Jessiejaymz810s closed pull request #31128: Pending changes exported from your codespace (master...codespace-studious-train-xjj599jwjjvc6g99) https://github.com/bitcoin/bitcoin/pull/31128
<bitcoin-git>
[bitcoin] Jessiejaymz810s opened pull request #31128: Pending changes exported from your codespace (master...codespace-studious-train-xjj599jwjjvc6g99) https://github.com/bitcoin/bitcoin/pull/31128
<blackhat1337>
hood with bitcoin dos. otherwise they'd be patched. idiots.
<padillac>
so here's the deal - patch the exploit or archive the repo. until uptime (remote orphan witchcraft) is solved, if it can be in the face of massive botnets - bitcoin can never, ever - ever - be a global reserve asset. it isn't bulletproof whatsoever. people are fucking religious about exploitable software and assume it's a magical thing when it's
<padillac>
bitcoin-core/blockstream is probably mad because i've been a dick to them like 12 times
<bitcoin-git>
[bitcoin] fanquake opened pull request #31125: depends: add *FLAGS to gen_id (master...external_flags_plus_linker_cache) https://github.com/bitcoin/bitcoin/pull/31125
<bitcoin-git>
[bitcoin] fanquake merged pull request #26334: Add Signet and testnet4 launch shortcuts for Windows (master...2022/10/windows-signet) https://github.com/bitcoin/bitcoin/pull/26334
<bitcoin-git>
bitcoin/master 77b2923 Sjors Provoost: Add Signet launch shortcut for Windows
<bitcoin-git>
bitcoin/master cfd03de Sjors Provoost: Add Testnet4 launch shortcut for Windows
<bitcoin-git>
bitcoin/master 6848739 merge-script: Merge bitcoin/bitcoin#26334: Add Signet and testnet4 launch shortcuts for ...