Bitcoin Core Github
44 subscribers
121K links
Download Telegram
💬 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.
maflcko closed an issue: "test: functional test failures under -DENABLE_WALLET=OFF"
(https://github.com/bitcoin/bitcoin/issues/32347)
💬 maflcko commented on issue "test: functional test failures under -DENABLE_WALLET=OFF":
(https://github.com/bitcoin/bitcoin/issues/32347#issuecomment-2846803315)
> genuinely fixed this

I agree: With the removal of `is_specified_wallet_compiled` this should no longer happen. Closing for now, but feel free to re-open if the issue still exists.
💬 0xB10C commented on pull request "cli: add -usefile option":
(https://github.com/bitcoin/bitcoin/pull/32399#issuecomment-2846837427)
> This might also be helpful for users outside of the functional tests (although there is always the option to use the rpc interface directly instead of bitcoin-cli).

I've been using `-stdin` (e.g. `cat block.hex | bitcoin-cli -stdin submitblock`) for this. Would this work here too?