💬 achow101 commented on pull request "Remove the legacy wallet and BDB dependency":
(https://github.com/bitcoin/bitcoin/pull/28710#issuecomment-2839914088)
> The `updateWatchOnlyLabels` stuff is still wrong. I think the entire second column for watch-only needs to be stripped from the GUI. But at least not rendered.
Fixed it so it doesn't render. The full removal can be done in a followup.
(https://github.com/bitcoin/bitcoin/pull/28710#issuecomment-2839914088)
> The `updateWatchOnlyLabels` stuff is still wrong. I think the entire second column for watch-only needs to be stripped from the GUI. But at least not rendered.
Fixed it so it doesn't render. The full removal can be done in a followup.
💬 cbspears commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839926151)
Concept ACK. Relay policies should be updated to match consensus rules, especially when there is demonstrated demand for nonstandard transaction types that are not identified as DoS attack vectors.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839926151)
Concept ACK. Relay policies should be updated to match consensus rules, especially when there is demonstrated demand for nonstandard transaction types that are not identified as DoS attack vectors.
💬 sonoranai commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839940404)
NACK—lifting OP_RETURN limits trades off blockchain efficiency for marginal utility, risking bloat and undermining Bitcoin’s core monetary use-case. This should not proceed.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839940404)
NACK—lifting OP_RETURN limits trades off blockchain efficiency for marginal utility, risking bloat and undermining Bitcoin’s core monetary use-case. This should not proceed.
💬 davidgumberg commented on pull request "net: remove unnecessary check from AlreadyConnectedToAddress()":
(https://github.com/bitcoin/bitcoin/pull/32338#issuecomment-2839948463)
crACK f1b142856a4ecd0a0d90bc3d
To rephrase the justification in 94e85a82a753a0aa's commit message and the PR description, because the first check (`FindNode(CNetAddr(addr))`), is indifferent to `addr`'s port (`CNetAddr` [has no](https://github.com/bitcoin/bitcoin/blob/f1b142856a4ecd0a0d90bc3d73ef5137997b14ff/src/netaddress.h#L108-L130) `port` member.), if the first, less specific check for just the address fails, the second more specific check for the address and port will always fail.
I r
...
(https://github.com/bitcoin/bitcoin/pull/32338#issuecomment-2839948463)
crACK f1b142856a4ecd0a0d90bc3d
To rephrase the justification in 94e85a82a753a0aa's commit message and the PR description, because the first check (`FindNode(CNetAddr(addr))`), is indifferent to `addr`'s port (`CNetAddr` [has no](https://github.com/bitcoin/bitcoin/blob/f1b142856a4ecd0a0d90bc3d73ef5137997b14ff/src/netaddress.h#L108-L130) `port` member.), if the first, less specific check for just the address fails, the second more specific check for the address and port will always fail.
I r
...
💬 sonoranai commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839963236)
> Removing arbitrary datacarrier size limits aligns with the principle that Bitcoin should be a flexible, permissionless settlement layer — where fees, not code, decide the economic viability of embedding metadata.
That position overlooks a critical reality:
Bitcoin’s economic viability isn’t solely determined by fees but also by node operability and decentralization.
Removing OP_RETURN limits opens the door to systematic blockchain bloat, disproportionately burdening smaller
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839963236)
> Removing arbitrary datacarrier size limits aligns with the principle that Bitcoin should be a flexible, permissionless settlement layer — where fees, not code, decide the economic viability of embedding metadata.
That position overlooks a critical reality:
Bitcoin’s economic viability isn’t solely determined by fees but also by node operability and decentralization.
Removing OP_RETURN limits opens the door to systematic blockchain bloat, disproportionately burdening smaller
...
💬 LaurentMT commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840080051)
Concept NACK.
This proposal won't allow to reach the stated goal (limiting the misuse of witness data) if the incentives model isn't aligned too but doing it is likely to be very contentious.
As is, data stored in an op_return output will consume more resources (block weight) than the same amount of data stored in the witness and as a consequence will do more harm than good by providing a "solution" that decreases the utility provided by the network (independently of how this utility is me
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840080051)
Concept NACK.
This proposal won't allow to reach the stated goal (limiting the misuse of witness data) if the incentives model isn't aligned too but doing it is likely to be very contentious.
As is, data stored in an op_return output will consume more resources (block weight) than the same amount of data stored in the witness and as a consequence will do more harm than good by providing a "solution" that decreases the utility provided by the network (independently of how this utility is me
...
💬 LaurentMT commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840080546)
Concept NACK.
This proposal won't allow to reach the stated goal (limiting the misuse of witness data) if the incentives model isn't aligned too but doing it is likely to be very contentious.
As is, data stored in an op_return output will consume more resources (block weight) than the same amount of data stored in the witness and as a consequence will do more harm than good by providing a "solution" that decreases the utility provided by the network (independently of how this utility is me
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840080546)
Concept NACK.
This proposal won't allow to reach the stated goal (limiting the misuse of witness data) if the incentives model isn't aligned too but doing it is likely to be very contentious.
As is, data stored in an op_return output will consume more resources (block weight) than the same amount of data stored in the witness and as a consequence will do more harm than good by providing a "solution" that decreases the utility provided by the network (independently of how this utility is me
...
💬 alecov commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840120671)
NAK. This is nonsense. There's already a fuckton of L1s doing exactly that.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840120671)
NAK. This is nonsense. There's already a fuckton of L1s doing exactly that.
💬 miketwenty1 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840126837)
Concept ACK.
Right now AFAIK:
- 1 standardness OP_RETURN per transaction, capped on size.
- People who want to bypass this limit use specialized services and send transactions directly to miners.
- "Clever" ideas have come about to embed data arbitrarily within rules of replay standardness, and these utxo's cannot be pruned, unlike OP_RETURN data.
- If the rules to cap OP_RETURN didn't exist, perhaps the current trend of embedding into witness data and creating forever dust wouldn't have
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840126837)
Concept ACK.
Right now AFAIK:
- 1 standardness OP_RETURN per transaction, capped on size.
- People who want to bypass this limit use specialized services and send transactions directly to miners.
- "Clever" ideas have come about to embed data arbitrarily within rules of replay standardness, and these utxo's cannot be pruned, unlike OP_RETURN data.
- If the rules to cap OP_RETURN didn't exist, perhaps the current trend of embedding into witness data and creating forever dust wouldn't have
...
📝 darosior opened a pull request: "policy: allow more than one OP_RETURN outputs per tx"
(https://github.com/bitcoin/bitcoin/pull/32381)
Please keep conceptual discussions on the corresponding [mailing list thread](https://gnusha.org/pi/bitcoindev/rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com
).
Because of the restriction on the number of `OP_RETURN` outputs per transaction, people are designing protocols that store data in non-pruneable and unspendable outputs. Lift this restriction to stop preventing them from using a less harmful way of achieving
...
(https://github.com/bitcoin/bitcoin/pull/32381)
Please keep conceptual discussions on the corresponding [mailing list thread](https://gnusha.org/pi/bitcoindev/rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com
).
Because of the restriction on the number of `OP_RETURN` outputs per transaction, people are designing protocols that store data in non-pruneable and unspendable outputs. Lift this restriction to stop preventing them from using a less harmful way of achieving
...
👋 darosior's pull request is ready for review: "policy: allow more than one OP_RETURN outputs per tx"
(https://github.com/bitcoin/bitcoin/pull/32381)
(https://github.com/bitcoin/bitcoin/pull/32381)
💬 TheCharlatan commented on pull request "Add bitcoin-{node,gui} to release binaries for IPC":
(https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2067359715)
> Fixed. @TheCharlatan why was this set to Yes in the original?
It did not make that much sense to include since it was not part of the release binaries yet, but I thought it could be considered a runtime dependency in case it is not linked statically through depends or some other method.
(https://github.com/bitcoin/bitcoin/pull/31802#discussion_r2067359715)
> Fixed. @TheCharlatan why was this set to Yes in the original?
It did not make that much sense to include since it was not part of the release binaries yet, but I thought it could be considered a runtime dependency in case it is not linked statically through depends or some other method.
💬 TheCharlatan commented on pull request "Add bitcoin-{node,gui} to release binaries for IPC":
(https://github.com/bitcoin/bitcoin/pull/31802#issuecomment-2840157913)
Concept ACK
> An alternative approach could be to make Cap'n Proto optional and have -DENABLE_IPC default to ON only if its present. Though I vaguely recall that with CMake we wanted to move away from enabling config options depending on whether a library is found.
Yeah, this is intentionally not done anymore since the cmake migration. I think the current approach is fine.
(https://github.com/bitcoin/bitcoin/pull/31802#issuecomment-2840157913)
Concept ACK
> An alternative approach could be to make Cap'n Proto optional and have -DENABLE_IPC default to ON only if its present. Though I vaguely recall that with CMake we wanted to move away from enabling config options depending on whether a library is found.
Yeah, this is intentionally not done anymore since the cmake migration. I think the current approach is fine.
💬 fjahr commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840158373)
Concept ACK to remove the limits on OP_RETURN (both size and count). I don't see a need to remove the config options at this point and would support keeping them in at this point, with a deprecation message. Though that is not a blocker for me.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2840158373)
Concept ACK to remove the limits on OP_RETURN (both size and count). I don't see a need to remove the config options at this point and would support keeping them in at this point, with a deprecation message. Though that is not a blocker for me.
📝 w0xlt opened 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).
💬 l0rinc commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840165283)
Would it be possible to summarize the pros and cons raised across the internets in the PR description - if for no other reason, to avoid repeated comments on the same topic? Maybe it would help bring the two sides together on this admittedly contentious issue, where both have valid concerns and good arguments.
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840165283)
Would it be possible to summarize the pros and cons raised across the internets in the PR description - if for no other reason, to avoid repeated comments on the same topic? Maybe it would help bring the two sides together on this admittedly contentious issue, where both have valid concerns and good arguments.
💬 jarolrod commented on pull request "interface: Expose load utxo snapshot functionality":
(https://github.com/bitcoin-core/gui/pull/869#issuecomment-2840173805)
@D33r-Gee no, your interface changes are part of what gets merged into the qml repo. It is part of the changeset to implement your assumeutxo work -> in the qml repo all in the qml repo. Then the process of packaging it up to upstream is, primarily, outside of your concern. I am just mentioning this to show why this shouldn't be open here.
(https://github.com/bitcoin-core/gui/pull/869#issuecomment-2840173805)
@D33r-Gee no, your interface changes are part of what gets merged into the qml repo. It is part of the changeset to implement your assumeutxo work -> in the qml repo all in the qml repo. Then the process of packaging it up to upstream is, primarily, outside of your concern. I am just mentioning this to show why this shouldn't be open here.
📝 w0xlt converted_to_draft 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).
✅ 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)
💬 nsvrn commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840175804)
"allow" when no one is asking for this and has no positive effect or other basis, on that reason Concept NACK
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2840175804)
"allow" when no one is asking for this and has no positive effect or other basis, on that reason Concept NACK