💬 kevkevinpal commented on pull request "mempool: Log added for dumping mempool transactions to disk":
(https://github.com/bitcoin/bitcoin/pull/29402#discussion_r1488897358)
updated in this commit [b9f449b](https://github.com/bitcoin/bitcoin/pull/29402/commits/b9f449b2d0637c09fd8dc3f44078355827af4a92)

💬 kevkevinpal commented on pull request "mempool: Log added for dumping mempool transactions to disk":
(https://github.com/bitcoin/bitcoin/pull/29402#discussion_r1488899166)
I think this is what you are talking about unless I'm getting confused [b9f449b](https://github.com/bitcoin/bitcoin/pull/29402/commits/b9f449b2d0637c09fd8dc3f44078355827af4a92)

the <util/fs.h> includes is already imported but I added `fs::` before `file_size`

💬 DoctorBuzz1 commented on issue "Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee]":
(https://github.com/bitcoin/bitcoin/issues/29423#issuecomment-1943222606)
Rate limit the spam, which is overtaking the monetary use-case of Bitcoin, and the batch Txs like you suggest wouldn't be a real problem. It's only a problem when the spam continues to jack up fees for no legit reason. See here: https://twitter.com/DoctorBuzz1/status/1757659895426330648

Even in the current fee market, I think it would be tough to find a legit batch Tx that would be triggered by this change, considering the savings mentioned in your link. And even if you COULD find an exam
...

💬 jadijadi commented on issue "Weird focus rect displayed on inital sync":
(https://github.com/bitcoin-core/gui/issues/783#issuecomment-1943256980)
Thanks for the explanation. I can reproduce and will work on it today.

💬 maflcko commented on pull request "rpc: Drop migratewallet experimental warning":
(https://github.com/bitcoin/bitcoin/pull/28037#issuecomment-1943262513)
Not sure. I am using the spinning storage only to test `migratewallet`. It finished after 2 hours.

I don't want to block this pull request, but I wanted to share what I am seeing when running the migration on a slow storage. Migration is a one-time cost, so I'll leave it up to others whether to improve it, and by how much. However, if `migratewallet` is expected to take long for other wallets if they reside on slow storage, it may be good to add a note to the RPC? Something like, "Depending o
...

💬 ArmchairCryptologist commented on issue "Move from Static Dust Limit [330 / 546 sats] to Variable Dust Limit [= to TxFee]":
(https://github.com/bitcoin/bitcoin/issues/29423#issuecomment-1943280826)
If we wanted to revamp the dust threshold to, say, increase the cost of ordinals/inscriptions and stop people from junking up the UTXO set without significantly affecting normal usage, a more compatible solution might be to define it as a UTXO that cannot be economically spent at the fee level of the transaction creating it (or a multiplier of said fee), rather than basing it on the total fee of the transaction.

Of course, seeing as we cannot in general know exactly how much data is required
...

💬 maflcko commented on pull request "mempool: Log added for dumping mempool transactions to disk":
(https://github.com/bitcoin/bitcoin/pull/29402#discussion_r1489094999)
No, I don't think this was addressed?

📝 stratospher opened a pull request: "test/BIP324: disconnection scenarios during v2 handshake"
(https://github.com/bitcoin/bitcoin/pull/29431)
Add tests for the following v2 handshake scenarios:
1. Disconnection happens when > `MAX_GARBAGE_LEN` bytes garbage is sent
2. Disconnection happens when incorrect garbage terminator is sent
3. Disconnection happens when garbage bytes are tampered with
4. Disconnection happens when AAD of first encrypted packet after the garbage terminator is not filled
5. bitcoind ignores non-empty version packet and no disconnection happens

All these tests require a modified v2 P2P class (different fro
...

💬 hebasto commented on pull request "Update translation source file for v27.0 string freeze":
(https://github.com/bitcoin-core/gui/pull/793#issuecomment-1943421925)
@hernanmarino

> I'm a little late but, in order to collaborate with this in the future what exactly should I be diffing ? between what branches/ files ? Thanks

Thank you for your interest!

Here are all steps to verify this PR (and similar ones in the future):
```
git fetch origin pull/793/head
git checkout FETCH_HEAD
make -C depends -j $(nproc)
./autogen.sh
./configure CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site # Use the corresponding path if building on macO
...

💬 hebasto commented on pull request "doc: Update translation process guide":
(https://github.com/bitcoin/bitcoin/pull/29414#discussion_r1489222081)
Because it is outdated.

💬 maflcko commented on pull request "wallet: cache IsMine scriptPubKeys to improve performance of descriptor wallets":
(https://github.com/bitcoin/bitcoin/pull/26008#issuecomment-1943469180)
Tested `time loadwallet` with my normal regtest wallet (https://github.com/bitcoin/bitcoin/issues/28510#issuecomment-1727561717), didn't review or check for correctness.

Before:

```
real 0m35.182s
```

After:

```
real 0m3.622s

💬 maflcko commented on pull request "rpc: Drop migratewallet experimental warning":
(https://github.com/bitcoin/bitcoin/pull/28037#issuecomment-1943470403)
I guess `time loadwallet` will be improved by https://github.com/bitcoin/bitcoin/pull/26008#issuecomment-1943469180

💬 maflcko commented on pull request "test: add missing tests for Assumeutxo":
(https://github.com/bitcoin/bitcoin/pull/29428#issuecomment-1943485615)
@aureleoules Looks like https://corecheck.dev/bitcoin/bitcoin/pulls/29428 is dead?

💬 maflcko commented on pull request "mempool: Log added for dumping mempool transactions to disk":
(https://github.com/bitcoin/bitcoin/pull/29402#discussion_r1489258713)
nit: Instead of c-style casts, you can use non-narrowing C++11 casts like `float{thing}`, or `float(thing)`, if narrowing is required.

👍 alfonsoromanz approved a pull request: "wallet: Allow user to navigate options while encrypting at creation"
(https://github.com/bitcoin-core/gui/pull/722#pullrequestreview-1880045594)
Re-Tested ACK


📝 Sjors opened a pull request: "Stratum v2 Template Provider (take 3)"
(https://github.com/bitcoin/bitcoin/pull/29432)
Based on on @Fi3's https://github.com/bitcoin/bitcoin/compare/master...Fi3:bitcoin:PatchTemplates which is based on @ccdle12's #27854. I rebased it and re-wrote the commit history. Compared to #28983 it introduces EllSwift in the handshake and fixes various bugs. I used that opportunity to change the branch name, which makes testing against [SRI](https://github.com/stratum-mining/stratum) slightly easier. There's no conceptual discussion on #28983 so it can be ignored by reviewers.

See [docs/
...

✅ Sjors closed a pull request: "Stratum v2 Template Provider (take 2)"
(https://github.com/bitcoin/bitcoin/pull/28983)

💬 Sjors commented on pull request "Stratum v2 Template Provider (take 2)":
(https://github.com/bitcoin/bitcoin/pull/28983#issuecomment-1943589901)
This PR is superseeded by #29432.

👍 theStack approved a pull request: "test: use v2 everywhere for P2PConnection if --v2transport is enabled"
(https://github.com/bitcoin/bitcoin/pull/29358#pullrequestreview-1880066965)
Tested ACK bf5662c678455fb47c402f8520215726ddfe7a94

💬 theStack commented on pull request "test: use v2 everywhere for P2PConnection if --v2transport is enabled":
(https://github.com/bitcoin/bitcoin/pull/29358#discussion_r1489336354)
in commit 5fc9db504b9ac784019e7e8c215c31abfccb62b6, method `add_outbound_p2p_connection`:
Is this wait needed? IIUC, the wait in the line below should be sufficient, as it can only pass if a v2 handshake has already happened