š¬ 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952908348)
Sorry he like people building using LLM. I love such people.
I wont share bug but exploit them. If cashu i will fuck them them not just exploit.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2952908348)
Sorry he like people building using LLM. I love such people.
I wont share bug but exploit them. If cashu i will fuck them them not just exploit.
š¬ stringintech commented on pull request "test: headers sync timeout":
(https://github.com/bitcoin/bitcoin/pull/32677#issuecomment-2952919063)
> I was thinking if we could add this timeout test in [`p2p_initial_headers_sync.py`](https://github.com/bitcoin/bitcoin/blob/master/test/functional/p2p_initial_headers_sync.py) instead of creating another one.
@yuvicc Actually, I did not consider that. However, now that I am thinking about it, the two sub-tests in the new test file share some context that are not used by the test file you mentioned. So, I think it is cleaner to keep them separate, especially if it will be extended to test th
...
(https://github.com/bitcoin/bitcoin/pull/32677#issuecomment-2952919063)
> I was thinking if we could add this timeout test in [`p2p_initial_headers_sync.py`](https://github.com/bitcoin/bitcoin/blob/master/test/functional/p2p_initial_headers_sync.py) instead of creating another one.
@yuvicc Actually, I did not consider that. However, now that I am thinking about it, the two sub-tests in the new test file share some context that are not used by the test file you mentioned. So, I think it is cleaner to keep them separate, especially if it will be extended to test th
...
š¬ negatratoron commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953002949)
I know this is a long thread, and I'm basically a totally new face on this project. Nevertheless, I'd like to put down some thoughts.
Overall, I think it's good UX for Bitcoin Core to perform the best fee estimation, which means relaying the most relevant transactions to that estimation.
Sounds like this PR looks to do that by configuring Bitcoin Core to relay large "data carrier" transactions, which are currently actually being mined but getting relayed using out-of-band software. This
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953002949)
I know this is a long thread, and I'm basically a totally new face on this project. Nevertheless, I'd like to put down some thoughts.
Overall, I think it's good UX for Bitcoin Core to perform the best fee estimation, which means relaying the most relevant transactions to that estimation.
Sounds like this PR looks to do that by configuring Bitcoin Core to relay large "data carrier" transactions, which are currently actually being mined but getting relayed using out-of-band software. This
...
š¬ petertodd commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953042281)
BitcoinMechanic:
There is a big difference between a filter being annoying enough that you choose to use unspendable outputs instead of OP_Return, and a filter annoying enough that you just give up on your project with millions of dollars of funding.
BitVM being a good example: even though their oversized transactions cost on the order of $15k to get mined, and aren't standard, BitVM use-cases were able to negotiate deals with miners to mine these non-standard, oversized transactions.
B
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953042281)
BitcoinMechanic:
There is a big difference between a filter being annoying enough that you choose to use unspendable outputs instead of OP_Return, and a filter annoying enough that you just give up on your project with millions of dollars of funding.
BitVM being a good example: even though their oversized transactions cost on the order of $15k to get mined, and aren't standard, BitVM use-cases were able to negotiate deals with miners to mine these non-standard, oversized transactions.
B
...
š¬ BitcoinMechanic commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953097803)
@petertodd
>filter annoying enough that you just give up
They don't need to give up, they can pivot to something less annoying or to another chain. **Which is what you're assuming they will do if the PR gets merged**
>BitVM use-cases were able to negotiate deals
I was already fully aware that filters cause spammers to have to go to these additional lengths, you don't need to keep convincing me and it doesn't in any way justify nodes helping them out.
>Bitcoin Core is not in a pos
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953097803)
@petertodd
>filter annoying enough that you just give up
They don't need to give up, they can pivot to something less annoying or to another chain. **Which is what you're assuming they will do if the PR gets merged**
>BitVM use-cases were able to negotiate deals
I was already fully aware that filters cause spammers to have to go to these additional lengths, you don't need to keep convincing me and it doesn't in any way justify nodes helping them out.
>Bitcoin Core is not in a pos
...
š snapcrackleandpop opened a pull request: "Update README.md"
(https://github.com/bitcoin/bitcoin/pull/32702)
When reading, it needs to be amended so "the graphical user interface" makes sense. Small but important input.
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user e
...
(https://github.com/bitcoin/bitcoin/pull/32702)
When reading, it needs to be amended so "the graphical user interface" makes sense. Small but important input.
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user e
...
š¬ Muniru0 commented on issue "doc: Developer Notes don't give advice on initialisms in class/function/method names":
(https://github.com/bitcoin/bitcoin/issues/32698#issuecomment-2953157325)
@JeremyRand that is a sound point to make. The screaming/acronym caps I believe have being used to kind of draw attention to major acronyms in the codebase like `RPC` and `JSON`. I will jump on to fix it by proposing the use of `UpperCamelCase` in the developer notes as already stated and further clarifying that :
Both class names like:
`JSONRPCRequest` and `HtmlEscape` should become `JsonRpcRequest` and `HtmlEscape`.
(https://github.com/bitcoin/bitcoin/issues/32698#issuecomment-2953157325)
@JeremyRand that is a sound point to make. The screaming/acronym caps I believe have being used to kind of draw attention to major acronyms in the codebase like `RPC` and `JSON`. I will jump on to fix it by proposing the use of `UpperCamelCase` in the developer notes as already stated and further clarifying that :
Both class names like:
`JSONRPCRequest` and `HtmlEscape` should become `JsonRpcRequest` and `HtmlEscape`.
š¬ gmaxwell commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953273539)
@petertodd worse, the opposition can't even keep a coherent message about what they're in favor of censoring. They claim non-financial transactions but then go on and on about wanting to block citria or bitvm which are indisputably transactions transferring bitcoin value and not mere collateral use. And certainly not spam in any traditional sense as the parties to the transaction are eagerly consenting.
This seems to always be the trajectory of censors in traditional system were access co
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953273539)
@petertodd worse, the opposition can't even keep a coherent message about what they're in favor of censoring. They claim non-financial transactions but then go on and on about wanting to block citria or bitvm which are indisputably transactions transferring bitcoin value and not mere collateral use. And certainly not spam in any traditional sense as the parties to the transaction are eagerly consenting.
This seems to always be the trajectory of censors in traditional system were access co
...
š¬ nsvrn commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953284742)
@gmaxwell It doesn't matter who wrote what quote about internet, Bitcoin onchain can't sustain prolonger micropayments or spam. May be instead of writing essays go check out the chainstate db, it's full of dust outputs that may never get consolidated. Only solution you've to that is some form of roundabout technical solution that will increase trust in the system to remediate future IBD bottlenecks.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953284742)
@gmaxwell It doesn't matter who wrote what quote about internet, Bitcoin onchain can't sustain prolonger micropayments or spam. May be instead of writing essays go check out the chainstate db, it's full of dust outputs that may never get consolidated. Only solution you've to that is some form of roundabout technical solution that will increase trust in the system to remediate future IBD bottlenecks.
š¬ gmaxwell commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953292462)
@nsvrn to whatever extent larger OP_RETURNS (the subject of this PR!) are used, they will speed up IBD-- because they avoid putting data in the chainstate database, because they are less weight dense so effectively reduce the size of blocks when used, and because they require very little processing compared to other transaction data that would otherwise be in their place.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953292462)
@nsvrn to whatever extent larger OP_RETURNS (the subject of this PR!) are used, they will speed up IBD-- because they avoid putting data in the chainstate database, because they are less weight dense so effectively reduce the size of blocks when used, and because they require very little processing compared to other transaction data that would otherwise be in their place.
š¬ nsvrn commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953297031)
@gmaxwell then ask John Gilmore to fix the inscription bug and come back with a solution
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953297031)
@gmaxwell then ask John Gilmore to fix the inscription bug and come back with a solution
š¬ AMoynahan89 commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953581593)
@gmaxwell
> @nsvrn to whatever extent larger OP_RETURNS (the subject of this PR!) are used, they will speed up IBD-- because they avoid putting data in the chainstate database, because they are less weight dense so effectively reduce the size of blocks when used, and because they require very little processing compared to other transaction data that would otherwise be in their place.
This is a major flaw in the reasoning in support of this pr. Claiming IBD speed will go up due to this cha
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953581593)
@gmaxwell
> @nsvrn to whatever extent larger OP_RETURNS (the subject of this PR!) are used, they will speed up IBD-- because they avoid putting data in the chainstate database, because they are less weight dense so effectively reduce the size of blocks when used, and because they require very little processing compared to other transaction data that would otherwise be in their place.
This is a major flaw in the reasoning in support of this pr. Claiming IBD speed will go up due to this cha
...
š¬ gmaxwell commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953597660)
@AMoynahan89 you misunderstand my comment. It's not likely to see significant usage, but if it did it would the usage would either move fake outputs to opreturn thus improving UTXO set effects or it would be displacing other usage which would make blocks smaller, because OP_RETURN is 100% non-witness data it counts for more weight.
It's like how if you have a bag which is normally filled with mostly rubber ducks and limited to 4 kg and you add some ball bearings while keeping the same weight
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953597660)
@AMoynahan89 you misunderstand my comment. It's not likely to see significant usage, but if it did it would the usage would either move fake outputs to opreturn thus improving UTXO set effects or it would be displacing other usage which would make blocks smaller, because OP_RETURN is 100% non-witness data it counts for more weight.
It's like how if you have a bag which is normally filled with mostly rubber ducks and limited to 4 kg and you add some ball bearings while keeping the same weight
...
š¤ Prabhat1308 reviewed a pull request: "test: Turn util/test_runner into functional test"
(https://github.com/bitcoin/bitcoin/pull/32697#pullrequestreview-2908339551)
[fae1c12](https://github.com/bitcoin/bitcoin/pull/32697/commits/fae1c12296e03a148512c345477669c9f531f58d) tACK
(https://github.com/bitcoin/bitcoin/pull/32697#pullrequestreview-2908339551)
[fae1c12](https://github.com/bitcoin/bitcoin/pull/32697/commits/fae1c12296e03a148512c345477669c9f531f58d) tACK
š¬ 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-2953943547)
Not much has changed, Fulcrum and CLN keep complaining. I observe that Fulcrum reconnects quickly after it complains but CLN has much more serious complains about the rpc calls `getmempoolinfo` and `getblockhash`:
```
2025-06-08T05:23:52.559Z UNUSUAL plugin-bcli: bitcoin-cli: finished bitcoin-cli -datadir=/media/ssd/.bitcoin/ -rpcclienttimeout=900 getmempoolinfo (29957 ms)
2025-06-08T05:28:43.125Z UNUSUAL plugin-bcli: bitcoin-cli: finished bitcoin-cli -datadir=/media/ssd/.bitcoin/ -rpcclienttim
...
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2953943547)
Not much has changed, Fulcrum and CLN keep complaining. I observe that Fulcrum reconnects quickly after it complains but CLN has much more serious complains about the rpc calls `getmempoolinfo` and `getblockhash`:
```
2025-06-08T05:23:52.559Z UNUSUAL plugin-bcli: bitcoin-cli: finished bitcoin-cli -datadir=/media/ssd/.bitcoin/ -rpcclienttimeout=900 getmempoolinfo (29957 ms)
2025-06-08T05:28:43.125Z UNUSUAL plugin-bcli: bitcoin-cli: finished bitcoin-cli -datadir=/media/ssd/.bitcoin/ -rpcclienttim
...
š¬ nsvrn commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953969911)
@gmaxwell then start to learn to stay on topic, this PR is also not about internet or John Gilmore
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2953969911)
@gmaxwell then start to learn to stay on topic, this PR is also not about internet or John Gilmore
š¬ Mercy435 commented on issue "test: `tool_wallet.py` references no-longer used CI":
(https://github.com/bitcoin/bitcoin/issues/32576#issuecomment-2954055504)
Hi @jonatack, I noticed this issue (#32576) is still open and that your previous PR (#28116) was closed a while back. Are you still planning to work on it?
If not, Iād be happy to take it over and submit a small PR to remove the outdated Appveyor-related comments. Let me know ā I can have a patch ready in a few days.
(https://github.com/bitcoin/bitcoin/issues/32576#issuecomment-2954055504)
Hi @jonatack, I noticed this issue (#32576) is still open and that your previous PR (#28116) was closed a while back. Are you still planning to work on it?
If not, Iād be happy to take it over and submit a small PR to remove the outdated Appveyor-related comments. Let me know ā I can have a patch ready in a few days.
š¬ yuvicc commented on issue "doc: Developer Notes don't give advice on initialisms in class/function/method names":
(https://github.com/bitcoin/bitcoin/issues/32698#issuecomment-2954089014)
> I will jump on to fix it by proposing the use of `UpperCamelCase` in the developer notes as already stated and further clarifying that :
ACK on this, it would be helpful for the new contributors.
> Both class names like: `JSONRPCRequest` and `HtmlEscape` should become `JsonRpcRequest` and `HtmlEscape`.
We shall not open a PR for a typo but can be updated when we touch the codebase in future.
(https://github.com/bitcoin/bitcoin/issues/32698#issuecomment-2954089014)
> I will jump on to fix it by proposing the use of `UpperCamelCase` in the developer notes as already stated and further clarifying that :
ACK on this, it would be helpful for the new contributors.
> Both class names like: `JSONRPCRequest` and `HtmlEscape` should become `JsonRpcRequest` and `HtmlEscape`.
We shall not open a PR for a typo but can be updated when we touch the codebase in future.
š¬ HowHsu commented on pull request "checkqueue: set MAX_SCRIPTCHECK_THREADS to nCores - 1":
(https://github.com/bitcoin/bitcoin/pull/32692#issuecomment-2954090526)
Hi Sipa,
> The reason for the existing limit of 15 is because benchmarks showed that even on an otherwise unloaded machine with more cores than that, adding more script validation threads was net slower after about that many.
Any doc about this test?
> That benchmark dates from 2013
Is the benchmark you mentioned /bench/connectblock.cpp
I've done some investigation, and found the bottleneck may be the ECC calculation itself, not lock contension or something else.
I did some te
...
(https://github.com/bitcoin/bitcoin/pull/32692#issuecomment-2954090526)
Hi Sipa,
> The reason for the existing limit of 15 is because benchmarks showed that even on an otherwise unloaded machine with more cores than that, adding more script validation threads was net slower after about that many.
Any doc about this test?
> That benchmark dates from 2013
Is the benchmark you mentioned /bench/connectblock.cpp
I've done some investigation, and found the bottleneck may be the ECC calculation itself, not lock contension or something else.
I did some te
...
š¬ 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-2954107388)
~~Another observation: the files in blocks/index and chainstate are about 32 MiB now but the files in indexes/txindex are still at 2 MiB. Does increasing the file sizes in indexes/txindex require a -reindex?~~
Some of the files have now moved to 32MiB also in `.bitcoin/indexes/txindex`: [diff_indexes_txindex_du.txt](https://bitcoinserver.nl/diff_indexes_txindex_du_2.txt).
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2954107388)
~~Another observation: the files in blocks/index and chainstate are about 32 MiB now but the files in indexes/txindex are still at 2 MiB. Does increasing the file sizes in indexes/txindex require a -reindex?~~
Some of the files have now moved to 32MiB also in `.bitcoin/indexes/txindex`: [diff_indexes_txindex_du.txt](https://bitcoinserver.nl/diff_indexes_txindex_du_2.txt).