💬 ajtowns commented on pull request "RPC: Add maxfeerate and maxburnamount args to submitpackage":
(https://github.com/bitcoin/bitcoin/pull/28950#issuecomment-1916502753)
Isn't this check a little bit later than ideal? Wouldn't it make more sense to check both maxfeerate and maxburnamount as part of `signrawtransactionwith*` and `walletprocesspsbt` so that you never create a tx that can lose your money, rather than creating it and hoping that it won't find its way onto the network via some method other than rpc with default args?

💬 Sjors commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#issuecomment-1916514936)
> If bitcoin core is not generating this key, then it seems reasonable to have the pubkey along with it so that it can be verified. If bitcoin core is generating this key, I don't see why we are writing it to disk unencrypted.

We generate the key for Stratum v2. We don't generate the key for Tor and I2P. We also don't encrypt those.

I don't see how encryption could work for a server application like a Template Provider. Putting the password in a config file adds complexity and no security
...

💬 kevkevinpal commented on pull request "test: Handle functional test disk-full error":
(https://github.com/bitcoin/bitcoin/pull/29335#issuecomment-1916529533)
Concept ACK [ebb842a](https://github.com/bitcoin/bitcoin/pull/29335/commits/ebb842ae4fbb20d2933e6852afd055bedeacf8c2)

💬 kevkevinpal commented on pull request "test: Handle functional test disk-full error":
(https://github.com/bitcoin/bitcoin/pull/29335#discussion_r1470966212)
I think we can reword this to
`Tests aborted: Insufficient space available in directory: {tmpdir}`

Since the device may have space but the `tmpdir` we are using might have insufficient space

💬 josibake commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1470968822)
Interestingly, in https://github.com/bitcoin/bitcoin/blob/411ba32af21a56efa0a570b6aa8bf8f035410230/src/rpc/mempool.cpp#L89

`sendrawtransaction` takes a fee_rate argument, which is used to calculate a `max_tx_fee` based on the size of the transaction, and this `max_tx_fee` is passed to `BroadcastTransaction`. This means a user could typo an insane `maxfeerate` when calling `sendrawtransaction` that bypasses the default max tx fee.

Perhaps it does make more sense to have `BroadcastTransactio
...

💬 glozow commented on pull request "RPC: Add maxfeerate and maxburnamount args to submitpackage":
(https://github.com/bitcoin/bitcoin/pull/28950#issuecomment-1916562018)
> Isn't this check a little bit later than ideal? Wouldn't it make more sense to check both maxfeerate and maxburnamount as part of `signrawtransactionwith*` and `walletprocesspsbt` so that you never create a tx that can lose your money

I think it's indeed good to have that, but isn't it still possible that transactions submitted via `submitpackage` was created somewhere else?

💬 josibake commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#issuecomment-1916576350)
> It would help if you read the Stratum v2 spec on this

This PR is adding generic `Serialize/Deserialize` commands to `CKey` which allows you to read and write 32 bytes without any context. I don't think this is a good change for Bitcoin Core.

After talking through your specific usecase for SV2, I better understand *why* you want to read and write a key to disk and how you intend to provide context for the key, but I don't think it's a compelling enough reason to motivate a general change
...

💬 dergoegge commented on pull request "redeclare nChainTx to use uint64_t":
(https://github.com/bitcoin/bitcoin/pull/29331#issuecomment-1916582679)
> It's annoying that each test doing something like that would need to add an entry to the regtest chainparams, maybe my suggestion https://github.com/bitcoin/bitcoin/issues/29261#issuecomment-1907059722 to allow that per RPC could make sense (not necessarily in this PR).

I was thinking of a unit test, so no need for an RPC but yes some way to add assumeutxo data for tests would be needed (I assumed we already have this).

💬 BrandonOdiwuor commented on pull request "test: Handle functional test disk-full error":
(https://github.com/bitcoin/bitcoin/pull/29335#discussion_r1471026049)
The total size of the generated testdir after running `./test_runner.py --nocleanup` is `11GB` on my system

See the list of the generated folders and their sizes on the attached file below:
`sudo du -h /tmp/test_runner_₿_🏃_20240130_125641/ > ~/tmp-test_runner_₿_🏃_20240130_125641-test-files.txt`

[tmp-test_runner_₿_🏃_20240130_125641-test-files.txt](https://gith
...

💬 maflcko commented on pull request "test: Handle functional test disk-full error":
(https://github.com/bitcoin/bitcoin/pull/29335#discussion_r1471035243)
```
1.1G /tmp/test_runner_₿_🏃_20240130_125641/feature_block_289
```

So this value seems wrong either way? How can 66 MB be enough to fit 1.1GB, or even 11GB?

⚠️ Rucade opened an issue: "bitcoin core v.26 shuts down without warning - Doesnt save blocks downloaded"
(https://github.com/bitcoin/bitcoin/issues/29348)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

bitcoin core v.26 shuts down all the time unexpectedly, crashes and asks to Force Quit or wait so it does not save the blocks downloaded unless I shut it down first which is a terrible task every few minutes. I am at June 22nd 2023 for days trying to download the rest of the blocks. How do I fix this "bug"?

### Expected behaviour

to get the core loading properly I need to fix this bug or
...

💬 fanquake commented on pull request "build: LLD based macOS toolchain":
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1916637496)
Added a change to fix the `make deploy` CI failure. It involves switching from `otool`, to `llvm-objdump`, which for our needs (listing shared lib deps) is a drop-in replacement with the right flags (`--macho` `--dylibs-used`). We could have used `llvm-otool`, but we'd have the same problem that we would have had with `llvm-libtool`, which is that some distros (Ubuntu) only ship this binary with a version-suffix, which makes it annoying to find/use. Using `llvm-objdump` avoids this issue, and it
...

💬 maflcko commented on issue "bitcoin core v.26 shuts down without warning - Doesnt save blocks downloaded":
(https://github.com/bitcoin/bitcoin/issues/29348#issuecomment-1916637658)
Please check your debug.log for possible causes; Alternatively you can upload it here.

You can find the debug.log in your [data dir](https://github.com/bitcoin/bitcoin/blob/master/doc/files.md#data-directory-location).

Please be aware that the debug log might contain personally identifying information.

💬 maflcko commented on issue "bitcoin core v.26 shuts down without warning - Doesnt save blocks downloaded":
(https://github.com/bitcoin/bitcoin/issues/29348#issuecomment-1916638124)
Bitcoin Core makes heavy use of CPU, RAM and disk IO. Hardware defects might only become visible when running Bitcoin Core. You might want to check your hardware for defects.

* memtest86 to check your RAM
* to check the CPU behaviour under load, use linpack or Prime95
* to test your storage device use smartctl or CrystalDiskInfo

Source: https://bitcoin.stackexchange.com/a/12206

💬 Rucade commented on issue "bitcoin core v.26 shuts down without warning - Doesnt save blocks downloaded":
(https://github.com/bitcoin/bitcoin/issues/29348#issuecomment-1916671273)
debug log
[debug.log](https://github.com/bitcoin/bitcoin/files/14097165/debug.log)

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471073380)
Done

💬 Rucade commented on issue "bitcoin core v.26 shuts down without warning - Doesnt save blocks downloaded":
(https://github.com/bitcoin/bitcoin/issues/29348#issuecomment-1916672672)
> Please check your debug.log for possible causes; Alternatively you can upload it here.
>
> You can find the debug.log in your [data dir](https://github.com/bitcoin/bitcoin/blob/master/doc/files.md#data-directory-location).
>
> Please be aware that the debug log might contain personally identifying information.

[debug.log](https://github.com/bitcoin/bitcoin/files/14097173/debug.log)

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471074052)
Removed `PackageWithAncestorCounts`, now just using `Package`. Did a bit of refactoring inside `PackageV3Checks` so that we can use references instead of copies for the Txid and Wtxid.

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471074300)
Removed the duplicate check, nice

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1471074585)
Indeed! I've removed the duplicate check