💬 maflcko commented on pull request "test: Handle functional test disk-full error":
(https://github.com/bitcoin/bitcoin/pull/29335#discussion_r1469392954)
I wonder if the check could be done upfront, to not even run any test, if it is unclear whether the device will even hold enough to run the tests.

💬 stickies-v commented on pull request "test: ensure output is large enough to pay for its fees":
(https://github.com/bitcoin/bitcoin/pull/29283#discussion_r1469395573)
Thanks for reporting this @maflcko, need to round the minimum value to 8 decimals to fix this. Opening a pull now.

💬 josibake commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469368423)
I think we should keep the word "wallet" here, since this is a client set option. If you look at the RPC call above, it differentiates between the node wide policy of `relayMinFee` and the wallet set policy `m_min_fee` by adding the world "wallet" to the RPC error.

🤔 josibake reviewed a pull request: "Wallet: Add `maxfeerate` wallet startup option"
(https://github.com/bitcoin/bitcoin/pull/29278#pullrequestreview-1848310090)
It seems odd to me that we would ever have `maxtxfee` and `maxfeerate` set together as they seem to cover entirely different scenarios.

For `maxtxfee`, a user is expressing "I don't or care what my transaction size is but I know I never want to spend more than X in total fees."

For `maxfeerate` as user is expressing "I know that my transactions will vary a lot in size, so I don't know what the total fees will be, but I do know that I don't want to pay more than X sats/per vbyte."

I am s
...

💬 josibake commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#discussion_r1469372132)
I don't think we should remove this check for setting a `max_fee` that results in fee rates less than the `relayMinFee`.

💬 Sjors commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#issuecomment-1914420467)
I added `Check()` when deserialising.

> Not familiar with the stratumv2 spec, but this seems odd to me

In Stratum v2 a pool or Template Provider (implemented in #28983) may (optionally) have an identity. This is necessary to prevent stealing hash rate (at least for the pool). In order to protect that identity in the long run, you can keep its private key on a different machine, generate a static key for the server and sign a certificate for that static key.

> not a good fit for CKey


...

💬 Sjors commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#discussion_r1469402317)
Done

💬 Sjors commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#discussion_r1469402366)
Added

📝 stickies-v opened a pull request: "test: fix wallet_import_rescan unrounded minimum amount"
(https://github.com/bitcoin/bitcoin/pull/29343)
Addresses https://github.com/bitcoin/bitcoin/pull/29283#discussion_r1468842089.

Fixes a `JSONRPCException: Invalid amount (-3)` exception by ensuring the amount sent to `sendtoaddress` is rounded to 8 decimals.

See https://cirrus-ci.com/task/5562947183837184?logs=ci#L2559

Note: since `round` can also round down, `min_amount` is not _exactly_ guaranteed, but this is not a problem for the current usage. I've added a docstring to highlight this.

💬 stickies-v commented on pull request "test: ensure output is large enough to pay for its fees":
(https://github.com/bitcoin/bitcoin/pull/29283#discussion_r1469408527)
https://github.com/bitcoin/bitcoin/pull/29343/

👍 vasild approved a pull request: "CKey: add Serialize and Unserialize"
(https://github.com/bitcoin/bitcoin/pull/29295#pullrequestreview-1848385247)
ACK 683f988f90bd625544529b2366984bb677dd6e31

💬 vasild commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#discussion_r1469415640)
No need for the extra nesting `{`.

💬 Sjors commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#issuecomment-1914474598)
I dropped support for uncompressed keys and added a comment to explain the difference with OpenSSL encoding. Also added test for invalid keys.

💬 maflcko commented on pull request "test: Treat msg_version.relay as unsigned, Remove `struct` packing in messages.py":
(https://github.com/bitcoin/bitcoin/pull/29067#discussion_r1469441903)
> I suppose it doesn't really matter there, but would still keep that consistent with the actual type.

Thanks, done.

Also, rebased to fix the CI failure.

💬 dergoegge commented on pull request "redeclare nChainTx to use uint64_t":
(https://github.com/bitcoin/bitcoin/pull/29331#issuecomment-1914487359)
Would you mind adding a test? It should be possible to fake a large `nChainTx` in a test using assume utxo

👍 dergoegge approved a pull request: "fuzz: Print coverage summary after run_once"
(https://github.com/bitcoin/bitcoin/pull/29329#pullrequestreview-1848441332)
ACK fa4a08d424aa93f55b05fc9d83c8465599e5cece

Good idea to only collect and print the stats when using libfuzzer.

💬 maflcko commented on pull request "fuzz: Print coverage summary after run_once":
(https://github.com/bitcoin/bitcoin/pull/29329#issuecomment-1914493611)
(Added missing `if using_libfuzzer` check to fix macOS CI.)

💬 maflcko commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#discussion_r1469449395)
template implies `inline`, so it can be removed. Also, could run clang-format on new code?

💬 maflcko commented on pull request "CKey: add Serialize and Unserialize":
(https://github.com/bitcoin/bitcoin/pull/29295#discussion_r1469450644)
Any reason to cast a byte span to a u-char span? I think you can replace all `Make*Span()` by just `Span{}`.

💬 maflcko commented on pull request "util: check for errors after close and read in AutoFile":
(https://github.com/bitcoin/bitcoin/pull/29307#issuecomment-1914506129)
I don't think any care close-check needs to be done when reading from a file.

So what about removing the `write` method from `AutoFile`, and introduce a new derived class to add it back. This class could `Assume` that the file was flushed/closed before the destructor is called?