💬 theuni commented on pull request "build: LLD based macOS toolchain":
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1885470222)
> > Would still like to see them PR'd separately, but I cherry-picked the two relevant commits, dropped `native_cmake`, and have dropped anything libtool related here.
>
> It's been quite a while since I worked on those, I don't remember if they were completely merge-ready (I suspect windows cross might be broken for ex.). Playing with them locally now.

Here's a cleaned up version: https://github.com/theuni/bitcoin/commits/depends-no-libtool/
They needed an update after 63c0c4ff10b2f6ed85
...

🚀 achow101 merged a pull request: "logging: Simplify API for level based logging"
(https://github.com/bitcoin/bitcoin/pull/28318)

💬 achow101 commented on pull request "fuzz: fix `connman` initialization":
(https://github.com/bitcoin/bitcoin/pull/29211#issuecomment-1885493837)
ACK e84dc36733687fffe08ae4621b571cc66afc047d

🚀 achow101 merged a pull request: "fuzz: fix `connman` initialization"
(https://github.com/bitcoin/bitcoin/pull/29211)

💬 theuni commented on pull request "build: LLD based macOS toolchain":
(https://github.com/bitcoin/bitcoin/pull/21778#issuecomment-1885576324)
Blah, it looks like the win32 filename is borked with cmake: `liblibminiupnpc.a`

Want to punt the libtool removal to a follow-up PR to avoid slowing this one down?

🚀 achow101 merged a pull request: "test: wallet migration, add coverage for tx extra data"
(https://github.com/bitcoin/bitcoin/pull/29204)

✅ achow101 closed a pull request: "Allow configuring target block time for a signet"
(https://github.com/bitcoin/bitcoin/pull/27446)

💬 achow101 commented on pull request "Allow configuring target block time for a signet":
(https://github.com/bitcoin/bitcoin/pull/27446#issuecomment-1885622170)
Closing as there is continued disagreement over the approach and no further changes have been made to this PR. This seems to be at a stalemate and unlikely to go anywhere.

💬 glozow commented on issue "`-maxtxfee` is used as a fee and a feerate":
(https://github.com/bitcoin/bitcoin/issues/29220#issuecomment-1885647767)
This was partially motivated by seeing #29217, as I thought "don't we already have a max feerate?" and realized it was a max absolute fee.

📝 Christewart opened a pull request: "Implement OP_ADD64, OP_SUB64, OP_MUL64, OP_DIV64, OP_LESSTHAN64, OP_L…"
(https://github.com/bitcoin/bitcoin/pull/29221)
This PR adds 64 bit arithmetic op codes to the Script interpreter.


This PR corresponds with this BIP proposal: https://github.com/bitcoin/bips/pull/1538

This work is heavily borrowed from the elements implementation of 64 bit op codes: https://github.com/ElementsProject/elements/pull/1020

💬 mzumsande commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1445399806)
here, and in `peer_accept_connection`: I think the default values aren't necessary and could be dropped. They are not used right now, and it seems better if future callers are forced make a decision on whether to use v2 or not!

💬 mzumsande commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1447657783)
Trying to wrap my head around this:
Let's say we receive the garbage and then receive one or more decoy packages. Then we cut the response here, but if no version package has been received so far, we can still return `0, True` earlier in the while loop and try again later.
But then the next time this function is called, wouldn't authentication fail because we've already removed the garbage terminator from the response?

Not a big deal though - because bitcoind doesn't send any decoy message
...

💬 mzumsande commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1447962448)
I think that this should be moved outside of the `if connection_type == "feeler":` clause and be done before:
After all the v2 reconnection logically stuff comes first, and then all the existing v1 logic still applies to the downgraded v1 connection - for example, the reconnection logic should also work if `add_outbound_p2p_connection` specified a feeler connection - in which case we currently wouldn't call `wait_for_reconnect`.

💬 mzumsande commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1447884179)
nit: `reject` sounds like we actively do something, `ignore` seems better.

💬 Eunovo commented on pull request "test: wallet rescan with reorged parent + IsFromMe child in mempool":
(https://github.com/bitcoin/bitcoin/pull/29179#issuecomment-1885834450)
Tested ACK [d9df438](https://github.com/bitcoin/bitcoin/pull/29179/commits/d9df438c6e581dae0c818a4c2f5fe95627ae26bc)

Ran the tests locally and got `test_framework.authproxy.JSONRPCException: Invalid or non-wallet transaction id (-5)` for both `wallet_import_rescan` and `wallet_rescan_unconfirmed` when random order is used in `CTxMemPool::entryAll()`.

📝 kevkevinpal opened a pull request: "doc: upgrade Bitcoin Core license to 2024"
(https://github.com/bitcoin/bitcoin/pull/29222)
See https://github.com/bitcoin/bitcoin/pull/26748, [23945](https://github.com/bitcoin/bitcoin/pull/23945), https://github.com/bitcoin/bitcoin/pull/20805, https://github.com/bitcoin/bitcoin/pull/17801, https://github.com/bitcoin/bitcoin/pull/15061

Every year had his upgrade :)

---

cherry-picked these commits from this PR by @22388o and then squashed them to open this PR above is the original desc of the PR
https://github.com/kevkevinpal/bitcoin/pull/new/updateBitcoinLicense2024

85a9
...

💬 mzumsande commented on pull request "Fix -netinfo backward compat with getpeerinfo pre-v26":
(https://github.com/bitcoin/bitcoin/pull/29212#discussion_r1448067295)
ok, if it's on purpose it's fine.

💬 mzumsande commented on pull request "Fix -netinfo backward compat with getpeerinfo pre-v26":
(https://github.com/bitcoin/bitcoin/pull/29212#issuecomment-1885855351)
Code Review ACK 5fa74609b833643334dfb5519f2023119984267b

💬 mzumsande commented on issue "Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)":
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1885891577)
> A softfork making data storage impractical. [...] It would also be a slow process

It's going to be a slow process either way:

Even if Bitcoin Core changed its default policy, the effect on propagation would be negligible for a long time.
The p2p network is densely connected, with reachable nodes having 8 tx-relaying outbound peers and typically many more tx-relaying inbounds. Some network simulations I did in the context of full-RBF a few years ago indicated that already a minority of 1
...

💬 murchandamus commented on pull request "Add Gutter Guard Selector":
(https://github.com/bitcoin/bitcoin/pull/28977#issuecomment-1885907384)
Yeah, oldest first might be better for soaking up tiny UTXOs at low feerates that have been piling up during bouts of high feerates.

@achow101: What do you think about one of the two like the following progression

| | <2s/vB | <3s/vB | <4s/vB | <5s/vB | <6s/vB | <7s/vB | <8s/vB | <9s/vB | <10s/vB | >=10s/vB |
| --- | --- | -- | -- | -- | -- | -- | -- | -- | -- | -- |
| [A:] UTXO Limit | +21^† | +18^† | +15 | +12 | +10 | +8 | +6 | +5 | +4 |+3|
| [B:] UTXO Limit | +4
...