💬 hebasto commented on pull request "depends: Do not consider `CC` environment variable for detecting system":
(https://github.com/bitcoin/bitcoin/pull/29963#issuecomment-2079059322)
> A better diff might be something like:
> ...
> which would at least be using the option that is meant to be used for this.

I agree. Implemented.

Thanks!

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580742501)
Thanks, I've moved it to the outer loop.
Kept bool, seems harmless and I imagine we can find some more interesting code paths by sometimes not setting it immediately.

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580739332)
As discussed offline, I agree the fuzz test has a few quirks that could be fixed up, but I think they are out of scope for this PR so I'm going to mark this resolved.

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580743469)
added

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580756146)
haha oops, deleted

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580755767)
Ok I've done a bit of refactoring to split this into 2 functions for finding the package and validating/processing the package, and made a `PackageToValidate` struct that's difficult to misuse. Got rid of these "set me if you find something" variables.

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580737130)
fixed

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580750294)
Packages aren't ever reconsiderable since we never submit anything beyond 1p1c. I've clarified this in the docs now. I definitely think we should cache a rejection when the error is `PCKG_POLICY` or `PCKG_MEMPOOL_ERROR`.

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580736833)
added

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580698811)
done

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1580693314)
removed

💬 josibake commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2079095313)
@Sjors I've updated #28122 to sort outpoints lexicographically and added @setavenger 's test case. This should fix the discrepancy between your two indexes. Thanks again for testing this! Really glad we caught this one.

💬 Sjors commented on pull request "Silent Payments: Implement BIP352":
(https://github.com/bitcoin/bitcoin/pull/28122#discussion_r1580842378)
7a27533332d14cf98f7e165f464142132e9f9d85: if you're going to change this here instead of adding a custom sort for BIP352, then you should add a note that it's critical for BIP352.

However I'm not sure if we should sort this way by default. If I wanted to list transaction outputs, I'd want to sorted by their integer version.

That said, I don't know if we currently expose any RPC where this sort order is exposed.

💬 josibake commented on pull request "Silent Payments: Implement BIP352":
(https://github.com/bitcoin/bitcoin/pull/28122#discussion_r1580846838)
From what I could tell, we don’t expose this anywhere. I’m in favor of making this the default since we only ever really talking about outpoints in terms of their serialised encoding. Gonna give it some more thought, but I’m considering opening this commit as its own PR. It seems preferable to me to have one way of sorting outpoints vs creating a special case for silent payments, especially when there doesn’t seem to be any other “sort outpoints” use case (e.g. none of the tests failed when I ma
...

💬 josibake commented on pull request "Silent Payments: Implement BIP352":
(https://github.com/bitcoin/bitcoin/pull/28122#discussion_r1580850619)
But still need to verify re: displayed in RPCs. At that point tho, we could just sort by `vout` and ignore the txid in the sort

💬 naiyoma commented on pull request "net: update comment for service bit support info for seed.bitcoin.sipa.be":
(https://github.com/bitcoin/bitcoin/pull/29809#issuecomment-2079140202)
> I also think it would be good to get this out of chainparams, bitcoind only ever uses "x9" anyway as far as I can see, so I'm not sure why the status of other combinations needs to be tracked here. Maybe adding the info in the first place was meant as a service to other software that would actually use those other combinations?

I'm working on this [script](https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/162) to filter seeds, I think it's okay to delete all the combinations co
...

👍 laanwj approved a pull request: "guix: remove bzip2 from deps"
(https://github.com/bitcoin/bitcoin/pull/29895#pullrequestreview-2024816991)
Compared the binaries. `bitcoin-qt` has three differences:
- `_Z17FormatFullVersionB5cxx11v`
- version string in `.rodata` section
- checksum in `.debug_info` section

This is fully expected. ACK b8e084b9781eaa4d624a3c1d58b39c07005a0e13

💬 Sjors commented on pull request "Silent Payments: Implement BIP352":
(https://github.com/bitcoin/bitcoin/pull/28122#discussion_r1580901500)
Separate PR sounds good to get more eyes on it. Meanwhile this is fine a temporary fix for this PR.

💬 nanlour commented on pull request "ThreadSanitizer: Fix #29767":
(https://github.com/bitcoin/bitcoin/pull/29776#issuecomment-2079233223)
> Not going to look at it right now, but I suspect this fix just creates a different race instead.
> Looks like furszy already got this in https://github.com/bitcoin/bitcoin/pull/29867
I think the race condition fixed in #29867 was not introduced by my change; it was created by #28955, although my change makes the race condition window bigger.

💬 laanwj commented on pull request "refactor: Avoid unused-variable warning in init.cpp":
(https://github.com/bitcoin/bitcoin/pull/29968#discussion_r1580927959)
ACK on improving the syntax, but it seems a matter of time before the compiler again becomes smart enough to see this variable is unused?
Mayb eadd
```
(void)unix;
```
to the `!HAVE_SOCKADDR_UN` path just in case?