💬 hMsats commented on issue "Self-compiled bitcoind 29.0 much slower than self-compiled 28.0 on my system":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2868402344)
@maflcko I found time to run 29.0 with the following debug catagories:
```
debug=bench
debug=blockstorage
debug=cmpctblock
debug=tor
debug=validation
debug=rpc
debug=zmq
```
You can find it [here](https://bitcoinserver.nl/debug.log) and more system information on my [website](https://bitcoinserver.nl).
There are background callers. Besides a full node I run: Fulcrum (public electrum server), 2 CLN lightning nodes, electrum personal server. It's maybe a lot but 28.0 has no problems with it. At
...
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2868402344)
@maflcko I found time to run 29.0 with the following debug catagories:
```
debug=bench
debug=blockstorage
debug=cmpctblock
debug=tor
debug=validation
debug=rpc
debug=zmq
```
You can find it [here](https://bitcoinserver.nl/debug.log) and more system information on my [website](https://bitcoinserver.nl).
There are background callers. Besides a full node I run: Fulcrum (public electrum server), 2 CLN lightning nodes, electrum personal server. It's maybe a lot but 28.0 has no problems with it. At
...
💬 0xB10C commented on pull request "tracing: fix invalid argument in mempool_monitor":
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2868609868)
This came to my mind again: We might want to consider maintaining these tools outside of the Bitcoin Core repo as mentioned in #31274 6)
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2868609868)
This came to my mind again: We might want to consider maintaining these tools outside of the Bitcoin Core repo as mentioned in #31274 6)
💬 hebasto commented on pull request "thread-safety: fix annotations with REVERSE_LOCK":
(https://github.com/bitcoin/bitcoin/pull/32465#issuecomment-2868610302)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/32465#issuecomment-2868610302)
Concept ACK.
💬 aryaethn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868616096)
Concept ACK.
Even though I am not a Bitcoin Developer, I see this of benefit for the ecosystem around Bitcoin, specially DeFi ecosystem, like Bridges, DEXs, and Lending. Removing data limit on OP_RETURN, or at least loosening the limit, provides a way for on-chain communication for DeFi dApps that try to include Bitcoin in DeFi.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868616096)
Concept ACK.
Even though I am not a Bitcoin Developer, I see this of benefit for the ecosystem around Bitcoin, specially DeFi ecosystem, like Bridges, DEXs, and Lending. Removing data limit on OP_RETURN, or at least loosening the limit, provides a way for on-chain communication for DeFi dApps that try to include Bitcoin in DeFi.
💬 aryaethn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868619847)
> Concept NACK.
>
> There's already more than enough garbage in the Bitcoin chain thanks to the Ordinals Taproot hijacking. There's no need to make it even easier for people to spam the chain.
As you know, people pay for every byte of data they post. So how is that spamming when you pay for the so-called "garbage"?
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868619847)
> Concept NACK.
>
> There's already more than enough garbage in the Bitcoin chain thanks to the Ordinals Taproot hijacking. There's no need to make it even easier for people to spam the chain.
As you know, people pay for every byte of data they post. So how is that spamming when you pay for the so-called "garbage"?
💬 TheCharlatan commented on pull request "miner: timelock the coinbase to the mined block's height":
(https://github.com/bitcoin/bitcoin/pull/32155#issuecomment-2868657949)
> Edit: Oh, is it because of set ordering by txid or something like that, and the error message depends on which tx is checked first? If so, it would be nice to have that in the commit message.
Yes, see https://github.com/bitcoin/bitcoin/pull/32155#discussion_r2052783821 above.
(https://github.com/bitcoin/bitcoin/pull/32155#issuecomment-2868657949)
> Edit: Oh, is it because of set ordering by txid or something like that, and the error message depends on which tx is checked first? If so, it would be nice to have that in the commit message.
Yes, see https://github.com/bitcoin/bitcoin/pull/32155#discussion_r2052783821 above.
🤔 hebasto reviewed a pull request: "checkqueue: make the queue non-optional for CCheckQueueControl and drop legacy locking macro usage"
(https://github.com/bitcoin/bitcoin/pull/32467#pullrequestreview-2830641730)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/32467#pullrequestreview-2830641730)
Concept ACK.
💬 rstmsn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868703772)
> As you know, people pay for every byte of data they post. So how is that spamming when you pay for the so-called "garbage"?
It is reasonably well agreed upon that if there was a highly effective way of excluding things like JPEG data from being stored on the chain, it most certainly would be excluded.
Some users exploit weaknesses in the ability to parse for & successfully exclude this data.
Paying a transaction fee as part of that process does not legitimise the behaviour.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868703772)
> As you know, people pay for every byte of data they post. So how is that spamming when you pay for the so-called "garbage"?
It is reasonably well agreed upon that if there was a highly effective way of excluding things like JPEG data from being stored on the chain, it most certainly would be excluded.
Some users exploit weaknesses in the ability to parse for & successfully exclude this data.
Paying a transaction fee as part of that process does not legitimise the behaviour.
💬 aryaethn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868709140)
> It is reasonably well agreed upon that if there was a highly effective way of excluding things like JPEG data from being stored on the chain, it most certainly would be excluded.
I understand and agree that heavy data is "**better**" to be stored some where else, with a link or other ways like that. Maybe on a file storage chain, or ipfs-based blockchains. No force, just better to be.
> Some users exploit weaknesses in the ability to parse for & successfully exclude this data.
> Payi
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868709140)
> It is reasonably well agreed upon that if there was a highly effective way of excluding things like JPEG data from being stored on the chain, it most certainly would be excluded.
I understand and agree that heavy data is "**better**" to be stored some where else, with a link or other ways like that. Maybe on a file storage chain, or ipfs-based blockchains. No force, just better to be.
> Some users exploit weaknesses in the ability to parse for & successfully exclude this data.
> Payi
...
💬 rstmsn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868712837)
> I know it doesn't legitimize the action, but it does not break any rules. Bitcoin's consensus is based on "Pay more fee to get included first". They pay the fee, and miner's are happy. I don't see the problem.
Exploiting the system to use it as cloud data storage pushes up the cost of running a node. The decentralisation characteristic is an emergent property of many users running and using their own nodes.
To the extent that this aspect becomes more expensive, the decentralisation cha
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868712837)
> I know it doesn't legitimize the action, but it does not break any rules. Bitcoin's consensus is based on "Pay more fee to get included first". They pay the fee, and miner's are happy. I don't see the problem.
Exploiting the system to use it as cloud data storage pushes up the cost of running a node. The decentralisation characteristic is an emergent property of many users running and using their own nodes.
To the extent that this aspect becomes more expensive, the decentralisation cha
...
💬 stringintech commented on pull request "kernel: Separate UTXO set access from validation functions":
(https://github.com/bitcoin/bitcoin/pull/32317#discussion_r2083107119)
Is there a reason we keep passing the `spent_outputs` instead of removing it (to simplify the API) and requiring callers to initialize `txdata` before calling `CheckInputScripts`?
(https://github.com/bitcoin/bitcoin/pull/32317#discussion_r2083107119)
Is there a reason we keep passing the `spent_outputs` instead of removing it (to simplify the API) and requiring callers to initialize `txdata` before calling `CheckInputScripts`?
💬 pithosian commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868741871)
NACK.
I've already made comments in the mailing list. To summarize: this change is not necessary for nonstandard OP_RETURN transactions to be relayed to miners via public mempools, nor is it necessary to prevent delays in relay of compact blocks. That said, I don't have strong feelings about removing `OP_RETURN` _limits_, or default configuration changes.
However, removing the `datacarrier` and `datacarriersize` options has not been well justified. Downloading a transaction twice is not th
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868741871)
NACK.
I've already made comments in the mailing list. To summarize: this change is not necessary for nonstandard OP_RETURN transactions to be relayed to miners via public mempools, nor is it necessary to prevent delays in relay of compact blocks. That said, I don't have strong feelings about removing `OP_RETURN` _limits_, or default configuration changes.
However, removing the `datacarrier` and `datacarriersize` options has not been well justified. Downloading a transaction twice is not th
...
💬 aryaethn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868742825)
> This debate is currently divided along the lines of those who believe we should remain proactive towards spam filtration, despite the lack of a 100% effective solution, vs those who believe the absence of a technically perfect solutions means we should capitulate to spammers, and remove all efforts to slow down / reduce spam.
I agree. It's a debate that no one wins by argument. Only the majority decides the winner.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868742825)
> This debate is currently divided along the lines of those who believe we should remain proactive towards spam filtration, despite the lack of a 100% effective solution, vs those who believe the absence of a technically perfect solutions means we should capitulate to spammers, and remove all efforts to slow down / reduce spam.
I agree. It's a debate that no one wins by argument. Only the majority decides the winner.
💬 walkjivefly commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868774968)
> > Concept NACK.
> > There's already more than enough garbage in the Bitcoin chain thanks to the Ordinals Taproot hijacking. There's no need to make it even easier for people to spam the chain.
>
> As you know, people pay for every byte of data they post. So how is that spamming when you pay for the so-called "garbage"?
The garbage transactions increase chain size, block occupancy and fees, and can make it harder and more expensive to get financial transactions onto the chain.
They a
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868774968)
> > Concept NACK.
> > There's already more than enough garbage in the Bitcoin chain thanks to the Ordinals Taproot hijacking. There's no need to make it even easier for people to spam the chain.
>
> As you know, people pay for every byte of data they post. So how is that spamming when you pay for the so-called "garbage"?
The garbage transactions increase chain size, block occupancy and fees, and can make it harder and more expensive to get financial transactions onto the chain.
They a
...
💬 walkjivefly commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868775970)
> I know it doesn't legitimize the action, but it does not break any rules. Bitcoin's consensus is based on "Pay more fee to get included first". They pay the fee, and miner's are happy. I don't see the problem.
Also true; miners are always going to be happy with more fees. But although they're essential to the operation of the network they represent only a very small percentage of the actual nodes in the network. They are not the only ones who need to be happy.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868775970)
> I know it doesn't legitimize the action, but it does not break any rules. Bitcoin's consensus is based on "Pay more fee to get included first". They pay the fee, and miner's are happy. I don't see the problem.
Also true; miners are always going to be happy with more fees. But although they're essential to the operation of the network they represent only a very small percentage of the actual nodes in the network. They are not the only ones who need to be happy.
👍 TheCharlatan approved a pull request: "thread-safety: fix annotations with REVERSE_LOCK"
(https://github.com/bitcoin/bitcoin/pull/32465#pullrequestreview-2830729911)
ACK 96a341d4064132292621af404de908f01fbe3e2f
(https://github.com/bitcoin/bitcoin/pull/32465#pullrequestreview-2830729911)
ACK 96a341d4064132292621af404de908f01fbe3e2f
💬 TheCharlatan commented on pull request "thread-safety: fix annotations with REVERSE_LOCK":
(https://github.com/bitcoin/bitcoin/pull/32465#discussion_r2083111057)
This threw me off for a bit, but while some attributes have been renamed, some have been kept the same, and their macros renamed instead. See: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#mutex-h
(https://github.com/bitcoin/bitcoin/pull/32465#discussion_r2083111057)
This threw me off for a bit, but while some attributes have been renamed, some have been kept the same, and their macros renamed instead. See: https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#mutex-h
💬 aryaethn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868783278)
> True, the spammers pay for every byte they put on chain but arbitrary non-financial content is not what Bitcoin was designed for. Remember the first line of the Bitcoin White Paper:
>
> Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
I generally agree with your argument with some specification. The current `OP_RETURN` size, makes even financial (DeFi) transa
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2868783278)
> True, the spammers pay for every byte they put on chain but arbitrary non-financial content is not what Bitcoin was designed for. Remember the first line of the Bitcoin White Paper:
>
> Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
I generally agree with your argument with some specification. The current `OP_RETURN` size, makes even financial (DeFi) transa
...
💬 TheCharlatan commented on pull request "kernel: Separate UTXO set access from validation functions":
(https://github.com/bitcoin/bitcoin/pull/32317#discussion_r2083133917)
My read is that the call to `txdata.Init` is delayed to after checking the script execution cache for performance reasons. Calling `Init` does some hashing, that would not be required if it is already in the cache. Moving the `spent_outputs` vector construction is already a potential performance downside for potential cache hits, though I think that is more acceptable in the grand scheme of things.
(https://github.com/bitcoin/bitcoin/pull/32317#discussion_r2083133917)
My read is that the call to `txdata.Init` is delayed to after checking the script execution cache for performance reasons. Calling `Init` does some hashing, that would not be required if it is already in the cache. Moving the `spent_outputs` vector construction is already a potential performance downside for potential cache hits, though I think that is more acceptable in the grand scheme of things.
💬 TheCharlatan commented on pull request "kernel: Separate UTXO set access from validation functions":
(https://github.com/bitcoin/bitcoin/pull/32317#discussion_r2083129268)
Yeah, that seems better. I had another version of this that tried to enforce everything through concepts, but thought that didn't really help with keeping things clear, so just dropped all the fancy type hints altogether.
(https://github.com/bitcoin/bitcoin/pull/32317#discussion_r2083129268)
Yeah, that seems better. I had another version of this that tried to enforce everything through concepts, but thought that didn't really help with keeping things clear, so just dropped all the fancy type hints altogether.