📝 hodlinator opened a pull request: "test: Fix copy-paste in wallet/test/db_tests ostream operator"
(https://github.com/bitcoin/bitcoin/pull/31038)
Fix accidentally remaining copy-pasted variable name.
Example output when intentionally adding `expected.erase(expected.begin());` before `BOOST_CHECK_EQUAL_COLLECTIONS` in *db_tests.cpp*/`CheckPrefix`
Before fix:
```
src/wallet/test/db_tests.cpp(61): error: in "db_tests/db_cursor_prefix_byte_test": check { actual.begin(), actual.end() } == { expected.begin(), expected.end() } has failed.
Mismatch at position 0: ("�", "�") != ("�suffix", "�suffix")
Mismatch at position 1: ("�suffix",
...
(https://github.com/bitcoin/bitcoin/pull/31038)
Fix accidentally remaining copy-pasted variable name.
Example output when intentionally adding `expected.erase(expected.begin());` before `BOOST_CHECK_EQUAL_COLLECTIONS` in *db_tests.cpp*/`CheckPrefix`
Before fix:
```
src/wallet/test/db_tests.cpp(61): error: in "db_tests/db_cursor_prefix_byte_test": check { actual.begin(), actual.end() } == { expected.begin(), expected.end() } has failed.
Mismatch at position 0: ("�", "�") != ("�suffix", "�suffix")
Mismatch at position 1: ("�suffix",
...
🤔 hodlinator reviewed a pull request: "bench: add support for custom data directory"
(https://github.com/bitcoin/bitcoin/pull/31000#pullrequestreview-2350404241)
`git range-diff master 1ba225c ded1a6c`
Still feel like it would be good to call a common function adding *-testdatadir* to an `ArgsManager` instead of duplicating the functionality between test/bench (and having a different description-string).
(https://github.com/bitcoin/bitcoin/pull/31000#pullrequestreview-2350404241)
`git range-diff master 1ba225c ded1a6c`
Still feel like it would be good to call a common function adding *-testdatadir* to an `ArgsManager` instead of duplicating the functionality between test/bench (and having a different description-string).
💬 hodlinator commented on pull request "bench: add support for custom data directory":
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788721681)
Agree a `SetupTestArgs` may not communicate clearly enough that the function is used in a broader context. How about calling it `SetupCommonTestArgs` and adding a comment about it being used in benchmarks as well? That, together with no longer marking the function `static` (private to the compilation unit), might mitigate your concerns?
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788721681)
Agree a `SetupTestArgs` may not communicate clearly enough that the function is used in a broader context. How about calling it `SetupCommonTestArgs` and adding a comment about it being used in benchmarks as well? That, together with no longer marking the function `static` (private to the compilation unit), might mitigate your concerns?
💬 hodlinator commented on pull request "bench: add support for custom data directory":
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788722245)
> I don't feel strong about the capitalization neither but it looks incorrect to introduce it now when all other functions aren't using it.
(`SetupBenchArgs` is capitalized, `main` must be non-capitalized, so that only leaves `parseAsymptote` to change beyond the function under discussion).
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788722245)
> I don't feel strong about the capitalization neither but it looks incorrect to introduce it now when all other functions aren't using it.
(`SetupBenchArgs` is capitalized, `main` must be non-capitalized, so that only leaves `parseAsymptote` to change beyond the function under discussion).
💬 hodlinator commented on pull request "bench: add support for custom data directory":
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788724651)
A bit heavy for one arg as it is right now, but I like that it avoids repeating the name. :+1:
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788724651)
A bit heavy for one arg as it is right now, but I like that it avoids repeating the name. :+1:
💬 furszy commented on pull request "bench: add support for custom data directory":
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788760477)
> Agree a `SetupTestArgs` may not communicate clearly enough that the function is used in a broader context. How about calling it `SetupCommonTestArgs` and adding a comment about it being used in benchmarks as well? That, together with no longer marking the function `static` (private to the compilation unit), might mitigate your concerns?
I'm not so in favor of mentioning upper level binaries or frameworks in lower level files but no problem in applying the suggestion.
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788760477)
> Agree a `SetupTestArgs` may not communicate clearly enough that the function is used in a broader context. How about calling it `SetupCommonTestArgs` and adding a comment about it being used in benchmarks as well? That, together with no longer marking the function `static` (private to the compilation unit), might mitigate your concerns?
I'm not so in favor of mentioning upper level binaries or frameworks in lower level files but no problem in applying the suggestion.
💬 furszy commented on pull request "bench: add support for custom data directory":
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788763177)
Hmm well, I'm still a bit reluctant to it. It would add `test/util/setup_common.h` dependency to the benchmark binary entry point just for a single line of code.
(https://github.com/bitcoin/bitcoin/pull/31000#discussion_r1788763177)
Hmm well, I'm still a bit reluctant to it. It would add `test/util/setup_common.h` dependency to the benchmark binary entry point just for a single line of code.
💬 kilianmh commented on issue "RFC: Formal description of the RPC API":
(https://github.com/bitcoin/bitcoin/issues/29912#issuecomment-2395240266)
Thank you for your comments @hodlinator
1.
> A more automated way would be to do something like the Golang RPC doc generator in my first link above.
Indeed, autogeneration is the best way forward. I just did copy paste to showcase what can be done.
2.
> Conversely, have you noticed anything bitcoind does that goes against the OpenRPC spec?
You mentioned the main thing that i am not sure of if it is possible:
> JSON-RPC interface only uses [one main path + wallet path](https
...
(https://github.com/bitcoin/bitcoin/issues/29912#issuecomment-2395240266)
Thank you for your comments @hodlinator
1.
> A more automated way would be to do something like the Golang RPC doc generator in my first link above.
Indeed, autogeneration is the best way forward. I just did copy paste to showcase what can be done.
2.
> Conversely, have you noticed anything bitcoind does that goes against the OpenRPC spec?
You mentioned the main thing that i am not sure of if it is possible:
> JSON-RPC interface only uses [one main path + wallet path](https
...
💬 1440000bytes commented on issue "Listen on random port by default (not 8333)":
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2395248735)
There are 7000 IPv4 and 2000 IPv6 nodes. I expect this ratio to continue for next 10 years based on this [adoption](https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption).
IPv4 nodes will not be able to benefit from non-default port support because of DNS seeds and IPv6.
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2395248735)
There are 7000 IPv4 and 2000 IPv6 nodes. I expect this ratio to continue for next 10 years based on this [adoption](https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption).
IPv4 nodes will not be able to benefit from non-default port support because of DNS seeds and IPv6.
💬 melvincarvalho commented on issue "[Testnet] Insufficient data or no feerate found":
(https://github.com/bitcoin/bitcoin/issues/31032#issuecomment-2395402903)
@azazar There are currently 3 working faucets (which imho is much better than testnet3):
https://github.com/testnet4/awesome-testnet4?tab=readme-ov-file#faucets
I know vkbit is looking into creating a faucet, and I’ve got one in progress as well. If you’re working on testnet4 projects, feel free to reach out to me directly (Nostr/Twitter), and I can share some of what I’ve got.
From what I can tell, blocks are being CPU mined roughly every 20 minutes, though timestamps are spoofed by +2
...
(https://github.com/bitcoin/bitcoin/issues/31032#issuecomment-2395402903)
@azazar There are currently 3 working faucets (which imho is much better than testnet3):
https://github.com/testnet4/awesome-testnet4?tab=readme-ov-file#faucets
I know vkbit is looking into creating a faucet, and I’ve got one in progress as well. If you’re working on testnet4 projects, feel free to reach out to me directly (Nostr/Twitter), and I can share some of what I’ve got.
From what I can tell, blocks are being CPU mined roughly every 20 minutes, though timestamps are spoofed by +2
...
⚠️ fanquake opened an issue: "RPC breakage with v28.0"
(https://github.com/bitcoin/bitcoin/issues/31039)
If you're experiencing issues with Bitcoin Core 28.x, and using RPC, please report them here.
(https://github.com/bitcoin/bitcoin/issues/31039)
If you're experiencing issues with Bitcoin Core 28.x, and using RPC, please report them here.
💬 sipa commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395421935)
Known issues:
* Some software sends the JSON-RPC version as a number (`"version": 1.0`) instead of as a string (`"version": "1.0"`), which fails the sanity check introduced with JSON-RPC 2.0 compatibility (#27101).
* The `"warnings"` field returned by some RPCs (`getblockchaininfo`, `getmininginfo`, and `getnetworkinfo`) is now an array instead of a string. The old behavior can be re-enabled by running with `-deprecatedrpc=warning`.
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395421935)
Known issues:
* Some software sends the JSON-RPC version as a number (`"version": 1.0`) instead of as a string (`"version": "1.0"`), which fails the sanity check introduced with JSON-RPC 2.0 compatibility (#27101).
* The `"warnings"` field returned by some RPCs (`getblockchaininfo`, `getmininginfo`, and `getnetworkinfo`) is now an array instead of a string. The old behavior can be re-enabled by running with `-deprecatedrpc=warning`.
💬 sipa commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395422943)
LND up to 0.18.3 seems to be incompatible with Bitcoin Core 28.0 due to the `"warnings"` field change: https://github.com/lightningnetwork/lnd/issues/9053.
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395422943)
LND up to 0.18.3 seems to be incompatible with Bitcoin Core 28.0 due to the `"warnings"` field change: https://github.com/lightningnetwork/lnd/issues/9053.
💬 sipa commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395424053)
The `bitcoin-rpc` NPM package seems to be incompatible with Bitcoin Core 28.0 due to sending an incorrect version type: https://github.com/vansergen/rpc-bitcoin/pull/65.
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395424053)
The `bitcoin-rpc` NPM package seems to be incompatible with Bitcoin Core 28.0 due to sending an incorrect version type: https://github.com/vansergen/rpc-bitcoin/pull/65.
💬 pinheadmz commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395424261)
The value for "version" was never checked and still is not. The value for "jsonrpc" since @27101 MUST be a string. If that string is "1.0" then the old JSONRPC behavior is followed (since some old documentation incorrectly recommended this). If that string is "2.0" then the new JSONRPC behavior is followed.
Sending any other string or value type for "jsonrpc" returns a parsing error.
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395424261)
The value for "version" was never checked and still is not. The value for "jsonrpc" since @27101 MUST be a string. If that string is "1.0" then the old JSONRPC behavior is followed (since some old documentation incorrectly recommended this). If that string is "2.0" then the new JSONRPC behavior is followed.
Sending any other string or value type for "jsonrpc" returns a parsing error.
💬 sipa commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395424650)
@pinheadmz Thanks, fixed.
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395424650)
@pinheadmz Thanks, fixed.
💬 dr-orlovsky commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395438242)
I do experience.
Basically mempool electrs v3.0.0 in combination with Bitcoin Core v28.0 kill each other once Bitcoin core stops IBS and mempool load
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395438242)
I do experience.
Basically mempool electrs v3.0.0 in combination with Bitcoin Core v28.0 kill each other once Bitcoin core stops IBS and mempool load
💬 ketominer commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395440376)
> The `bitcoin-rpc` NPM package seems to be incompatible with Bitcoin Core 28.0 due to sending an incorrect version type: [vansergen/rpc-bitcoin#65](https://github.com/vansergen/rpc-bitcoin/pull/65).
Which FWIW in turn affects Dojo which uses this library. Dojo Coder is aware of the issue and working on changing the RPC client library or fixing rpc-bitcoin but it seems pretty much unmaintained.
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395440376)
> The `bitcoin-rpc` NPM package seems to be incompatible with Bitcoin Core 28.0 due to sending an incorrect version type: [vansergen/rpc-bitcoin#65](https://github.com/vansergen/rpc-bitcoin/pull/65).
Which FWIW in turn affects Dojo which uses this library. Dojo Coder is aware of the issue and working on changing the RPC client library or fixing rpc-bitcoin but it seems pretty much unmaintained.
💬 sipa commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395440892)
@dr-orlovsky Does running with `-deprecatedrpc=warnings` fix your issue?
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395440892)
@dr-orlovsky Does running with `-deprecatedrpc=warnings` fix your issue?
💬 epiccurious commented on issue "RPC breakage with v28.0":
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395452735)
Saw someone's tweet about having to increase `rpcworkqueue`.
https://x.com/_behodler/status/1842657622018683198
(https://github.com/bitcoin/bitcoin/issues/31039#issuecomment-2395452735)
Saw someone's tweet about having to increase `rpcworkqueue`.
https://x.com/_behodler/status/1842657622018683198