š¬ enirox001 commented on pull request "test: Replace legacy wallet with MiniWallet in rpc_getblockstats.py":
(https://github.com/bitcoin/bitcoin/pull/33184#discussion_r2399696431)
> This is basically testing that two results of `getblockstats` match each other. It doesn't actually determine the `expected_tip_stats` in the test and then compare against the actual result of `getblockstats`.
This is a good observation. I've reverted to using hardcoded expected values instead of circular getblockstats comparisons, ensuring the test validates actual correctness rather than just consistency.
(https://github.com/bitcoin/bitcoin/pull/33184#discussion_r2399696431)
> This is basically testing that two results of `getblockstats` match each other. It doesn't actually determine the `expected_tip_stats` in the test and then compare against the actual result of `getblockstats`.
This is a good observation. I've reverted to using hardcoded expected values instead of circular getblockstats comparisons, ensuring the test validates actual correctness rather than just consistency.
š ujok777 opened a pull request: "Create simpl2"
(https://github.com/bitcoin/bitcoin/pull/33527)
patches
(https://github.com/bitcoin/bitcoin/pull/33527)
patches
š¬ polespinasa commented on pull request "RPC: add sendrawtransactiontopeer":
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3362532664)
> Maybe it should just do validation then, and can be followed up by the raw send?
If this is the flow we want to follow then this PR is not necessary at all. We can already do that with `testmempoolaccept` and then `sendmsgtopeer`
> > Additionally, peer_id argument could take an array of ids and send the tx to multiple peers. (this is not implemented, but shouldn't be difficult to)
>
> Sounds like a job for batching.
Yeah that's why I didn't implement it in the first place, but it's
...
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3362532664)
> Maybe it should just do validation then, and can be followed up by the raw send?
If this is the flow we want to follow then this PR is not necessary at all. We can already do that with `testmempoolaccept` and then `sendmsgtopeer`
> > Additionally, peer_id argument could take an array of ids and send the tx to multiple peers. (this is not implemented, but shouldn't be difficult to)
>
> Sounds like a job for batching.
Yeah that's why I didn't implement it in the first place, but it's
...
š davidgumberg approved a pull request: "ci: remove 3rd party js from windows dll gha job"
(https://github.com/bitcoin/bitcoin/pull/32513#pullrequestreview-3296059963)
crACK 156927903d64297
Nice! Was bad that we were depending on 3rd party JS before this.
This branch also extends the executable manifest check to all binaries, which would have caught the missing manifest in #31375 which #32634 caught.
(https://github.com/bitcoin/bitcoin/pull/32513#pullrequestreview-3296059963)
crACK 156927903d64297
Nice! Was bad that we were depending on 3rd party JS before this.
This branch also extends the executable manifest check to all binaries, which would have caught the missing manifest in #31375 which #32634 caught.
š¬ willcl-ark commented on pull request "depends: static libxcb-cursor":
(https://github.com/bitcoin/bitcoin/pull/33434#issuecomment-3362609863)
(matching) Guix hashes from my x64 build:
```
⯠find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
cf7f86d91288477c11afdc767969d6b19b0ba1e62c73924e72b22a2527374653 guix-build-eca50854e1cb/output/aarch64-linux-gnu/SHA256SUMS.part
5afe50eb76079f96a5129b5e51e2ede657f10c5031abe24a875410f006c55511 guix-build-eca50854e1cb/output/aarch64-linux-gnu/bitcoin-eca50854e1cb-aarch64-linux-gnu-debug.tar.gz
ba6f7937c5d333e64560abcd95dbb
...
(https://github.com/bitcoin/bitcoin/pull/33434#issuecomment-3362609863)
(matching) Guix hashes from my x64 build:
```
⯠find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
cf7f86d91288477c11afdc767969d6b19b0ba1e62c73924e72b22a2527374653 guix-build-eca50854e1cb/output/aarch64-linux-gnu/SHA256SUMS.part
5afe50eb76079f96a5129b5e51e2ede657f10c5031abe24a875410f006c55511 guix-build-eca50854e1cb/output/aarch64-linux-gnu/bitcoin-eca50854e1cb-aarch64-linux-gnu-debug.tar.gz
ba6f7937c5d333e64560abcd95dbb
...
š willcl-ark approved a pull request: "depends: static libxcb-cursor"
(https://github.com/bitcoin/bitcoin/pull/33434#pullrequestreview-3296113693)
Code review ACK eca50854e1cb04e20478bd3df4762e18520a3611
I have not tested this on Ubuntu, but the changes look correct to me. After doing a guix build, I verified that the bitcoin-qt binary did not link to `libxcb-cursor`
```
⯠ldd bitcoin-eca50854e1cb/bin/bitcoin-qt
linux-vdso.so.1 (0x00007f4e3afa5000)
libfontconfig.so.1 => not found
libfreetype.so.6 => not found
libxkbcommon.so.0 => not found
libxkbcommon-x11.so.0 => not found
libxc
...
(https://github.com/bitcoin/bitcoin/pull/33434#pullrequestreview-3296113693)
Code review ACK eca50854e1cb04e20478bd3df4762e18520a3611
I have not tested this on Ubuntu, but the changes look correct to me. After doing a guix build, I verified that the bitcoin-qt binary did not link to `libxcb-cursor`
```
⯠ldd bitcoin-eca50854e1cb/bin/bitcoin-qt
linux-vdso.so.1 (0x00007f4e3afa5000)
libfontconfig.so.1 => not found
libfreetype.so.6 => not found
libxkbcommon.so.0 => not found
libxkbcommon-x11.so.0 => not found
libxc
...
š¬ theuni commented on pull request "RPC: add sendrawtransactiontopeer":
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3362707310)
> Overall sending a tx to multiple desired peers can be already done with `testmempoolaccept` + N * (`sendmsgtopeer`). IMHO is worth having it all with one RPC.
Strongly disagree. This seems like a case of feature creep to me. RPCs are easy to add and very tough to remove. If there were an issue with atomicity between calls or something, I might agree. But otherwise, chaining rpc calls sounds like the reasonable thing to do.
> Additionally, peer_id argument could take an array of ids and
...
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3362707310)
> Overall sending a tx to multiple desired peers can be already done with `testmempoolaccept` + N * (`sendmsgtopeer`). IMHO is worth having it all with one RPC.
Strongly disagree. This seems like a case of feature creep to me. RPCs are easy to add and very tough to remove. If there were an issue with atomicity between calls or something, I might agree. But otherwise, chaining rpc calls sounds like the reasonable thing to do.
> Additionally, peer_id argument could take an array of ids and
...
š¬ polespinasa commented on pull request "RPC: add sendrawtransactiontopeer":
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3362739329)
I'm closing the PR for lack of support. Thank you all for your time commenting and reviewing :)
> Allowing `sendmsgtopeer` to send to multiple peers (or a new rpc call to do so) would fill in the missing functionality without catering to a single use-case.
This approach makes sense to me as long as there are more network messages that might be worth sending to multiple peers. I might investigate that and if so open a PR with `sendmsgtopeer[M..N]` (probably a new rpc to keep backward compat
...
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3362739329)
I'm closing the PR for lack of support. Thank you all for your time commenting and reviewing :)
> Allowing `sendmsgtopeer` to send to multiple peers (or a new rpc call to do so) would fill in the missing functionality without catering to a single use-case.
This approach makes sense to me as long as there are more network messages that might be worth sending to multiple peers. I might investigate that and if so open a PR with `sendmsgtopeer[M..N]` (probably a new rpc to keep backward compat
...
ā
polespinasa closed a pull request: "RPC: add sendrawtransactiontopeer"
(https://github.com/bitcoin/bitcoin/pull/33507)
(https://github.com/bitcoin/bitcoin/pull/33507)
š¬ Rustix69 commented on issue "Use compact blocks while doing background validation":
(https://github.com/bitcoin/bitcoin/issues/33431#issuecomment-3362748510)
@maflcko @willcl-ark Hi, Iād like to work on enabling Compact Blocks after loading a snapshot and syncing to the chain tip, even when `assumetxoutset` is used. Please assign this to me. Thanks!
(https://github.com/bitcoin/bitcoin/issues/33431#issuecomment-3362748510)
@maflcko @willcl-ark Hi, Iād like to work on enabling Compact Blocks after loading a snapshot and syncing to the chain tip, even when `assumetxoutset` is used. Please assign this to me. Thanks!
š¬ polespinasa commented on issue "Use compact blocks while doing background validation":
(https://github.com/bitcoin/bitcoin/issues/33431#issuecomment-3362809710)
Hey @Rustix69 you can see a bit more context here:
https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2025-09-03#1756937607-1756942864;
https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2025-09-04#1756944505-1756998050;
(https://github.com/bitcoin/bitcoin/issues/33431#issuecomment-3362809710)
Hey @Rustix69 you can see a bit more context here:
https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2025-09-03#1756937607-1756942864;
https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2025-09-04#1756944505-1756998050;
š¬ Christewart commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3362837158)
One thing I noticed was the `getwalletinfo` RPC removed the fields `balance`, `immature_balance`, and `unconfirmed_balance` from the RPC result in 0ec255139be3745a135386e9db957fe81bc3d833. Is this worth a release note?
As a side note, it seems that [`walletversion`](https://github.com/bitcoin/bitcoin/blob/72c1f13c3374b23be6049a390b9d47748a495754/src/wallet/rpc/wallet.cpp#L43) might be able to be removed too as the comment indicates it has been deprecated and is related to now unsupported legac
...
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3362837158)
One thing I noticed was the `getwalletinfo` RPC removed the fields `balance`, `immature_balance`, and `unconfirmed_balance` from the RPC result in 0ec255139be3745a135386e9db957fe81bc3d833. Is this worth a release note?
As a side note, it seems that [`walletversion`](https://github.com/bitcoin/bitcoin/blob/72c1f13c3374b23be6049a390b9d47748a495754/src/wallet/rpc/wallet.cpp#L43) might be able to be removed too as the comment indicates it has been deprecated and is related to now unsupported legac
...
š¬ tehcmanmax commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3362924508)
> Moved the release date forward a week, as we still need to do at least an rc3.
Move it to the next year
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3362924508)
> Moved the release date forward a week, as we still need to do at least an rc3.
Move it to the next year
š¤ mzumsande reviewed a pull request: "RPC: add sendrawtransactiontopeer"
(https://github.com/bitcoin/bitcoin/pull/33507#pullrequestreview-3296600308)
`sendmsgtopeer` is a debug-only rpc originally meant only for tests. If we want it to be part of workflows from actual users, we should announce it in release notes (and maybe polish it up a bit).
(https://github.com/bitcoin/bitcoin/pull/33507#pullrequestreview-3296600308)
`sendmsgtopeer` is a debug-only rpc originally meant only for tests. If we want it to be part of workflows from actual users, we should announce it in release notes (and maybe polish it up a bit).
š glozow opened a pull request: "wallet: don't consider unconfirmed TRUC coins with ancestors"
(https://github.com/bitcoin/bitcoin/pull/33528)
Addresses https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3319935660
There is not an explicit check that the to-be-created wallet transaction would be within the {TRUC, normal} ancestor limits. This means that the wallet may create a transaction that violates these limits, but fail to broadcast it in `CommitTransaction`.
This appears to be expected behavior for the normal ancestor limits (and any other situation in which the wallet creates a tx that was rejected by mempool) an
...
(https://github.com/bitcoin/bitcoin/pull/33528)
Addresses https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3319935660
There is not an explicit check that the to-be-created wallet transaction would be within the {TRUC, normal} ancestor limits. This means that the wallet may create a transaction that violates these limits, but fail to broadcast it in `CommitTransaction`.
This appears to be expected behavior for the normal ancestor limits (and any other situation in which the wallet creates a tx that was rejected by mempool) an
...
š¬ glozow commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3363386699)
> If I create a tx3 that is a child of tx2 (all as v3 txs) the send command fails silently.
Thanks @monlovesmango!
Do you see this in your debug.log?
```
CommitTransaction(): Transaction cannot be broadcast immediately, TRUC-violation, tx <tx3> would have too many ancestors
```
If so, please see #33528
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3363386699)
> If I create a tx3 that is a child of tx2 (all as v3 txs) the send command fails silently.
Thanks @monlovesmango!
Do you see this in your debug.log?
```
CommitTransaction(): Transaction cannot be broadcast immediately, TRUC-violation, tx <tx3> would have too many ancestors
```
If so, please see #33528
š dergoegge approved a pull request: "[29.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/33474#pullrequestreview-3296841430)
ACK 2d7ebd2d913ea63c1a23fefa0a09ee06fb069161
(https://github.com/bitcoin/bitcoin/pull/33474#pullrequestreview-3296841430)
ACK 2d7ebd2d913ea63c1a23fefa0a09ee06fb069161
š¬ polespinasa commented on pull request "RPC: add sendrawtransactiontopeer":
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3363657228)
@mzumsande true.
Also I got some comments on X about it, proposing the new RPC call to recreate the whole `INV - GETDATA - TX` flow and not just send a `tx` message.
(https://github.com/bitcoin/bitcoin/pull/33507#issuecomment-3363657228)
@mzumsande true.
Also I got some comments on X about it, proposing the new RPC call to recreate the whole `INV - GETDATA - TX` flow and not just send a `tx` message.
š uluba9 opened a pull request: "Update .gitattributes"
(https://github.com/bitcoin/bitcoin/pull/33529)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
(https://github.com/bitcoin/bitcoin/pull/33529)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
ā
uluba9 closed a pull request: "Update .gitattributes"
(https://github.com/bitcoin/bitcoin/pull/33529)
(https://github.com/bitcoin/bitcoin/pull/33529)