💬 D33r-Gee commented on pull request "interface: Expose load utxo snapshot functionality":
(https://github.com/bitcoin-core/gui/pull/869#issuecomment-2839736166)
> when qml is ready and it is being up-streamed, this feature, which you find useful as part of the qml change-set, would then be packaged up as part of the PR's integrating this into core.
Thank you for explaining the relationship between this interface change and the QML project so clearly. I see now that my timing was off, and this change is contingent upon the QML GUI being ready for upstreaming, not a standalone addition for the current GUI.
Just to ensure I've fully grasped the workf
...
(https://github.com/bitcoin-core/gui/pull/869#issuecomment-2839736166)
> when qml is ready and it is being up-streamed, this feature, which you find useful as part of the qml change-set, would then be packaged up as part of the PR's integrating this into core.
Thank you for explaining the relationship between this interface change and the QML project so clearly. I see now that my timing was off, and this change is contingent upon the QML GUI being ready for upstreaming, not a standalone addition for the current GUI.
Just to ensure I've fully grasped the workf
...
🤔 mzumsande reviewed a pull request: "refactor: validation: mark CheckBlockIndex as const"
(https://github.com/bitcoin/bitcoin/pull/32364#pullrequestreview-2804523333)
Concept ACK
Don't really love duplicating `GetAll` in the second commit, but if there is no better solution, marking CBI as const seems more important.
(https://github.com/bitcoin/bitcoin/pull/32364#pullrequestreview-2804523333)
Concept ACK
Don't really love duplicating `GetAll` in the second commit, but if there is no better solution, marking CBI as const seems more important.
💬 achow101 commented on pull request "psbt: add non-default sighash types to PSBTs and unify sighash type match checking":
(https://github.com/bitcoin/bitcoin/pull/31622#discussion_r2067073053)
DEFAULT becomes ALL for non-taproot. It's just easier to put DEFAULT everywhere since it covers all cases.
(https://github.com/bitcoin/bitcoin/pull/31622#discussion_r2067073053)
DEFAULT becomes ALL for non-taproot. It's just easier to put DEFAULT everywhere since it covers all cases.
🤔 jaonoctus reviewed a pull request: "Remove arbitrary limits on OP_Return (datacarrier) outputs"
(https://github.com/bitcoin/bitcoin/pull/32359#pullrequestreview-2804538701)
Concept ACK
This is just a mempool policy and other implementations, like Libre Relay, "bypass" it. So I don't see a reason to filter transactions from the mempool if we're still going to accept them in blocks. So if someone wants to broadcast a certain type of transaction that follows the consensus rules validated by nodes and they are paying for, they should be able to
(https://github.com/bitcoin/bitcoin/pull/32359#pullrequestreview-2804538701)
Concept ACK
This is just a mempool policy and other implementations, like Libre Relay, "bypass" it. So I don't see a reason to filter transactions from the mempool if we're still going to accept them in blocks. So if someone wants to broadcast a certain type of transaction that follows the consensus rules validated by nodes and they are paying for, they should be able to
💬 dibend commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839757016)
I own hashfs.com want to buy that for your side project or do you want a currency it's called coin for a reason
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839757016)
I own hashfs.com want to buy that for your side project or do you want a currency it's called coin for a reason
💬 murchandamus commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839802096)
Concept ACK on removing the limit on OP_RETURN size and count.
The limit on OP_RETURNs size is ineffectual, causes increased node traffic, and drives mining centralization. While I have no personal desire for more large OP_RETURNs on the blockchain, it is preferable to have data be written into OP_RETURNs than the UTXO set, and it is preferable to see the transactions I’m competing with in my mempool, than to incentivize build-out of mechanisms for direct submission to the largest mining pool
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839802096)
Concept ACK on removing the limit on OP_RETURN size and count.
The limit on OP_RETURNs size is ineffectual, causes increased node traffic, and drives mining centralization. While I have no personal desire for more large OP_RETURNs on the blockchain, it is preferable to have data be written into OP_RETURNs than the UTXO set, and it is preferable to see the transactions I’m competing with in my mempool, than to incentivize build-out of mechanisms for direct submission to the largest mining pool
...
🤔 janb84 reviewed a pull request: "fuzz: doc: add info about `afl-system-config` for macOS"
(https://github.com/bitcoin/bitcoin/pull/32175#pullrequestreview-2804587876)
reACK [61ea5f3](https://github.com/bitcoin/bitcoin/pull/32175/commits/61ea5f348da71b886807c0492587835dd7e57499)
Changes since last ACK:
- none, CI related push
(https://github.com/bitcoin/bitcoin/pull/32175#pullrequestreview-2804587876)
reACK [61ea5f3](https://github.com/bitcoin/bitcoin/pull/32175/commits/61ea5f348da71b886807c0492587835dd7e57499)
Changes since last ACK:
- none, CI related push
💬 gavinmclelland commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839861569)
This change brings Bitcoin closer to its original spirit as designed by Satoshi Nakamoto.
Early Bitcoin allowed arbitrary data to be recorded on-chain without hardcoded limits. OP_RETURN and transaction outputs were intended to serve general-purpose timestamping, settlement, and proof anchoring, governed by economic incentives rather than protocol constraints.
Removing arbitrary datacarrier size limits aligns with the principle that Bitcoin should be a flexible, permissionless settlement layer
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839861569)
This change brings Bitcoin closer to its original spirit as designed by Satoshi Nakamoto.
Early Bitcoin allowed arbitrary data to be recorded on-chain without hardcoded limits. OP_RETURN and transaction outputs were intended to serve general-purpose timestamping, settlement, and proof anchoring, governed by economic incentives rather than protocol constraints.
Removing arbitrary datacarrier size limits aligns with the principle that Bitcoin should be a flexible, permissionless settlement layer
...
💬 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.