💬 achow101 commented on pull request "Remove `dnsseed.bitcoin.dashjr.org` temporarily":
(https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872136121)
The issue with old nodes was resolved. There is no evidence otherwise that the seeder violates the DNS seed policy.

💬 achow101 commented on pull request "Remove luke from dns seeds":
(https://github.com/bitcoin/bitcoin/pull/29152#issuecomment-1872136680)
Do not open duplicate PRs. If you believe a PR should be reopened, then you can comment and discuss on the closed one.

✅ achow101 closed a pull request: "Remove luke from dns seeds"
(https://github.com/bitcoin/bitcoin/pull/29152)

📝 achow101 locked a pull request: "Remove luke from dns seeds"
(https://github.com/bitcoin/bitcoin/pull/29152)
No reason shared to closed in this PR : https://github.com/bitcoin/bitcoin/pull/28936

💬 etfmoon commented on pull request "Remove `dnsseed.bitcoin.dashjr.org` temporarily":
(https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872161052)
> https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872136121



> A DNS seed operating organization or person is expected to follow good host security practices
> The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operator's understanding and capability.

Evidence: https://pastebin.com/raw/Cwk2a1xr

Maybe read descriptions and https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-polic
...

💬 1440000bytes commented on pull request "Remove `dnsseed.bitcoin.dashjr.org` temporarily":
(https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872169440)
Do not close PRs. If you believe a PR should not need more research, then you can comment.

💬 achow101 commented on pull request "Remove `dnsseed.bitcoin.dashjr.org` temporarily":
(https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872189682)
> > [#29149 (comment)](https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872136121)
>
> > A DNS seed operating organization or person is expected to follow good host security practices
> > The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operator's understanding and capability.
>
> Evidence: https://pastebin.com/raw/Cwk2a1xr
>
> Maybe read descriptions and https://github.com/bitcoin/bitco
...

💬 1440000bytes commented on pull request "Remove `dnsseed.bitcoin.dashjr.org` temporarily":
(https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872200086)



💬 1440000bytes commented on pull request "Remove `dnsseed.bitcoin.dashjr.org` temporarily":
(https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872201337)
Why not remove that policy doc that this point? bunch of hypocrites

💬 pablomartin4btc commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1438330730)
Yeah, I meant to write how to pass the additional flags in the `[permissions@]`'s syntax format (the default behaviour should be without the `out` in it as `noban,in@1.2.3.4`, perhaps that's confusing?). Feel free to ignore if doesn't make sense to you.

💬 mzumsande commented on pull request "p2p: Increase inbound capacity for block-relay only connections":
(https://github.com/bitcoin/bitcoin/pull/28463#issuecomment-1872227505)
After discussing wit @amitiuttarwar I've now lowered the inbound percentage from 60% to 50% (leading to 95 instead of 113 slots for tx-relaying inbounds). This way, we'll be more aligned with the `typical` number of tx-relaying inbounds today, because nodes today usually have a significant number of block-relay-only inbounds as @0xB10C .
The previous number of 113 was aligned with the `maximum` number of tx-relaying inbounds.

💬 luke-jr commented on pull request "Remove `dnsseed.bitcoin.dashjr.org` temporarily":
(https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872231344)
>...the results may be randomized but must not single-out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed.

To be clear, this refers to giving different results to different requesters. It does not forbid selection of which peers to return as results to everyone, which is quite normal for DNS seeds.

💬 etfmoon commented on pull request "Remove `dnsseed.bitcoin.dashjr.org` temporarily":
(https://github.com/bitcoin/bitcoin/pull/29149#issuecomment-1872237278)
> To be clear

This pull request was close without any answers and we know the politics involved in it with reasons.

💬 luke-jr commented on pull request "guix: Use DOS newlines for SHA256SUMS files":
(https://github.com/bitcoin/bitcoin/pull/29147#issuecomment-1872243366)
>It would be good to list at least one benefit, otherwise the benefits of this change are unclear.

Having a single file to download for the signatures is simpler for end users.

👋 mzumsande's pull request is ready for review: "p2p: Increase inbound capacity for block-relay only connections"
(https://github.com/bitcoin/bitcoin/pull/28463)

⚠️ dooglus opened an issue: "new crash in v26.0"
(https://github.com/bitcoin/bitcoin/issues/29153)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

bitcoin-qt crashed while loading wallets at startup.

I used to see occasional crashes on startup a few years ago, but it hasn't been happening at all in the last couple of major releases.

I've been running v26.0 for a week or two and haven't had any problem with it crashing until today.

Here's a backtrace. I run it in gdb habitually because I used to see a lot of crashes and never
...

💬 murchandamus commented on pull request "wallet, rpc: document and update `sendall` behavior around unconfirmed inputs":
(https://github.com/bitcoin/bitcoin/pull/28979#discussion_r1438397150)
The code seems correct to me, but the test seems to have failed on line 408:
https://cirrus-ci.com/task/6362440724643840?logs=ci#L2630

📝 mjdietzx opened a pull request: "tests: improve wallet multisig descriptor test and docs"
(https://github.com/bitcoin/bitcoin/pull/29154)
It is best to store all key origin information
(master key fingerprint and all derivation steps)
in the multisig descriptor. Being explicit with
this information should be beneficial if this approach is used with other wallets/signers (whether hardware or software). There is no harm including all of this with xpubs (if anything it simplifies the test code) and makes this example/docs more complete and safer incase it is referenced by others.

<!--
*** Please remove the following help text
...

💬 furszy commented on pull request "p2p: make block download logic aware of limited peers threshold":
(https://github.com/bitcoin/bitcoin/pull/28120#discussion_r1438410355)
I'm not sure what you are referring to. Could you rephrase it please.
You want to update `pindexLastCommonBlock` to `pindex`?

✅ dimitaracev closed a pull request: "wallet: move lock to the top of ReleaseWallet"
(https://github.com/bitcoin/bitcoin/pull/29143)

📝 dimitaracev opened a pull request: "wallet: move lock at the top of ReleaseWallet"
(https://github.com/bitcoin/bitcoin/pull/29155)
Fixes https://github.com/bitcoin/bitcoin/issues/29073