💬 sipa commented on pull request "Add functional test for IPC interface":
(https://github.com/bitcoin/bitcoin/pull/33201#discussion_r2320004970)
Ok, added `--break-system-packages` back to the 4 CI jobs that failed as a result of removing it globally.
(https://github.com/bitcoin/bitcoin/pull/33201#discussion_r2320004970)
Ok, added `--break-system-packages` back to the 4 CI jobs that failed as a result of removing it globally.
💬 willcl-ark commented on issue "ci: GHA fallback centos task runs out of space":
(https://github.com/bitcoin/bitcoin/issues/33293#issuecomment-3250566706)
Seems we are probably already swapping before we start the functional tests:
https://github.com/willcl-ark/bitcoin/actions/runs/17442003339/job/49527090325#step:8:3768
I tested cleaning scratch dir and object files in this run which got it to pass. They seem the obvious choices to me to remove (probably right after building), any other ideas here?
(https://github.com/bitcoin/bitcoin/issues/33293#issuecomment-3250566706)
Seems we are probably already swapping before we start the functional tests:
https://github.com/willcl-ark/bitcoin/actions/runs/17442003339/job/49527090325#step:8:3768
I tested cleaning scratch dir and object files in this run which got it to pass. They seem the obvious choices to me to remove (probably right after building), any other ideas here?
⚠️ AceHack opened an issue: "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3"
(https://github.com/bitcoin/bitcoin/issues/33298)
This is a significant security issue. I don't want to allow easily decodable images in my transactions because, by law, I would then be responsible for content moderation. Please save Bitcoin for the little guys like me so we can continue to run a node and home miners legally without fear. I hope nothing immoral or illicit that is easily decodable ever makes it into the actual chain, the miner responsible should be immediately arrested who mined that block. I don't want to relay this crap eit
...
(https://github.com/bitcoin/bitcoin/issues/33298)
This is a significant security issue. I don't want to allow easily decodable images in my transactions because, by law, I would then be responsible for content moderation. Please save Bitcoin for the little guys like me so we can continue to run a node and home miners legally without fear. I hope nothing immoral or illicit that is easily decodable ever makes it into the actual chain, the miner responsible should be immediately arrested who mined that block. I don't want to relay this crap eit
...
💬 ryanofsky commented on issue "cmake: Errors not actually errors?":
(https://github.com/bitcoin/bitcoin/issues/33153#issuecomment-3250597155)
> Since we want to distribute our own packages, we have no way to provide .pc files that are not broken.
This seems like a reason not to distribute .pc files, but it doesn't seem like a reason not to generate them in local builds and generate them for package managers. There are other build systems besides cmake, and it seems like it would be nice if you could build and install the kernel from source or use a package manager, and build against the library in a meson project, or rust/zig/python/
...
(https://github.com/bitcoin/bitcoin/issues/33153#issuecomment-3250597155)
> Since we want to distribute our own packages, we have no way to provide .pc files that are not broken.
This seems like a reason not to distribute .pc files, but it doesn't seem like a reason not to generate them in local builds and generate them for package managers. There are other build systems besides cmake, and it seems like it would be nice if you could build and install the kernel from source or use a package manager, and build against the library in a meson project, or rust/zig/python/
...
📝 mzumsande opened a pull request: "wallet: reduce unconditional logging during load"
(https://github.com/bitcoin/bitcoin/pull/33299)
Currently the unconditional log during init with a default wallet happens three times:
```
2025-09-03T19:57:16Z init message: Verifying wallet(s)…
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
(...)
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
2025-09-03T19:57:16Z init
...
(https://github.com/bitcoin/bitcoin/pull/33299)
Currently the unconditional log during init with a default wallet happens three times:
```
2025-09-03T19:57:16Z init message: Verifying wallet(s)…
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
(...)
2025-09-03T19:57:16Z Using SQLite Version 3.45.1
2025-09-03T19:57:16Z Using wallet XXX/.bitcoin/regtest
2025-09-03T19:57:16Z init
...
💬 pinheadmz commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250621739)
v29 and all supported previous versions of Bitcoin allow "easily decodeable images" in transaction data, inscriptions proved that. In fact, stuffing data into witness blobs is *cheaper* than stuffing it in to op_returns. I think this issue should be closed as a duplicate but you can still comment here (or, perhaps more appropriately, on bitcoin.stackexchange.com) if you have additional questions. Please keep in mind the Bitcoin Core issue tracker is reserved for specific implementation issues an
...
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250621739)
v29 and all supported previous versions of Bitcoin allow "easily decodeable images" in transaction data, inscriptions proved that. In fact, stuffing data into witness blobs is *cheaper* than stuffing it in to op_returns. I think this issue should be closed as a duplicate but you can still comment here (or, perhaps more appropriately, on bitcoin.stackexchange.com) if you have additional questions. Please keep in mind the Bitcoin Core issue tracker is reserved for specific implementation issues an
...
✅ achow101 closed an issue: "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3"
(https://github.com/bitcoin/bitcoin/issues/33298)
(https://github.com/bitcoin/bitcoin/issues/33298)
💬 optout21 commented on pull request "mini miner: enable `Linearize` return package feerates":
(https://github.com/bitcoin/bitcoin/pull/33216#issuecomment-3250624967)
This PR only extends the return data with the package fee rate, but it does not use the new data. Is a follow-up PR available (as draft) where the new data is used?
(https://github.com/bitcoin/bitcoin/pull/33216#issuecomment-3250624967)
This PR only extends the return data with the package fee rate, but it does not use the new data. Is a follow-up PR available (as draft) where the new data is used?
💬 AceHack commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250671153)
I will use bitcoin.stackexchange.com, thank you for your kind response, but one triggers advanced AV and one does not; it's all in one contiguous block.
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250671153)
I will use bitcoin.stackexchange.com, thank you for your kind response, but one triggers advanced AV and one does not; it's all in one contiguous block.
💬 pinheadmz commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250679338)
Witness blobs are also contiguous data. Out of curiosity what is the source of your information?
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250679338)
Witness blobs are also contiguous data. Out of curiosity what is the source of your information?
💬 AceHack commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250708796)
It's my understanding you cannot simply copy the raw bytes from a Bitcoin block or mempool and open them as an image file without using Ordinals-specific software to reassemble them correctly, therefore won't trip AV. This is not true for the larger op return, that WILL trip AV. I'm trying to look at the code and gather the information myself, I've been a developer for 25+ years. I apologize if I get anything wrong.
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250708796)
It's my understanding you cannot simply copy the raw bytes from a Bitcoin block or mempool and open them as an image file without using Ordinals-specific software to reassemble them correctly, therefore won't trip AV. This is not true for the larger op return, that WILL trip AV. I'm trying to look at the code and gather the information myself, I've been a developer for 25+ years. I apologize if I get anything wrong.
💬 pinheadmz commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250766238)
There are other types of data stuffing that do require reassembly, like imagine creating a transaction with 100 outputs and each output's address was a piece of a large blob.
But inscriptions embed data in a witness blob in a single transaction input.
Example:
https://mempool.space/tx/64359c5b7e0ab1ad19ad7682bc9e95fd7c25ef85f115cb0fe6d37cce54611111?mode=details
Over 1 kB just in the witness. Contiguous data. See if you can decode the data yourself! Supposedly it is this image:
https://ordi
...
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250766238)
There are other types of data stuffing that do require reassembly, like imagine creating a transaction with 100 outputs and each output's address was a piece of a large blob.
But inscriptions embed data in a witness blob in a single transaction input.
Example:
https://mempool.space/tx/64359c5b7e0ab1ad19ad7682bc9e95fd7c25ef85f115cb0fe6d37cce54611111?mode=details
Over 1 kB just in the witness. Contiguous data. See if you can decode the data yourself! Supposedly it is this image:
https://ordi
...
💬 sipa commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250782457)
The block data is obfuscated on disk, to avoid AV software triggering on the files.
Policy changes aren't relevant for this; the transactions can make it into blocks without problems, regardless of what your software allows in its mempool.
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250782457)
The block data is obfuscated on disk, to avoid AV software triggering on the files.
Policy changes aren't relevant for this; the transactions can make it into blocks without problems, regardless of what your software allows in its mempool.
💬 AceHack commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250787540)
Yes but not in the mempool where windows core isolation scans and others advanced scanning software. Memory is scanned to which is why I don't want to relay this stuff cause then I have to decode it into memory on my node.
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250787540)
Yes but not in the mempool where windows core isolation scans and others advanced scanning software. Memory is scanned to which is why I don't want to relay this stuff cause then I have to decode it into memory on my node.
💬 sipa commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250798597)
If you don't care about having a useful mempool in your node you can disable it with the `-blocksonly` setting. But even that won't prevent your node from downloading, processing, and holding into memory the transaction when it makes it into a block.
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250798597)
If you don't care about having a useful mempool in your node you can disable it with the `-blocksonly` setting. But even that won't prevent your node from downloading, processing, and holding into memory the transaction when it makes it into a block.
💬 pinheadmz commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250799612)
The real problem is, you already do relay that stuff. The v30 release won't affect that. You can choose to run without a mempool in -blocksonly mode. Otherwise, fine-tuning censorship into a system that is censorship-resistant by design is a major technical challenge and we could use your help!
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250799612)
The real problem is, you already do relay that stuff. The v30 release won't affect that. You can choose to run without a mempool in -blocksonly mode. Otherwise, fine-tuning censorship into a system that is censorship-resistant by design is a major technical challenge and we could use your help!
📝 romanz converted_to_draft a pull request: "index: store per-block transaction locations for efficient lookups"
(https://github.com/bitcoin/bitcoin/pull/32541)
Currently, electrs and other indexers map between an address/scripthash to the list of the relevant transactions.
However, in order to fetch those transactions from bitcoind, electrs relies on reading the whole block and post-filtering for a specific transaction[^1]. Other indexers use a `txindex` to fetch a transaction using its txid [^2][^3][^4].
The above approach has significant storage and CPU overhead, since the `txid` is a pseudo-random 32-byte value.
This PR is adding support fo
...
(https://github.com/bitcoin/bitcoin/pull/32541)
Currently, electrs and other indexers map between an address/scripthash to the list of the relevant transactions.
However, in order to fetch those transactions from bitcoind, electrs relies on reading the whole block and post-filtering for a specific transaction[^1]. Other indexers use a `txindex` to fetch a transaction using its txid [^2][^3][^4].
The above approach has significant storage and CPU overhead, since the `txid` is a pseudo-random 32-byte value.
This PR is adding support fo
...
💬 AceHack commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250824489)
I disagree, I don't relay op return larger than 40(43) bytes today, so I absolutely don't relay "that" stuff. Suppose someone has chosen to hack/exploit data into fake addresses, witness data, and write complicated logic to reassemble that data elsewhere, that is beyond the scope of what I can reasonably control as a node operator and I strongly disagree with. I can't be held responsible for that. I CAN be held responsible for relaying data that is obviously illicit without any reassembly requi
...
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250824489)
I disagree, I don't relay op return larger than 40(43) bytes today, so I absolutely don't relay "that" stuff. Suppose someone has chosen to hack/exploit data into fake addresses, witness data, and write complicated logic to reassemble that data elsewhere, that is beyond the scope of what I can reasonably control as a node operator and I strongly disagree with. I can't be held responsible for that. I CAN be held responsible for relaying data that is obviously illicit without any reassembly requi
...
💬 AceHack commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250853096)
Also this is not censorship, this is individual bottom up node filtering, the opposite of censorship. Not allow node runners to filter obvious illicit data or "bad" them from the mempool is the definition of censorship. The 3 update will actively censor the node runners ability to filter data it deems ilicit without being punished and features restricted that make home mining not possible, further centralizing mining, which I guess is the goal of this update.
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250853096)
Also this is not censorship, this is individual bottom up node filtering, the opposite of censorship. Not allow node runners to filter obvious illicit data or "bad" them from the mempool is the definition of censorship. The 3 update will actively censor the node runners ability to filter data it deems ilicit without being punished and features restricted that make home mining not possible, further centralizing mining, which I guess is the goal of this update.
💬 sipa commented on issue "Please restrict Data Carrier/OP Return to < 80 bytes please before releasing 3":
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250882488)
Nobody is prevented from anything, as nobody is required to run Bitcoin Core, v30 or otherwise. You can run ot. I realize this may sound snarky, but it is very sincere: Bitcoin's strength lies in the fact that the network is ultimately defined by what software people choose to run, of their own choice. I obviously disagree with you in this particular case, but I do hope that if ever Bitcoin Core actually ships changes that hurt the network, that you and other users choose to run something else.
...
(https://github.com/bitcoin/bitcoin/issues/33298#issuecomment-3250882488)
Nobody is prevented from anything, as nobody is required to run Bitcoin Core, v30 or otherwise. You can run ot. I realize this may sound snarky, but it is very sincere: Bitcoin's strength lies in the fact that the network is ultimately defined by what software people choose to run, of their own choice. I obviously disagree with you in this particular case, but I do hope that if ever Bitcoin Core actually ships changes that hurt the network, that you and other users choose to run something else.
...