💬 fanquake commented on pull request "[27.x] Backports":
(https://github.com/bitcoin/bitcoin/pull/29888#issuecomment-2106584973)
> I suggest to add https://github.com/bitcoin-core/gui/pull/812 and https://github.com/bitcoin-core/gui/pull/813.

I'll put these into the next PR, that will likely also do release prep.

🚀 fanquake merged a pull request: "[27.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/29888)

📝 fanquake opened a pull request: "[27.x] Backports and probably finalize"
(https://github.com/bitcoin/bitcoin/pull/30092)
Backports:
* https://github.com/bitcoin-core/gui/pull/812
* https://github.com/bitcoin-core/gui/pull/813

💬 fanquake commented on pull request "Don't permit port in proxy IP option":
(https://github.com/bitcoin-core/gui/pull/813#issuecomment-2106620980)
Backported in https://github.com/bitcoin/bitcoin/pull/30092.

💬 fanquake commented on pull request "Fix create unsigned transaction fee bump":
(https://github.com/bitcoin-core/gui/pull/812#issuecomment-2106621277)
Backported in https://github.com/bitcoin/bitcoin/pull/30092.

💬 fanquake commented on pull request "contrib: lief updates":
(https://github.com/bitcoin/bitcoin/pull/30084#issuecomment-2106656448)
> would you be concept ACK on updating the guix manifest to a recent lief (0.14 or maybe imminent 0.15), or prefer to hold off for now?

I don't really think we need to update or change anything in our release infrastructure right now, particularly if the only reason is so that linters can be run against versions of dependencies that we don't use.

If anything, I think the docs could be updated in some way to say that running the linters outside the container, or with versions that differ fr
...

💬 wtogami commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2106691767)
> So if the difficulty hack is removed completely, anyone wishing to submit a transaction would have to go purchase and set up mining hardware, or find a miner willing to accept the transaction.

With zero changes to Core, signet could serve the same need to get non standard transactions into test blocks. Signet could have a website where you submit nonstandard transactions for the miner to include. This would directly parallel how out-of-band transactions are added by miners on mainnet.

💬 ajtowns commented on issue "contrib/signet/miner: miner won't consider --nbits parameter":
(https://github.com/bitcoin/bitcoin/issues/30091#issuecomment-2106767458)
The `--nbits` value sets the desired difficulty; to reach that desired difficulty when the target difficulty is lower, blocks need to be mined faster than normal. Since the maximum difficulty increase is 4x, the block rate will be at most 4x faster than normal, ie 2m30s instead of 10m. Setting --min-nbits is saying "I don't need the difficulty to increase" which implies just mining a block every 10 minutes is fine since the chain starts at a difficulty matching min nbits.

The fast mining of t
...

💬 ajtowns commented on issue "contrib/signet/miner: miner won't consider --nbits parameter":
(https://github.com/bitcoin/bitcoin/issues/30091#issuecomment-2106772366)
(Signet adopts essentially the same rules as mainnet, so the only way to sustain blocks that are more frequent than once every 10 minutes is to continually raise the difficulty, which results in real costs, or to make use of the timewarp bug)

💬 russeree commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2106776587)
tACK - 06c2c713c52b60231efc3e00d2c5eb0bf9e345f9

💬 craigraw commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2106789221)
tACK https://github.com/bitcoin/bitcoin/commit/06c2c713c52b60231efc3e00d2c5eb0bf9e345f9

💬 maflcko commented on pull request "cli: Detect port errors in rpcconnect and rpcport":
(https://github.com/bitcoin/bitcoin/pull/29521#discussion_r1597970957)
```suggestion
port=ToIntegral<uint16_t>(rpcport_arg.value_or(0));
if (port == 0) {
```

if you treat `0` as invalid, there is no need to also have nullopt be invalid as well, no?

This should also fix the false-positive compiler warning?

An alternative would be to suppress the false-positive warning in the CI task config.

💬 Emzy commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2106805681)
tACK 06c2c71

I'm just tested mining with CPUs and a S9 ASIC.

💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#discussion_r1597984017)
> only send me stuff where the UTXOs have a value of >= X

So now we need an index and efficient sorting.

> It might also be case of trying to fit a square peg into a round hole

For the index without cut-through I think BIP157 is fine. But to get the extra bandwidth savings of cut-through and a (custom) dust limit, it indeed seems we need something else. But ideally that shouldn't block shipping something that works, even if it uses a bit more bandwidth that we'd like.

It's worth cons
...

💬 maflcko commented on pull request "test: switch from curl to urllib for HTTP requests":
(https://github.com/bitcoin/bitcoin/pull/29970#discussion_r1598001674)
> Should this change be in a new commit or should I force it on the previous commit?

Squashing seems fine?

💬 fanquake commented on pull request "test: switch from curl to urllib for HTTP requests":
(https://github.com/bitcoin/bitcoin/pull/29970#discussion_r1598004575)
If this is part of the standard library, I don't think you need to list it as a requirement.

💬 iw4p commented on pull request "test: switch from curl to urllib for HTTP requests":
(https://github.com/bitcoin/bitcoin/pull/29970#discussion_r1598009105)
To rewrite the git history for having the last change on the last commit and ignore old ones, I forced it. I used squashing only for merging before that.

💬 Sjors commented on pull request "crypto: add `NUMS_H` const":
(https://github.com/bitcoin/bitcoin/pull/30048#discussion_r1598013264)
I think that would require adding [sage](https://www.sagemath.org) to our test dependencies.

💬 josibake commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#discussion_r1598018340)
> For the index without cut-through I think BIP157 is fine

Agree.

> It's worth considering at least adding the 546 sat dust limit to BIP352

I'd argue these are all implementation details/optimizations. The BIP itself should be reserved for describing the protocol. There also might be use cases where where the value of the output is not the primary concern.

💬 willcl-ark commented on issue "contrib/signet/miner: miner won't consider --nbits parameter":
(https://github.com/bitcoin/bitcoin/issues/30091#issuecomment-2106890826)
Ah I see!

So the 2:30 block times are expected then, and at the first difficulty adjustment I would be expecting the difficulty to increase to such a point that it would take my CPU 600 seconds to generate a block.

I did discuss this possiblilty with @pinheadmz late last night, but was too impatient to let my signet miner run to an adjustment to find out. Thanks @ajtowns