💬 kosuodhmwa commented on issue "VM disk for OS (Debian 12.x) gets smaller and smaller - NOT the same disk i used for .bitdoin data directory which is mounted on another disk":
(https://github.com/bitcoin/bitcoin/issues/30191#issuecomment-2140295531)
Here the drive used for ~/.bitcoin (data) symlink


/dev/sda1 1054729716 650342244 350736480 65% /mnt/btcdrive

💬 sipa commented on issue "VM disk for OS (Debian 12.x) gets smaller and smaller - NOT the same disk i used for .bitdoin data directory which is mounted on another disk":
(https://github.com/bitcoin/bitcoin/issues/30191#issuecomment-2140304393)
Inside the VM, what do you get if you type `ls -l ~/.bitcoin`?

💬 kosuodhmwa commented on issue "VM disk for OS (Debian 12.x) gets smaller and smaller - NOT the same disk i used for .bitdoin data directory which is mounted on another disk":
(https://github.com/bitcoin/bitcoin/issues/30191#issuecomment-2140342760)
Thank you very much - will look on it ASAP

💬 kosuodhmwa commented on issue "VM disk for OS (Debian 12.x) gets smaller and smaller - NOT the same disk i used for .bitdoin data directory which is mounted on another disk":
(https://github.com/bitcoin/bitcoin/issues/30191#issuecomment-2140359209)
(Now the VM was completely fu**ed up, because 0.0gb left)

💬 TheBlueMatt commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2140458431)
> > In practice today that probably means pre-mining a handful of blocks to add the test cases and then checkpointing the end of the pre-mine.
>
> That makes sense if we want the test cases as early as possible in the chain. In that case someone should provide such a script in the next few months, then we can make a new genesis block, run the script, add the checkpoint and merge this PR.
>
> I do hope we can rid of the checkpoint code entirely (see https://github.com/bitcoin/bitcoin/pull/2
...

💬 maflcko commented on pull request "test: Added test coverage to listsinceblock rpc":
(https://github.com/bitcoin/bitcoin/pull/30195#discussion_r1621221575)
Seems easier to rename the file than to change its permissions?

💬 murchandamus commented on pull request "Fix waste calculation in SelectionResult":
(https://github.com/bitcoin/bitcoin/pull/28366#discussion_r1621223307)
I guess, but the point of this PR is that `change_cost` no longer needs to be set to 0 to indicate that no change is being created.

💬 kevkevinpal commented on pull request "test: Added test coverage to listsinceblock rpc":
(https://github.com/bitcoin/bitcoin/pull/30195#discussion_r1621231556)
Yes that might make more sense, I've tried to do such in [f278ac9](https://github.com/bitcoin/bitcoin/pull/30195/commits/f278ac9f78b802e578ad35fd756ddbce229364d4)

Lets see if it passes the ci, it was passing on my machine

💬 Sjors commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2140539320)
> @Sjors suggestion to change nActualTimespan was also aimed at this problem

No it wasn't, it seems I was confused myself and thought there was no problem: https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1599635493

💬 murchandamus commented on pull request "Fix waste calculation in SelectionResult":
(https://github.com/bitcoin/bitcoin/pull/28366#discussion_r1621255404)
Unfortunately, we don’t have the `change_fee` or `feerate` readily available in the BnB function. The following passes the tests, though:

```cpp
- result.RecalculateWaste(cost_of_change, cost_of_change, CAmount{0});
+ /* Calculate the fee for a P2WPKH change output */
+ if (utxo_pool.at(0).long_term_fee) {
+ const CFeeRate feerate = utxo_pool.at(0).m_long_term_feerate * (utxo_pool.at(0).fee / utxo_pool.at(0).long_term_fee);
+ const CAmount change_fee = feerate.GetF
...

💬 murchandamus commented on pull request "Fix waste calculation in SelectionResult":
(https://github.com/bitcoin/bitcoin/pull/28366#discussion_r1621257403)
Let me know if you have a suggestion how I should amend the code.

💬 murchandamus commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2140656559)
> > I missed that before, but the improved text on the BIP made me realize. It looks like an attacker could jack up the difficulty by mining a few difficulty periods with an ASIC and then stop after the last block in a difficulty period. The network would then be on a difficulty some 4n higher than before, and stuck looking to mine a first block at full difficulty.
>
> I don't think that's much of a concern -- all you'd need to do is invalidateblock the last block of the period, mine a new on
...

💬 fjahr commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#discussion_r1621295595)
Taken, thanks!

💬 fjahr commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#discussion_r1621295778)
Ok, passing CChain and BlockMan as parameters now.

💬 fjahr commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#discussion_r1621295907)
Taken, thanks!

💬 fjahr commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#discussion_r1621298451)
I have adopted these changes with minor edits and that addresses your previous comment about the genesis behavior as well.

💬 fjahr commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#discussion_r1621299243)
Addressed in the other comment on this commit

💬 fjahr commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#issuecomment-2140704680)
Addressed comments from @ryanofsky , thank you for the thoughtful review!

📝 mzumsande opened a pull request: "validation: Improve, document and test logic for chains building on invalid blocks"
(https://github.com/bitcoin/bitcoin/pull/30207)
Some improvements with respect to invalid blocks and blocks building on them:

1.) The fields `m_best_header` (best header irrespective on whether we have the full block or not) and `BLOCK_FAILED_CHILD` (BlockStatus saying that a header descends from an invalid block) are populated on a best-effort basis and can sometimes be off. This is not too bad because critical consensus code doesn't rely on either of these, but it is kind of brittle, especially because this is not clearly documented. Do
...

🤔 furszy reviewed a pull request: "validation: Improve, document and test logic for chains building on invalid blocks"
(https://github.com/bitcoin/bitcoin/pull/30207#pullrequestreview-2089313850)
Concept ACK