💬 maflcko commented on pull request "miniscript: make operator""_mst consteval":
(https://github.com/bitcoin/bitcoin/pull/28657#issuecomment-1889501254)
Maybe mark as draft while this is waiting on #29165? (29165 won't happen unless someone bumps google's oss-fuzz's clang)
(https://github.com/bitcoin/bitcoin/pull/28657#issuecomment-1889501254)
Maybe mark as draft while this is waiting on #29165? (29165 won't happen unless someone bumps google's oss-fuzz's clang)
💬 fjahr commented on pull request "doc: Add missing backtick in developer notes logging section":
(https://github.com/bitcoin/bitcoin/pull/29241#discussion_r1450602869)
Done, thanks!
(https://github.com/bitcoin/bitcoin/pull/29241#discussion_r1450602869)
Done, thanks!
📝 sipa converted_to_draft a pull request: "miniscript: make operator""_mst consteval"
(https://github.com/bitcoin/bitcoin/pull/28657)
It seems modern compilers don't realize that all invocations of operator""_mst can be evaluated at compile time, despite the `constexpr` keyword.
Since C++20, we can force them to evaluate at compile time using `consteval`, turning all the miniscript type constants into actual compile-time constants.
This should give a nice but not very important speedup for miniscript logic, but it's also a way to start testing C++20 features.
(https://github.com/bitcoin/bitcoin/pull/28657)
It seems modern compilers don't realize that all invocations of operator""_mst can be evaluated at compile time, despite the `constexpr` keyword.
Since C++20, we can force them to evaluate at compile time using `consteval`, turning all the miniscript type constants into actual compile-time constants.
This should give a nice but not very important speedup for miniscript logic, but it's also a way to start testing C++20 features.
💬 mzumsande commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#issuecomment-1889521586)
> If so, it seems more natural to me to specify outbound net permissions wherever that manual connection is instructed
That would mean adding logic / additional options for it in possibly multiple spots, and having yet another place where net permissions are defined. If that becomes too messy, another option would be to leave it in `-whitelist` but just not apply it to automatic outbound connections.
(https://github.com/bitcoin/bitcoin/pull/27114#issuecomment-1889521586)
> If so, it seems more natural to me to specify outbound net permissions wherever that manual connection is instructed
That would mean adding logic / additional options for it in possibly multiple spots, and having yet another place where net permissions are defined. If that becomes too messy, another option would be to leave it in `-whitelist` but just not apply it to automatic outbound connections.
💬 Sjors commented on pull request "Stratum v2 Template Provider (take 2)":
(https://github.com/bitcoin/bitcoin/pull/28983#issuecomment-1889525495)
I added support for generating a self-signed certificate. The authority key is printed in the log in base58 format, so it can easily be used on the SRI side.
(https://github.com/bitcoin/bitcoin/pull/28983#issuecomment-1889525495)
I added support for generating a self-signed certificate. The authority key is printed in the log in base58 format, so it can easily be used on the SRI side.
🤔 murchandamus reviewed a pull request: "wallet: Add CoinGrinder coin selection algorithm"
(https://github.com/bitcoin/bitcoin/pull/27877#pullrequestreview-1817293438)
Addressed Ishaana’s review
Added a test with a pattern of mixed weight inputs to highlight the improvements from optimizations.
(https://github.com/bitcoin/bitcoin/pull/27877#pullrequestreview-1817293438)
Addressed Ishaana’s review
Added a test with a pattern of mixed weight inputs to highlight the improvements from optimizations.
💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449749043)
Good catch, thanks. Fixed.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449749043)
Good catch, thanks. Fixed.
💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449754512)
Rephrased, especially given that there is no lookahead yet
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449754512)
Rephrased, especially given that there is no lookahead yet
💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449756790)
Fixed
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449756790)
Fixed
💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449762046)
Good point, thanks for pointing that out.
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449762046)
Good point, thanks for pointing that out.
💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449760026)
Thanks, starting a few commits later we will SHIFT when `curr_weight` exceeds the `best_selection_weight`, so the second part of this condition can only trigger on same weight. Since we do not have the SHIFT criteria here yet, this is a bug. Fixed by explicitly checking that weight is tied.
My argument for preferring an input set with fewer funds is that the wallet’s confirmed balance is reduced less and therefore the wallet has more flexible and higher liquidity in case this transaction does
...
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1449760026)
Thanks, starting a few commits later we will SHIFT when `curr_weight` exceeds the `best_selection_weight`, so the second part of this condition can only trigger on same weight. Since we do not have the SHIFT criteria here yet, this is a bug. Fixed by explicitly checking that weight is tied.
My argument for preferring an input set with fewer funds is that the wallet’s confirmed balance is reduced less and therefore the wallet has more flexible and higher liquidity in case this transaction does
...
💬 m3dwards commented on issue "ci: failure in `wallet_assumeutxo.py --descriptors`":
(https://github.com/bitcoin/bitcoin/issues/29234#issuecomment-1889549162)
Trying to replicate this locally and at the moment I get a different failure:
```shell
assert_raises_rpc_error(-4, "Wallet loading failed. Error loading wallet. Wallet requires blocks to be downloaded, and software does not currently support loading wallets while blocks are being downloaded out of order when using assumeutxo snapshots. Wallet should be able to load successfully after node sync reaches height 299", n1.restorewallet, "w", "backup_w.dat")
```
(https://github.com/bitcoin/bitcoin/issues/29234#issuecomment-1889549162)
Trying to replicate this locally and at the moment I get a different failure:
```shell
assert_raises_rpc_error(-4, "Wallet loading failed. Error loading wallet. Wallet requires blocks to be downloaded, and software does not currently support loading wallets while blocks are being downloaded out of order when using assumeutxo snapshots. Wallet should be able to load successfully after node sync reaches height 299", n1.restorewallet, "w", "backup_w.dat")
```
💬 jonatack commented on pull request "doc: Add missing backtick in developer notes logging section":
(https://github.com/bitcoin/bitcoin/pull/29241#issuecomment-1889576187)
ACK c003562120c193c296ac754b4bb8cff02bbbe4dc
Tangential, I don't understand the macro ordering in this line:
```
The macros `LogInfo`, `LogDebug`, `LogTrace`, `LogWarning` and `LogError` are available for
```
(https://github.com/bitcoin/bitcoin/pull/29241#issuecomment-1889576187)
ACK c003562120c193c296ac754b4bb8cff02bbbe4dc
Tangential, I don't understand the macro ordering in this line:
```
The macros `LogInfo`, `LogDebug`, `LogTrace`, `LogWarning` and `LogError` are available for
```
🤔 ryanofsky reviewed a pull request: "RPC/Wallet: Convert walletprocesspsbt to use options parameter"
(https://github.com/bitcoin/bitcoin/pull/24963#pullrequestreview-1818316586)
Code review f43f992b7318086859f710b920b4427e6c657fe8. I think this looks pretty close, and the approach taken in this PR to preserves backwards compatibility seems pretty clean. I would have thought prior to this PR that we might need to break backwards compatibility to convert existing named parameters to options, but this is not the case. Two things I think should be improved:
1. Lack of enforcement for m_type_per_name vector. Right now the MatchesType implementation just checks if the para
...
(https://github.com/bitcoin/bitcoin/pull/24963#pullrequestreview-1818316586)
Code review f43f992b7318086859f710b920b4427e6c657fe8. I think this looks pretty close, and the approach taken in this PR to preserves backwards compatibility seems pretty clean. I would have thought prior to this PR that we might need to break backwards compatibility to convert existing named parameters to options, but this is not the case. Two things I think should be improved:
1. Lack of enforcement for m_type_per_name vector. Right now the MatchesType implementation just checks if the para
...
💬 ryanofsky commented on pull request "RPC/Wallet: Convert walletprocesspsbt to use options parameter":
(https://github.com/bitcoin/bitcoin/pull/24963#discussion_r1450514731)
In commit "RPC: Support specifying different types for param aliases" (c2612273ef0b3ef127ba03c87f2a3303f0b9d299)
I'm pretty sure you can simplify this and revert all changes to this function. All this is doing is getting the `sign` parameter type from the outer parameter declaration instead of the inner option declaration, which doesn't change anything because both types are boolean. The output of "bitcoin-cli -regtest help dump_all_command_conversions" is the same with or without this change
...
(https://github.com/bitcoin/bitcoin/pull/24963#discussion_r1450514731)
In commit "RPC: Support specifying different types for param aliases" (c2612273ef0b3ef127ba03c87f2a3303f0b9d299)
I'm pretty sure you can simplify this and revert all changes to this function. All this is doing is getting the `sign` parameter type from the outer parameter declaration instead of the inner option declaration, which doesn't change anything because both types are boolean. The output of "bitcoin-cli -regtest help dump_all_command_conversions" is the same with or without this change
...
💬 ryanofsky commented on pull request "RPC/Wallet: Convert walletprocesspsbt to use options parameter":
(https://github.com/bitcoin/bitcoin/pull/24963#discussion_r1450616033)
In commit "RPC: Support specifying different types for param aliases" (c2612273ef0b3ef127ba03c87f2a3303f0b9d299)
I don't think this check is strict enough, because it isn't actually verifying the parameter was passed with the corresponding name for the `m_type_per_name` value. It will accept a parameter with any type found in the vector, not just a parameter with the correct type for its name. This is not good because it means in the walletprocesspsbt case you could pass options=true and it w
...
(https://github.com/bitcoin/bitcoin/pull/24963#discussion_r1450616033)
In commit "RPC: Support specifying different types for param aliases" (c2612273ef0b3ef127ba03c87f2a3303f0b9d299)
I don't think this check is strict enough, because it isn't actually verifying the parameter was passed with the corresponding name for the `m_type_per_name` value. It will accept a parameter with any type found in the vector, not just a parameter with the correct type for its name. This is not good because it means in the walletprocesspsbt case you could pass options=true and it w
...
👍 BrandonOdiwuor approved a pull request: "test: unbreak: exclude windows from wallet_assumeutxo"
(https://github.com/bitcoin/bitcoin/pull/29238#pullrequestreview-1818617575)
Code Review ACK 99399ae88fa23c0333bc2b0d59b48d0936a869c7
(https://github.com/bitcoin/bitcoin/pull/29238#pullrequestreview-1818617575)
Code Review ACK 99399ae88fa23c0333bc2b0d59b48d0936a869c7
💬 mzumsande commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1450676078)
just want to add that if this turned out annoying to fix (I didn't see an immediate trivial fix but haven't looked hard), I'd be fine just throwing an assert / error if decoy packages are received in this PR (since bitcoind shouldn't send those anyway).
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1450676078)
just want to add that if this turned out annoying to fix (I didn't see an immediate trivial fix but haven't looked hard), I'd be fine just throwing an assert / error if decoy packages are received in this PR (since bitcoind shouldn't send those anyway).
💬 sipa commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1450623741)
In commit "[test] Perform initial v2 handshake":
I think it's not very clean to reach into `self.v2_state`'s internals to figure out how much `respond_v2_handshake` has consumed. It would be better if the function just returned how much was consumed (if anything).
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1450623741)
In commit "[test] Perform initial v2 handshake":
I think it's not very clean to reach into `self.v2_state`'s internals to figure out how much `respond_v2_handshake` has consumed. It would be better if the function just returned how much was consumed (if anything).
💬 sipa commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1448904297)
In "In commit "[test] Construct class to handle v2 P2P protocol functions"
Nit: see above, I think it would be cleaner to return `(0, None)` in case no complete packet is present, and `(-1, None)` in case of error. That would make the description:
* int: number of bytes consumed (or -1 if error)
* bytes: contents of decrypted non-decoy packet if any (or None otherwise)
Since the callers don't care about the distinction between "no packet processed" or "decoy packet processed" for what to
...
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1448904297)
In "In commit "[test] Construct class to handle v2 P2P protocol functions"
Nit: see above, I think it would be cleaner to return `(0, None)` in case no complete packet is present, and `(-1, None)` in case of error. That would make the description:
* int: number of bytes consumed (or -1 if error)
* bytes: contents of decrypted non-decoy packet if any (or None otherwise)
Since the callers don't care about the distinction between "no packet processed" or "decoy packet processed" for what to
...