💬 Dorex45 commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3375633908)
V30 😃
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3375633908)
V30 😃
💬 janb84 commented on pull request "Clear out space on GHA jobs":
(https://github.com/bitcoin/bitcoin/pull/33514#issuecomment-3375647372)
> > A run applying to all jobs when using GHA can be seen here: https://github.com/willcl-ark/bitcoin/actions/runs/18274913987
>
> Looking there, it seems like the cleanup step can take up to 10 minutes to complete i.e. https://github.com/willcl-ark/bitcoin/actions/runs/18274913987/job/52024710440. Although I guess that is less of an issue if it's not running in this repo.
Ok I missed this in my review, I also have a slight preference to revert this to only apply to the CentOS job. I woul
...
(https://github.com/bitcoin/bitcoin/pull/33514#issuecomment-3375647372)
> > A run applying to all jobs when using GHA can be seen here: https://github.com/willcl-ark/bitcoin/actions/runs/18274913987
>
> Looking there, it seems like the cleanup step can take up to 10 minutes to complete i.e. https://github.com/willcl-ark/bitcoin/actions/runs/18274913987/job/52024710440. Although I guess that is less of an issue if it's not running in this repo.
Ok I missed this in my review, I also have a slight preference to revert this to only apply to the CentOS job. I woul
...
📝 maflcko opened a pull request: "build: Bump clang minimum supported version to 17"
(https://github.com/bitcoin/bitcoin/pull/33555)
(https://github.com/bitcoin/bitcoin/pull/33555)
💬 Sjors commented on pull request "wallet: allow skipping script paths":
(https://github.com/bitcoin/bitcoin/pull/32857#issuecomment-3375694837)
@rkrux I'm not too worried about reviews just yet, let's focus on getting https://github.com/bitcoin/bitcoin/pull/29675 in.
(https://github.com/bitcoin/bitcoin/pull/32857#issuecomment-3375694837)
@rkrux I'm not too worried about reviews just yet, let's focus on getting https://github.com/bitcoin/bitcoin/pull/29675 in.
👋 maflcko's pull request is ready for review: "build: Bump clang minimum supported version to 17"
(https://github.com/bitcoin/bitcoin/pull/33555)
(https://github.com/bitcoin/bitcoin/pull/33555)
💬 vasild commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#issuecomment-3375748629)
`dd32dfaaf3...69c015b258`: fix windows compilation
(https://github.com/bitcoin/bitcoin/pull/30988#issuecomment-3375748629)
`dd32dfaaf3...69c015b258`: fix windows compilation
👋 fanquake's pull request is ready for review: "[28.x] More backports"
(https://github.com/bitcoin/bitcoin/pull/33535)
(https://github.com/bitcoin/bitcoin/pull/33535)
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-3375858344)
`21efe8fa82...7d837fef28`: rebase due to conflicts; remove changes that were already merged via https://github.com/bitcoin/bitcoin/pull/33454
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-3375858344)
`21efe8fa82...7d837fef28`: rebase due to conflicts; remove changes that were already merged via https://github.com/bitcoin/bitcoin/pull/33454
🚀 fanquake merged a pull request: "[28.x] More backports"
(https://github.com/bitcoin/bitcoin/pull/33535)
(https://github.com/bitcoin/bitcoin/pull/33535)
💬 BenWestgate commented on pull request "doc: update multisig tutorial to use multipath descriptors":
(https://github.com/bitcoin/bitcoin/pull/33286#issuecomment-3375898948)
> The checksum for a descriptor without one can be computed using the `getdescriptorinfo` RPC. The response has the `descriptor` field, which is the descriptor with the checksum added.
This is not true for multi-path descriptors, we have to take the `checksum` field and append it to our input, similar to a private descriptor.
Should we document this?
(https://github.com/bitcoin/bitcoin/pull/33286#issuecomment-3375898948)
> The checksum for a descriptor without one can be computed using the `getdescriptorinfo` RPC. The response has the `descriptor` field, which is the descriptor with the checksum added.
This is not true for multi-path descriptors, we have to take the `checksum` field and append it to our input, similar to a private descriptor.
Should we document this?
💬 vasild commented on pull request "net: make m_nodes_mutex non-recursive":
(https://github.com/bitcoin/bitcoin/pull/32394#issuecomment-3375909395)
`aaa75c1a41...492be23a18`: rebase due to conflicts
(https://github.com/bitcoin/bitcoin/pull/32394#issuecomment-3375909395)
`aaa75c1a41...492be23a18`: rebase due to conflicts
💬 vasild commented on pull request "i2p: make a time gap between creating transient sessions and using them":
(https://github.com/bitcoin/bitcoin/pull/32065#issuecomment-3375937098)
`fc1ba52a4d...539d8b474e`: rebase due to conflicts
(https://github.com/bitcoin/bitcoin/pull/32065#issuecomment-3375937098)
`fc1ba52a4d...539d8b474e`: rebase due to conflicts
💬 vasild commented on pull request "net: replace manual reference counting of CNode with shared_ptr":
(https://github.com/bitcoin/bitcoin/pull/32015#issuecomment-3376001564)
`d026d5475e...abc29c4d8b`: rebase due to conflicts
(https://github.com/bitcoin/bitcoin/pull/32015#issuecomment-3376001564)
`d026d5475e...abc29c4d8b`: rebase due to conflicts
⚠️ fanquake opened an issue: "build: `libcapnp*.so` "warning: GCS is required by -z gcs, but this shared library lacks the necessary property note.""
(https://github.com/bitcoin/bitcoin/issues/33556)
Building master (919e6d01e93a57d991ed456bc67c43605583ada8) in a Ubuntu 25.10 container (on aarch64), I see:
```bash
[ 1%] Linking CXX executable mpgen
/usr/lib/aarch64-linux-gnu/libcapnp-rpc-1.1.0.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libcapnpc-1.1.0.so: warning: GCS is requi
...
(https://github.com/bitcoin/bitcoin/issues/33556)
Building master (919e6d01e93a57d991ed456bc67c43605583ada8) in a Ubuntu 25.10 container (on aarch64), I see:
```bash
[ 1%] Linking CXX executable mpgen
/usr/lib/aarch64-linux-gnu/libcapnp-rpc-1.1.0.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libcapnpc-1.1.0.so: warning: GCS is requi
...
💬 fanquake commented on issue "build: `libcapnp*.so` "warning: GCS is required by -z gcs, but this shared library lacks the necessary property note."":
(https://github.com/bitcoin/bitcoin/issues/33556#issuecomment-3376045494)
cc @Sjors @ryanofsky.
(https://github.com/bitcoin/bitcoin/issues/33556#issuecomment-3376045494)
cc @Sjors @ryanofsky.
💬 vasild commented on pull request "RPC: add sendrawtransactiontopeer":
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3376091752)
This looked like an easy way for users to unintentionally dox themselves. Why would one want to send their transaction to a given peer(s) only and not to all like `sendrawtransaction` RPC?
1. To obfuscate the transaction origin? Doing this properly is more involved, see [#29415](https://github.com/bitcoin/bitcoin/pull/29415) which does exactly that. If we would add an assumption that there is a known trusted peer which is ok to know the transaction origin, then one might as well connect just
...
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3376091752)
This looked like an easy way for users to unintentionally dox themselves. Why would one want to send their transaction to a given peer(s) only and not to all like `sendrawtransaction` RPC?
1. To obfuscate the transaction origin? Doing this properly is more involved, see [#29415](https://github.com/bitcoin/bitcoin/pull/29415) which does exactly that. If we would add an assumption that there is a known trusted peer which is ok to know the transaction origin, then one might as well connect just
...
📝 fanquake opened a pull request: "[28.x] 28.3rc2"
(https://github.com/bitcoin/bitcoin/pull/33557)
Backports:
* #33482
Plus final changes for a `28.3rc2`.
(https://github.com/bitcoin/bitcoin/pull/33557)
Backports:
* #33482
Plus final changes for a `28.3rc2`.
💬 fanquake commented on pull request "contrib: fix macOS deployment with no translations":
(https://github.com/bitcoin/bitcoin/pull/33482#issuecomment-3376135903)
Backported to `28.x` in #33557.
(https://github.com/bitcoin/bitcoin/pull/33482#issuecomment-3376135903)
Backported to `28.x` in #33557.
💬 hebasto commented on pull request "build: Bump clang minimum supported version to 17":
(https://github.com/bitcoin/bitcoin/pull/33555#issuecomment-3376204721)
> (Apart from dropping the small workaround, this bump allows the `ci_native_nowallet_libbitcoinkernel` CI to run on riscv64 without running into an ICE with clang-16.)
Is there an open issue for this?
(https://github.com/bitcoin/bitcoin/pull/33555#issuecomment-3376204721)
> (Apart from dropping the small workaround, this bump allows the `ci_native_nowallet_libbitcoinkernel` CI to run on riscv64 without running into an ICE with clang-16.)
Is there an open issue for this?
📝 maflcko opened a pull request: "ci: Use native platform for win-cross task"
(https://github.com/bitcoin/bitcoin/pull/33558)
Forcing the architecture to amd64 is no longer required. Dropping it should have some benefits:
* Faster CI speed on other arches (riscv64, arm, ...)
* Unlock the CI task to run on riscv64 at all
(https://github.com/bitcoin/bitcoin/pull/33558)
Forcing the architecture to amd64 is no longer required. Dropping it should have some benefits:
* Faster CI speed on other arches (riscv64, arm, ...)
* Unlock the CI task to run on riscv64 at all