💬 theStack commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1597725786)
nit:
```suggestion
assert_equal(node.getmempoolentry(tx_child["txid"])["wtxid"], tx_child["wtxid"])
```

💬 pinheadmz commented on issue "contrib/signet/miner: miner won't consider --nbits parameter":
(https://github.com/bitcoin/bitcoin/issues/30091#issuecomment-2106397970)
@edilmedeiros this might be expected behavior although not well documented. If I recall, the signet miner generates the first 100 blocks as fast as possible with 100% CPU (to cross coinbase maturity) so you can start spending signet coins right away. It will *eventually* retarget to your configured difficulty. If you're able to, I'd let your process run at least 2,016 blocks and then check if its acting as expected.

💬 pinheadmz commented on issue "contrib/signet/miner: miner won't consider --nbits parameter":
(https://github.com/bitcoin/bitcoin/issues/30091#issuecomment-2106398197)
For the descriptor wallet question, I ran a custom signet for an educational program earlier this year and wrote a script that created a descriptor wallet in regtest, then spawned signet with that descriptor: https://github.com/chaincodelabs/signet-wallet-project/blob/main/signet-setup.py

🤔 furszy reviewed a pull request: "script/sign: avoid duplicated signature verification after signing (+introduce signing benchmarks)"
(https://github.com/bitcoin/bitcoin/pull/28923#pullrequestreview-2051468976)
utACK fe92c15f0c44

💬 edilmedeiros commented on issue "contrib/signet/miner: miner won't consider --nbits parameter":
(https://github.com/bitcoin/bitcoin/issues/30091#issuecomment-2106401030)
> @edilmedeiros this might be expected behavior although not well documented. If I recall, the signet miner generates the first 100 blocks as fast as possible with 100% CPU (to cross coinbase maturity) so you can start spending signet coins right away. It will _eventually_ retarget to your configured difficulty. If you're able to, I'd let your process run at least 2,016 blocks and then check if its acting as expected.

I was running this way after the 100 block threshold when I perceived this
...

✅ luke-jr closed a pull request: "Bugfix: RPC/Mining: getblocktemplate: Delay updating nTransactionsUpdatedLast and time_start until after the new template is cached"
(https://github.com/bitcoin/bitcoin/pull/30088)

💬 luke-jr commented on pull request "Bugfix: RPC/Mining: getblocktemplate: Delay updating nTransactionsUpdatedLast and time_start until after the new template is cached":
(https://github.com/bitcoin/bitcoin/pull/30088#issuecomment-2106408589)
Indeed, forgot about cs_main

💬 Saraeutsza commented on pull request "wallet: add coin selection parameter `add_excess_to_recipient_position` for changeless txs with excess that would be added to fees":
(https://github.com/bitcoin/bitcoin/pull/30080#issuecomment-2106429004)
[](https://github.com/bitcoin/bitcoin/actions/workflows/ci.yml)[](url)

💬 tdb3 commented on pull request "cli: Detect port errors in rpcconnect and rpcport":
(https://github.com/bitcoin/bitcoin/pull/29521#discussion_r1597779699)
Thanks @cbergqvist. Good observation.

Looks like rpc_bind.py uses `--ipv4` and `--ipv6` arguments to run the test exclusively with ipv4 or ipv6 (not both), which at first glance doesn't seem to be desirable for interface_bitcoin_cli.py (dependence on network type is a somewhat small part of the test). I could see there being value in refactoring interface_bitcoin_cli.py to include wider coverage of bitcoin-cli with ipv4 and ipv6, but I'm thinking this sort of refactor would be a good follow
...

💬 tdb3 commented on pull request "cli: Detect port errors in rpcconnect and rpcport":
(https://github.com/bitcoin/bitcoin/pull/29521#issuecomment-2106531828)
Seeing a CI error for arm-linux-gnueabihf-g++ (on a line unchanged in this latest push). Will look into this.

```
In function ‘UniValue CallRPC(BaseRequestHandler*, const std::string&, const std::vector<std::__cxx11::basic_string<char> >&, const std::optional<std::__cxx11::basic_string<char> >&)’,
inlined from ‘UniValue ConnectAndCallRPC(BaseRequestHandler*, const std::string&, const std::vector<std::__cxx11::basic_string<char> >&, const std::optional<std::__cxx11::basic_string<char> >
...

💬 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