Bitcoin Core Github
44 subscribers
120K links
Download Telegram
💬 maflcko commented on pull request "tests: cover abortrescan() in-flight True path with dynamic-tail retry":
(https://github.com/bitcoin/bitcoin/pull/33131#discussion_r2382182289)
are you still working on this?
maflcko closed a pull request: "Prevent file descriptor exhaustion from too many RPC calls"
(https://github.com/bitcoin/bitcoin/pull/27731)
💬 maflcko commented on pull request "Prevent file descriptor exhaustion from too many RPC calls":
(https://github.com/bitcoin/bitcoin/pull/27731#issuecomment-3338327596)
+gha CI
📝 maflcko reopened a pull request: "Prevent file descriptor exhaustion from too many RPC calls"
(https://github.com/bitcoin/bitcoin/pull/27731)
Fixes #11368

This requires libevent 2.2.1 which so far was only [released in alpha](https://github.com/libevent/libevent/releases/tag/release-2.2.1-alpha).

For more context see specifically https://github.com/bitcoin/bitcoin/issues/11368#issuecomment-632717903, this uses the feature mentioned there as libevent#592.
💬 janb84 commented on pull request "build: Move CMAKE_SKIP_INSTALL_RPATH from CMake to Guix script":
(https://github.com/bitcoin/bitcoin/pull/33470#discussion_r2382259990)
Now that you have changed this, please update the PR description to match the recent change:

"Add -DCMAKE_SKIP_INSTALL_RPATH=TRUE to Guix build script cmake configuration" =>
Add -DCMAKE_SKIP_RPATH=TRUE to Guix build script cmake configuration
💬 theStack commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2382295705)
in commit fd52cd05d2bf11e059472e74fe6a771aa139b136: I noticed that the creation/extension of the `PSBTInput.m_musig2_{pubnonces,partial_sigs}` maps is slightly more complex here (involving a loop), in contrast to the counter-part in the other direction in `FillSignatureData`, where a single-line `.insert` is used. Is that intentional, or can they be unified in either way (i.e. also only use bare `.insert` here, or introduce loops in `FillSignatureData` as well if it's needed)?

Right now, `Fil
...
1
💬 vasild commented on pull request "ci: detect outbound internet traffic generated while running tests":
(https://github.com/bitcoin/bitcoin/pull/31349#issuecomment-3338565128)
`151edfaf78...f4fdf81d3a`: rebase and [remove `INTERNET_TRAFFIC_EXPECTED`](https://github.com/bitcoin/bitcoin/pull/31349#discussion_r2333792206).
💬 vasild commented on pull request "ci: detect outbound internet traffic generated while running tests":
(https://github.com/bitcoin/bitcoin/pull/31349#discussion_r2382314894)
Removed `INTERNET_TRAFFIC_EXPECTED`. Maybe it was an overkill in the first place.
💬 willcl-ark commented on pull request "test: Run bench sanity checks in parallel with functional tests":
(https://github.com/bitcoin/bitcoin/pull/33142#issuecomment-3338762732)
Ah interesting, that is quite similar in the end to my "workaround" (of building first, then a `generate_bench_tests` target).

I am Concept ACK using the python framework then, in the absence of any other benefits.
💬 theStack commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2382545727)
in commits 0829833bf418d3fae35ceac57cae6137c1e9067d, e54d27d0f81c7a9c8991516f1ed06e86d52d6c79 and b6b66426125e46deb331927a5942e157578e712c: nit, in spirit of #33399: could use `secp256k1_context_static` where sufficient. If I didn't miss anything, I think the only two secp256k1 calls introduced in this PR that need the `secp256k1_context_sign` context are:
* `secp256k1_musig_nonce_gen` and
* `secp256k1_keypair_create`
💬 theStack commented on pull request "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys":
(https://github.com/bitcoin/bitcoin/pull/29675#discussion_r2382524112)
in commit e54d27d0f81c7a9c8991516f1ed06e86d52d6c79: consistency nit: same as in `CreateMuSig2AggregateSig`, could also check that the pubnonces and pubkey count match here, i.e.
```
// Check if enough pubnonces
if (pubnonces.size() != pubkeys.size()) return std::nullopt;

```
💬 brunoerg commented on issue "Ability to retrieve peer info by peer id":
(https://github.com/bitcoin/bitcoin/issues/33478#issuecomment-3338963332)
> for reference, this seems related to [#32741](https://github.com/bitcoin/bitcoin/pull/32741)

Should #32741 be up for graps?
💬 glozow commented on pull request "docs: Undeprecate datacarrier and datacarriersize configuration options":
(https://github.com/bitcoin/bitcoin/pull/33453#issuecomment-3338979025)
> Tangibly, that would mean closing this PR and a new one to change the sentence
> Let me know @glozow.

It looks like you have conceptual support from folks to change the string, but strong preferences for one of two approaches. Your call whether you want to change your PR, leave it as is, open a new one, etc. Not everyone will agree.
💬 glozow commented on pull request "[28.x] More backports":
(https://github.com/bitcoin/bitcoin/pull/33415#discussion_r2382612607)
fixed in #33476
💬 glozow commented on pull request "[28.x] backports + 28.3rc1":
(https://github.com/bitcoin/bitcoin/pull/33476#discussion_r2382621427)
fixed
💬 glozow commented on pull request "test: improve BDB parser (handle internal/overflow pages, support all page sizes)":
(https://github.com/bitcoin/bitcoin/pull/30125#issuecomment-3339002781)
backported to 28.x in #33476
💬 glozow commented on pull request "policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee":
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3339005617)
backported to 29.x in #33226
backported to 28.x in #33476
👋 glozow's pull request is ready for review: "[28.x] backports + 28.3rc1"
(https://github.com/bitcoin/bitcoin/pull/33476)
💬 glozow commented on pull request "[28.x] backports + 28.3rc1":
(https://github.com/bitcoin/bitcoin/pull/33476#issuecomment-3339030472)
Ready for review, though I think the tidy job tripped somehow?
🤔 rkrux reviewed a pull request: "wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys"
(https://github.com/bitcoin/bitcoin/pull/29675#pullrequestreview-3272643818)
Code review 02994c2cbe2f051b868f49e65fac042feace2edf

Thanks for addressing the previous comments.

I'm about to wrap up my review by taking a look at the `libsecp` specific functions used in the `CreateMuSig2*` functions.