💬 andrewtoth commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-2956083575)
> my understanding is that any Tor- or I2P-enabled node will be able to receive these txs and then broadcast them out to all their peers.

@kdmukai it's even better than that, any node listening on clearnet can also receive these txs through Tor exit nodes and appear to be the broadcast origin.

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2956095394)
> Does increasing the file sizes in indexes/txindex require a -reindex?

@hMsats -reindex is overkill for recreating the txindex. Shut down the node, delete `.bitcoin/indexes` and start up, and only the txindex will be recreated.

💬 glozow commented on pull request "[28.x] 28.2rc2":
(https://github.com/bitcoin/bitcoin/pull/32684#issuecomment-2956100913)
ACK fb6239327700acc8b038d7d241c33439e3f6916e

💬 fanquake commented on pull request "rpc: Note in fundrawtransaction doc, fee rate is for package":
(https://github.com/bitcoin/bitcoin/pull/32607#issuecomment-2956101728)
Backported to `29.x` in #32589.

🚀 glozow merged a pull request: "[28.x] 28.2rc2"
(https://github.com/bitcoin/bitcoin/pull/32684)

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2956151056)
@andrewtoth oh, that sounds scary to me but I have a fresh backup so I'll try that. Thanks!

💬 theStack commented on pull request "test: refactor: overhaul (w)txid determination for `CTransaction` objects":
(https://github.com/bitcoin/bitcoin/pull/32421#issuecomment-2956178171)
Rebased on master.

💬 sipa commented on pull request "Embed default ASMap as binary dump header file":
(https://github.com/bitcoin/bitcoin/pull/28792#issuecomment-2956185880)
To convince myself that with all the bit/byte order changes, no semantics of the actual interpretation are affected, I wrote some known-correct unit tests for the asmap interpreter, added before the changes in this PR, and maintained throughout: https://github.com/sipa/bitcoin/commits/pr28792. Feel free to grab any part of it.

💬 Zeegaths commented on pull request "docs: adds correct updated documentation links":
(https://github.com/bitcoin/bitcoin/pull/32699#issuecomment-2956256591)
> This makes it necessary to manually update the links with every release, or at least with every new version that contains changes to those documentation files.

it does, still trying to get a workaround that automatically updates it

👍 theStack approved a pull request: "rpc, doc: update `listdescriptors` RCP help"
(https://github.com/bitcoin/bitcoin/pull/32708#pullrequestreview-2910597716)
ACK b44514b876333a94ae242da8b1e4cee439c2d37e

💬 Crypt-iQ commented on pull request "p2p: Add witness mutation check inside FillBlock":
(https://github.com/bitcoin/bitcoin/pull/32646#discussion_r2136018337)
If `fail_block_mutated` is true, does that mean the txid merkle commitment won't be found valid? I might be misreading the comment.

💬 Crypt-iQ commented on pull request "p2p: Add witness mutation check inside FillBlock":
(https://github.com/bitcoin/bitcoin/pull/32646#discussion_r2136058304)
> Both merkle checks can fail due to collisions

Interesting, I did not know this. Since the header merkle check is first... if the witness merkle check fails due to collision, does that mean that the transaction that collided had the same txid but a different wtxid? Or is there another way for short ID collisions to affect the witness merkle check?

💬 polespinasa commented on pull request "rpc: generateblock to allow multiple outputs":
(https://github.com/bitcoin/bitcoin/pull/32468#issuecomment-2956338245)
> However, if the overload accepts a string and a non-string, it is unclear how to proceed. Maybe similar to `hash_or_height`?

I was trying to make the cli accept `bitcoin-cli generateblock address` but seems that the only way to do it is by requesting a json type object from the user `bitcoin-cli generateblock `'"address"'` like `hash_or_height`

🤔 polespinasa reviewed a pull request: "rpc: generateblock to allow multiple outputs"
(https://github.com/bitcoin/bitcoin/pull/32468#pullrequestreview-2910675272)
00a5104ea984d75ae769a4af49d480272e8562f6
added `outputs` param to the RPCConvertParams lists to make `rpc_help.py` test pass

💬 polespinasa commented on pull request "rpc: generateblock to allow multiple outputs":
(https://github.com/bitcoin/bitcoin/pull/32468#discussion_r2136087582)
This test fails for some unexpected reason.
It is unable to parse the address although is the same as the other tests, so format should be correct.
`TestFramework (ERROR): Called Process failed with 'error: Error parsing JSON: bcrt1p9yfmy5h72durp7zrhlw9lf7jpwjgvwdg0jr0lqmmjtgg83266lqsekaqka`

Maybe some of the functions used for parsing needs a lock to work correctly with concurrency?

friendly ping @maflcko for help here :)

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2956491227)
@andrewtoth I just realized I shouldn't remove `indexes` because a user that switches from a lower version to 29.0 wouldn't do that and I want to see what happens in the most common use case.

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2956494635)
Ok, just wanted to point out you don't need a -reindex just for recreating the txindex. -reindex will wipe all your block index and chainstate as well.

💬 l0rinc commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2956497312)
Thanks for testing it, please keep us in the loop.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2956500358)
@andrewtoth Yes, thanks I also realized what the difference is.

💬 nothingmuch commented on pull request "[Draft/POC] Add secp256k1-based HPKE (Hybrid Public Key Encryption) For Payjoin v2":
(https://github.com/bitcoin/bitcoin/pull/32617#issuecomment-2956505713)
> Good catch. I still need to verify whether `PSK` is used by OHTTP in the Payjoin v2 protocol,

I can confirm that neither BIP 77 nor the rust-payjoin implementations depend on the PSK functionality. There are ideas for future extensions that might make use of that, but they are only ideas at this point and would not be a part of BIP 77 itself.