💬 achow101 commented on pull request "Dialog for allowing the user to choose the change output when bumping a tx":
(https://github.com/bitcoin-core/gui/pull/700#issuecomment-2394515614)
Rebased and fixed the build issue in the first commit.
(https://github.com/bitcoin-core/gui/pull/700#issuecomment-2394515614)
Rebased and fixed the build issue in the first commit.
💬 tdb3 commented on pull request "rpc: add getorphantxs":
(https://github.com/bitcoin/bitcoin/pull/30793#discussion_r1788275942)
I would support either, with the latter being my preference (at least initially/in transition)
(https://github.com/bitcoin/bitcoin/pull/30793#discussion_r1788275942)
I would support either, with the latter being my preference (at least initially/in transition)
💬 0xB10C commented on issue "Prioritize processing of peers based on their CPU usage":
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2394709587)
Interesting idea - I remember that we briefly chatted about this a while ago.
How does this behave during e.g. IBD when a "good" peer sends us a bunch of blocks and we spent a lot of CPU time validating them? Does something like this need to be excluded? I guess it's similar for peers that constantly send us transactions we don't know about yet (maybe because they are just better connected or they are broadcasting them) - not sure if we want to process their messages slower.
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2394709587)
Interesting idea - I remember that we briefly chatted about this a while ago.
How does this behave during e.g. IBD when a "good" peer sends us a bunch of blocks and we spent a lot of CPU time validating them? Does something like this need to be excluded? I guess it's similar for peers that constantly send us transactions we don't know about yet (maybe because they are just better connected or they are broadcasting them) - not sure if we want to process their messages slower.
💬 hodlinator commented on pull request "descriptor: Add proper Clone function to miniscript::Node":
(https://github.com/bitcoin/bitcoin/pull/30866#discussion_r1788379490)
The PR description asserts:
> Multipath descriptors requires performing a deep copy
Would be happy if you cared to add an elaboration on why that is.
It seemed to me like it should be safe to just have another `shared_ptr` point to the same `const Node`. Unless something on the outside could own a non-const reference into the node hierarchy and mutate it that way? In that case maybe it would be more robust for the `MiniscriptDescriptor`-ctor to be the one ensuring it holds a unique refere
...
(https://github.com/bitcoin/bitcoin/pull/30866#discussion_r1788379490)
The PR description asserts:
> Multipath descriptors requires performing a deep copy
Would be happy if you cared to add an elaboration on why that is.
It seemed to me like it should be safe to just have another `shared_ptr` point to the same `const Node`. Unless something on the outside could own a non-const reference into the node hierarchy and mutate it that way? In that case maybe it would be more robust for the `MiniscriptDescriptor`-ctor to be the one ensuring it holds a unique refere
...
💬 russeree commented on pull request "Enhanced error messages for invalid network prefix during address parsing.":
(https://github.com/bitcoin/bitcoin/pull/27260#discussion_r1788394254)
> [7478ac6](https://github.com/bitcoin/bitcoin/commit/7478ac6af922c302e292ace7f61e6eaa461da727): this change belongs in the previous commit [07f9733](https://github.com/bitcoin/bitcoin/commit/07f9733e6022d77d755321914a2a2a1dd7ce0d59)
>
> (One way to move it there is by doing `git rebase -i HEAD~3`, setting "e" for the first commit, and then add these lines. Then you do a `git commit -a --amend` to update the first commit. Then `git rebase --continue`, which should automatically adjust the sec
...
(https://github.com/bitcoin/bitcoin/pull/27260#discussion_r1788394254)
> [7478ac6](https://github.com/bitcoin/bitcoin/commit/7478ac6af922c302e292ace7f61e6eaa461da727): this change belongs in the previous commit [07f9733](https://github.com/bitcoin/bitcoin/commit/07f9733e6022d77d755321914a2a2a1dd7ce0d59)
>
> (One way to move it there is by doing `git rebase -i HEAD~3`, setting "e" for the first commit, and then add these lines. Then you do a `git commit -a --amend` to update the first commit. Then `git rebase --continue`, which should automatically adjust the sec
...
💬 russeree commented on pull request "Enhanced error messages for invalid network prefix during address parsing.":
(https://github.com/bitcoin/bitcoin/pull/27260#issuecomment-2394760664)
> Re last commit message, you can leave this out:
>
> > A complete refactor of the previous pull to simplify logic and reduce the
> > chance of technical debt.
This has been removed.
(https://github.com/bitcoin/bitcoin/pull/27260#issuecomment-2394760664)
> Re last commit message, you can leave this out:
>
> > A complete refactor of the previous pull to simplify logic and reduce the
> > chance of technical debt.
This has been removed.
💬 fjahr commented on issue "assumeutxo: not syncing the snapshot chainstate":
(https://github.com/bitcoin/bitcoin/issues/30971#issuecomment-2394768306)
> If this gets to the point that the snapshot load completes, I'll close this.
I don't think we have to close this right away, we can keep this open for a few more weeks to see if this issue occurs for other users. Having an open issue already makes it easier for people to engage. But did loading of the snapshot actually complete eventually @fanquake ?
I am currently looking into the obfuscation key because I find it suspicious that it changes for `chainstate_snapshot`. From my understand
...
(https://github.com/bitcoin/bitcoin/issues/30971#issuecomment-2394768306)
> If this gets to the point that the snapshot load completes, I'll close this.
I don't think we have to close this right away, we can keep this open for a few more weeks to see if this issue occurs for other users. Having an open issue already makes it easier for people to engage. But did loading of the snapshot actually complete eventually @fanquake ?
I am currently looking into the obfuscation key because I find it suspicious that it changes for `chainstate_snapshot`. From my understand
...
🤔 promag reviewed a pull request: "qt6: Handle different signatures of `QANEF::nativeEventFilter`"
(https://github.com/bitcoin-core/gui/pull/840#pullrequestreview-2349357223)
I think small changes to make code compatible with both versions are fine until support for qt5 is dropped.
Code review ACK 80761afced12c774a1768fb27a3975d456981ae0.
Alternative is to use type alias
```cpp
#if (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0))
using result_t = qintptr*;
#else
using result_t = long*;
#endif
(https://github.com/bitcoin-core/gui/pull/840#pullrequestreview-2349357223)
I think small changes to make code compatible with both versions are fine until support for qt5 is dropped.
Code review ACK 80761afced12c774a1768fb27a3975d456981ae0.
Alternative is to use type alias
```cpp
#if (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0))
using result_t = qintptr*;
#else
using result_t = long*;
#endif
💬 hebasto commented on pull request "build: Switch to Qt 6":
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2394777591)
Guix builds for the recent push:
- `aarch64`:
```
ad3093fa02114e2ec80b54312ff0df232893dc73395630c3d7fdb34d7fe79d83 guix-build-b0322c462106/output/aarch64-linux-gnu/SHA256SUMS.part
d0b95a6538bb8ad217dcbf6cf481d9849d8a9b0c40ca18717cd3594087a5a5a5 guix-build-b0322c462106/output/aarch64-linux-gnu/bitcoin-b0322c462106-aarch64-linux-gnu-debug.tar.gz
d85f9ce2e9ffb310d55fcc4b9755a52d33935bb742f460fc7b6b74b61bad35a3 guix-build-b0322c462106/output/aarch64-linux-gnu/bitcoin-b0322c462106-aarch64-lin
...
(https://github.com/bitcoin/bitcoin/pull/30997#issuecomment-2394777591)
Guix builds for the recent push:
- `aarch64`:
```
ad3093fa02114e2ec80b54312ff0df232893dc73395630c3d7fdb34d7fe79d83 guix-build-b0322c462106/output/aarch64-linux-gnu/SHA256SUMS.part
d0b95a6538bb8ad217dcbf6cf481d9849d8a9b0c40ca18717cd3594087a5a5a5 guix-build-b0322c462106/output/aarch64-linux-gnu/bitcoin-b0322c462106-aarch64-linux-gnu-debug.tar.gz
d85f9ce2e9ffb310d55fcc4b9755a52d33935bb742f460fc7b6b74b61bad35a3 guix-build-b0322c462106/output/aarch64-linux-gnu/bitcoin-b0322c462106-aarch64-lin
...
🤔 promag reviewed a pull request: "Fix display issues for IPv6 proxy setup in Options Dialog (UI only, no functionality impact)"
(https://github.com/bitcoin-core/gui/pull/836#pullrequestreview-2349362315)
Code review ACK fee4cba48472239f7a426db62f45c4b6af8e5ef2.
(https://github.com/bitcoin-core/gui/pull/836#pullrequestreview-2349362315)
Code review ACK fee4cba48472239f7a426db62f45c4b6af8e5ef2.
📝 achow101 opened a pull request: "[28.x] doc: Sync 28.0 release notes with website"
(https://github.com/bitcoin/bitcoin/pull/31034)
Since there were some changes to the release notes after the tagging, update the in branch release notes to match those that ended up on the website.
(https://github.com/bitcoin/bitcoin/pull/31034)
Since there were some changes to the release notes after the tagging, update the in branch release notes to match those that ended up on the website.
📝 achow101 opened a pull request: "doc: Archive 28.0 release notes"
(https://github.com/bitcoin/bitcoin/pull/31035)
Matches the release notes on the website.
(https://github.com/bitcoin/bitcoin/pull/31035)
Matches the release notes on the website.
💬 achow101 commented on pull request "descriptor: Add proper Clone function to miniscript::Node":
(https://github.com/bitcoin/bitcoin/pull/30866#discussion_r1788418189)
It's not strictly necessary but I decided to do it this way to follow the pattern used for all other descriptors. The multipath expanded descriptors are treated as separate descriptors everywhere, and doing a deep copy retains that behavior which will allow for future changes that may modify specific descriptors.
(https://github.com/bitcoin/bitcoin/pull/30866#discussion_r1788418189)
It's not strictly necessary but I decided to do it this way to follow the pattern used for all other descriptors. The multipath expanded descriptors are treated as separate descriptors everywhere, and doing a deep copy retains that behavior which will allow for future changes that may modify specific descriptors.
⚠️ vasild opened an issue: "Listen on random port by default (not 8333)"
(https://github.com/bitcoin/bitcoin/issues/31036)
### Please describe the feature you'd like to see added.
Connections to port 8333 can be recognized right away as Bitcoin P2P connections. While it is still possible to recognize Bitcoin P2P connections regardless of the port, random ports would make network-wide monitoring harder.
### Is your feature related to a problem, if so please describe it.
Network-wide monitoring.
### Describe the solution you'd like
The listening address and port of a node are propagated and saved in other nodes
...
(https://github.com/bitcoin/bitcoin/issues/31036)
### Please describe the feature you'd like to see added.
Connections to port 8333 can be recognized right away as Bitcoin P2P connections. While it is still possible to recognize Bitcoin P2P connections regardless of the port, random ports would make network-wide monitoring harder.
### Is your feature related to a problem, if so please describe it.
Network-wide monitoring.
### Describe the solution you'd like
The listening address and port of a node are propagated and saved in other nodes
...
💬 vasild commented on issue "Prioritize processing of peers based on their CPU usage":
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2394932171)
Good questions that I do not have an answer to.
I guess this should start with planting some metrics - CPU time used by each peer in the last 1, 5 and 15 minutes and assessing what a "usual" situation looks like.
Specific to CPU DoS via invalid transactions: for peers that send us such transactions, maybe multiply the CPU time by a factor e.g. 10x or 100x. Or the other way around - nullify CPU time spend on definitely-good-and-positive things like new blocks or new transactions that we acc
...
(https://github.com/bitcoin/bitcoin/issues/31033#issuecomment-2394932171)
Good questions that I do not have an answer to.
I guess this should start with planting some metrics - CPU time used by each peer in the last 1, 5 and 15 minutes and assessing what a "usual" situation looks like.
Specific to CPU DoS via invalid transactions: for peers that send us such transactions, maybe multiply the CPU time by a factor e.g. 10x or 100x. Or the other way around - nullify CPU time spend on definitely-good-and-positive things like new blocks or new transactions that we acc
...
💬 azazar commented on issue "[Testnet] Insufficient data or no feerate found":
(https://github.com/bitcoin/bitcoin/issues/31032#issuecomment-2394951796)
The Testnet is becoming more frustrating. Testnet coins are nearly impossible to get without an ASIC, and now sending them has become a hassle too.
(https://github.com/bitcoin/bitcoin/issues/31032#issuecomment-2394951796)
The Testnet is becoming more frustrating. Testnet coins are nearly impossible to get without an ASIC, and now sending them has become a hassle too.
💬 JayBitron commented on issue "Unable to cross compile on linux for macos (28.x branch)":
(https://github.com/bitcoin/bitcoin/issues/31027#issuecomment-2394960152)
@hebasto can you try compiling yourself, including the qt wallet
(https://github.com/bitcoin/bitcoin/issues/31027#issuecomment-2394960152)
@hebasto can you try compiling yourself, including the qt wallet
💬 laanwj commented on pull request "doc: Archive 28.0 release notes":
(https://github.com/bitcoin/bitcoin/pull/31035#issuecomment-2394995331)
Does not exactly match the release notes on the v28.0 tag:
```
git diff f019fcec4126aa2618734016711063d3b44260fc:doc/release-notes/release-notes-28.0.md v28.0:doc/release-notes.md | wc
333
```
It does match the one on the website, minus Jekyll metadata wrapping and two EOL space differences.
ACK f019fcec4126aa2618734016711063d3b44260fc
(https://github.com/bitcoin/bitcoin/pull/31035#issuecomment-2394995331)
Does not exactly match the release notes on the v28.0 tag:
```
git diff f019fcec4126aa2618734016711063d3b44260fc:doc/release-notes/release-notes-28.0.md v28.0:doc/release-notes.md | wc
333
```
It does match the one on the website, minus Jekyll metadata wrapping and two EOL space differences.
ACK f019fcec4126aa2618734016711063d3b44260fc
💬 Sjors commented on pull request "Add multiprocess binaries to release build":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2395041597)
Added a commit to enable multiprocess on more CI environments.
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2395041597)
Added a commit to enable multiprocess on more CI environments.
💬 pinheadmz commented on issue "Unable to cross compile on linux for macos (28.x branch)":
(https://github.com/bitcoin/bitcoin/issues/31027#issuecomment-2395054359)
I'm getting the same error but inside a guix build: https://gist.github.com/pinheadmz/a2603f7f62c7627f33a10d8f39443f20
(https://github.com/bitcoin/bitcoin/issues/31027#issuecomment-2395054359)
I'm getting the same error but inside a guix build: https://gist.github.com/pinheadmz/a2603f7f62c7627f33a10d8f39443f20