💬 achow101 commented on pull request "wallet: refactor: various master key encryption cleanups":
(https://github.com/bitcoin/bitcoin/pull/31398#issuecomment-2840450528)
ACK a8333fc9ff9adaa97a1f9024f5783cc071777150
(https://github.com/bitcoin/bitcoin/pull/31398#issuecomment-2840450528)
ACK a8333fc9ff9adaa97a1f9024f5783cc071777150
🚀 achow101 merged a pull request: "wallet: refactor: various master key encryption cleanups"
(https://github.com/bitcoin/bitcoin/pull/31398)
(https://github.com/bitcoin/bitcoin/pull/31398)
📝 w0xlt reopened a pull request: "Make `cs_db` mutex non-recursive"
(https://github.com/bitcoin/bitcoin/pull/32382)
Make `cs_db` mutex non-recursive (related to https://github.com/bitcoin/bitcoin/issues/19303).
(https://github.com/bitcoin/bitcoin/pull/32382)
Make `cs_db` mutex non-recursive (related to https://github.com/bitcoin/bitcoin/issues/19303).
💬 jlopp commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840479090)
> A change such as this will have severe consequences on storage space, disincentivizing users from running nodes.
Absolutely false, @jackedproxy. This policy change does not increase the total data throughput allowed on the network. If anything, one could argue that it does the opposite: OP_RETURN data is not discounted like witness data is, thus the size of blocks with data in OP_RETURNs is smaller than those with data in witnesses.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840479090)
> A change such as this will have severe consequences on storage space, disincentivizing users from running nodes.
Absolutely false, @jackedproxy. This policy change does not increase the total data throughput allowed on the network. If anything, one could argue that it does the opposite: OP_RETURN data is not discounted like witness data is, thus the size of blocks with data in OP_RETURNs is smaller than those with data in witnesses.
💬 jlopp commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840489884)
> Bitcoin's mempool and network already face challenges from known attack vectors like flood and loot attacks, replacement cycling, and irreversible fee attacks, which exploit transaction propagation and fee mechanics to burden nodes or disrupt confirmation reliability.
>
> By removing OP_RETURN limits, we risk introducing new vectors for abuse, such as flooding the network with large, unspendable data outputs, without clear mitigations. These could amplify mempool bloat, increase node resour
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840489884)
> Bitcoin's mempool and network already face challenges from known attack vectors like flood and loot attacks, replacement cycling, and irreversible fee attacks, which exploit transaction propagation and fee mechanics to burden nodes or disrupt confirmation reliability.
>
> By removing OP_RETURN limits, we risk introducing new vectors for abuse, such as flooding the network with large, unspendable data outputs, without clear mitigations. These could amplify mempool bloat, increase node resour
...
💬 blksqd commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840503560)
Seems to me that Peterodd has an agenda and this issue appears to reflect his wish to brute force this PR at all costs. That alone should make this change rejectable.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840503560)
Seems to me that Peterodd has an agenda and this issue appears to reflect his wish to brute force this PR at all costs. That alone should make this change rejectable.
💬 theStack commented on pull request "subprocess: Backport upstream changes":
(https://github.com/bitcoin/bitcoin/pull/32358#issuecomment-2840503906)
From what I found, the following merged upstream PRs since our initial cpp-subprocess import (see PR #28981, commit cc8b9875b104c31f0a5b5e4195a8278ec55f35f7, based on upstream https://github.com/arun11299/cpp-subprocess/commit/4025693decacaceb9420efedbf4967a04cb028e7) are not included yet in this PR branch:
* https://github.com/arun11299/cpp-subprocess/pull/106
* https://github.com/arun11299/cpp-subprocess/pull/107
Any reason for that? (Note that my review so far is only based on comparin
...
(https://github.com/bitcoin/bitcoin/pull/32358#issuecomment-2840503906)
From what I found, the following merged upstream PRs since our initial cpp-subprocess import (see PR #28981, commit cc8b9875b104c31f0a5b5e4195a8278ec55f35f7, based on upstream https://github.com/arun11299/cpp-subprocess/commit/4025693decacaceb9420efedbf4967a04cb028e7) are not included yet in this PR branch:
* https://github.com/arun11299/cpp-subprocess/pull/106
* https://github.com/arun11299/cpp-subprocess/pull/107
Any reason for that? (Note that my review so far is only based on comparin
...
📝 hebasto opened a pull request: "util: Remove `fsbridge::get_filesystem_error_message()`"
(https://github.com/bitcoin/bitcoin/pull/32383)
The `fsbridge::get_filesystem_error_message()` function exhibits several drawbacks:
1. It was introduced in https://github.com/bitcoin/bitcoin/pull/14192 to account for platform-specific variations in
`boost::filesystem::filesystem_error::what()`. Since [migrating](https://github.com/bitcoin/bitcoin/pull/20744) to `std::filesystem`, those discrepancies no longer exist.
2. It fails to display UTF-8 paths correctly on Windows:
```
> build\bin\Release\bitcoind.exe -datadir="C:\Users\hebast
...
(https://github.com/bitcoin/bitcoin/pull/32383)
The `fsbridge::get_filesystem_error_message()` function exhibits several drawbacks:
1. It was introduced in https://github.com/bitcoin/bitcoin/pull/14192 to account for platform-specific variations in
`boost::filesystem::filesystem_error::what()`. Since [migrating](https://github.com/bitcoin/bitcoin/pull/20744) to `std::filesystem`, those discrepancies no longer exist.
2. It fails to display UTF-8 paths correctly on Windows:
```
> build\bin\Release\bitcoind.exe -datadir="C:\Users\hebast
...
✅ w0xlt closed a pull request: "Make `cs_db` mutex non-recursive"
(https://github.com/bitcoin/bitcoin/pull/32382)
(https://github.com/bitcoin/bitcoin/pull/32382)
💬 hebasto commented on pull request "subprocess: Backport upstream changes":
(https://github.com/bitcoin/bitcoin/pull/32358#issuecomment-2840526058)
> From what I found, the following merged upstream PRs since our initial cpp-subprocess import (see PR #28981, commit [cc8b987](https://github.com/bitcoin/bitcoin/commit/cc8b9875b104c31f0a5b5e4195a8278ec55f35f7), based on upstream [arun11299/cpp-subprocess@4025693](https://github.com/arun11299/cpp-subprocess/commit/4025693decacaceb9420efedbf4967a04cb028e7)) are not included yet in this PR branch:
>
> * [Fix issues #103 and #104 arun11299/cpp-subprocess#106](https://github.com/arun11299/cp
...
(https://github.com/bitcoin/bitcoin/pull/32358#issuecomment-2840526058)
> From what I found, the following merged upstream PRs since our initial cpp-subprocess import (see PR #28981, commit [cc8b987](https://github.com/bitcoin/bitcoin/commit/cc8b9875b104c31f0a5b5e4195a8278ec55f35f7), based on upstream [arun11299/cpp-subprocess@4025693](https://github.com/arun11299/cpp-subprocess/commit/4025693decacaceb9420efedbf4967a04cb028e7)) are not included yet in this PR branch:
>
> * [Fix issues #103 and #104 arun11299/cpp-subprocess#106](https://github.com/arun11299/cp
...
💬 hebasto commented on pull request "subprocess: Backport upstream changes":
(https://github.com/bitcoin/bitcoin/pull/32358#issuecomment-2840530508)
> For easier review, it might make sense to add a list of the backported upstream PRs also to the PR description.
Thanks! Done.
(https://github.com/bitcoin/bitcoin/pull/32358#issuecomment-2840530508)
> For easier review, it might make sense to add a list of the backported upstream PRs also to the PR description.
Thanks! Done.
💬 21M4TW commented on issue "Allow sending untrusted utxos in the sendtoaddress api":
(https://github.com/bitcoin/bitcoin/issues/32034#issuecomment-2840543377)
If the utxo is coming from another wallet, you will need an external mechanism to sign it? Isn't the purpose of the createpsbt function?
(https://github.com/bitcoin/bitcoin/issues/32034#issuecomment-2840543377)
If the utxo is coming from another wallet, you will need an external mechanism to sign it? Isn't the purpose of the createpsbt function?
💬 0ceanSlim commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840552186)
> That makes no difference and everyone knows this, making it easier is not a strategy. That's like saying its easy for someone to jump over my fence, thus why should i be allowed to put up a fence? The point is Im deciding whether or not i want a fence and when you push a change that removes the option, you're going to make people furious over nothing... and per you're own argument it wouldn't change anything. If it doesn't change anything then its clearly not needed for any reason. The only re
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840552186)
> That makes no difference and everyone knows this, making it easier is not a strategy. That's like saying its easy for someone to jump over my fence, thus why should i be allowed to put up a fence? The point is Im deciding whether or not i want a fence and when you push a change that removes the option, you're going to make people furious over nothing... and per you're own argument it wouldn't change anything. If it doesn't change anything then its clearly not needed for any reason. The only re
...
💬 portlandhodl commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840658744)
Concept Ack
Same code is already being applied to at least 3-5% of hashrate today at MARA.
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840658744)
Concept Ack
Same code is already being applied to at least 3-5% of hashrate today at MARA.
💬 luke-jr commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840679141)
Concept NACK. At a minimum, it would need to tally up the total length (including the sizes of additional amount + script size fields) and ensure it remains under the datacarriersize limit. But also, such "protocols" are abusive and should not exist. Even if they were to be tolerated, they could just as well divide the existing datacarrier space without having multiple outputs.
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840679141)
Concept NACK. At a minimum, it would need to tally up the total length (including the sizes of additional amount + script size fields) and ensure it remains under the datacarriersize limit. But also, such "protocols" are abusive and should not exist. Even if they were to be tolerated, they could just as well divide the existing datacarrier space without having multiple outputs.
💬 chrisguida commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840679803)
Concept NACK, same reason as on https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833932824.
The proper solution is to [filter inscriptions](https://github.com/bitcoin/bitcoin/pull/28408), not to keep appeasing the spammers. The more we appease them, the more "economic demand" there will be to create spam.
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840679803)
Concept NACK, same reason as on https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833932824.
The proper solution is to [filter inscriptions](https://github.com/bitcoin/bitcoin/pull/28408), not to keep appeasing the spammers. The more we appease them, the more "economic demand" there will be to create spam.
💬 sbddesign commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840700497)
Concept ACK
As long as there is hashrate willing to include a non-standard OP_RETURN in a block, then no one single node's policy is going to prevent that OP_RETURN from entering a block. And if users are going to try and store data on-chain, using an output that does add to the existing UTXO set seems preferable.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840700497)
Concept ACK
As long as there is hashrate willing to include a non-standard OP_RETURN in a block, then no one single node's policy is going to prevent that OP_RETURN from entering a block. And if users are going to try and store data on-chain, using an output that does add to the existing UTXO set seems preferable.
💬 SergioDemianLerner commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840716517)
Concept ACK.
OP_RETURN not only allows arbitrary data to be included, it allows data that can be consumed by Bitcoin smart contracts with ESSPI (https://arxiv.org/abs/2503.02772). This facilitates the creation of Bitcoin L2s that need more expressive Bitcoin contracts to work.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840716517)
Concept ACK.
OP_RETURN not only allows arbitrary data to be included, it allows data that can be consumed by Bitcoin smart contracts with ESSPI (https://arxiv.org/abs/2503.02772). This facilitates the creation of Bitcoin L2s that need more expressive Bitcoin contracts to work.
💬 albertoig commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840718366)
Concept NACK. This is a direct method of attack.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840718366)
Concept NACK. This is a direct method of attack.
💬 abdelrahman543873 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840751279)
The proposed Bitcoin Core change could pose risks to Bitcoin's usability and decentralization by allowing more non-financial data, potentially bloating the blockchain and making it harder for regular users to run nodes. This might centralize control, as only those with significant resources could manage full nodes
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840751279)
The proposed Bitcoin Core change could pose risks to Bitcoin's usability and decentralization by allowing more non-financial data, potentially bloating the blockchain and making it harder for regular users to run nodes. This might centralize control, as only those with significant resources could manage full nodes