📝 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
...
(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
(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))
(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
(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-
...
(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)
(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
(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
(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?
(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))
(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`.
(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
(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) ?
(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.
(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.
💬 dergoegge commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1517911046)
One shot connections + immediate tx broadcast without inv,getdata exchange leaks that the tx is likely being broadcast or the first time (easy to censor the tx as the receiver).
Perhaps it is worth combining this with https://github.com/bitcoin/bitcoin/pull/27213 and instead of one-shot connections we broadcast only to existing selected connections on these privacy networks. Our own transactions would then still benefit from being broadcast along side other transactions.
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1517911046)
One shot connections + immediate tx broadcast without inv,getdata exchange leaks that the tx is likely being broadcast or the first time (easy to censor the tx as the receiver).
Perhaps it is worth combining this with https://github.com/bitcoin/bitcoin/pull/27213 and instead of one-shot connections we broadcast only to existing selected connections on these privacy networks. Our own transactions would then still benefit from being broadcast along side other transactions.
📝 fanquake opened a pull request: "ci: drop untrusted bpfcc tool usage"
(https://github.com/bitcoin/bitcoin/pull/27510)
Followup to #27360, where we migrated this job to Ubuntu 23.04, which ships with newer versions of the tools: https://packages.ubuntu.com/lunar/bpfcc-tools.
(https://github.com/bitcoin/bitcoin/pull/27510)
Followup to #27360, where we migrated this job to Ubuntu 23.04, which ships with newer versions of the tools: https://packages.ubuntu.com/lunar/bpfcc-tools.
🤔 0xB10C reviewed a pull request: "ci: drop untrusted bpfcc tool usage"
(https://github.com/bitcoin/bitcoin/pull/27510#pullrequestreview-1395884958)
Big Concept ACK!
(https://github.com/bitcoin/bitcoin/pull/27510#pullrequestreview-1395884958)
Big Concept ACK!
💬 0xB10C commented on pull request "ci: drop untrusted bpfcc tool usage":
(https://github.com/bitcoin/bitcoin/pull/27510#discussion_r1173836551)
You can drop the comment too
(https://github.com/bitcoin/bitcoin/pull/27510#discussion_r1173836551)
You can drop the comment too
💬 dergoegge commented on pull request "net: use interruptible async getaddrinfo wrapper from libevent for DNS":
(https://github.com/bitcoin/bitcoin/pull/27505#discussion_r1173837388)
> libevent does not call the platform getaddrinfo for dns requests, it has its own async methods
That explains why it doesn't hang, thanks!
But it does seem like it uses `getaddrinfo` in some cases: https://github.com/libevent/libevent/blob/75208132d5b7a8fff59ca3bf47253179ec314951/evutil.c#L1686
(https://github.com/bitcoin/bitcoin/pull/27505#discussion_r1173837388)
> libevent does not call the platform getaddrinfo for dns requests, it has its own async methods
That explains why it doesn't hang, thanks!
But it does seem like it uses `getaddrinfo` in some cases: https://github.com/libevent/libevent/blob/75208132d5b7a8fff59ca3bf47253179ec314951/evutil.c#L1686
💬 fanquake commented on pull request "ci: drop untrusted bpfcc tool usage":
(https://github.com/bitcoin/bitcoin/pull/27510#discussion_r1173839494)
Thanks, dropped.
(https://github.com/bitcoin/bitcoin/pull/27510#discussion_r1173839494)
Thanks, dropped.