💬 sipa commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657558910)
Fixed.
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657558910)
Fixed.
💬 maflcko commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657560540)
nit in c8da96061a777a4206e05f7cde0f5de6f3ce3e8e: Are you sure about "never reseeded"?
It should be possible to call `SeedRandomForTest` twice, to toggle the seed, or reseed with the existing seed, no?
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657560540)
nit in c8da96061a777a4206e05f7cde0f5de6f3ce3e8e: Are you sure about "never reseeded"?
It should be possible to call `SeedRandomForTest` twice, to toggle the seed, or reseed with the existing seed, no?
💬 sipa commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657560878)
> Forgot to address this?
I don't think so?
```diff
diff --git a/src/random.h b/src/random.h
index ab4e049817..fd05e7e575 100644
--- a/src/random.h
+++ b/src/random.h
@@ -28,8 +28,8 @@
* The following (classes of) functions interact with that state by mixing in new
* entropy, and optionally extracting random output from it:
*
- * - The GetRand*() class of functions, as well as construction of FastRandomContext objects,
- * perform 'fast' seeding, consisting of mixing in:
...
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657560878)
> Forgot to address this?
I don't think so?
```diff
diff --git a/src/random.h b/src/random.h
index ab4e049817..fd05e7e575 100644
--- a/src/random.h
+++ b/src/random.h
@@ -28,8 +28,8 @@
* The following (classes of) functions interact with that state by mixing in new
* entropy, and optionally extracting random output from it:
*
- * - The GetRand*() class of functions, as well as construction of FastRandomContext objects,
- * perform 'fast' seeding, consisting of mixing in:
...
💬 maflcko commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657561740)
Ah, I looked at the previous force push :sweat_smile:
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657561740)
Ah, I looked at the previous force push :sweat_smile:
💬 sipa commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657563307)
Eh, I see how this is confusing.
It can obviously be reinitialized (resetting it), but it doesn't every gather real entropy, and is unaffected by `RandAddPeriod()` or `RandAddEvent()`.
Feel like proposing some language that would be clearer?
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657563307)
Eh, I see how this is confusing.
It can obviously be reinitialized (resetting it), but it doesn't every gather real entropy, and is unaffected by `RandAddPeriod()` or `RandAddEvent()`.
Feel like proposing some language that would be clearer?
💬 maflcko commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#issuecomment-2195320994)
re-ACK 1a2eae1f6d2487e8363b660e68c22474c317921e 📔
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: re-ACK 1a2eae1f6d2487e8363b
...
(https://github.com/bitcoin/bitcoin/pull/29625#issuecomment-2195320994)
re-ACK 1a2eae1f6d2487e8363b660e68c22474c317921e 📔
<details><summary>Show signature</summary>
Signature:
```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: re-ACK 1a2eae1f6d2487e8363b
...
💬 am-sq commented on pull request "doc: clarify loadwallet path loading for wallets":
(https://github.com/bitcoin/bitcoin/pull/30302#discussion_r1657568396)
```c++
...
+ "\nLoad wallet using absolute path (Unix):\n"
+ HelpExampleCli("loadwallet", "\"/home/myusername/specialWallet/\"")
+ HelpExampleRpc("loadwallet", "\"/home/myusername/specialWallet/\"")
+ "\nLoad wallet using absolute path (Windows):\n"
+ HelpExampleCli("loadwallet", "\"C:\\Users\\myusername\\specialWallet\\\"")
+ HelpExampleRpc("loadwallet", "\"C:\\Users\\myusername\\specialWallet\\\"")
...
```
(https://github.com/bitcoin/bitcoin/pull/30302#discussion_r1657568396)
```c++
...
+ "\nLoad wallet using absolute path (Unix):\n"
+ HelpExampleCli("loadwallet", "\"/home/myusername/specialWallet/\"")
+ HelpExampleRpc("loadwallet", "\"/home/myusername/specialWallet/\"")
+ "\nLoad wallet using absolute path (Windows):\n"
+ HelpExampleCli("loadwallet", "\"C:\\Users\\myusername\\specialWallet\\\"")
+ HelpExampleRpc("loadwallet", "\"C:\\Users\\myusername\\specialWallet\\\"")
...
```
🚀 achow101 merged a pull request: "refactor, wallet: get serialized size of `CRecipient`s directly"
(https://github.com/bitcoin/bitcoin/pull/30050)
(https://github.com/bitcoin/bitcoin/pull/30050)
💬 maflcko commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657596728)
Maybe "never strengthened" or "never fed further bytes" instead of "never reseeded"? But just a nit. Anything is fine here.
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657596728)
Maybe "never strengthened" or "never fed further bytes" instead of "never reseeded"? But just a nit. Anything is fine here.
💬 achow101 commented on pull request "init: Add option for rpccookie permissions (replace 26088)":
(https://github.com/bitcoin/bitcoin/pull/28167#issuecomment-2195406588)
ACK 73f0a6cbd0b628675028fbd5a37eff8115e7ccfe
(https://github.com/bitcoin/bitcoin/pull/28167#issuecomment-2195406588)
ACK 73f0a6cbd0b628675028fbd5a37eff8115e7ccfe
💬 sipa commented on pull request "Several randomness improvements":
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657625195)
```diff
diff --git a/src/random.h b/src/random.h
index e67e295b5f..f447216776 100644
--- a/src/random.h
+++ b/src/random.h
@@ -64,9 +64,11 @@
* (up to) the first 32 bytes of H are produced as output, while the last 32 bytes
* become the new RNG state.
*
- * During tests, the RNG is put into a special deterministic mode, in which the output of
- * all RNG functions, with the exception of GetStrongRandBytes(), is replaced with the
- * output of a deterministic RNG that is initiali
...
(https://github.com/bitcoin/bitcoin/pull/29625#discussion_r1657625195)
```diff
diff --git a/src/random.h b/src/random.h
index e67e295b5f..f447216776 100644
--- a/src/random.h
+++ b/src/random.h
@@ -64,9 +64,11 @@
* (up to) the first 32 bytes of H are produced as output, while the last 32 bytes
* become the new RNG state.
*
- * During tests, the RNG is put into a special deterministic mode, in which the output of
- * all RNG functions, with the exception of GetStrongRandBytes(), is replaced with the
- * output of a deterministic RNG that is initiali
...
💬 maflcko commented on pull request "wallet: notify when preset + automatic inputs exceed max weight":
(https://github.com/bitcoin/bitcoin/pull/30309#discussion_r1657628378)
https://cirrus-ci.com/task/5319226913718272?logs=ci#L1930
```
test 2024-06-26T19:28:29.157000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
File "/ci_container_base/ci/scratch/build/bitcoin-i686-pc-linux-gnu/test/functional/test_framework/util.py", line 157, in try_rpc
fun(*args, **kwds)
File "/ci_container_ba
...
(https://github.com/bitcoin/bitcoin/pull/30309#discussion_r1657628378)
https://cirrus-ci.com/task/5319226913718272?logs=ci#L1930
```
test 2024-06-26T19:28:29.157000Z TestFramework (ERROR): Assertion failed
Traceback (most recent call last):
File "/ci_container_base/ci/scratch/build/bitcoin-i686-pc-linux-gnu/test/functional/test_framework/util.py", line 157, in try_rpc
fun(*args, **kwds)
File "/ci_container_ba
...
👍 itornaza approved a pull request: "Mining interface followups, reduce cs_main locking, test rpc bug fix"
(https://github.com/bitcoin/bitcoin/pull/30335#pullrequestreview-2146255026)
Tested ACK a74b0f93efa1d9eaf5abc2f6591c44a632aec6ed
Code reviewed and validated all the initial refactor and appended fix changes as they were discovered during the course of this PR.
Cleaned up and rebuilt this commit running the unit, functional and extended tests that all pass.
(https://github.com/bitcoin/bitcoin/pull/30335#pullrequestreview-2146255026)
Tested ACK a74b0f93efa1d9eaf5abc2f6591c44a632aec6ed
Code reviewed and validated all the initial refactor and appended fix changes as they were discovered during the course of this PR.
Cleaned up and rebuilt this commit running the unit, functional and extended tests that all pass.
🤔 mzumsande reviewed a pull request: "Don't empty dbcache on prune flushes: >30% faster IBD"
(https://github.com/bitcoin/bitcoin/pull/28280#pullrequestreview-2142888699)
> A non-pruned IBD with full dbcache to tip ended up using 12% more memory, but it was also 2.7% faster somehow.
I'm not sure if I understand this, is this still the case?
Why would a node use more memory after this pull? Shouldn't the 2 added pointers be included in the dbcache accounting, resulting in more frequent flushes due to the cache filling up faster, but not in an increase in memory when the cache is full?
(https://github.com/bitcoin/bitcoin/pull/28280#pullrequestreview-2142888699)
> A non-pruned IBD with full dbcache to tip ended up using 12% more memory, but it was also 2.7% faster somehow.
I'm not sure if I understand this, is this still the case?
Why would a node use more memory after this pull? Shouldn't the 2 added pointers be included in the dbcache accounting, resulting in more frequent flushes due to the cache filling up faster, but not in an increase in memory when the cache is full?
💬 mzumsande commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509)
This comment and the implementation further persists the notion of FRESH-but-not-DIRTY coin, which I think is unfortunate, because it should be impossible for them to exist:
The only place in which they could be created is [here](https://github.com/bitcoin/bitcoin/blob/b27afb7fb774809c9c075d56e44657e0b607a00c/src/coins.cpp#L54), while fetching a coin from the parent that is spent. However that is not possible because we'd only get to that point if the [GetCoin()](https://github.com/bitcoin/bitc
...
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509)
This comment and the implementation further persists the notion of FRESH-but-not-DIRTY coin, which I think is unfortunate, because it should be impossible for them to exist:
The only place in which they could be created is [here](https://github.com/bitcoin/bitcoin/blob/b27afb7fb774809c9c075d56e44657e0b607a00c/src/coins.cpp#L54), while fetching a coin from the parent that is spent. However that is not possible because we'd only get to that point if the [GetCoin()](https://github.com/bitcoin/bitc
...
💬 mzumsande commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1657288151)
I think that it should be explained in a comment similar as it's already done in `CCoinsViewCache::BatchWrite` why we keep unspent coins because this is not obvious.
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1657288151)
I think that it should be explained in a comment similar as it's already done in `CCoinsViewCache::BatchWrite` why we keep unspent coins because this is not obvious.
💬 mzumsande commented on pull request "Don't empty dbcache on prune flushes: >30% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1657659234)
see https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509, I think that FRESH-but-not-DIRTY coins may not exist.
(https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1657659234)
see https://github.com/bitcoin/bitcoin/pull/28280#discussion_r1655477509, I think that FRESH-but-not-DIRTY coins may not exist.
💬 paplorinc commented on pull request "refactor, wallet: get serialized size of `CRecipient`s directly":
(https://github.com/bitcoin/bitcoin/pull/30050#discussion_r1657672491)
Rebased https://github.com/bitcoin/bitcoin/pull/30093 after this merge - it became trivial after your changes
(https://github.com/bitcoin/bitcoin/pull/30050#discussion_r1657672491)
Rebased https://github.com/bitcoin/bitcoin/pull/30093 after this merge - it became trivial after your changes
💬 ishaanam commented on pull request "wallet, rpc: add anti-fee-sniping to `send` and `sendall`":
(https://github.com/bitcoin/bitcoin/pull/28944#discussion_r1657685887)
> It also enforces that the sequences are either MAX_SEQUENCE_NONFINAL or MAX_BIP125_RBF_SEQUENCE, so this needs to be checking that as well otherwise an assertion will be hit. Or a commit could be added to relax those checks
I have added these checks to `FinishTransaction`.
(https://github.com/bitcoin/bitcoin/pull/28944#discussion_r1657685887)
> It also enforces that the sequences are either MAX_SEQUENCE_NONFINAL or MAX_BIP125_RBF_SEQUENCE, so this needs to be checking that as well otherwise an assertion will be hit. Or a commit could be added to relax those checks
I have added these checks to `FinishTransaction`.
💬 ishaanam commented on pull request "wallet, rpc: add anti-fee-sniping to `send` and `sendall`":
(https://github.com/bitcoin/bitcoin/pull/28944#discussion_r1657687535)
Here the wallet is locked because it runs `CWallet::GetLastBlockHash` and `CWallet::GetLastBlockHeight` which both require `pwallet->cs_wallet` to be locked.
(https://github.com/bitcoin/bitcoin/pull/28944#discussion_r1657687535)
Here the wallet is locked because it runs `CWallet::GetLastBlockHash` and `CWallet::GetLastBlockHeight` which both require `pwallet->cs_wallet` to be locked.