👍 TheCharlatan approved a pull request: "RPC: Return `permitbaremultisig` and `maxdatacarriersize` in `getmempoolinfo`"
(https://github.com/bitcoin/bitcoin/pull/29954#pullrequestreview-2866286522)
ACK d165ac8779b2b692007a7474c19cee4194946e75

💬 m3dwards commented on pull request "ci: remove 3rd party js from windows dll gha job":
(https://github.com/bitcoin/bitcoin/pull/32513#discussion_r2105809870)
Done, thanks for the spot!

💬 yancyribbens commented on issue "Support `Accept` HTTP header in REST API":
(https://github.com/bitcoin/bitcoin/issues/32583#issuecomment-2906823581)
I'm not sure what is meant by two conflicting types really.

I was thinking it would be possible to make a request using either json or binary in the request HTTP header. For example:

```
curl -X POST https://bitcoin
-H 'Accept: application/json'
```

OR

```
curl -X POST https://bitcoin
-H 'Accept: application/octet-stream'
```

If no Accept content type is set then default to what it is now, json.

I'm not sure, is that what the code snippet above is doing? I don't really grok what's
...

💬 yancyribbens commented on pull request "rest: fetch spent transaction outputs by blockhash":
(https://github.com/bitcoin/bitcoin/pull/32540#issuecomment-2906824816)
> would it be OK to implement it in a separate PR?


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

💬 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