Bitcoin Core Github
43 subscribers
123K links
Download Telegram
💬 dergoegge commented on pull request "net: use interruptible async getaddrinfo wrapper from libevent for DNS":
(https://github.com/bitcoin/bitcoin/pull/27505#issuecomment-1517787932)
> Any suggestions?

The issue seems somewhat stale so maybe no need to fix? Judging by your last comment, you were also not able to reproduce? (https://github.com/bitcoin/bitcoin/issues/16778#issuecomment-1458423187)
💬 pinheadmz commented on pull request "net: use interruptible async getaddrinfo wrapper from libevent for DNS":
(https://github.com/bitcoin/bitcoin/pull/27505#issuecomment-1517793681)
I was able to somewhat reproduce -- by sending all DNS requests on my machine to a blackhole resolver, I observed a 30 second pause during shutdown. But I think that 30 seconds may be platform-specific, or whatever the local `getaddrinfo()` implementation is.
💬 pinheadmz commented on issue "Compiling a bitcoin core version that accepts transactions over 100vkb":
(https://github.com/bitcoin/bitcoin/issues/27490#issuecomment-1517797906)
If you're modifying the source code, you won't get much help with build errors here. I think we should close this issue.
🚀 fanquake merged a pull request: "depends: reuse _config_opts for CMake options"
(https://github.com/bitcoin/bitcoin/pull/27496)
💬 dergoegge commented on pull request "net: use interruptible async getaddrinfo wrapper from libevent for DNS":
(https://github.com/bitcoin/bitcoin/pull/27505#discussion_r1173774847)
Wouldn't this also wait indefinitely for `getaddrinfo` to finish before the thread can join?
📝 vasild opened a pull request: "Relay own transactions only via short-lived Tor or I2P connections"
(https://github.com/bitcoin/bitcoin/pull/27509)
_This is an early draft to get some feedback on the design. It compiles, but some obvious things are missing._

Introduce a new connection type for relaying sensitive data (our own transactions) with the following properties:
* started whenever there are local unbroadcast transactions to be sent
* only opened to Tor or I2P peers
* opened regardless of max connections limits
* after handshake is completed one local transaction is pushed to the peer and the connection is closed
* ignore all
...
🤔 darosior reviewed a pull request: "kernel: chainparams updates for 25.x"
(https://github.com/bitcoin/bitcoin/pull/27482#pullrequestreview-1395792882)
ACK a2bef805c11a4ab391f4ea635bfde7dd2ec9ce81

```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK a2bef805c11a4ab391f4ea635bfde7dd2ec9ce81 -- it's what i got on my node too.
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEEWQtykmla/6W2csuy4T/BRc0/QwQFAmRCkgIACgkQ4T/BRc0/
QwQICwv/Y9xMr4N/IfzZo/i49/3TFw6vMi5W4/zu0qluakMU1FCcvrokJ6LbKORA
gZsfLfdXTDdH9q9nXSkHNgQEKUXp15F81qIrv050Q7o02zMTxq9dLixJA30Fzhnz
8g7zCR0ASCzWC0hYHDSTQgYwH0q8cEvwxhfyIEiRTgEjsAFUHn4Ap5q5oQxDWvVR
4flCksNAJzXj7YHcp
...
📝 vasild converted_to_draft a pull request: "Relay own transactions only via short-lived Tor or I2P connections"
(https://github.com/bitcoin/bitcoin/pull/27509)
_This is an early draft to get some feedback on the design. It compiles, but some obvious things are missing._

Introduce a new connection type for relaying sensitive data (our own transactions) with the following properties:
* started whenever there are local unbroadcast transactions to be sent
* only opened to Tor or I2P peers
* opened regardless of max connections limits
* after handshake is completed one local transaction is pushed to the peer and the connection is closed
* ignore all
...
💬 dergoegge commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1517861239)
Concept ACK - cool!

> after handshake is completed one local transaction is pushed to the peer and the connection is closed

https://github.com/bitcoin/bitcoin/issues/4432 comes to mind
💬 TheCharlatan commented on pull request "refactor, kernel: Decouple ArgsManager from blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27125#issuecomment-1517866792)
Rebased 908d95e46f15f6b4def9534bc09fcdb3c0a5ef54 -> 1a7d73d30e312e862be4560601302e79725b1bc7 ([removeBlockstorageArgs_13](https://github.com/TheCharlatan/bitcoin/tree/removeBlockstorageArgs_13) -> [removeBlockstorageArgs_14](https://github.com/TheCharlatan/bitcoin/tree/removeBlockstorageArgs_14), [compare](https://github.com/TheCharlatan/bitcoin/compare/removeBlockstorageArgs_13..removeBlockstorageArgs_14))
💬 pinheadmz commented on pull request "net: use interruptible async getaddrinfo wrapper from libevent for DNS":
(https://github.com/bitcoin/bitcoin/pull/27505#discussion_r1173797262)
2 sec timeout waiting for the callback and then the loop will close. With my black hole dns resolver, the patch saves 30 seconds against master on the unit test in the second commit.

It took me some work to figure out that using ..._once() to start the event loop would allow me to quit the loop manually which allows join() to succeed
💬 fkorotkov commented on pull request "ci: use LLVM/clang-16 in native_asan job":
(https://github.com/bitcoin/bitcoin/pull/27360#discussion_r1173800223)
You can check for available images in ubuntu project like this:

```console
gcloud compute images list --project ubuntu-os-cloud --no-standard-images

NAME PROJECT FAMILY DEPRECATED STATUS
ubuntu-1804-bionic-arm64-v20230418 ubuntu-os-cloud ubuntu-1804-lts-arm64 READY
ubuntu-1804-bionic-v20230418 ubuntu-os-cloud ubuntu-1804-lts READY
ubuntu-
...
💬 pinheadmz commented on pull request "net: use interruptible async getaddrinfo wrapper from libevent for DNS":
(https://github.com/bitcoin/bitcoin/pull/27505#discussion_r1173800861)
(libevent does not call the platform getaddrinfo for dns requests, it has its own async methods)
💬 kristapsk commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1517878136)
Concept ACK
💬 MaxHillebrand commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1517885182)
Concept ACK
💬 MarcoFalke commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1517890871)
Looking at the current implementation, I am not sure how useful this is going to be, if the transaction is sent along with the potentially uniquely identifying UA comment, or other fingerprints in the version message. Maybe it makes sense to define a static version message, similar to how the tor browser replaces headers with constants?
💬 TheCharlatan commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#issuecomment-1517890877)
Rebased 32a70863215ac14b6402fd2a054aedbfe01ff30d -> 7d361083d72a267de4af258e574219abdef0fc82 ([kernelChainType_1](https://github.com/TheCharlatan/bitcoin/tree/kernelChainType_1) -> [kernelChainType_2](https://github.com/TheCharlatan/bitcoin/tree/kernelChainType_2), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelChainType_1..kernelChainType_2))
💬 fanquake commented on pull request "ci: use LLVM/clang-16 in native_asan job":
(https://github.com/bitcoin/bitcoin/pull/27360#discussion_r1173813693)
@fkorotkov Thanks for the info. Have pushed to use `family/ubuntu-2304-amd64`.
💬 MarcoFalke commented on pull request "ci: use LLVM/clang-16 in native_asan job":
(https://github.com/bitcoin/bitcoin/pull/27360#issuecomment-1517895581)
review ACK a440295fa99c6f0e7913c884cce904e22e243565
💬 sipa commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1517896418)
@MarcoFalke Good idea! Perhaps it's worth mimicking `bitcoin-submittx` (https://github.com/laanwj/bitcoin-submittx/blob/master/bitcoin-submittx#L28) ?
💬 kristapsk commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1517904089)
> Looking at the current implementation, I am not sure how useful this is going to be, if the transaction is sent along with the potentially uniquely identifying UA comment, or other fingerprints in the version message. Maybe it makes sense to define a static version message, similar to how the tor browser replaces headers with constants?

Or it could randomize it, from the list of different version strings.