💬 maflcko commented on issue "Bitcoin Core on mainnet shows testnet3 dir as a wallet to open and allows opening it":
(https://github.com/bitcoin/bitcoin/issues/16107#issuecomment-2853868126)
For reference, BDB removal https://github.com/bitcoin/bitcoin/pull/31250 was merged (for 30.0)
Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?
(https://github.com/bitcoin/bitcoin/issues/16107#issuecomment-2853868126)
For reference, BDB removal https://github.com/bitcoin/bitcoin/pull/31250 was merged (for 30.0)
Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?
💬 Sjors commented on pull request "Shuffle depends instructions and recommend modern make for macOS":
(https://github.com/bitcoin/bitcoin/pull/32086#discussion_r2075086317)
The commit message of 99e6490dc51adde35b58e8d193aca7c1c422dbf3 explains why:
> In the Configuring section, use Linux native compilation as the
> example instead of Windows cross-compile.
Previously this documented started with cross compilation, which "above" referred to. In this PR I start with native compilation.
(https://github.com/bitcoin/bitcoin/pull/32086#discussion_r2075086317)
The commit message of 99e6490dc51adde35b58e8d193aca7c1c422dbf3 explains why:
> In the Configuring section, use Linux native compilation as the
> example instead of Windows cross-compile.
Previously this documented started with cross compilation, which "above" referred to. In this PR I start with native compilation.
✅ maflcko closed an issue: "ThreadDNSAddressSeed hangs on sk_wait_data and doesn't stop on exit"
(https://github.com/bitcoin/bitcoin/issues/16778)
(https://github.com/bitcoin/bitcoin/issues/16778)
💬 maflcko commented on issue "ThreadDNSAddressSeed hangs on sk_wait_data and doesn't stop on exit":
(https://github.com/bitcoin/bitcoin/issues/16778#issuecomment-2853879949)
There were two reports of this in 2019, but it hasn't happened since. So I'll be closing this for now.
If it happens again, this issue can be re-opened or a new issue can be filed, referencing this issue, if needed.
(https://github.com/bitcoin/bitcoin/issues/16778#issuecomment-2853879949)
There were two reports of this in 2019, but it hasn't happened since. So I'll be closing this for now.
If it happens again, this issue can be re-opened or a new issue can be filed, referencing this issue, if needed.
📝 laanwj opened a pull request: "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory"
(https://github.com/bitcoin/bitcoin/pull/32423)
This PR does two things:
### Undeprecate rpcuser/rpcpassword, change message to security warning
Back in 2015, in https://github.com/bitcoin/bitcoin/pull/7044, we added configuration option `rpcauth` for multiple RPC users. At the same time the old settings for single-user configuration `rpcuser` and `rpcpassword` were "soon" to be deprecated.
The main reason for this deprecation is that while `-rpcpassword` stores the password in plain text, `-rpcauth` stores a hash, so it doesn't appe
...
(https://github.com/bitcoin/bitcoin/pull/32423)
This PR does two things:
### Undeprecate rpcuser/rpcpassword, change message to security warning
Back in 2015, in https://github.com/bitcoin/bitcoin/pull/7044, we added configuration option `rpcauth` for multiple RPC users. At the same time the old settings for single-user configuration `rpcuser` and `rpcpassword` were "soon" to be deprecated.
The main reason for this deprecation is that while `-rpcpassword` stores the password in plain text, `-rpcauth` stores a hash, so it doesn't appe
...
💬 maflcko commented on issue "Wallet Missing Balances/Unspent":
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-2853910452)
> > Further, the spending tx here is a send-from-self-to-self, which should be listed in balance/listunspent when I ask for 0-conf as the limit, AFAIU, or at least should have an option to, which is a second bug.
>
> It only includes the utxo in the balance and in `listunspent` if it is available for spending. A transaction that is not in the mempool should not have any of its outputs available for spending since any attempt to spend them (currently) would result in a transaction that probably
...
(https://github.com/bitcoin/bitcoin/issues/28797#issuecomment-2853910452)
> > Further, the spending tx here is a send-from-self-to-self, which should be listed in balance/listunspent when I ask for 0-conf as the limit, AFAIU, or at least should have an option to, which is a second bug.
>
> It only includes the utxo in the balance and in `listunspent` if it is available for spending. A transaction that is not in the mempool should not have any of its outputs available for spending since any attempt to spend them (currently) would result in a transaction that probably
...
📝 crStiv opened a pull request: "docs: clarify RPC credentials security boundary"
(https://github.com/bitcoin/bitcoin/pull/32424)
Explicitly states that RPC credentials grant full administrative access to the node and filesystem resources accessible by bitcoind. Adds a new section in JSON-RPC-interface.md to address issue #32274 by documenting that providing RPC credentials to untrusted clients
(https://github.com/bitcoin/bitcoin/pull/32424)
Explicitly states that RPC credentials grant full administrative access to the node and filesystem resources accessible by bitcoind. Adds a new section in JSON-RPC-interface.md to address issue #32274 by documenting that providing RPC credentials to untrusted clients
💬 i5hi commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2853915109)
After looking further into this issue; I can understand removing the limits as a default config in core (although i would prefer it not to be this way) - but why is the ability to configure it being removed all together?
As a node runner I should be allowed to configure my mempool and not have it filled with what I consider spam. This can make running a node very RAM expensive.
A conservative approach would be to let the defaults be as it is and allow it to be increased for those who chos
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2853915109)
After looking further into this issue; I can understand removing the limits as a default config in core (although i would prefer it not to be this way) - but why is the ability to configure it being removed all together?
As a node runner I should be allowed to configure my mempool and not have it filled with what I consider spam. This can make running a node very RAM expensive.
A conservative approach would be to let the defaults be as it is and allow it to be increased for those who chos
...
💬 Eunovo commented on pull request "descriptors: taproot partial descriptors":
(https://github.com/bitcoin/bitcoin/pull/30243#issuecomment-2853955008)
Rebased on master.
(https://github.com/bitcoin/bitcoin/pull/30243#issuecomment-2853955008)
Rebased on master.
💬 stickies-v commented on pull request "validation: stricter internal handling of invalid blocks":
(https://github.com/bitcoin/bitcoin/pull/31405#discussion_r2075130957)
> So I have remove the commit that adds it for now.
That seems good to me.
> My understanding is that it must always pass if cs_main isn't held (because at that time, other threads could change the block index / invoke CBI themselves), but not necessarily while cs_main is held (not everything is atomic).
This still feels awkward to me, like we're sprinkling tests throughout the code in case they catch something without a clear aim. If we're trying to ensure that `InvalidateBlock()` doe
...
(https://github.com/bitcoin/bitcoin/pull/31405#discussion_r2075130957)
> So I have remove the commit that adds it for now.
That seems good to me.
> My understanding is that it must always pass if cs_main isn't held (because at that time, other threads could change the block index / invoke CBI themselves), but not necessarily while cs_main is held (not everything is atomic).
This still feels awkward to me, like we're sprinkling tests throughout the code in case they catch something without a clear aim. If we're trying to ensure that `InvalidateBlock()` doe
...
🤔 maflcko reviewed a pull request: "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory"
(https://github.com/bitcoin/bitcoin/pull/32423#pullrequestreview-2817605176)
concept ack
(https://github.com/bitcoin/bitcoin/pull/32423#pullrequestreview-2817605176)
concept ack
💬 maflcko commented on pull request "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory":
(https://github.com/bitcoin/bitcoin/pull/32423#discussion_r2075115534)
nit in 1b28314259952b70071eeeae11867e921729c4c7: Can drop the trailing newline, if you retouch.
(https://github.com/bitcoin/bitcoin/pull/32423#discussion_r2075115534)
nit in 1b28314259952b70071eeeae11867e921729c4c7: Can drop the trailing newline, if you retouch.
💬 maflcko commented on pull request "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory":
(https://github.com/bitcoin/bitcoin/pull/32423#discussion_r2075124023)
nit in 2392b4324777e002dc5363bac7f85cc6f8586818: For new code, `UCharCast` may be better than a "raw" cast, but only if you re-touch.
(https://github.com/bitcoin/bitcoin/pull/32423#discussion_r2075124023)
nit in 2392b4324777e002dc5363bac7f85cc6f8586818: For new code, `UCharCast` may be better than a "raw" cast, but only if you re-touch.
💬 stickies-v commented on pull request "validation: stricter internal handling of invalid blocks":
(https://github.com/bitcoin/bitcoin/pull/31405#discussion_r2075137416)
Thanks, the new comment "Children of failed blocks should be marked as BLOCK_FAILED_CHILD instead." works for me, can be marked as resolved.
(https://github.com/bitcoin/bitcoin/pull/31405#discussion_r2075137416)
Thanks, the new comment "Children of failed blocks should be marked as BLOCK_FAILED_CHILD instead." works for me, can be marked as resolved.
💬 stickies-v commented on pull request "validation: stricter internal handling of invalid blocks":
(https://github.com/bitcoin/bitcoin/pull/31405#discussion_r2075145379)
> So I have remove the commit that adds it for now.
Actually, it looks like 79bef1bc52afab860782d6d9a6016b93f94c4503 is still here (with HEAD 9d001dc1b1627f7a973e21227955bba1f473d6aa)
(https://github.com/bitcoin/bitcoin/pull/31405#discussion_r2075145379)
> So I have remove the commit that adds it for now.
Actually, it looks like 79bef1bc52afab860782d6d9a6016b93f94c4503 is still here (with HEAD 9d001dc1b1627f7a973e21227955bba1f473d6aa)
💬 laanwj commented on pull request "rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory":
(https://github.com/bitcoin/bitcoin/pull/32423#discussion_r2075159204)
self-nit: This could be `std::string_view` as well.
(https://github.com/bitcoin/bitcoin/pull/32423#discussion_r2075159204)
self-nit: This could be `std::string_view` as well.
💬 maflcko commented on pull request "miniscript refactor: Remove unique_ptr-indirection (#30866 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/31713#issuecomment-2854028630)
If there is a clang-tidy bug, it could make sense to minimize the reproducer and report/fix it upstream
(https://github.com/bitcoin/bitcoin/pull/31713#issuecomment-2854028630)
If there is a clang-tidy bug, it could make sense to minimize the reproducer and report/fix it upstream
✅ maflcko closed an issue: "ci: failures in cross-built Windows CI"
(https://github.com/bitcoin/bitcoin/issues/32197)
(https://github.com/bitcoin/bitcoin/issues/32197)
💬 maflcko commented on issue "ci: failures in cross-built Windows CI":
(https://github.com/bitcoin/bitcoin/issues/32197#issuecomment-2854038524)
4eee328a9820fe4f9b70129f25b65a2be1833596
(https://github.com/bitcoin/bitcoin/issues/32197#issuecomment-2854038524)
4eee328a9820fe4f9b70129f25b65a2be1833596
💬 hodlinator commented on pull request "miniscript refactor: Remove unique_ptr-indirection (#30866 follow-up)":
(https://github.com/bitcoin/bitcoin/pull/31713#issuecomment-2854049412)
> If there is a clang-tidy bug, it could make sense to minimize the reproducer and report/fix it upstream
Currently trying to just recreate the CI failure locally on NixOS instead of spamming subscribers of the PR (a bit involved due to clang-tidy depending on generated LLVM headers).
https://reviews.llvm.org/D72362 which added the recursion check does mention not supporting destructors.
(https://github.com/bitcoin/bitcoin/pull/31713#issuecomment-2854049412)
> If there is a clang-tidy bug, it could make sense to minimize the reproducer and report/fix it upstream
Currently trying to just recreate the CI failure locally on NixOS instead of spamming subscribers of the PR (a bit involved due to clang-tidy depending on generated LLVM headers).
https://reviews.llvm.org/D72362 which added the recursion check does mention not supporting destructors.