💬 TheGuySwann commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839584321)
NACK
Not only is this issue deeply controversial and the standard has been since the beginning to not force or push changes that are controversial and this is a horrible look and will create pointless distrust in Core, but continuing to spend time on this issue and making changes for the sake of making changes when nobody asked for this is such a profound waste of time and resources.
This is only showing people that core isn't interested in what the users or the network actually care about
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839584321)
NACK
Not only is this issue deeply controversial and the standard has been since the beginning to not force or push changes that are controversial and this is a horrible look and will create pointless distrust in Core, but continuing to spend time on this issue and making changes for the sake of making changes when nobody asked for this is such a profound waste of time and resources.
This is only showing people that core isn't interested in what the users or the network actually care about
...
💬 fanquake commented on issue "build: x86 afl++ ASan build broken "error: inline assembly requires more registers than available"":
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2839586999)
I think the issue here is similar to #32323. The user provided flags (to override the hardening options) aren't checked during CMake compiler checks, which means the disabling doesn't actually happen when using afl. As far as I can tell this also isn't fixed by #32367. Will open a PR to further patch fcf-protection out.
(https://github.com/bitcoin/bitcoin/issues/31913#issuecomment-2839586999)
I think the issue here is similar to #32323. The user provided flags (to override the hardening options) aren't checked during CMake compiler checks, which means the disabling doesn't actually happen when using afl. As far as I can tell this also isn't fixed by #32367. Will open a PR to further patch fcf-protection out.
💬 rot13maxi commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839587470)
Here’s an opreturn from a year ago that contains a base64-encoded dickbutt: https://mempool.space/tx/8c9fe58186c199fa9f8d72c121a45270f70d3854e67238f3c7c319989a50921b
Not mined by MARA btw.
if someone wants to put something fun or malicious in an opreturn, its not hard.
Also, if inscriptions ever became a popular mechanism for content that was illegal or politically unpopular and people/companies/LEO wanted to scan for it, its trivial to add (the hashes of) inscription-encoded versions
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2839587470)
Here’s an opreturn from a year ago that contains a base64-encoded dickbutt: https://mempool.space/tx/8c9fe58186c199fa9f8d72c121a45270f70d3854e67238f3c7c319989a50921b
Not mined by MARA btw.
if someone wants to put something fun or malicious in an opreturn, its not hard.
Also, if inscriptions ever became a popular mechanism for content that was illegal or politically unpopular and people/companies/LEO wanted to scan for it, its trivial to add (the hashes of) inscription-encoded versions
...
📝 hebasto opened a pull request: "[PoC] Modernize use of UTF-8 in Windows code"
(https://github.com/bitcoin/bitcoin/pull/32380)
The main goal is to remove [deprecated](https://github.com/bitcoin/bitcoin/issues/32361) code (removed in C++26).
This PR demonstrates Microsoft's modern [approach](https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page) to handling UTF-8:
> Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured
...
(https://github.com/bitcoin/bitcoin/pull/32380)
The main goal is to remove [deprecated](https://github.com/bitcoin/bitcoin/issues/32361) code (removed in C++26).
This PR demonstrates Microsoft's modern [approach](https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page) to handling UTF-8:
> Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured
...
💬 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