💬 andrewtoth commented on pull request "rpc,rest,zmq: faster getblock, NotifyBlock and rest_block by reading raw block":
(https://github.com/bitcoin/bitcoin/pull/26415#discussion_r1448161451)
Fixed. Apparently `IsBlockPruned` is not sufficient to know whether we can read the block or not. Getting the file position of a block that we don't have returns us a null `FlatFilePos`, and `ReadBlockFromDisk` fails on opening a file at null position. `ReadRawBlockFromDisk` instead first tries to decrement `nPos` by 8 before trying to open the file, which results in UB due to `nPos` being unsigned and 0 for a null position.

💬 ariard commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1886085872)
I think this is correct to say that nversion=3 is a weak pinning mitigation.
One can always use a revoked state with max outgoing HTLC outputs=483 to pin.
So 483 * 33 + 1000, you have ~18k vbytes state, mempool backlog at 20 sat/vb, you can steal ~100 USD payments.
Yes `max_offered_htlc` chan policy param can be introduced at the LN-level to bound more commitment size.
However mempool backlog will always make the level of pin exposure dynamic, a bad thing.
(Let's be nice and not introduce c
...

💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1448210370)
```suggestion
* reach the target. We continue with the direct successor of our `next_utxo` for the
```

💬 murchandamus commented on pull request "wallet: Add CoinGrinder coin selection algorithm":
(https://github.com/bitcoin/bitcoin/pull/27877#discussion_r1448211928)
```suggestion
// Success, adding more weight cannot be better: SHIFT
```

💬 saltduck commented on issue "Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)":
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-1886210780)
Can we just remove the discount of the segwit data? It is fair for both generic users and the attackers.在 2024年1月11日，07:11，Martin Zumsande ***@***.***> 写道：

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

💬 maflcko commented on pull request "doc: upgrade Bitcoin Core license to 2024":
(https://github.com/bitcoin/bitcoin/pull/29222#issuecomment-1886617839)
In the OP: Just linking to the previous year's pull should be enough. Also, the link to open a pull request doesn't make sense. Also, the @-mention should be removed from the pull description, as described in the docs.

🤔 glozow reviewed a pull request: "mempool / rpc: followup to getprioritisedtransactions and delete a mapDeltas entry when delta==0"
(https://github.com/bitcoin/bitcoin/pull/28885#pullrequestreview-1815052118)
ACK 5353af1c8a2dd402a303a786d8aae5edbfc1ff3a

💬 glozow commented on pull request "mempool / rpc: followup to getprioritisedtransactions and delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/28885#discussion_r1448536720)
dc189d3ec5c4af9bca02928dfeb4770570060982: I'm not sure that "new fee" would be understood by people. It would also be helpful to add the units here, i.e.
```suggestion
{RPCResult::Type::NUM, "modified_fee", /*optional=*/true, "modified fee in satoshis. Only returned if in_mempool=true"},
```

📝 BrandonOdiwuor opened a pull request: "wallet: Refactor DumpWallet function to accept -dumpfile path argument"
(https://github.com/bitcoin/bitcoin/pull/29223)
Quick follow-up to https://github.com/bitcoin/bitcoin/pull/29117, coming from _https://github.com/bitcoin/bitcoin/pull/29117#discussion_r1431999422_.

Refactor `DumpWallet(...)` to accept the `-dumpfile` path arg instead of the entire `ArgsManager`

💬 maflcko commented on pull request "wallet: Refactor DumpWallet function to accept -dumpfile path argument":
(https://github.com/bitcoin/bitcoin/pull/29223#issuecomment-1886719702)
Not sure. The current version seems just fine

👍 fanquake approved a pull request: "Use hardened runtime on macOS release builds."
(https://github.com/bitcoin/bitcoin/pull/29127#pullrequestreview-1815147663)
ACK 4fdd836db92e789c98b9e68398ca931a968cc9c3 - we can move ahead with this, and figure out notarisation / stapling as a followup.

✅ fanquake closed an issue: "macOS App Notarization"
(https://github.com/bitcoin/bitcoin/issues/15774)

🚀 fanquake merged a pull request: "Use hardened runtime on macOS release builds."
(https://github.com/bitcoin/bitcoin/pull/29127)

⚠️ fanquake reopened an issue: "macOS App Notarization"
(https://github.com/bitcoin/bitcoin/issues/15774)
> The Apple notary service is an automated system that scans your software for malicious content, checks for code-signing issues, and returns the results to you quickly. If there are no issues, the notary service generates a ticket for you to staple to your software; the notary service also publishes that ticket online where Gatekeeper can find it.

> Beginning in **macOS 10.14.5**, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must
...

🤔 glozow reviewed a pull request: "RPC: add new `listmempooltransactions`"
(https://github.com/bitcoin/bitcoin/pull/29016#pullrequestreview-1815145958)
> > Assuming you mean the sequence emitted from Transaction{AddedTo,RemovedFrom}Mempool, note that this is not actually the case (they're usually off by 1 or more due to when the sequence increments happen).
>
> Can you say more about this divergence or point me to a doc that contains more info?

It's more that they just happen to use the same counter, but that doesn't mean they match.
The mempool entry's sequence number is assigned here;
https://github.com/bitcoin/bitcoin/blob/fcacbab487
...

💬 glozow commented on pull request "RPC: add new `listmempooltransactions`":
(https://github.com/bitcoin/bitcoin/pull/29016#discussion_r1448596725)
Do note that a mempool tx from a recently disconnected block would be skipped here

💬 deyw-bit commented on issue "Failed loading mempool when restarting bitcoind":
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886783736)
I can confirm a similar issue in a node running Bitcoin Core 25.1, as detailed below:

Config options:
- maxmempool=2000
- mempoolexpiry=720
- mempoolfullrbf=1

Prior to the node's restart, the mempool size was approximately 1.14 GB, which filled up over roughly 26 hours of uptime since the last node restart.

After initiating the shutdown, the node restarted immediately. According to the logs, the mempool was dumped ("Dumped mempool: 1.0479s to copy, 10.5051s to dump"). However, there
...

💬 maflcko commented on pull request "test: add assumeutxo wallet test":
(https://github.com/bitcoin/bitcoin/pull/28838#issuecomment-1886787577)
lgtm ACK 997b9a73e5166b4244f7c5b4fe144d524f3005f4

💬 maflcko commented on issue "Failed loading mempool when restarting bitcoind":
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886796183)
> Ten minutes later, it increased to 18MB and continued to grow gradually

Loading the mempool takes time after a startup. You can monitor whether it is complete over the getmempoolinfo RPC (`loaded` field). Once it is loaded, the loading result will be printed to the debug log.

💬 deyw-bit commented on issue "Failed loading mempool when restarting bitcoind":
(https://github.com/bitcoin/bitcoin/issues/29193#issuecomment-1886805643)
Okay, will keep monitoring it, right now (90 minutes after restart), bitcoin-cli getmempoolinfo returns "loaded": false