diff --git a/libbitcoinkernel-sys/bitcoin/.github/workflows/ci.yml b/libbitcoinkernel-sys/bitcoin/.github/workflows/ci.yml index 3ffaafe3..d4336462 100644 --- a/libbitcoinkernel-sys/bitcoin/.github/workflows/ci.yml +++ b/libbitcoinkernel-sys/bitcoin/.github/workflows/ci.yml @@ -468,7 +468,7 @@ jobs: file-env: './ci/test/00_setup_env_arm.sh' provider: 'gha' - - name: 'ASan + LSan + UBSan + integer' + - name: 'ASan + LSan + UBSan + integer, no depends, USDT' cirrus-runner: 'ghcr.io/cirruslabs/ubuntu-runner-amd64:24.04-md' # has to match container in ci/test/00_setup_env_native_asan.sh for tracing tools fallback-runner: 'ubuntu-24.04' timeout-minutes: 120 diff --git a/libbitcoinkernel-sys/bitcoin/ci/test/00_setup_env_native_asan.sh b/libbitcoinkernel-sys/bitcoin/ci/test/00_setup_env_native_asan.sh index 0e732240..229d4fff 100755 --- a/libbitcoinkernel-sys/bitcoin/ci/test/00_setup_env_native_asan.sh +++ b/libbitcoinkernel-sys/bitcoin/ci/test/00_setup_env_native_asan.sh @@ -26,7 +26,7 @@ export NO_DEPENDS=1 export GOAL="install" export CI_LIMIT_STACK_SIZE=1 export BITCOIN_CONFIG="\ - --preset=dev-mode \ + -DWITH_USDT=ON -DWITH_ZMQ=ON -DBUILD_GUI=ON \ -DSANITIZERS=address,float-divide-by-zero,integer,undefined \ -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ diff --git a/libbitcoinkernel-sys/bitcoin/doc/i2p.md b/libbitcoinkernel-sys/bitcoin/doc/i2p.md index 624b651f..b769a74d 100644 --- a/libbitcoinkernel-sys/bitcoin/doc/i2p.md +++ b/libbitcoinkernel-sys/bitcoin/doc/i2p.md @@ -166,13 +166,3 @@ In most cases, the default router settings should work fine. Please see the "General Guidance for Developers" section in https://geti2p.net/en/docs/api/samv3 if you are developing a downstream application that may be bundling I2P with Bitcoin. - -## Privacy recommendations - -- Operating a node that listens on multiple networks (e.g. IPv4 and I2P) can help - strengthen the Bitcoin network, as nodes in this configuration (i.e. bridge nodes) increase - the cost and complexity of launching eclipse and partition attacks. However, under certain - conditions, an adversary that can connect to your node on multiple networks may be - able to correlate those identities by observing shared runtime characteristics. It - is not recommended to expose your node over multiple networks if you require - unlinkability across those identities. diff --git a/libbitcoinkernel-sys/bitcoin/doc/tor.md b/libbitcoinkernel-sys/bitcoin/doc/tor.md index e9db555f..839c02ee 100644 --- a/libbitcoinkernel-sys/bitcoin/doc/tor.md +++ b/libbitcoinkernel-sys/bitcoin/doc/tor.md @@ -238,10 +238,3 @@ for normal IPv4/IPv6 communication, use: Otherwise it is trivial to link them, which may reduce privacy. Onion services created automatically (as in section 2) always have only one port open. -- Operating a node that listens on multiple networks (e.g. IPv4 and Tor) can help - strengthen the Bitcoin network, as nodes in this configuration (i.e. bridge nodes) increase - the cost and complexity of launching eclipse and partition attacks. However, under certain - conditions, an adversary that can connect to your node on multiple networks may be - able to correlate those identities by observing shared runtime characteristics. It - is not recommended to expose your node over multiple networks if you require - unlinkability across those identities. diff --git a/libbitcoinkernel-sys/bitcoin/src/bench/connectblock.cpp b/libbitcoinkernel-sys/bitcoin/src/bench/connectblock.cpp index 3746ea29..9ea50601 100644 --- a/libbitcoinkernel-sys/bitcoin/src/bench/connectblock.cpp +++ b/libbitcoinkernel-sys/bitcoin/src/bench/connectblock.cpp @@ -9,6 +9,7 @@ #include