💬 jonatack commented on pull request "docs: add ramdisk guide for running tests on OSX":
(https://github.com/bitcoin/bitcoin/pull/27124#issuecomment-1440636295)
ACK 2f84ad7b9e62dd710940c2f265b65973b94864d7

M1 Max, macOS 13.2

```bash
$ diskutil erasevolume HFS+ ramdisk $(hdiutil attach -nomount ram://8388608)
Started erase on disk6
Unmounting disk
Erasing
Initialized /dev/rdisk6 as a 4 GB case-insensitive HFS Plus volume
Mounting disk
Finished erase on disk6 (ramdisk)

$ diskutil info disk6 | grep -e Size
Disk Size: 4.3 GB (4294967296 Bytes) (exactly 8388608 512-Byte-Units)
Device Block Size: 512 Bytes
A
...

📝 ishaanam opened a pull request: "wallet: when a block is disconnected, update transactions that are no longer conflicted"
(https://github.com/bitcoin/bitcoin/pull/27145)
This implements a fix for #7315. Previously when a block was disconnected any transactions that were conflicting with transactions mined in that block were not updated to be marked as inactive. The fix implemented here is described on the [Bitcoin DevWiki](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Wallet-Transaction-Conflict-Tracking#idea-refresh-conflicted). A test which tested the previous behavior has also been updated.

💬 achow101 commented on pull request "validation: Improve error handling when VerifyDB dosn't finish successfully":
(https://github.com/bitcoin/bitcoin/pull/25574#issuecomment-1440651446)
ACK 0af16e7134459e0820ab95d751093876c1ec4c6d

💬 jonatack commented on pull request "assumeutxo: background validation completion":
(https://github.com/bitcoin/bitcoin/pull/25740#issuecomment-1440655812)
In the pull description, could drop or update "Since it's dependent on the commits in https://github.com/bitcoin/bitcoin/pull/25667, I'm opening this as a draft."

🚀 achow101 merged a pull request: "validation: Improve error handling when VerifyDB dosn't finish successfully"
(https://github.com/bitcoin/bitcoin/pull/25574)

💬 ariard commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1114818128)
Don't know if transaction received through BIP152's `BLOCKTXN` should be `TryRemovingFromSet()`.

💬 ariard commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1114821225)
If the "fast" (i.e 2s) has been reasoned out in the bip or the paper, the section can be referenced too, I think.

💬 ariard commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1114835166)
Can add a comment about what `TxReconciliationTracker::IsPeerNextToReconcileWith()` does, like assumptions on peers queue and phase we're in.

💬 ariard commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1114866248)
Not sure this new comment still holds with the introduction of `MAX_SET_SIZE=3000`.

💬 ariard commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1114877866)
Correct the max set size (`MAX_SET_SIZE`) is enforced by `ShouldFanoutTo()` which happens before the call to `AddToSet()`, don't know if it could be more conservative with another check here.

💬 ariard commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1114886751)
Well we might have some small discrepancy in old code, doesn't seem to matter here.

💬 ariard commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1114888417)
I think it's accurate with the current comment of warning about less frequent reconciliations introducing high transaction relay latency. Like some trade-off between bandwidth and 0confs UX to be aware, I would say.

💬 ariard commented on pull request "p2p: Fill reconciliation sets and request reconciliation (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/26283#discussion_r1114890070)
Gotcha, just means the malicious outbound peer will never move forward its own reconciliation.

💬 Ayush170-Future commented on issue "listtransactions results order unkown":
(https://github.com/bitcoin/bitcoin/issues/17739#issuecomment-1440726908)
Hello!
Is this issue up for grab? 
Also, if it is, could someone help specify what kind of documentation has to be updated?

I'd love to get started on this.

💬 officialfrancismendoza commented on issue "rpc: prevent non-zero value OP_RETURN outputs in sendrawtransaction":
(https://github.com/bitcoin/bitcoin/issues/25899#issuecomment-1440763838)
I'd like to work on this. Please assign

💬 furszy commented on pull request "wallet: group outputs only once, decouple it from Coin Selection":
(https://github.com/bitcoin/bitcoin/pull/25806#discussion_r1114930512)
hmm, that would make the avoid partial spends flow even uglier, plus I don't think that that will be negligible for big wallets (+50k UTXOs wallets).

The later removal of negative UTXOs will leave APS full groups with less than 100 entries, which will force us to re-order groups so they are full again (moving UTXOs from one group to another), then if the wallet does not include partial groups, will need to discard those groups too.
So making this changes would actually introduce more code th
...

💬 Xekyo commented on pull request "wallet: group outputs only once, decouple it from Coin Selection":
(https://github.com/bitcoin/bitcoin/pull/25806#discussion_r1110370140)
Here and everywhere in this commit, the `positive_only` check is redundant because `¬A ∨ A ∧ B = ¬A ∨ B`

```suggestion
if (output.GetEffectiveValue() > 0 || !positive_only ) {
```

💬 furszy commented on pull request "wallet: group outputs only once, decouple it from Coin Selection":
(https://github.com/bitcoin/bitcoin/pull/25806#discussion_r1114969240)
yeah k 👌🏼, will do the change if need to re-touch to not invalidate the other reviews only for this small redundancy.

📝 theuni opened a pull request: "Fix various libbitcoinkernel DLL build problems"
(https://github.com/bitcoin/bitcoin/pull/27146)
Fixes #25008. Ping @TheCharlatan

1. Fixup the build defines so that exports are clean.
2. Work around a libtool issue wrt dependency calculation
3. Simplify everything by only ever building in-tree bitcoin-chainstate against a static libbitcoinkernel
4. Remove Windows-only hack that disabled dll creation

👍 ariard approved a pull request: "assumeutxo: background validation completion"
(https://github.com/bitcoin/bitcoin/pull/25740)
ACK a00d0e78.

Since last ACK ab41e8b4:
- move `nPruneTarget` usage to `BlockManager::GetPruneTarget()` in `LoadChainstate()`
- bug report call message (i.e `PACKAGE_BUGREPORT`) in `LogPrintf` in `ActivateBestChain()`
- move `GetUTXOStats` mention to `ComputeUTXOStats` in `MaybeCompleteSnapshotValidation` comment
- new `BOOST_CHECK`s in `chainstatemanager_snapshot_completion` about cache size bytes