<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
<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 ...
<sdaftuar>
specifically in https://corecheck.dev/bitcoin/bitcoin/pulls/31122, it reports MempoolEviction has slowed down, but for me I see no significant difference running on master versus my branch
<bitcoin-git>
[bitcoin] l0rinc opened pull request #31118: doc: replace `-?` with `-h` for bench_bitcoin help (master...l0rinc/bench-help) https://github.com/bitcoin/bitcoin/pull/31118
<gribble>
https://github.com/bitcoin/bitcoin/issues/22729 | Make it possible to disable Tor binds and abort startup on bind failure by vasild · Pull Request #22729 · bitcoin/bitcoin · GitHub
<bitcoin-git>
[bitcoin] achow101 closed pull request #30232: refactor: policy: Pass kernel::MemPoolOptions to IsStandard[Tx] rather than long list of individual options (master...refactor_mempoolopts) https://github.com/bitcoin/bitcoin/pull/30232
<bitcoin-git>
[bitcoin] achow101 closed pull request #29748: test: Makes `wait_for_getdata` delete data on checks, plus allows to check the getdata message type (master...202403-waitforgetdata-cleanup) https://github.com/bitcoin/bitcoin/pull/29748
<bitcoin-git>
[bitcoin] achow101 closed pull request #22693: RPC/Wallet: Add "use_txids" to output of getaddressinfo (master...getaddressinfo_txids) https://github.com/bitcoin/bitcoin/pull/22693
<bitcoin-git>
[bitcoin] achow101 closed pull request #30717: rpc: Add test-only RPCs under `-test=option` flag (master...feat-refactor_test_only_rpcs) https://github.com/bitcoin/bitcoin/pull/30717
<bitcoin-git>
[bitcoin] achow101 closed pull request #27331: refactor: extract CCheckQueue's data handling into a separate container "Bag" (master...2023-03-bag) https://github.com/bitcoin/bitcoin/pull/27331
<bitcoin-git>
[bitcoin] dergoegge opened pull request #31093: Introduce `g_fuzzing` global for fuzzing checks (master...2024-10-g_fuzz) https://github.com/bitcoin/bitcoin/pull/31093
<bitcoin-git>
[bitcoin] Av32000 closed pull request #31084: doc: Add xz-utils to the general dependencies for windows build (master...doc-windows-build-fix) https://github.com/bitcoin/bitcoin/pull/31084
<bitcoin-git>
[bitcoin] brunoerg closed pull request #28869: contrib: add test for bucketing with asmap (master...2023-11-asmap-stress) https://github.com/bitcoin/bitcoin/pull/28869
<bitcoin-git>
[bitcoin] Av32000 opened pull request #31084: doc: Add xz-utils to the general dependencies for windows build (master...doc-windows-build-fix) https://github.com/bitcoin/bitcoin/pull/31084
<bitcoin-git>
[bitcoin] furszy closed pull request #30385: [WIP] p2p: send not_found msgs for unknown, pruned or unwilling to share blocks (master...2024_p2p_notfound_block_v2) https://github.com/bitcoin/bitcoin/pull/30385
<bitcoin-git>
[bitcoin] ryanofsky closed pull request #31074: util: Check bilingual_str format strings at compile time (master...pr/bicheck) https://github.com/bitcoin/bitcoin/pull/31074
2024-10-11
<bitcoin-git>
[bitcoin] ryanofsky opened pull request #31074: util: Check bilingual_str format strings at compile time (master...pr/bicheck) https://github.com/bitcoin/bitcoin/pull/31074
<bitcoin-git>
[bitcoin] dergoegge opened pull request #31073: ci: Split out native fuzz jobs for macOS and windows (master...2024-10-native-fuzz) https://github.com/bitcoin/bitcoin/pull/31073
<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
<achow101>
/home/ava/bitcoin/bitcoin/musig2/src/pubkey.h:12:10: fatal error: secp256k1_musig.h: No such file or directory
<bitcoin-git>
[bitcoin] maflcko opened pull request #31067: test: Print CompletedProcess object on error (master...2410-test-print-err) https://github.com/bitcoin/bitcoin/pull/31067
<vasild>
see "## 3. Manually create a Bitcoin Core onion service" in doc/tor.md