Bitcoin Core Github
44 subscribers
120K links
Download Telegram
💬 glozow commented on pull request "validate package transactions with their in-package ancestor sets":
(https://github.com/bitcoin/bitcoin/pull/26711#discussion_r1246479807)
> So my https://github.com/bitcoin/bitcoin/pull/26711#discussion_r1226067022 for that would be to have net_processing do retries:

This seems like a good option to consider for computational complexity, but I think could be even slower if we are blocked by UTXO fetching - they are cached when fetched in `PreChecks`, uncached at the end of `ProcessNewPackage`, and then reloaded again when we retry. So just thinking about UTXO fetching, it seems better to do retries while we have them loaded and
...
📝 fanquake opened a pull request: "contrib: add macOS test for fixup_chains usage"
(https://github.com/bitcoin/bitcoin/pull/27999)
Followup to #27676, adding the check for chain fixups.

Somewhat annoyingly, we have to patch support for `-no_fixup_chains` into ld64. As it doesn't seem to have been added [until a later version](https://github.com/apple-oss-distributions/ld64/blob/59a99ab60399c5e6c49e6945a9e1049c42b71135/src/ld/Options.cpp#L4172).
💬 glozow commented on pull request "validate package transactions with their in-package ancestor sets":
(https://github.com/bitcoin/bitcoin/pull/26711#discussion_r1246480765)
After whiteboarding this idea + chunking, ended up with https://github.com/bitcoin/bitcoin/pull/26711#issuecomment-1612912372
💬 stratospher commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#discussion_r1244700187)
53c1b7a: nit: since starting with block_counter = 1 is a detail of RFC8439's AEAD and not RFC8439's ChaCha20, would it be better to just mention the general form?
```suggestion
* In this mode, only 2^38 - 64*block_counter bytes can be encrypted.
```
💬 stratospher commented on pull request "Add support for RFC8439 variant of ChaCha20":
(https://github.com/bitcoin/bitcoin/pull/27985#discussion_r1246254085)
2c0c749: this test vector is repeated in this [line](https://github.com/bitcoin/bitcoin/blob/626d3464695ed513e555371b870a5899872d723b/src/test/crypto_tests.cpp#L486).
👍 dergoegge approved a pull request: "test: Fuzz on macOS"
(https://github.com/bitcoin/bitcoin/pull/27932#pullrequestreview-1505139891)
utACK fae7c50d201726f605938c3511dd9119efeea5ec
⚠️ naftalimurgor opened an issue: "Error: no RPC connection" when trying to run Bitcoin Core functional tests"
(https://github.com/bitcoin/bitcoin/issues/28000)
### Motivation

I'm getting a strange error running tests under `/src/test/functional/` with the following error:

```sh
Temporary test directory at /tmp/test_runner_₿_🏃_20220504_123152
Running Unit Tests for Test Framework Modules
..........
----------------------------------------------------------------------
Ran 10 tests in 0.614s

OK
Traceback (most recent call last):
File "/usr/src/bitcoin/test/functional/create_cache.py", line 27, in <module>
CreateCache().main()
Fil
...
💬 fanquake commented on pull request "contrib: add macOS test for fixup_chains usage":
(https://github.com/bitcoin/bitcoin/pull/27999#issuecomment-1613016499)
cc @theuni
💬 dergoegge commented on pull request "ci: build Valgrind (3.21) from source":
(https://github.com/bitcoin/bitcoin/pull/27992#issuecomment-1613018513)
Concept ACK

Speeding up the valgrind jobs seems like a nice win! (assuming our self compiled valgrind isn't skipping more expensive checks).
🚀 fanquake merged a pull request: "test: Fuzz on macOS"
(https://github.com/bitcoin/bitcoin/pull/27932)
👍 hebasto approved a pull request: "ci: filter all subtrees from tidy output"
(https://github.com/bitcoin/bitcoin/pull/27996#pullrequestreview-1505169342)
re-ACK 62633b50461cb67dfb37d6485e604152e727559c
💬 MarcoFalke commented on issue "Error: no RPC connection" when trying to run Bitcoin Core functional tests":
(https://github.com/bitcoin/bitcoin/issues/28000#issuecomment-1613069039)
Can you try with:


```diff
diff --git a/test/functional/test_framework/test_node.py b/test/functional/test_framework/test_node.py
index 5111d88e15..1e605e00b8 100755
--- a/test/functional/test_framework/test_node.py
+++ b/test/functional/test_framework/test_node.py
@@ -232,6 +232,8 @@ class TestNode():
poll_per_s = 4
for _ in range(poll_per_s * self.rpc_timeout):
if self.process.poll() is not None:
+ self.stderr.seek(0)
+
...
🚀 fanquake merged a pull request: "ci: filter all subtrees from tidy output"
(https://github.com/bitcoin/bitcoin/pull/27996)
💬 willcl-ark commented on pull request "net: run disconnect in I2P thread":
(https://github.com/bitcoin/bitcoin/pull/27912#issuecomment-1613098947)
Yes I agree and like this approach better.

I had created a `ThreadI2PSocketHandler()` thread which essentially had the same loop as `ThreadSocketHandler()`. The repetition of `DisconnectNodes()` and `NotifyNumConnectionsChanged()` in two threads seemed annoying (and needed a few new locks) and I was considering whether a _new_ seperate thread should just handle disconnecting nodes marked for disconnection and notifications, but I think doing it as part of `CreateNodeFromAcceptedSocket()` (in
...
💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#issuecomment-1613145594)
`4557cc336f...353d323356`: take some suggestions

Invalidates ACK from @jonatack
⚠️ re2005 opened an issue: "Unable to send funds"
(https://github.com/bitcoin/bitcoin/issues/28001)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Using Bitcoin Core `v25.0.0` have it sync (pruned)

My wallet shows valid balance but I'm not able to send funds

### Expected behaviour

Be able to send funds when the wallet display you have balance

![Screenshot 2023-06-29 at 15 00 51](https://github.com/bitcoin/bitcoin/assets/2920357/8e1fea39-7032-4743-bf8f-f9b11f9b8cad)


### Steps to reproduce

- Try to send funds to a valid rec
...
💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246596157)
Alright, so I got it the other way around. So the point is to avoid recompiling all tests if e.g. `ALL_NETWORKS` is changed (defined in `test/util/net.h`). That lowers the re-compilation from 28-29 sec to about 10 sec (if `src/test/util/net.h` is modified).

I will leave it as it is because moving the code around would further increase the size of this PR which suffers from lack of interest from reviewers and I think expanding it may further turn people away.
💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246596519)
Done.
💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246596786)
Done.
💬 vasild commented on pull request "test: add end-to-end tests for CConnman and PeerManager":
(https://github.com/bitcoin/bitcoin/pull/26812#discussion_r1246602200)
Done.

I changed it to use `{}` as suggested but I don't see a point to use `{}` instead of `=` for initialization when `auto` is used. I find the `{}` variant a little bit less readable but see the merit to use it when `Type1 x{expresson_of_Type2};` is used to detect incompatibilities between `Type1` and `Type2`. But why do that for `auto x{expressoin_of_any_type};`?