💬 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
💬 nolim1t commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840754876)
> > Moderation suggestion: close to non-contributors.
>
> This is far more than a small technical change, so the broader community should not be shut out of the discussion or shuffled off to the mailing list. This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety.
>
> * Merging this PR means Bitcoin is no longer a decentralized currency.
>
> * Merging this PR means Bitcoin is no longer money.
>
> * Merging this PR means Bitcoin is
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840754876)
> > Moderation suggestion: close to non-contributors.
>
> This is far more than a small technical change, so the broader community should not be shut out of the discussion or shuffled off to the mailing list. This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety.
>
> * Merging this PR means Bitcoin is no longer a decentralized currency.
>
> * Merging this PR means Bitcoin is no longer money.
>
> * Merging this PR means Bitcoin is
...
💬 leCheeseRoyale commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840771858)
Additional Concerns – Concept NACK
While many critical points have already been raised, I’d like to highlight several underdiscussed but significant risks introduced by this PR:
1. Fee Market Distortion via “Cheap” OP_RETURNs
Removing all limits on OP_RETURNs creates a perverse incentive: transactions can now carry large, non-economic payloads while avoiding long-term storage costs (since OP_RETURNs don’t enter the UTXO set).This allows chain data to be subsidized at rates far below wh
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840771858)
Additional Concerns – Concept NACK
While many critical points have already been raised, I’d like to highlight several underdiscussed but significant risks introduced by this PR:
1. Fee Market Distortion via “Cheap” OP_RETURNs
Removing all limits on OP_RETURNs creates a perverse incentive: transactions can now carry large, non-economic payloads while avoiding long-term storage costs (since OP_RETURNs don’t enter the UTXO set).This allows chain data to be subsidized at rates far below wh
...
💬 adamdecaf commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840792912)
Concept Nack
Other coins can and have implemented wasteful experiments. There's no reason or authority to make Bitcoin into a shitcoin. Leave the hardest money on the planet alone and let it fix the world.
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840792912)
Concept Nack
Other coins can and have implemented wasteful experiments. There's no reason or authority to make Bitcoin into a shitcoin. Leave the hardest money on the planet alone and let it fix the world.
💬 leCheeseRoyale commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840803515)
Also peter todd, eric wall, and udi are all bad actors. homos
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840803515)
Also peter todd, eric wall, and udi are all bad actors. homos
💬 Bue-von-hon commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2840828249)
@luke-jr @instagibbs @maflcko @rkrux @glozow @adamandrews1 @w0xlt @1440000bytes
gentle ping.
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2840828249)
@luke-jr @instagibbs @maflcko @rkrux @glozow @adamandrews1 @w0xlt @1440000bytes
gentle ping.