✅ fanquake closed an issue: "`test/streams_tests.cpp` fails to compile on SunOS / illumos"
(https://github.com/bitcoin/bitcoin/issues/29884)
(https://github.com/bitcoin/bitcoin/issues/29884)
🚀 fanquake merged a pull request: "test: Fix `test/streams_tests.cpp` compilation on SunOS / illumos"
(https://github.com/bitcoin/bitcoin/pull/29907)
(https://github.com/bitcoin/bitcoin/pull/29907)
🚀 fanquake merged a pull request: "miniscript: make operator""_mst consteval"
(https://github.com/bitcoin/bitcoin/pull/28657)
(https://github.com/bitcoin/bitcoin/pull/28657)
💬 fanquake commented on pull request "msvc: Compile `test\fuzz\miniscript.cpp`":
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2093940009)
> Based on https://github.com/bitcoin/bitcoin/pull/28657.
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2093940009)
> Based on https://github.com/bitcoin/bitcoin/pull/28657.
💬 fjahr commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093953949)
> We made `acceptnonstdtxn=0` the default for testnet3 in #28354. We could flip it back on. Or we could make it easier to preferentially peer with no-standardness nodes (and miners) to get those in. I don't think relying on low difficulty blocks is the right solution, at least I don't think it's a good enough reason to keep them around.
Yeah, I tend to agree, I thought about flipping it back on earlier as well: https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2041139129 but we weren
...
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093953949)
> We made `acceptnonstdtxn=0` the default for testnet3 in #28354. We could flip it back on. Or we could make it easier to preferentially peer with no-standardness nodes (and miners) to get those in. I don't think relying on low difficulty blocks is the right solution, at least I don't think it's a good enough reason to keep them around.
Yeah, I tend to agree, I thought about flipping it back on earlier as well: https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2041139129 but we weren
...
💬 fanquake commented on pull request "guix: build with glibc 2.31":
(https://github.com/bitcoin/bitcoin/pull/29987#issuecomment-2093954870)
Rebased and pulled in 1 more commit from the 2.31 branch.
(https://github.com/bitcoin/bitcoin/pull/29987#issuecomment-2093954870)
Rebased and pulled in 1 more commit from the 2.31 branch.
💬 ajtowns commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2094003382)
> and `acceptnonstdtxn=1` as default is still a good solution
We've had a case where having this setting as default rendered [$76M of bitcoin inaccessible for months](https://github.com/bitcoin/bitcoin/pull/26348), so that doesn't seem like a good solution to me. If you're testing something that will require miners with meaningful hashpower running non-default things on mainnet, finding a miner who'll do the same thing on testnet first doesn't seem that unreasonable to me. You can always test
...
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2094003382)
> and `acceptnonstdtxn=1` as default is still a good solution
We've had a case where having this setting as default rendered [$76M of bitcoin inaccessible for months](https://github.com/bitcoin/bitcoin/pull/26348), so that doesn't seem like a good solution to me. If you're testing something that will require miners with meaningful hashpower running non-default things on mainnet, finding a miner who'll do the same thing on testnet first doesn't seem that unreasonable to me. You can always test
...
👋 hebasto's pull request is ready for review: "msvc: Compile `test\fuzz\miniscript.cpp`"
(https://github.com/bitcoin/bitcoin/pull/30031)
(https://github.com/bitcoin/bitcoin/pull/30031)
💬 hebasto commented on pull request "msvc: Compile `test\fuzz\miniscript.cpp`":
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094071793)
> > Based on #28657.
>
> Can be rebased now.
Rebased and undrafted.
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094071793)
> > Based on #28657.
>
> Can be rebased now.
Rebased and undrafted.
💬 Michealflair commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2094073473)
bc1quc0kme44uzqsqtpwfm93lfe8zgh5xrgv7zjtzy
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2094073473)
bc1quc0kme44uzqsqtpwfm93lfe8zgh5xrgv7zjtzy
💬 Emzy commented on issue "DNS seed "seed.bitcoinstats.com" doesn't support filtering while the comments says it does":
(https://github.com/bitcoin/bitcoin/issues/29911#issuecomment-2094078985)
> I have stopped using these DNS seeds. I found only 2 useful when I last tested:
>
> seed.bitcoin.sipa.be seed.bitcoin.wiz.biz
These have a very low TTL set, which is fine.
The DNS seeds using the DNSSEC setup https://github.com/sipa/bitcoin-seeder/pull/85 will renew the DNS zone every hour and have a TTL of 1h set.
The DNS seeder https://github.com/sipa/bitcoin-seeder is only providing long running Bitcoin nodes. So caching for one hour is not an issue.
(https://github.com/bitcoin/bitcoin/issues/29911#issuecomment-2094078985)
> I have stopped using these DNS seeds. I found only 2 useful when I last tested:
>
> seed.bitcoin.sipa.be seed.bitcoin.wiz.biz
These have a very low TTL set, which is fine.
The DNS seeds using the DNSSEC setup https://github.com/sipa/bitcoin-seeder/pull/85 will renew the DNS zone every hour and have a TTL of 1h set.
The DNS seeder https://github.com/sipa/bitcoin-seeder is only providing long running Bitcoin nodes. So caching for one hour is not an issue.
💬 maflcko commented on pull request "msvc: Compile `test\fuzz\miniscript.cpp`":
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094079027)
ACK 9155b733e153e799f09cc7f7e9199ad776b2cbb1
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094079027)
ACK 9155b733e153e799f09cc7f7e9199ad776b2cbb1
💬 maflcko commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2094081656)
> and `acceptnonstdtxn=1` as default is still a good solution
Not sure. `acceptnonstdtxn` is limited in what it allows. There are many non-standard examples that are not even exposed as a setting.
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2094081656)
> and `acceptnonstdtxn=1` as default is still a good solution
Not sure. `acceptnonstdtxn` is limited in what it allows. There are many non-standard examples that are not even exposed as a setting.
💬 maflcko commented on pull request "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set":
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-2094082588)
> Maybe into the CI or dev docs, given we'll never use -Werror by default for compilation?
Oh I see. `--enable-werror` is only set in the CI in this project. Seems fine to leave as-is.
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-2094082588)
> Maybe into the CI or dev docs, given we'll never use -Werror by default for compilation?
Oh I see. `--enable-werror` is only set in the CI in this project. Seems fine to leave as-is.
💬 0xB10C commented on issue "Manually Banning Peers Results in Crash":
(https://github.com/bitcoin/bitcoin/issues/29916#issuecomment-2094082633)
Could this be a race between "clicking on the peer to ban it in the GUI" and "the peer disconnecting"?
(https://github.com/bitcoin/bitcoin/issues/29916#issuecomment-2094082633)
Could this be a race between "clicking on the peer to ban it in the GUI" and "the peer disconnecting"?
💬 0xB10C commented on issue "Possible to Ban Clients by Name?":
(https://github.com/bitcoin/bitcoin/issues/30036#issuecomment-2094083082)
Looking at a few of my nodes, I haven't seen any `/Satoshi-BTC(Bitcoin Finance):0.15.1/` peers at all (yet?). Normally, user agents show up Additionally, I don't see any unusual amounts of outbound traffic on my nodes.
Do you know what they are sending to you? Can you post some of the IP addresses or the IP subnet they are connecting from? Do you think this could be targeted to your node? Does your node offer any special services e.g. `blockfilterindex=1 peerblockfilters=1 peerbloomfilters=1`
...
(https://github.com/bitcoin/bitcoin/issues/30036#issuecomment-2094083082)
Looking at a few of my nodes, I haven't seen any `/Satoshi-BTC(Bitcoin Finance):0.15.1/` peers at all (yet?). Normally, user agents show up Additionally, I don't see any unusual amounts of outbound traffic on my nodes.
Do you know what they are sending to you? Can you post some of the IP addresses or the IP subnet they are connecting from? Do you think this could be targeted to your node? Does your node offer any special services e.g. `blockfilterindex=1 peerblockfilters=1 peerbloomfilters=1`
...
💬 hebasto commented on issue "Use sigstore software transparency for releases":
(https://github.com/bitcoin/bitcoin/issues/21524#issuecomment-2094083640)
> But I think as soon as it does go into production use, we should try to use it for our releases.
The time has come?
(https://github.com/bitcoin/bitcoin/issues/21524#issuecomment-2094083640)
> But I think as soon as it does go into production use, we should try to use it for our releases.
The time has come?
👍 TheCharlatan approved a pull request: "msvc: Compile `test\fuzz\miniscript.cpp`"
(https://github.com/bitcoin/bitcoin/pull/30031#pullrequestreview-2039302733)
ACK 9155b733e153e799f09cc7f7e9199ad776b2cbb1
(https://github.com/bitcoin/bitcoin/pull/30031#pullrequestreview-2039302733)
ACK 9155b733e153e799f09cc7f7e9199ad776b2cbb1
💬 maflcko commented on issue "Use sigstore software transparency for releases":
(https://github.com/bitcoin/bitcoin/issues/21524#issuecomment-2094089674)
Does it offer any benefit over the existing workflow with guix attestations? See https://github.com/bitcoin-core/guix.sigs/
I presume every key and every attestation would have to be done twice and then uploaded to two different places? Or can sigstore just download and mirror the contents of the https://github.com/bitcoin-core/guix.sigs/ repo on its own?
(https://github.com/bitcoin/bitcoin/issues/21524#issuecomment-2094089674)
Does it offer any benefit over the existing workflow with guix attestations? See https://github.com/bitcoin-core/guix.sigs/
I presume every key and every attestation would have to be done twice and then uploaded to two different places? Or can sigstore just download and mirror the contents of the https://github.com/bitcoin-core/guix.sigs/ repo on its own?
✅ maflcko closed an issue: "Error when launching Bitcoin Core"
(https://github.com/bitcoin/bitcoin/issues/29995)
(https://github.com/bitcoin/bitcoin/issues/29995)