💬 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.

💬 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.

📝 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.

🤔 0xB10C reviewed a pull request: "ci: drop untrusted bpfcc tool usage"
(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

💬 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

💬 fanquake commented on pull request "ci: drop untrusted bpfcc tool usage":
(https://github.com/bitcoin/bitcoin/pull/27510#discussion_r1173839494)
Thanks, dropped.

💬 hebasto commented on pull request "ci: drop untrusted bpfcc tool usage":
(https://github.com/bitcoin/bitcoin/pull/27510#issuecomment-1517920614)
Concept ACK.

💬 fanquake commented on pull request "lint: stop ignoring LIEF imports":
(https://github.com/bitcoin/bitcoin/pull/27507#issuecomment-1517926243)
Put on top of #27483.

📝 fanquake converted_to_draft a pull request: "lint: stop ignoring LIEF imports"
(https://github.com/bitcoin/bitcoin/pull/27507)
Type stubs are now available as of 0.13.0.
See https://github.com/lief-project/LIEF/issues/650.

💬 batriskaweb3 commented on issue "Compiling a bitcoin core version that accepts transactions over 100vkb":
(https://github.com/bitcoin/bitcoin/issues/27490#issuecomment-1517945110)
this is pretty important for the entire ordinals community as it will allow them to inscribe ordinals bigger than 400kb on the blockchain

🤔 dergoegge reviewed a pull request: "refactor, kernel: Decouple ArgsManager from blockstorage"
(https://github.com/bitcoin/bitcoin/pull/27125#pullrequestreview-1395938681)
lgtm once the last `gArgs` access is removed.

💬 dergoegge commented on pull request "refactor, kernel: Decouple ArgsManager from blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1173878733)
```suggestion
return FlatFileSeq(m_opts.blocks_dir, "blk", m_opts.fast_prune ? 0x4000 /* 16kb */ : BLOCKFILE_CHUNK_SIZE);
```

The "util/system.h" include can almost be removed after this. `ScheduleBatchPriority()` is the only function that is still used.

💬 dergoegge commented on pull request "refactor, kernel: Decouple ArgsManager from blockstorage":
(https://github.com/bitcoin/bitcoin/pull/27125#discussion_r1173885220)
nit: Seems unnecessary to pass the entire `NodeContext` when you only need the blockman.

Feel free to ignore, but would be interested in why you chose to do it this way.

🤔 pablomartin4btc reviewed a pull request: "wallet: finish addressbook encapsulation"
(https://github.com/bitcoin/bitcoin/pull/26836#pullrequestreview-1395963136)
re-ACK 8fa0db1d487d76e3fa5ace0bd4d9a8b6bf8dbde1

💬 pinheadmz commented on pull request "net: use interruptible async getaddrinfo wrapper from libevent for DNS":
(https://github.com/bitcoin/bitcoin/pull/27505#discussion_r1173902633)
Yeah I think thats just to decode numeric addresses like "100.200.30.40" etc. It looked to me like if an actual DNS request is necessary it has its own methods to make reqests directly to the nameservers provided by the platform? When things get "serious":

https://github.com/libevent/libevent/blob/master/evdns.c#L5623