Bitcoin Core Github
44 subscribers
121K links
Download Telegram
πŸ“ mzumsande opened a pull request: "cli: add -usefile option"
(https://github.com/bitcoin/bitcoin/pull/32399)
Running large commands via `bitcoin-cli` (such as submitting a large tx or block) runs into the `MAX_ARG_STRLEN` limit, which is 128KB on many systems. (see e.g. https://trofi.github.io/posts/299-maximum-argument-count-on-linux-and-in-gcc.html for more info).

This PR suggests to make it possible to bypass this limit by allowing to put the command and all of its args into a file. The functional test framework is then adjusted to automatically use this option (using a temporary file) if `--usec
...
πŸ’¬ oxqnd commented on issue "combinerawtransaction confusing with distinct transactions":
(https://github.com/bitcoin/bitcoin/issues/25980#issuecomment-2845932631)
> > Could I try this issue?
>
> Would you mind reviewing https://github.com/bitcoin/bitcoin/pull/31298 instead?
>
> This solution is still up to date, it just hasn't gotten the right reviewers.

I’ll take a look at #31298, but it might take me a little while to get to it. Hope that’s okay!
πŸ’¬ rebroad commented on pull request "Enhanced Traffic Graph Widget with Multi-timeframe Support and Data Persistence":
(https://github.com/bitcoin-core/gui/pull/866#issuecomment-2845967863)
I've removed the code that changed the totals on the node - the GUI just keeps track now without writing values to the node. Also, added some checks for corrupt save files so that it doesn't load bad data.
πŸ’¬ achow101 commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#issuecomment-2846003391)
ACK 85368aafa0d1772626d5f615e272b1c1a580b42f
πŸ’¬ monlovesmango commented on pull request "Refactor BnB tests":
(https://github.com/bitcoin/bitcoin/pull/29532#issuecomment-2846047880)
ACK 85368aafa0d1772626d5f615e272b1c1a580b42f
πŸ“ davidgumberg opened a pull request: "random: Use modern Windows randomness functions"
(https://github.com/bitcoin/bitcoin/pull/32400)
This resolves #32391 and is a follow-up to #14089.

The old randomness API has been deprecated and will be removed at some point.[^1]

For reference on `BCryptGenRandom`, see: https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom.

[`STATUS_SUCCESS`](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55) gets defined here since including `ntstatus.h` is [more trouble](https://github.com/bitcoin-core/secp25
...
πŸ’¬ davidgumberg commented on issue "Use of deprecated CryptAcquireContext in random.cpp":
(https://github.com/bitcoin/bitcoin/issues/32391#issuecomment-2846087303)
Opened #32400 to resolve.
πŸ’¬ davidgumberg commented on pull request "crypto: Use secure_allocator for `AES256_ctx`":
(https://github.com/bitcoin/bitcoin/pull/31774#discussion_r2070981899)
Thanks, fixed.
πŸ’¬ davidgumberg commented on pull request "crypto: Use secure_allocator for `AES256_ctx`":
(https://github.com/bitcoin/bitcoin/pull/31774#discussion_r2070981955)
Thanks, fixed.
πŸ’¬ davidgumberg commented on pull request "crypto: Use secure_allocator for `AES256_ctx`":
(https://github.com/bitcoin/bitcoin/pull/31774#issuecomment-2846099273)
Rebase to address style feedback.
πŸ€” shahsb reviewed a pull request: "random: Use modern Windows randomness functions"
(https://github.com/bitcoin/bitcoin/pull/32400#pullrequestreview-2811079433)
Concept ACK
πŸ’¬ monlovesmango commented on pull request "tests: Added progress tracker when running fuzz test_runner.py":
(https://github.com/bitcoin/bitcoin/pull/32354#issuecomment-2846328501)
Concept ACK, but I think approach NACK.

Instead of creating a whole new set of output, why not just take the summary and print it as results arrive rather than holding them all until the end? I put together a quick POC which produces the output below in real time (rather than waiting until end):
```bash
(1/221) addition_overflow #60 DONE cov: 265 ft: 320 corp: 47/1674b lim: 62 exec/s: 0 rss: 115Mb
(2/221) addr_info_deserialize #110 DO
...
πŸ’¬ vasild commented on pull request "Split CConnman":
(https://github.com/bitcoin/bitcoin/pull/30988#issuecomment-2846425432)
`7ef9661fb0...503791ed57`: rebase due to conflicts
πŸ’¬ Sjors commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2846433582)
That sounds reasonable at first glance. Each commit has to pass the tests. Ideally anytime you introduce a new function you would also add at least one test, and/or use that function in existing code (to show that it doesn't break any test).
πŸ’¬ rebroad commented on pull request "Enhanced Traffic Graph Widget with Multi-timeframe Support and Data Persistence":
(https://github.com/bitcoin-core/gui/pull/866#issuecomment-2846478431)
I realise this PR is starting to look a bit messy with all the updates. I also realise I ought to separate various functionality changes into separate commits. Is it better to raise a new PR once this is done, force push to this one?
⚠️ Sjors opened an issue: "rfc: separate relay from mining policy"
(https://github.com/bitcoin/bitcoin/issues/32401)
Greg Maxwell brought up an idea on the mailinglist that I think is worth preserving here, although I don't think it's currently needed:

> That said, Bitcoin core has generally not
had knobs to adjust relay policy as distinct from mining policy in large
part because of the design assumption that the two need to be the same.
But in this case if there were a knob here I think would make more sense
for it to control **mining policy rather than relay policy**, since it would
actually have some
...
πŸ’¬ vasild commented on pull request "test: add mocked Sock that can read/write custom data and/or CNetMessages":
(https://github.com/bitcoin/bitcoin/pull/30205#issuecomment-2846604494)
This is low prio (for me) and I haven't had the time to PR it for a few months, so I am leaving it as it it. If anybody does PR the diff above or similar, then I would review.
⚠️ mrberlinorg opened an issue: "Removing the check for nDataOut > 1 would allow multiple OP_RETURN outputs in a single transaction, which goes against the standard behavior of the Bitcoin protocol. This could introduce several issues:"
(https://github.com/bitcoin/bitcoin/issues/32402)
Removing the check for nDataOut > 1 would allow multiple OP_RETURN outputs in a single transaction, which goes against the standard behavior of the Bitcoin protocol. This could introduce several issues:

Non-standard transactions: Multiple OP_RETURN outputs in a transaction are considered non-standard. Allowing them could lead to network inconsistencies, as some nodes might not be able to properly process or relay these transactions.

Network congestion: More OP_RETURN outputs
...
πŸ’¬ Sjors commented on pull request "test: add mocked Sock that can read/write custom data and/or CNetMessages":
(https://github.com/bitcoin/bitcoin/pull/30205#issuecomment-2846705290)
Feel free to tag me in such a PR.