👍 theuni approved a pull request: "build: remove `--enable-lcov-branch-coverage`"
(https://github.com/bitcoin/bitcoin/pull/30192#pullrequestreview-2088862324)
utACK cbd4640ede92a1a5d7b7c1367eb7c00a9f476c62

💬 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-2140277517)
Well you can look at it, presumably? How much data is in the `~/.bitcoin` directory? If it's empty, perhaps there is a configuration error and some other directory is used as datadir?

💬 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-2140291207)
the bitcoin application directory seems to be also very big... now i'm confused, i was thinking the bitcoind saves all its volatile data in ~/.bitcoin [data] - not in ~/bitcoin [application]


💬 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