Bitcoin Core Github
44 subscribers
120K links
Download Telegram
💬 ryanofsky commented on pull request "rpc: Handle -named argument parsing where '=' character is used":
(https://github.com/bitcoin/bitcoin/pull/32821#discussion_r2369939396)
In commit "rpc: Handle -named argument parsing where '=' character is used" (8eafb1e9ee4fff3a9ab4a7dc899bd2d57c29d04f)

Woud suggest replacing `parameter with PARAM_NAME="my".` with `parameter named "my"` so this is shorter and more understandable without the previous context.
💬 moonsettler commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321131775)
> I would prefer a PR improving the deprecation message to make it clear that we are discouraging the use of the option, but not planning to remove it (for the moment).

That is also fine. I have not changed my mind on this, I considered removing the option a bad move to begin with. This option being configurable made even less practical sense in the past than it has going forward.
👍 hodlinator approved a pull request: "Modernize use of UTF-8 in Windows code"
(https://github.com/bitcoin/bitcoin/pull/32380#pullrequestreview-3254889896)
ACK b74a92cdb2c4d9871865a67162f47f97fb7e642c

Latest push adds missing/previously avoided call to `SetupEnvironment()` (discovered in https://github.com/bitcoin/bitcoin/pull/32380#discussion_r2367130713), this entails also adding a dependency from bitcoin.exe on bitcoin_common.

Tested Windows-native build, running `bitcoin node`.
💬 Dorex45 commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3321181329)
Cant wait for the release of V 30,Bitcoin sidechains are in for a massive ride,Bitcoin utilities are yet to be unlocked tremendously.
V30 will champion the future of Bitcoin.
💬 BitcoinMechanic commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321194786)
Slating configurability for removal is one of three issues with https://github.com/bitcoin/bitcoin/pull/32406 which this fixes and is strictly an improvement.

The other two issues - datacarriersize no longer working correctly and the setting of it to a malicious default - both remain.

In that context, all this specific PR serves to do is help manufacture consent for an unjustified change in attitude towards arbitrary data by making the most mild concession possible to those against it, whi
...
⚠️ RandyMcMillan opened an issue: "cli:passing non-integers to datacarriersize"
(https://github.com/bitcoin/bitcoin/issues/33460)
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

While testing #33453

<img width="1847" height="1043" alt="Image" src="https://github.com/user-attachments/assets/a6ef5108-4ec1-4802-b061-14335cd8e84e" />


recommend reverting https://github.com/bitcoin/bitcoin/commit/63091b79e70b8e230a122fa6fb3dac91c80638e7
and adding additional tests.

cc: @bitschmidty @hebasto



This reminds me of an old issue. Passing di-graphs as values.

### Ex
...
💬 hebasto commented on pull request "msvc: Update vcpkg manifest":
(https://github.com/bitcoin/bitcoin/pull/33408#issuecomment-3321239131)
> nit: Discovered image blurring/smoothing worsened from master to PR. Here are two native Windows builds:

A quick search turned up a similar bug report: https://bugreports.qt.io/browse/QTBUG-136807.
💬 Dorex45 commented on issue "Release Schedule for 30.0":
(https://github.com/bitcoin/bitcoin/issues/32275#issuecomment-3321249513)
Release schedule for v30.0 ACK.
💬 bitschmidty commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321265268)
> this specific PR

This specific PR seeks clarity in the datacarrier options' future availability, in favor of removing the deprecation, as the deprecation designation definition is unclear, potentially incorrect (if the definition is will be removed), and causes uncertainty for Bitcoin Core users around timing.
💬 hodlinator commented on pull request "msvc: Update vcpkg manifest":
(https://github.com/bitcoin/bitcoin/pull/33408#issuecomment-3321301575)
> A quick search turned up a similar bug report: https://bugreports.qt.io/browse/QTBUG-136807.

Yes, eerily similar, but it's not explicitly comparing *6.8* to 6.9 (although the bug is on 6.9). It's comparing FreeType to native Windows font rendering.

Also notice that even the cut off corners in the Qt logo are different in my screenshots, which I'm guessing is not font-related.
💬 Ademan commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321385143)
utACK 451ba9a

I'd strongly caution against backporting this unless there's clear precedent, however. (I'm not claiming there is or isn't clear precedent)
💬 fanquake commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#issuecomment-3321448261)
Backported to 30.x in #33424.
💬 fanquake commented on pull request "system: improve handling around GetTotalRAM()":
(https://github.com/bitcoin/bitcoin/pull/33435#issuecomment-3321448632)
Backported to 30.x in #33435.
💬 hebasto commented on pull request "ci: remove 3rd party js from windows dll gha job":
(https://github.com/bitcoin/bitcoin/pull/32513#issuecomment-3321471464)
On the [master](https://github.com/bitcoin/bitcoin/actions/runs/17921155333/job/50956194860) branch:
```
VSCMD_ARG_HOST_ARCH: x64
VSCMD_ARG_TGT_ARCH: x64
```

However, with this [PR](https://github.com/bitcoin/bitcoin/actions/runs/17807365691/job/50622408408):
```
VSCMD_ARG_HOST_ARCH: x86
VSCMD_ARG_TGT_ARCH: x86
```
📝 fanquake opened a pull request: "ci: add Valgrind fuzz"
(https://github.com/bitcoin/bitcoin/pull/33461)
Valgrind fuzz runtime?
💬 glozow commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321521194)
> This specific PR seeks clarity in the datacarrier options' future availability

+1. I think the comments so far are largely on topic, but let's try to avoid rehashing the motivations around the policy change itself or re-litigating what the default value should be. Reminder that delving bitcoin, mailing list posts, and a meta topic on the bitcoin-core discussions page exist. Thanks!
💬 polespinasa commented on issue "cli:passing non-integers to datacarriersize":
(https://github.com/bitcoin/bitcoin/issues/33460#issuecomment-3321528433)
There's no need to rever https://github.com/bitcoin/bitcoin/commit/63091b79e70b8e230a122fa6fb3dac91c80638e7
Checking how we handle args, I saw that many numeric args accept strings without crashing.
See `-limitancestorcount` or `-bytespersigop` for example.

`-dustrelayfee` on the ther side does have type handling:
`Error: Invalid amount for -dustrelayfee=<amount>: 'aaa'`

Maybe this is a issue worth checking to add assertions on args types.
🤔 glozow reviewed a pull request: "rpc: Always return per-wtxid entries in submitpackage tx-results"
(https://github.com/bitcoin/bitcoin/pull/33427#pullrequestreview-3255249545)
ACK cad9a7fd7370f6df38370569f9d2de6ac6b7137a
💬 glozow commented on pull request "rpc: Always return per-wtxid entries in submitpackage tx-results":
(https://github.com/bitcoin/bitcoin/pull/33427#discussion_r2370347016)
Fwiw not a huge deal but I wouldn't recommend doing an unnecessary refactor at the same time as a fix to the missing RPC result.

Looks like this is creating a copy of the string to avoid 2 calls to `GetHex()`, which seems sensible.
💬 chrisguida commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3321570824)
NACK

This is too little, too late.

It does not matter whether this option is deprecated or not. With the merging of #32406, core has already signaled that it is absolutely unwilling to address data spam, ever, and is now accelerating towards spam maximization.

Since **our hostility** to spam _is_ the main deterrent against spam (see: why Vitalik stopped trying to build Ethereum on bitcoin: ["I did not want to build on a base protocol whose dev team would be at war with me"](https://x.co
...