💬 Tiffanywaters92 commented on pull request "wallet, assumeutxo: Don't Assume m_chain_tx_count, Improve wallet RPC errors":
(https://github.com/bitcoin/bitcoin/pull/30909#discussion_r1938118477)
So can I ask the worst question lol what is it that's wrong or needed with bitcoin with all of this? Simplest like for dummies kinda answer
(https://github.com/bitcoin/bitcoin/pull/30909#discussion_r1938118477)
So can I ask the worst question lol what is it that's wrong or needed with bitcoin with all of this? Simplest like for dummies kinda answer
💬 achow101 commented on pull request "wallet: Disable creating and loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/31250#issuecomment-2628621716)
Marking this as ready for review as it no longer has any prerequisites.
(https://github.com/bitcoin/bitcoin/pull/31250#issuecomment-2628621716)
Marking this as ready for review as it no longer has any prerequisites.
👋 achow101's pull request is ready for review: "wallet: Disable creating and loading legacy wallets"
(https://github.com/bitcoin/bitcoin/pull/31250)
(https://github.com/bitcoin/bitcoin/pull/31250)
💬 achow101 commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1938121255)
I think it's possible, but I can't figure it out right now.
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1938121255)
I think it's possible, but I can't figure it out right now.
💬 achow101 commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1938121303)
Done
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1938121303)
Done
💬 achow101 commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1938121319)
Done
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1938121319)
Done
💬 achow101 commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1938121540)
I changed it to `Assume` and added an early return here so that the failed migration is cleaned up.
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1938121540)
I changed it to `Assume` and added an early return here so that the failed migration is cleaned up.
💬 hebasto commented on pull request "ci: build multiprocess on most jobs":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2628639378)
> But I am surprised to see clang-tidy build succeeding.
So am I.
> There were so much other clang-tidy output in the previous failing job aside from the missing input file errors fixed by the cmake change: https://cirrus-ci.com/task/4607289014878208?logs=ci#L7174. But I guess all the other new clang-tidy output was warnings not errors, so they don't cause the job to fail.
It could be the result of the absence of `WarningsAsErrors: '*'` in `src/ipc/libmultiprocess/.clang-tidy`.
> Sti
...
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2628639378)
> But I am surprised to see clang-tidy build succeeding.
So am I.
> There were so much other clang-tidy output in the previous failing job aside from the missing input file errors fixed by the cmake change: https://cirrus-ci.com/task/4607289014878208?logs=ci#L7174. But I guess all the other new clang-tidy output was warnings not errors, so they don't cause the job to fail.
It could be the result of the absence of `WarningsAsErrors: '*'` in `src/ipc/libmultiprocess/.clang-tidy`.
> Sti
...
💬 brunoerg commented on pull request "rpc: collect transaction fees on generateblock":
(https://github.com/bitcoin/bitcoin/pull/31775#discussion_r1938131196)
```
19:24:04.713] /ci_container_base/src/node/miner.cpp:150:9: error: 'exclusive_locks_required' attribute cannot be applied to a statement
[19:24:04.713] 150 | EXCLUSIVE_LOCKS_REQUIRED(m_mempool->cs);
[19:24:04.713] | ^ ~
[19:24:04.713] /ci_container_base/src/threadsafety.h:31:54: note: expanded from macro 'EXCLUSIVE_LOCKS_REQUIRED'
[19:24:04.713] 31 | #define EXCLUSIVE_LOCKS_REQUIRED(...) __attribute__((exclusive_locks_requir
...
(https://github.com/bitcoin/bitcoin/pull/31775#discussion_r1938131196)
```
19:24:04.713] /ci_container_base/src/node/miner.cpp:150:9: error: 'exclusive_locks_required' attribute cannot be applied to a statement
[19:24:04.713] 150 | EXCLUSIVE_LOCKS_REQUIRED(m_mempool->cs);
[19:24:04.713] | ^ ~
[19:24:04.713] /ci_container_base/src/threadsafety.h:31:54: note: expanded from macro 'EXCLUSIVE_LOCKS_REQUIRED'
[19:24:04.713] 31 | #define EXCLUSIVE_LOCKS_REQUIRED(...) __attribute__((exclusive_locks_requir
...
📝 tdb3 converted_to_draft a pull request: "rpc: add `relevant_blocks` to `scanblocks status`"
(https://github.com/bitcoin/bitcoin/pull/30713)
Currently, after starting a scan with `scanblocks` the user must wait until the scan is complete to see the associated/relevant block hashes.
This updates the `scanblocks status` result object to provide the `relevant_blocks` found so far.
This enables earlier subsequent lookup within matching blocks (e.g. to run `getdescriptoractivity` in PR #30708)
Below is an example tested on signet by starting and obtaining status of a scan for an address that has received many coinbase outputs (so the
...
(https://github.com/bitcoin/bitcoin/pull/30713)
Currently, after starting a scan with `scanblocks` the user must wait until the scan is complete to see the associated/relevant block hashes.
This updates the `scanblocks status` result object to provide the `relevant_blocks` found so far.
This enables earlier subsequent lookup within matching blocks (e.g. to run `getdescriptoractivity` in PR #30708)
Below is an example tested on signet by starting and obtaining status of a scan for an address that has received many coinbase outputs (so the
...
💬 tdb3 commented on pull request "rpc: add `relevant_blocks` to `scanblocks status`":
(https://github.com/bitcoin/bitcoin/pull/30713#issuecomment-2628649148)
Will revisit later
(https://github.com/bitcoin/bitcoin/pull/30713#issuecomment-2628649148)
Will revisit later
💬 davidgumberg commented on issue "fuzz: oss-fuzz coverage build is failing":
(https://github.com/bitcoin/bitcoin/issues/31770#issuecomment-2628741241)
Bisected to https://github.com/bitcoin/bitcoin/commit/5691fa93c48c5b2c767f19aad5e972e4d760414a (#31661),
Can reproduce doing something like:
```bash
# setup
git clone --depth 1 https://github.com/google/oss-fuzz.git
git clone https://github.com/bitcoin/bitcoin oss-fuzz/bitcoin
git clone --depth 1 https://github.com/bitcoin-core/qa-assets oss-fuzz/bitcoin/assets
cd oss-fuzz
python infra/helper.py build_image bitcoin-core
# check out a commit hash for the local copy
BAD_COMMIT=5691fa93c4
GOOD_
...
(https://github.com/bitcoin/bitcoin/issues/31770#issuecomment-2628741241)
Bisected to https://github.com/bitcoin/bitcoin/commit/5691fa93c48c5b2c767f19aad5e972e4d760414a (#31661),
Can reproduce doing something like:
```bash
# setup
git clone --depth 1 https://github.com/google/oss-fuzz.git
git clone https://github.com/bitcoin/bitcoin oss-fuzz/bitcoin
git clone --depth 1 https://github.com/bitcoin-core/qa-assets oss-fuzz/bitcoin/assets
cd oss-fuzz
python infra/helper.py build_image bitcoin-core
# check out a commit hash for the local copy
BAD_COMMIT=5691fa93c4
GOOD_
...
💬 jonatack commented on pull request "rpc, logging: return "verificationprogress" of 1 when up to date":
(https://github.com/bitcoin/bitcoin/pull/31177#issuecomment-2628749739)
Thanks for updating -- will review.
(https://github.com/bitcoin/bitcoin/pull/31177#issuecomment-2628749739)
Thanks for updating -- will review.
💬 vasild commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1938204958)
Ok, it will never generate a template because it will never exit from `waitNext()` (when run from unit tests with mocktime which never advances). "BOOST_REQUIRE(block_template) checks will fail" -- they will never be reached in that case.
What about this (unit tests will use timeout=0):
```
now = now()
deadline = now + timeout;
do {
stuff;
now = now();
} while (now < deadline);
```
it will execute the body of the loop exactly once when given timeout=0 regardless of whether
...
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1938204958)
Ok, it will never generate a template because it will never exit from `waitNext()` (when run from unit tests with mocktime which never advances). "BOOST_REQUIRE(block_template) checks will fail" -- they will never be reached in that case.
What about this (unit tests will use timeout=0):
```
now = now()
deadline = now + timeout;
do {
stuff;
now = now();
} while (now < deadline);
```
it will execute the body of the loop exactly once when given timeout=0 regardless of whether
...
💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1938233022)
I think it's better explicitly mention the test issue:
1. Less likely for someone to accidentally break it and be confused
2. Maybe someone adds a nice macro one day `RUN_COMMAND_DO_OTHER_THING_IN_NEW_THREAD_AFTER(command, delay)`
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1938233022)
I think it's better explicitly mention the test issue:
1. Less likely for someone to accidentally break it and be confused
2. Maybe someone adds a nice macro one day `RUN_COMMAND_DO_OTHER_THING_IN_NEW_THREAD_AFTER(command, delay)`
💬 Sjors commented on pull request "rpc: add optional blockhash to waitfornewblock, unhide in help":
(https://github.com/bitcoin/bitcoin/pull/30635#issuecomment-2628866683)
Rebased after #31600.
(https://github.com/bitcoin/bitcoin/pull/30635#issuecomment-2628866683)
Rebased after #31600.
💬 Sjors commented on pull request "test: clarify timewarp grace period griefing attack":
(https://github.com/bitcoin/bitcoin/pull/31725#issuecomment-2628867551)
#31600 landed, ready for review
(https://github.com/bitcoin/bitcoin/pull/31725#issuecomment-2628867551)
#31600 landed, ready for review
👋 Sjors's pull request is ready for review: "test: clarify timewarp grace period griefing attack"
(https://github.com/bitcoin/bitcoin/pull/31725)
(https://github.com/bitcoin/bitcoin/pull/31725)
💬 Sjors commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1938236496)
Miners don't add the header though.
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1938236496)
Miners don't add the header though.
💬 Sjors commented on pull request "mining: bugfix: Fix duplicate coinbase tx weight reservation":
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1938237527)
Indeed, this could be `MAX_BLOCK_WEIGHT`, but definitely not `max_block_weight`.
The clamping does not prevent someone from creating a 4MB coinbase transaction while otherwise not mining anything by setting `-maxblockweight=0`. As nonsensical as that might be, but dropping `-blockmaxweight` seems better to discuss in a followup.
(https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1938237527)
Indeed, this could be `MAX_BLOCK_WEIGHT`, but definitely not `max_block_weight`.
The clamping does not prevent someone from creating a 4MB coinbase transaction while otherwise not mining anything by setting `-maxblockweight=0`. As nonsensical as that might be, but dropping `-blockmaxweight` seems better to discuss in a followup.