💬 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.
💬 TheCharlatan commented on pull request "(RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store":
(https://github.com/bitcoin/bitcoin/pull/32427#issuecomment-2868847845)
Re https://github.com/bitcoin/bitcoin/pull/32427#pullrequestreview-2823207472
> In my personal experience of running a node on crappy hardware a long time ago, it was usually 2. that would happen (I knew that because the reindex wouldn't scan all block files but abort with an error somewhere, and switch to IBD from peers).
That is interesting, I don't think I've ever run into blk file corruption. I agree with you that if that is something we need to be able to salvage from, that the reind
...
(https://github.com/bitcoin/bitcoin/pull/32427#issuecomment-2868847845)
Re https://github.com/bitcoin/bitcoin/pull/32427#pullrequestreview-2823207472
> In my personal experience of running a node on crappy hardware a long time ago, it was usually 2. that would happen (I knew that because the reindex wouldn't scan all block files but abort with an error somewhere, and switch to IBD from peers).
That is interesting, I don't think I've ever run into blk file corruption. I agree with you that if that is something we need to be able to salvage from, that the reind
...
💬 jb55 commented on pull request "tracing: fix invalid argument in mempool_monitor":
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2868895291)
that makes sense to me
(https://github.com/bitcoin/bitcoin/pull/32454#issuecomment-2868895291)
that makes sense to me
💬 JeremyRubin commented on pull request "[Policy] Discourage Unsigned Annexes":
(https://github.com/bitcoin/bitcoin/pull/32453#issuecomment-2868941155)
if anyone is looking for an annex in the wild, here is the first one on mainnet:
https://mempool.space/tx/b78748f2ee3222d9bf4b23ab917136c745531ccc5ef8097235d11e16483e466f?mode=details
seems to be keypath, so it's signed.
(https://github.com/bitcoin/bitcoin/pull/32453#issuecomment-2868941155)
if anyone is looking for an annex in the wild, here is the first one on mainnet:
https://mempool.space/tx/b78748f2ee3222d9bf4b23ab917136c745531ccc5ef8097235d11e16483e466f?mode=details
seems to be keypath, so it's signed.
🚀 fanquake merged a pull request: "build: simplify *ifaddr handling"
(https://github.com/bitcoin/bitcoin/pull/32446)
(https://github.com/bitcoin/bitcoin/pull/32446)
💬 fanquake commented on pull request "qt: drop unused watch-only functionality":
(https://github.com/bitcoin/bitcoin/pull/32459#issuecomment-2868953442)
Can be rebased now.
(https://github.com/bitcoin/bitcoin/pull/32459#issuecomment-2868953442)
Can be rebased now.