💬 hebasto commented on issue "windows: usage of deprecated `std:wstring_convert`":
(https://github.com/bitcoin/bitcoin/issues/32361#issuecomment-2839589640)
> Great, good to know that's possible. i guess by the time we switch to C++26 and this becomes a blocking issue, it will be fine to require a 2019 windows version, and we can simplify things by using the "ASCII" Windows APIs everywhere and provide strings as-is. This would also allow dropping the leveldb patch.
A proof of concept is available in https://github.com/bitcoin/bitcoin/pull/32380.
(https://github.com/bitcoin/bitcoin/issues/32361#issuecomment-2839589640)
> Great, good to know that's possible. i guess by the time we switch to C++26 and this becomes a blocking issue, it will be fine to require a 2019 windows version, and we can simplify things by using the "ASCII" Windows APIs everywhere and provide strings as-is. This would also allow dropping the leveldb patch.
A proof of concept is available in https://github.com/bitcoin/bitcoin/pull/32380.
💬 jarolrod commented on pull request "interface: Expose load utxo snapshot functionality":
(https://github.com/bitcoin-core/gui/pull/869#issuecomment-2839604209)
@D33r-Gee as we discussed a while ago, this is part (ultimately) of the qml change-set, 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.
This wouldn't be integrated into the qt widgets gui if qml is to replace it.
As is, this should be closed because the qt widgets gui can't use it, so this function goes to no-one.
(https://github.com/bitcoin-core/gui/pull/869#issuecomment-2839604209)
@D33r-Gee as we discussed a while ago, this is part (ultimately) of the qml change-set, 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.
This wouldn't be integrated into the qt widgets gui if qml is to replace it.
As is, this should be closed because the qt widgets gui can't use it, so this function goes to no-one.
💬 achow101 commented on issue "Cannot import descriptors with label and internal:false":
(https://github.com/bitcoin/bitcoin/issues/32376#issuecomment-2839612285)
#31514
(https://github.com/bitcoin/bitcoin/issues/32376#issuecomment-2839612285)
#31514
💬 TheGuySwann commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839617670)
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 reas
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839617670)
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 reas
...
💬 achow101 commented on issue "Stop shipping ARM32 builds for releases?":
(https://github.com/bitcoin/bitcoin/issues/32375#issuecomment-2839631534)
IIRC, Raspberry Pi OS only started shipping 64-bit OSes a couple of years ago. For a while, you could buy a Pi 3 or 4 which had 64-bit hardware but the available Raspberry Pi OS image was only 32-bit. I would imagine that several of these machines are probably still in use. It also seems like the 32-bit images are still prominently shown on their [website](https://www.raspberrypi.com/software/operating-systems/) so I think it may be a bit premature to stop shipping 32-bit?
(https://github.com/bitcoin/bitcoin/issues/32375#issuecomment-2839631534)
IIRC, Raspberry Pi OS only started shipping 64-bit OSes a couple of years ago. For a while, you could buy a Pi 3 or 4 which had 64-bit hardware but the available Raspberry Pi OS image was only 32-bit. I would imagine that several of these machines are probably still in use. It also seems like the 32-bit images are still prominently shown on their [website](https://www.raspberrypi.com/software/operating-systems/) so I think it may be a bit premature to stop shipping 32-bit?
💬 Psifour commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839636874)
Concept ACK
I support reducing/eliminating standardness rules where possible; however, the inclusion of a reduction in user (node runner) choice is unacceptable. Simplify this to just a change of the default value to match the blocksize or transaction size limits and I am 100% onboard.
I may think that it is illogical to do so, but I support having the `-datacarrier` and `-datacarriersize` flags remain available for those who feel they need them. Doing so is relatively trivial and comes wi
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839636874)
Concept ACK
I support reducing/eliminating standardness rules where possible; however, the inclusion of a reduction in user (node runner) choice is unacceptable. Simplify this to just a change of the default value to match the blocksize or transaction size limits and I am 100% onboard.
I may think that it is illogical to do so, but I support having the `-datacarrier` and `-datacarriersize` flags remain available for those who feel they need them. Doing so is relatively trivial and comes wi
...
💬 owenstrevor commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839647089)
Concept ACK.
Since @pinheadmz is allowing @wizkid057 from Ocean Mining—an organization that has repeatedly demonstrated impractical and ideologically-driven positions disconnected from reality—to keep his off-topic rant here, I trust the moderators will remain unbiased by similarly allowing myself and others the opportunity to respond to it.
> > Moderation suggestion: close to non-contributors.
>
> This is far more than a small technical change, so the broader community should not be sh
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839647089)
Concept ACK.
Since @pinheadmz is allowing @wizkid057 from Ocean Mining—an organization that has repeatedly demonstrated impractical and ideologically-driven positions disconnected from reality—to keep his off-topic rant here, I trust the moderators will remain unbiased by similarly allowing myself and others the opportunity to respond to it.
> > Moderation suggestion: close to non-contributors.
>
> This is far more than a small technical change, so the broader community should not be sh
...
🚀 achow101 merged a pull request: "descriptors: Reject + sign while parsing unsigned"
(https://github.com/bitcoin/bitcoin/pull/32365)
(https://github.com/bitcoin/bitcoin/pull/32365)
💬 crownbtc commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839663264)
NACK
Echoing the reasons stated by @TheGuySwann
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839663264)
NACK
Echoing the reasons stated by @TheGuySwann
💬 matthew-ellis commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839687218)
Bitcoin’s success rests on prioritizing decentralization and minimizing the resource burden on full nodes over time.
Removing arbitrary limits on OP_RETURN data increases the risk of blockchain bloat for marginal benefit. Even if fees partially discourage abuse, Bitcoin’s adversarial environment teaches that any opening for data monetization will eventually be exploited.
Every additional byte recorded imposes a cost not just today but permanently on future node operators, many of whom may not
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839687218)
Bitcoin’s success rests on prioritizing decentralization and minimizing the resource burden on full nodes over time.
Removing arbitrary limits on OP_RETURN data increases the risk of blockchain bloat for marginal benefit. Even if fees partially discourage abuse, Bitcoin’s adversarial environment teaches that any opening for data monetization will eventually be exploited.
Every additional byte recorded imposes a cost not just today but permanently on future node operators, many of whom may not
...
💬 billylindeman commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839688587)
Concept NACK,
Making it easier to embed files in bitcoin is fundamentally the opposite direction I would like to see the project go. Might be time to fork core if this gets merged in. Bitcoin is money, let's keep it that way.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839688587)
Concept NACK,
Making it easier to embed files in bitcoin is fundamentally the opposite direction I would like to see the project go. Might be time to fork core if this gets merged in. Bitcoin is money, let's keep it that way.
💬 darosior commented on pull request "p2p: stop special-casing witness-stripped error for unconfirmed transactions":
(https://github.com/bitcoin/bitcoin/pull/32379#discussion_r2067062143)
Done.
(https://github.com/bitcoin/bitcoin/pull/32379#discussion_r2067062143)
Done.
💬 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
...