💬 Riahiamirreza commented on issue "rpc: show P2(W)SH redeemScript in getrawtransaction (and friends)":
(https://github.com/bitcoin/bitcoin/issues/27391#issuecomment-1528866113)
For backward compatibility, Should I add another level of verbosity that includes `redeemScript` in the `scriptSig`?

💬 darosior commented on pull request "Wallet: estimate the size of signed inputs using descriptors":
(https://github.com/bitcoin/bitcoin/pull/26567#issuecomment-1528873153)
Rebased, and added Miniscript support since signing support was merged.

🤔 TheCharlatan requested changes to a pull request: "rpc: Optimize serialization disk space of dumptxoutset"
(https://github.com/bitcoin/bitcoin/pull/26045#pullrequestreview-1403015467)
Thank you for picking this up again.


These are just patches for fixing up my initial code, I also put the entire diff [here](https://github.com/TheCharlatan/bitcoin/commit/a36bde4b5bea3965aefbc208a39525d57ff312fb). The rest looks good to me, I tested `dumptxoutset` extensively on mainnet. The runtime performance of this branch is very similar to the base.

The following can be ignored in the context of this PR, but I still wan to take note:

During review I noticed that the execution t
...

💬 TheCharlatan commented on pull request "rpc: Optimize serialization disk space of dumptxoutset":
(https://github.com/bitcoin/bitcoin/pull/26045#discussion_r1180726604)
Using explicit `make_pair` can be avoided by directly calling `emplace_back` instead (same for further below).

💬 TheCharlatan commented on pull request "rpc: Optimize serialization disk space of dumptxoutset":
(https://github.com/bitcoin/bitcoin/pull/26045#discussion_r1181134612)
The file writing would be more DRY if it were declared as a lambda and then called here and below, e.g. like:
```
auto write_coins_to_file = [&](AutoFile& afile, const uint256& last_hash, const std::vector<std::pair<uint32_t, Coin>>& coins) {
afile << last_hash;
afile << static_cast<uint16_t>(coins.size());
for (auto [vout, coin] : coins) {
afile << vout;
afile << coin;
}
};
```

💬 TheCharlatan commented on pull request "rpc: Optimize serialization disk space of dumptxoutset":
(https://github.com/bitcoin/bitcoin/pull/26045#discussion_r1178515444)
This needs to be dropped.

💬 0xB10C commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#issuecomment-1528893509)
Concept ACK!

⚠️ Princeprince559 opened an issue: "Pur Chain"
(https://github.com/bitcoin/bitcoin/issues/27545)
### Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo

- [X] I still think this issue should be opened here

### Report

Print @gregorycrawford`active`

💬 Princeprince559 commented on issue "Pur Chain":
(https://github.com/bitcoin/bitcoin/issues/27545#issuecomment-1528916271)
Help desk

✅ fanquake closed an issue: "Pur Chain"
(https://github.com/bitcoin/bitcoin/issues/27545)

:lock: fanquake locked an issue: "Pur Chain"
(https://github.com/bitcoin/bitcoin/issues/27545)

📝 cefikhan opened a pull request: "ScriptToUniv can get address of PUBKEY"
(https://github.com/bitcoin/bitcoin/pull/27546)
rpc: ScriptToUniv Can get address of PUBKEY

💬 sipa commented on pull request "ScriptToUniv can get address of PUBKEY":
(https://github.com/bitcoin/bitcoin/pull/27546#issuecomment-1528961205)
Concept NACK

Sorry, no. P2PK outputs do not *have* an address. It's an outdated and confusing practice to refer to them as their corresponding P2PKH address.

💬 MarcoFalke commented on pull request "ScriptToUniv can get address of PUBKEY":
(https://github.com/bitcoin/bitcoin/pull/27546#issuecomment-1528974868)
Closing for now, because this seems to be controversial and all tests fail, so this can't be merged in any case. Let us know if you have any questions, or you can refer to stack exchange:

General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat.

✅ MarcoFalke closed a pull request: "ScriptToUniv can get address of PUBKEY"
(https://github.com/bitcoin/bitcoin/pull/27546)

💬 MarcoFalke commented on pull request "test: add coverage for `-bantime`":
(https://github.com/bitcoin/bitcoin/pull/26604#discussion_r1181194479)
Ah sorry. You are checking the ban_duration, not time_remaining. So this is fine. For reference, the output with the CPU put to sleep for a second looked like:

```json
{
"address": "127.0.0.1/32",
"ban_created": 1682845373,
"banned_until": 1682846607,
"ban_duration": 1234,
"time_remaining": 1233
}

💬 MarcoFalke commented on pull request "test: add coverage for `-bantime`":
(https://github.com/bitcoin/bitcoin/pull/26604#issuecomment-1528976262)
lgtm ACK 9c18992bbaf649f8c5461d5e4dc39eb1a07ffc77

🤔 TheCharlatan reviewed a pull request: "rpc: simplify scan blocks"
(https://github.com/bitcoin/bitcoin/pull/26780#pullrequestreview-1407084457)
Concept ACK

Does this require a release note for the s/filtertype/filter_type/ change?

💬 TheCharlatan commented on pull request "rpc: simplify scan blocks":
(https://github.com/bitcoin/bitcoin/pull/26780#discussion_r1181200641)
Isn't this set already in line 2392?

💬 TheCharlatan commented on pull request "rpc: simplify scan blocks":
(https://github.com/bitcoin/bitcoin/pull/26780#discussion_r1181200751)
To me the semantics of `stop_block` seem very similar. How about checking it as well?

💬 TheCharlatan commented on pull request "rpc: simplify scan blocks":
(https://github.com/bitcoin/bitcoin/pull/26780#discussion_r1181208231)
For reference,`end_range->nHeight` would be a bit easier to read, but is not guaranteed to have a value.