📝 Zeegaths opened a pull request: "docs: adds correct updated documentation links"
(https://github.com/bitcoin/bitcoin/pull/32699)
Added correct links to the docs in place of the missing docs' paths.
(https://github.com/bitcoin/bitcoin/pull/32699)
Added correct links to the docs in place of the missing docs' paths.
💬 petertodd commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952304160)
BitcoinMdchanic:
As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead.
Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs.
Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
On June 7, 2025 1:00:38 AM GM
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952304160)
BitcoinMdchanic:
As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead.
Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs.
Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
On June 7, 2025 1:00:38 AM GM
...
⚠️ hebasto opened an issue: "`bitcoin-qt` fails to start on Fedora 42"
(https://github.com/bitcoin/bitcoin/issues/32700)
On Fedora 42, `bitcoin-qt`, both statically and dynamically linked, fails to start:
```
$ ./build/bin/bitcoin-qt
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available pla
...
(https://github.com/bitcoin/bitcoin/issues/32700)
On Fedora 42, `bitcoin-qt`, both statically and dynamically linked, fails to start:
```
$ ./build/bin/bitcoin-qt
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available pla
...
✅ hebasto closed an issue: "`bitcoin-qt` fails to start on Fedora 42"
(https://github.com/bitcoin/bitcoin/issues/32700)
(https://github.com/bitcoin/bitcoin/issues/32700)
👍 willcl-ark approved a pull request: "[28.x] 28.2rc2"
(https://github.com/bitcoin/bitcoin/pull/32684#pullrequestreview-2907337580)
ACK fb6239327700acc8b038d7d241c33439e3f6916e
via `git range-diff 3b05c49...fb62393`
(https://github.com/bitcoin/bitcoin/pull/32684#pullrequestreview-2907337580)
ACK fb6239327700acc8b038d7d241c33439e3f6916e
via `git range-diff 3b05c49...fb62393`
💬 lordnakamoto commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952528774)
> BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
> […](#)
> On June 7, 2025 1:0
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952528774)
> BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
> […](#)
> On June 7, 2025 1:0
...
💬 bigshiny90 commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952543499)
> BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
> […](#)
> On June 7, 2025 1:0
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952543499)
> BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
> […](#)
> On June 7, 2025 1:0
...
💬 maflcko commented on pull request "ipc: add bitcoin-mine test program":
(https://github.com/bitcoin/bitcoin/pull/30437#discussion_r2133866597)
nit in 27c6576aba5c59402b8844703e04face2f41578c: would be better to call the env var `BITCOIN_MINE`, in symmetry with the attribute name. Also, I think this is missing the patch to the GHA Windows CI task. Otherwise, it would probably fail. (It is passing because IPC and the test is skipped on Windows)
See commit fac9c4dafeceac99d36c9e28436c603cfe0f567b for a reference.
but just a nit, feel free to ignore.
(https://github.com/bitcoin/bitcoin/pull/30437#discussion_r2133866597)
nit in 27c6576aba5c59402b8844703e04face2f41578c: would be better to call the env var `BITCOIN_MINE`, in symmetry with the attribute name. Also, I think this is missing the patch to the GHA Windows CI task. Otherwise, it would probably fail. (It is passing because IPC and the test is skipped on Windows)
See commit fac9c4dafeceac99d36c9e28436c603cfe0f567b for a reference.
but just a nit, feel free to ignore.
💬 l0rinc commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2952599259)
I have measured the cost of switching from `2MiB` `max_file_size` to `32MiB` from 700k blocks to 888,888:
<details>
<summary>Details</summary>
```bash
COMMIT_2MIB="c9417a59ee7b65d9dd3352c55f0e414d5dbdb7af"; COMMIT_32MIB="370c59261269fd9043674e0f4fd782a89e724473"; \
STOP1=700000; STOP2=888888; DBCACHE=2500; \
...
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2952599259)
I have measured the cost of switching from `2MiB` `max_file_size` to `32MiB` from 700k blocks to 888,888:
<details>
<summary>Details</summary>
```bash
COMMIT_2MIB="c9417a59ee7b65d9dd3352c55f0e414d5dbdb7af"; COMMIT_32MIB="370c59261269fd9043674e0f4fd782a89e724473"; \
STOP1=700000; STOP2=888888; DBCACHE=2500; \
...
💬 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952706652)
Either close this pull request or merge. I don't understand how "core" maintainers looking for this drama in this pull request over weekend.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952706652)
Either close this pull request or merge. I don't understand how "core" maintainers looking for this drama in this pull request over weekend.
💬 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952727035)
Maybe wait for Chaincode Labs and Monday? Or CIA?
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952727035)
Maybe wait for Chaincode Labs and Monday? Or CIA?
💬 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952741116)
Dysfunctional Core:
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952741116)
Dysfunctional Core:
💬 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952772253)
This was on on topic as we discussed open source here: https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939644399
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952772253)
This was on on topic as we discussed open source here: https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2939644399
💬 romanz commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2134033105)
> nit: can remove the casts
Changed `std::as_bytes(std::span{ssSpentResponse})` to `ssSpentResponse` in d4e212e8a6.
> If you want, you can also remove them in other places in this file.
```
$ git grep std::as_bytes src/rest.cpp
src/rest.cpp: req->WriteReply(HTTP_OK, std::as_bytes(std::span{block_data}));
```
I am not sure that I can remove it here, since `block_data` is `std::vector<uint8_t>`, and `WriteReply(...)` accepts `std::span<std::byte>`.
Maybe I can change `Read
...
(https://github.com/bitcoin/bitcoin/pull/32540#discussion_r2134033105)
> nit: can remove the casts
Changed `std::as_bytes(std::span{ssSpentResponse})` to `ssSpentResponse` in d4e212e8a6.
> If you want, you can also remove them in other places in this file.
```
$ git grep std::as_bytes src/rest.cpp
src/rest.cpp: req->WriteReply(HTTP_OK, std::as_bytes(std::span{block_data}));
```
I am not sure that I can remove it here, since `block_data` is `std::vector<uint8_t>`, and `WriteReply(...)` accepts `std::span<std::byte>`.
Maybe I can change `Read
...
📝 Christewart opened a pull request: "tests: Remove hardcoded addresstype in rpc_psbt.py"
(https://github.com/bitcoin/bitcoin/pull/32701)
Taproot PSBT support was added in #22558 so I believe hard coding the `-addresstype`'s in the test setup is no longer necessary as the TODO indicates?
(https://github.com/bitcoin/bitcoin/pull/32701)
Taproot PSBT support was added in #22558 so I believe hard coding the `-addresstype`'s in the test setup is no longer necessary as the TODO indicates?
💬 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952862625)
Filterooos are most dumb that created in our life.
However you missed things are changed by whom. They will have the same influence in other things.
One good thing BIP 8 and BIP 9 will become drama and Greg Maxwell cannot fix this with posts on reddit .
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952862625)
Filterooos are most dumb that created in our life.
However you missed things are changed by whom. They will have the same influence in other things.
One good thing BIP 8 and BIP 9 will become drama and Greg Maxwell cannot fix this with posts on reddit .
💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2952869084)
Thanks again for all this information, although it's not always easy to understand what the precise consequences are for my particular system.
I had to learn the hard way that the command `dd` is very dangerous, which caused quite a bit of a delay but I'm up and running again. My bitcoind, Fulcrum and 2 CLN nodes are now running for 6 hours with `max_file_size=32MiB` for bitcoind (starting from `max_file_size=2MiB` ) . Here are some preliminary results for the different file sizes for 2MiB and
...
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2952869084)
Thanks again for all this information, although it's not always easy to understand what the precise consequences are for my particular system.
I had to learn the hard way that the command `dd` is very dangerous, which caused quite a bit of a delay but I'm up and running again. My bitcoind, Fulcrum and 2 CLN nodes are now running for 6 hours with `max_file_size=32MiB` for bitcoind (starting from `max_file_size=2MiB` ) . Here are some preliminary results for the different file sizes for 2MiB and
...
💬 BitcoinMechanic commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952877909)
> BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
> […](#)
> On June 7, 2025 1:0
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952877909)
> BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
> […](#)
> On June 7, 2025 1:0
...
💬 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952892038)
> > BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
> > […](#)
> > On June 7, 20
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952892038)
> > BitcoinMdchanic: As we have repeatedly made clear, the reason why we want to remove the OP_Return limits is because they're sufficiently annoying that projects like Citrea are publishing data in the UTXO set instead. Obviously we are _hoping_ for an increase in the number of >80 byte OP_Returns, as projects switch to OP_Return instead of undependable UTXOs. Publishing data in general is already done on a large scale in witnesses, at 1/4th the cost of OP_Return.
> > […](#)
> > On June 7, 20
...
💬 willcl-ark commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952908266)
@1440000bytes please keep comments on topic, there are many subscribers here.
Comments about maintainers, other specific individuals, "drama" etc. are not on topic here in this thread. You can take that over to [bitcoin-core/meta](https://github.com/bitcoin-core/meta/), if you so desire.
Failure to keep future comments focused on review of the proposed changes will result in a temporary ban. If you want to debate this comment please also do so on https://github.com/bitcoin-core/meta/, and
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952908266)
@1440000bytes please keep comments on topic, there are many subscribers here.
Comments about maintainers, other specific individuals, "drama" etc. are not on topic here in this thread. You can take that over to [bitcoin-core/meta](https://github.com/bitcoin-core/meta/), if you so desire.
Failure to keep future comments focused on review of the proposed changes will result in a temporary ban. If you want to debate this comment please also do so on https://github.com/bitcoin-core/meta/, and
...