💬 instagibbs commented on pull request "policy: restrict all TRUC (v3) transactions to 10kvB":
(https://github.com/bitcoin/bitcoin/pull/29873#discussion_r1610126595)
wondering if we should have a constant ala `TX_TRUC_VERSION` that is easily greppable? Exceptions being sprinkled across the codebase like this will be harder to track

💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1610209650)
That said, it looks like FreeBSD 12 is pretty much unusable: https://forums.freebsd.org/threads/freebsd-12-2-stable-pkg-update-failed.92034/#post-640223

💬 t-bast commented on pull request "policy: restrict all TRUC (v3) transactions to 10kvB":
(https://github.com/bitcoin/bitcoin/pull/29873#issuecomment-2125127269)
Concept ACK on restricting to 10kvB.

Lightning will need an upgrade path for existing channels to start using TRUC txs, and we're working on several options to upgrade existing channels. We will make sure the upgrade mechanism lowers the maximum number of HTLCs to fit inside the 10kvB limit.

💬 theuni commented on pull request "rpc: avoid copying into UniValue":
(https://github.com/bitcoin/bitcoin/pull/30115#issuecomment-2125128514)
I think it's not really worth worrying about benchmarks here, I think it's pretty clear that moving can only be better.

I'd like to get this in if there are no objections, as there's some more low-hanging fruit wrt UniValue moves.

💬 jadijadi commented on pull request "Showing Local Addresses in Node Window":
(https://github.com/bitcoin-core/gui/pull/626#discussion_r1610270917)
Thanks for all the support and patient. Applying them. The `{}` was also my first try but I got:
`error: initializer list cannot be used on the right hand side of operator ':'`
Now I changed it to
```
if (m_context->connman)
return m_context->connman->getLocalAddresses();
else
return {};
```
to prevent that ugly `empty` variable of mine.

💬 fanquake commented on pull request "build: LLD based macOS toolchain":
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-2125173212)
> Another mismatch, this time on riscv64 -_-

I've just rebuilt on 2 different machines (one aarch64 one x86_64), and they match your output here (removing my comment above):
```bash
00becde2dd12878e3b9f50f27899a6a8b752343dade7c71781632715c3001473 guix-build-e8c25e8a35e3/output/aarch64-linux-gnu/SHA256SUMS.part
a685b9cee54014e74639be1e8db2d55b7c008fdb3b31c1c708c364a49b56759a guix-build-e8c25e8a35e3/output/aarch64-linux-gnu/bitcoin-e8c25e8a35e3-aarch64-linux-gnu-debug.tar.gz
d612281584098
...

💬 achow101 commented on pull request "depends: Fetch miniupnpc sources from an alternative website":
(https://github.com/bitcoin/bitcoin/pull/30151#issuecomment-2125175024)
ACK 21b8a14d37c19ce292d5529597e0d52338db48a9

The main page of tuxfamily.org has 2 posts stating that they've had weeks of downtime in the past 6 months, so I think it makes sense to switch to a different mirror as they seem to be having issues. It's unfortunate that miniupnp.free.fr is http only, but we check the hash so I think it's fine.

💬 jadijadi commented on pull request "Showing Local Addresses in Node Window":
(https://github.com/bitcoin-core/gui/pull/626#discussion_r1610274712)
This is more beautiful and understandable. Replaced the `it->first` & `it->second` with `addr` & `info`:

```
for (const auto& [addr, info] : hosts) {
local_addresses += QString::fromStdString(addr.ToStringAddr());
if (!addr.IsPrivacyNet()) local_addresses += ":" + QString::number(info.nPort);
local_addresses += ", ";
}
local_addresses.chop(2); // remove last ", "
```

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1610286827)
If so i would prefer not supporting it at all for older FreeBSD. It's so rare compared to the other operating systems already, and most of the userbase will be setting their own firewall. But we indeed need to check that it doesn't cause a compilation error.

👍 0xB10C approved a pull request: "net: add ASMap info in `getrawaddrman` RPC"
(https://github.com/bitcoin/bitcoin/pull/30062#pullrequestreview-2071759324)
ACK 1e54d61c4698debf3329d1960e06078ccbf8063c

I've played around with the `getrawaddrman` RPC with and without an asmap file loaded. Also loaded a json dump into addrman-observer. Works as expected.

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#issuecomment-2125210478)
Okay - added a NAT-PMP fallback and removed all user visible option changes, except for documentation.

💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-2125213533)
`e85cc59bad...057c79365c`: in order to decide whether to private broadcast to IPv4/IPv6 peers, instead of (before this force push) requiring that `-onion=` is explicitly set, do this (after this force push): keep track if we ever managed to connect to an `.onion` address via the `NET_ONION` proxy, if yes assume that this proxy is a Tor proxy and connecting to IPv4/IPv6 addresses through it will be done via the Tor network and via a Tor exit node.

This is better because it is stronger guarante
...

💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r1610296362)
> > Is there no better way of checking whether `-proxy` is an actual Tor proxy or just a regular SOCKS5 proxy?

> maybe we can keep track of whether we have have successfully managed to connect to at least one .onion address

Done in `e85cc59bad...057c79365c`, see https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-2125213533, also dropped the change in `tor.md` because that is not needed anymore.

Looks better now, thank you!

💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1610299087)
> If so i would prefer not supporting it at all for older FreeBSD.

Seems fine to me.

💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1610302369)
Concept ACK on keep just using `-natpmp` for both PCP and NATPMP.

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1610306635)
Whoops, fixed

💬 glozow commented on pull request "policy: restrict all TRUC (v3) transactions to 10kvB":
(https://github.com/bitcoin/bitcoin/pull/29873#discussion_r1610308435)
Ah that's a good idea. I can add it to #29496?

💬 instagibbs commented on pull request "policy: restrict all TRUC (v3) transactions to 10kvB":
(https://github.com/bitcoin/bitcoin/pull/29873#discussion_r1610309923)
sgtm

💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1610320133)
Added a version check for at least 13.2.

🤔 theStack reviewed a pull request: "rpc: introduce getversion RPC"
(https://github.com/bitcoin/bitcoin/pull/30112#pullrequestreview-2071898266)
Concept ACK