Bitcoin Core Github
43 subscribers
122K links
Download Telegram
💬 fanquake commented on pull request "refactor: modernize outdated trait patterns using helper aliases (C++14/C++17)":
(https://github.com/bitcoin/bitcoin/pull/31904#issuecomment-2728161946)
> As this is compile-time logic, i don't think this should actually affect the compiled code?

Yea, comparing the two branches only differs in version info in the binary.
🚀 fanquake merged a pull request: "refactor: modernize outdated trait patterns using helper aliases (C++14/C++17)"
(https://github.com/bitcoin/bitcoin/pull/31904)
💬 fanquake commented on pull request "[29.x] backports and rc2":
(https://github.com/bitcoin/bitcoin/pull/32062#issuecomment-2728233450)
Can also pull in https://github.com/bitcoin-core/gui/pull/858 (if not this rc than next).
📝 bigspider opened a pull request: "OP_CHECKCONTRACTVERIFY"
(https://github.com/bitcoin/bitcoin/pull/32080)
This is a first draft implementation of the `OP_CHECKCONTRACTVERIFY` (`CCV`) opcode.

`CCV` enables to build Script-based state machines that span across multiple transactions, by providing an ergonomic tool to commit to - and introspect - the Script and possibly some _data_ that is committed inside inputs or outputs.

Related to this PR:
- [Draft BIP specifications](https://github.com/bitcoin/bips/pull/1793).
- [Post on delving bitcoin](https://delvingbitcoin.org/t/op-checkcontractverify-
...
💬 bigspider commented on pull request "OP_CHECKCONTRACTVERIFY":
(https://github.com/bitcoin/bitcoin/pull/32080#issuecomment-2728360432)
I will look into the CI asap.
💬 fanquake commented on pull request "fuzz: Use serial task runner to increase fuzz stability":
(https://github.com/bitcoin/bitcoin/pull/31841#issuecomment-2728374587)
cc @marcofleon
💬 maflcko commented on pull request "qt: doc: adapt outdated binary paths to CMake changes":
(https://github.com/bitcoin-core/gui/pull/858#issuecomment-2728391524)
lgtm ACK 7ebc458a8cb994bc3c0c129da61353968d955bc2
💬 maflcko commented on pull request "qt: Add addressList field to SendCoinsRecipient for multiple addresses":
(https://github.com/bitcoin-core/gui/pull/857#issuecomment-2728394503)
Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits
💬 fanquake commented on pull request "build: align debugging flags to `-O0`":
(https://github.com/bitcoin/bitcoin/pull/29796#issuecomment-2728403796)
> Can you describe why you think it's important that they align?
💬 fanquake commented on pull request "doc: improve NODE_NETWORK_LIMITED documentation per BIP159":
(https://github.com/bitcoin/bitcoin/pull/31805#issuecomment-2728439567)
> Opened https://github.com/bitcoin/bips/pull/1768 and putting this in draft for now.

That has been merged.
💬 Prabhat1308 commented on pull request "test: Check datadir cleanup after assumeutxo was successful":
(https://github.com/bitcoin/bitcoin/pull/32033#issuecomment-2728473188)
re-ACK [`52482cb`](https://github.com/bitcoin/bitcoin/pull/32033/commits/52482cb24400f8c44ba9628aaaecb7c04b11beb2)
💬 maflcko commented on pull request "docs: fix typos":
(https://github.com/bitcoin/bitcoin/pull/32006#discussion_r1998121846)
this can probably be dropped completely. I'd guess it was written back when CI on open source was an fresh and possibly unknown concept. However, today, it seems common sense to require passing CI for all CI tasks, just like the code is required to compile on all supported build configs (even if they are not tested by CI). But the requirement that code must compile on all supported build configs isn't mentioned here either.

So, I'd say to either remove this (as it is common sense), or reword
...
👍 laanwj approved a pull request: "build: Drop option to disable hardening."
(https://github.com/bitcoin/bitcoin/pull/32071#pullrequestreview-2689416322)
Concept and code review ACK ecf2046d4b5c43ddf64f62f09cd3ed70dd5caafb
rationale: https://github.com/bitcoin/bitcoin/pull/32038#issuecomment-2717727013 https://github.com/bitcoin/bitcoin/pull/32038#issuecomment-2720530698
💬 maflcko commented on pull request "ci: [lint] Use Cirrus dockerfile cache":
(https://github.com/bitcoin/bitcoin/pull/31948#issuecomment-2728489736)
cc @willcl-ark
💬 Sjors commented on pull request "qt: doc: adapt outdated binary paths to CMake changes":
(https://github.com/bitcoin-core/gui/pull/858#issuecomment-2728501875)
utACK 7ebc458a8cb994bc3c0c129da61353968d955bc2
💬 Sjors commented on pull request "[29.x] backports and rc2":
(https://github.com/bitcoin/bitcoin/pull/32062#issuecomment-2728536081)
ACK f86997eb03d825b7c963adb1463ba83105628a74

I cherry-picked the pull requests, ran `gen-bitcoin-conf.sh` (built with ` -DWITH_ZMQ=ON`) and compared to this PR (minus the version bump commits).

I do get a slightly difference in `share/examples/bitcoin.conf`, maybe due to a build option?

```
-# estimatefee, http, i2p, ipc, leveldb, libevent, mempool,
+# estimatefee, http, i2p, ipc, leveldb, libevent, lock, mempool,
```
📝 fanquake opened a pull request: "depends: patch Qt rounding bugs"
(https://github.com/bitcoin/bitcoin/pull/32081)
When compiled under -O0, this code was causing runtime failures in the 32-bit Clang gui wallet tests. Work around that by importing a commit from upstream: https://github.com/qt/qtbase/commit/8c8b9a4173f4add522ec13de85107deba7c82da0.

Can be recreated with:
```bash
make -C depends/ DEBUG=1 CFLAGS="-O0" CXXFLAGS="-O0" HOST=i686-pc-linux-gnu
cmake -B build --toolchain /root/ci_scratch/depends/i686-pc-linux-gnu/toolchain.cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER='clang;-m32' -DCMAKE_CX
...
fanquake closed a pull request: "build: align debugging flags to `-O0`"
(https://github.com/bitcoin/bitcoin/pull/29796)
💬 fanquake commented on pull request "build: align debugging flags to `-O0`":
(https://github.com/bitcoin/bitcoin/pull/29796#issuecomment-2728537087)
> Can you describe why you think it's important that they align?

Mostly for more intuitive behaviour. I think this was more interesting when it was going to be -Og or -O1. Maybe the better approach is to discuss this (and the passing through of flags) further as part of #31920. I'll split out the Qt cherry-pick and close this PR. At least this has surfaced a couple bugs.
🤔 stratospher reviewed a pull request: "net: Only attempt v2->v1 transport downgrade if online"
(https://github.com/bitcoin/bitcoin/pull/32073#pullrequestreview-2689560351)
`fNetworkActive` doesn't indicate whether our node is online/offline - it's just a node specific option configured using RPC/GUI to enable/disable P2P network activity. So even with this patch, we'd still attempt for a v1 reconnection if we're trying to establish a v2 connection during the time period when our internet goes off :)

(Could you update the online/offline terminology in the PR?)

If we're attempting a v2 connection during the time period when the `fNetworkActive` option is toggl
...