💬 alfonsoromanz commented on pull request "test: assumeutxo: add missing tests in wallet_assumeutxo.py":
(https://github.com/bitcoin/bitcoin/pull/30455#issuecomment-3602119940)
rebased and force-pushed to resolve the CI test failures.

Also addressed feedback from theStack

- moved the `validate_snapshot_import` and `complete_background_validation` methods into an own refactoring commit
- added a comma after `["-fastprune", "-prune=1"]` for smaller future diff if another node is added
- deduplicated the expected error message within `test_backup_during_background_sync_pruned_node` so it doesn't have to be adapted twice if it ever changes

💬 ismaelsadeeq commented on issue "Mining IPC `createNewBlock` should not return before IBD is over":
(https://github.com/bitcoin/bitcoin/issues/33994#issuecomment-3602165226)
@plebhash It will be nice to get to the root of the issue and see whether it's bitcoin core or from the template provider.
Can you please provide the logs and setups accessible in a text file and not a discord link I think some people might not have discord.
cc @Sjors I attempt to reproduce the failure but was not successful yet.
blocking `createnewblock` from creating template during ibd is potential solution and would also delegate the responsibility of polling isinitialblockdownload to the
...

💬 sdaftuar commented on pull request "fuzz: gate mempool entry based on weight":
(https://github.com/bitcoin/bitcoin/pull/33985#issuecomment-3602179098)
ACK 804329400a73df00dfd7a5209c659d4a22b9ce47

💬 fanquake commented on pull request "fuzz: gate mempool entry based on weight":
(https://github.com/bitcoin/bitcoin/pull/33985#issuecomment-3602185685)
cc @dergoegge

💬 Sjors commented on pull request "refactor: disentangle miner startup defaults from runtime options":
(https://github.com/bitcoin/bitcoin/pull/33966#issuecomment-3602275695)
Rebased on the latest #33965 which allowed for some simplifications:
- `ClampOptions` no longer takes a `MiningArgs` argument
- no modifications to RPC code
- the new `block_max_weight` option on `BlockCreateOptions` will no longer be ignored if a caller sets it, only the tx_pool fuzzer does.

We could trivially make the new `block_max_weight` option available to IPC clients, but I don't think we should encourage its use.

Note that I brought back `ApplyArgsManOptions` in `miner.cpp`, but
...

💬 Sjors commented on pull request "mining: fix -blockreservedweight shadows IPC option":
(https://github.com/bitcoin/bitcoin/pull/33965#issuecomment-3602323654)
Rebased after #33591 because #33966 has a trivial merge conflict with it and I want to keep that cleanly based on this PR.

💬 ajtowns commented on issue "Standardness policy rules for legacy Multisig script is incoherent":
(https://github.com/bitcoin/bitcoin/issues/33882#issuecomment-3602342513)
> P2SH allows non-solvable redeem scripts with low sigop counts (PR https://github.com/bitcoin/bitcoin/pull/4365), while legacy scripts still require solvability. This inconsistency is hard to justify, especially since both rely on sigop limits for security.

> I agree. I think my next step would be to PR a change to `AreInputsStandard` to bring P2SH and legacy script policy into alignment.

I think I disagree with this -- we allow spends of fairly arbitrary p2sh scripts, but limit legacy spends
...

💬 Sjors commented on issue "Mining IPC `createNewBlock` should not return before IBD is over":
(https://github.com/bitcoin/bitcoin/issues/33994#issuecomment-3602376905)
The problem is that `ChainstateManager::IsInitialBlockDownload()` uses a fairly relaxed heuristic:

https://github.com/bitcoin/bitcoin/blob/d0f6d9953a15d7c7111d46dcb76ab2bb18e5dee3/src/validation.cpp#L1998-L2023

We could make this function much more precise by having it consider the most proof-of-work (not invalid) header chain.

But that might have impacts in other places in the codebase, potentially causing things to get stuck longer than needed just because we're missing a few recent blocks.
...

💬 sipa commented on issue "Mining IPC `createNewBlock` should not return before IBD is over":
(https://github.com/bitcoin/bitcoin/issues/33994#issuecomment-3602401780)
You can't use "active_tip == best_known_block_header" as condition for mining, because an attacker could mine a block, relay the header, and never relay the block. Sure, very expensive, but if the outcome is shutting down other miners, some joker might try it.

Bitcoin nodes are *always* synchronizing, and unless you have very strong evidence to the contrary, you should act as if your active tip is the best block on the chain. If we had evidence of a better block, it would be our best tip instea
...

👍 ismaelsadeeq approved a pull request: "fuzz: gate mempool entry based on weight"
(https://github.com/bitcoin/bitcoin/pull/33985#pullrequestreview-3530516004)
utACK 804329400a73df00dfd7a5209c659d4a22b9ce47

📝 hebasto opened a pull request: "depends: Propagate native C compiler to `sqlite` package"
(https://github.com/bitcoin/bitcoin/pull/33995)
This PR:

1. Ensures that autosetup can build the local bootstrap `jimsh0` when neither `jimsh` nor `tclsh` is available on the system.

2. Removes the `tcl` package from the Guix manifest.

This is an alternative to https://github.com/bitcoin/bitcoin/pull/33975.

💬 hebasto commented on pull request "depends, doc: Add `tcl` as build dependency for `sqlite` package":
(https://github.com/bitcoin/bitcoin/pull/33975#issuecomment-3602441211)
> Can we just pass the compiler through?

See https://github.com/bitcoin/bitcoin/pull/33995.

👍 dergoegge approved a pull request: "fuzz: gate mempool entry based on weight"
(https://github.com/bitcoin/bitcoin/pull/33985#pullrequestreview-3530571242)
utACK 804329400a73df00dfd7a5209c659d4a22b9ce47

✅ fanquake closed an issue: "integer overflow in FUZZ=package_rbf"
(https://github.com/bitcoin/bitcoin/issues/33981)

🚀 fanquake merged a pull request: "fuzz: gate mempool entry based on weight"
(https://github.com/bitcoin/bitcoin/pull/33985)

💬 Sjors commented on issue "Mining IPC `createNewBlock` should not return before IBD is over":
(https://github.com/bitcoin/bitcoin/issues/33994#issuecomment-3602538081)
Makes sense. We'll have to find another method of preventing a burst of new templates while the node churns through the last day worth of blocks.

The Template Provider client could simply wait 1 minute at startup if IBD was initially true and changed to false. In practice that only happens after the _node_ restarts (we wouldn't want to waste one minute each time the TP restarts).

💬 plebhash commented on issue "Mining IPC `createNewBlock` should not return before IBD is over":
(https://github.com/bitcoin/bitcoin/issues/33994#issuecomment-3602551596)
> Can you please provide the logs and setups accessible in a text file and not a discord link I think some people might not have discord.

yeah sorry I was in a hurry for the workshop, indeed pasting Discord links is not ideal

this is what @jbesraa said:
> I think handling IBD and other initialization aspects is critical when working in production env.
> As these two services need to set on the same machine you usually deploy them through the same "task" and I think they should wait for each o
...

💬 roconnor-blockstream commented on issue "Standardness policy rules for legacy Multisig script is incoherent":
(https://github.com/bitcoin/bitcoin/issues/33882#issuecomment-3602626488)
> I think I disagree with this -- we allow spends of fairly arbitrary p2sh scripts, but limit legacy spends to only a few known templates. That's a good thing because it reserves a lot of space for upgrade hooks, which have been used for p2sh, segwit and taproot.

One thing I suggested to @151henry151 was to not only limit the number of checksig operations but to require at least one checksig operation. Does that make you more comfortable?

💬 fjahr commented on pull request "test: assumeutxo: add missing tests in wallet_assumeutxo.py":
(https://github.com/bitcoin/bitcoin/pull/30455#issuecomment-3602628277)
re-ACK cb7d5bfe4a59d6034e3a77486cbd423e1a3bfa44

Confirmed the changes were addressing comments and a rebase.

💬 plebhash commented on issue "Mining IPC `createNewBlock` should not return before IBD is over":
(https://github.com/bitcoin/bitcoin/issues/33994#issuecomment-3602646676)
> `IsInitialBlockDownload()` is essentially this very conservative check. Only if you're really behind it'll say true.

how far behind? are we talking ~2, ~20 or ~200 blocks behind?