💬 sipa commented on issue "Support `Accept` HTTP header in REST API":
(https://github.com/bitcoin/bitcoin/issues/32583#issuecomment-2906828308)
I don't understand the point of this. The format is already specified using the extension, which seems more convenient to me than needing an additional header to specify the content type, and having two distinct ways of specifying it seems significantly worse than just having one.

> I'm not sure what is meant by two conflicting types really.

I suspect Marco means: what do you do if someone requests `/block/$BLOCKHASH.bin`, but with `Accept: application/json` header.

💬 TheBlueMatt commented on issue "compact block fingerprinting":
(https://github.com/bitcoin/bitcoin/issues/28272#issuecomment-2906834205)
The get transaction RT is the long pole mostly because Bitcoin Core won't respond to the request until it finishes validating the block (but will send the initial compact block prior to doing so). This makes it pretty slow depending on your peer, but also means that requesting it from many peers may be advantageous (because some peers will validate the block faster). Responding to the message should be ~free for the peers.

It might also be worth pointing out that dropping unsolicited messages p
...

💬 yancyribbens commented on issue "Support `Accept` HTTP header in REST API":
(https://github.com/bitcoin/bitcoin/issues/32583#issuecomment-2906837470)
> The format is already specified using the extension, which seems more convenient to me than needing an additional header to specify the content type,

Oh, if one can say `.bin` or `.json` in the request to specify the expected content format that's great.

In the PR https://github.com/bitcoin/bitcoin/pull/32540

> We can significantly optimize it by adding a new REST endpoint, using a binary response format (returning a collection of spent txout lists, one per each block transaction)

So I wa
...

💬 sipa commented on issue "Support `Accept` HTTP header in REST API":
(https://github.com/bitcoin/bitcoin/issues/32583#issuecomment-2906838614)
I suggest you read the [documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md) on the REST interface before commenting on it.

#32540 adds a new REST endpoint, which provides information that no current endpoint provides. Like all REST endpoints, it provides this information in a number of formats, based on the extension of the filename used in the request.

💬 yancyribbens commented on issue "Support `Accept` HTTP header in REST API":
(https://github.com/bitcoin/bitcoin/issues/32583#issuecomment-2906839560)
> I suggest you read the [documentation](https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md) on the REST interface before commenting on it.

> https://github.com/bitcoin/bitcoin/pull/32540 adds a new REST endpoint, which provides information that no current endpoint provides. Like all REST endpoints, it provides this information in a number of formats, based on the extension of the filename used in the request.

I see that now. My mistake.

💬 yancyribbens commented on issue "Support `Accept` HTTP header in REST API":
(https://github.com/bitcoin/bitcoin/issues/32583#issuecomment-2906843314)
@romanz sorry to lead you astray, I should have inspected your PR a bit closer.

💬 yancyribbens commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#issuecomment-2906852632)
> I was thinking it might be not ideal to have this endpoint in addition to adding a content-type. Unless the plan is to deprecate this after content type is added? Maybe that's what is meant by the two conflicting types mentioned https://github.com/bitcoin/bitcoin/issues/32583#issuecomment-2901076206

Please disregard

💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2906870658)
> and data *carrier* limits are more about protecting the p2p and mempool
layers - not protecting from inclusion in blocks

Simply not true. The only motivation for the rule is to nudge people to not store arbitrary data on chain when it can be avoided.

> the knock-on effects of arbitrary data at the p2p layer could be severe in ways that have nothing to do with block storage

There is zero reason to think this. Transactions can be up to 100kvB in any other shape or form, and the p2p nee
...

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