✅ maflcko closed an issue: "Consider making 27.x Long-Term Support (LTS)"
(https://github.com/bitcoin/bitcoin/issues/31068)
(https://github.com/bitcoin/bitcoin/issues/31068)
💬 maflcko commented on issue "Consider making 27.x Long-Term Support (LTS)":
(https://github.com/bitcoin/bitcoin/issues/31068#issuecomment-2853860202)
The feature request didn't seem to attract much attention in the past. Thus, closing due to lack of interest, progress and direction.
Pull requests with improvements are always welcome. Moreover, it is possible to re-open this issue or create a new issue referencing it, if there is fresh interest.
(https://github.com/bitcoin/bitcoin/issues/31068#issuecomment-2853860202)
The feature request didn't seem to attract much attention in the past. Thus, closing due to lack of interest, progress and direction.
Pull requests with improvements are always welcome. Moreover, it is possible to re-open this issue or create a new issue referencing it, if there is fresh interest.
💬 Sjors commented on pull request "Shuffle depends instructions and recommend modern make for macOS":
(https://github.com/bitcoin/bitcoin/pull/32086#discussion_r2075080871)
https://github.com/bitcoin/bitcoin/compare/7238f242d78f3d71834764031d7904d19525bab3..22cff32319de64cb98e1c89b9a7ed35611e89e27
(https://github.com/bitcoin/bitcoin/pull/32086#discussion_r2075080871)
https://github.com/bitcoin/bitcoin/compare/7238f242d78f3d71834764031d7904d19525bab3..22cff32319de64cb98e1c89b9a7ed35611e89e27
💬 fanquake commented on pull request "Shuffle depends instructions and recommend modern make for macOS":
(https://github.com/bitcoin/bitcoin/pull/32086#discussion_r2075081228)
Not sure what you mean. There's no need to change anything here, the Windows example was fine before your PR, and is still fine now.
(https://github.com/bitcoin/bitcoin/pull/32086#discussion_r2075081228)
Not sure what you mean. There's no need to change anything here, the Windows example was fine before your PR, and is still fine now.
✅ maflcko closed an issue: "Bitcoin Core on mainnet shows testnet3 dir as a wallet to open and allows opening it"
(https://github.com/bitcoin/bitcoin/issues/16107)
(https://github.com/bitcoin/bitcoin/issues/16107)
💬 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)