💬 fanquake commented on pull request "depends: remove `FORCE_USE_SYSTEM_CLANG`":
(https://github.com/bitcoin/bitcoin/pull/30201#discussion_r1621068763)
Yea. If/when it does change, everything will continue to change in lockstep.

💬 Sjors commented on pull request "Introduce Miner interface":
(https://github.com/bitcoin/bitcoin/pull/30200#discussion_r1621071328)
@ryanofsky I'm not sure what the design philophy is behind `Ensure` and `EnsureAny`. The other methods here return more low level objects.

Perhaps related to what you said here:

> > I think of "Context" as being a passive container for state instead of an object you would call methods on. The top level interfaces like `interfaces::Chain` `interface::Node` `interfaces::Wallet` are actually stateless themselves, and only point to state stored in other places. (The idea is to let interface in
...

💬 theuni commented on pull request "depends: consolidate dependency docs":
(https://github.com/bitcoin/bitcoin/pull/30204#discussion_r1621091245)
> I think I'd actually rather remove bsdmainutils, as I really wanted the dependencies listed here to just be what is required to actually build depends, rather than everything needed for Bitcoin Core.

Works for me.

💬 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-2140266954)
bitcoind is not (directly) on Windows 10 (pro, x64) - the screenshot just shows the drives used by my bitcoind Debian 12.5 virtual machine.

since i added "txindex=1", the drive B:\ where ~/.bitcoind linux mount point saves its data increase NOT, while I:\ drive (where the debian 12.5 os is, the rest, excluding ~/.bitcoind) space decreased rapidly... ca. from 40gb left to 3.7gb left

My implication: bitcoind does not only save its data in ~/.bitcoin directory ("data directory" where the blo
...

👍 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!