📝 instagibbs opened a pull request: "p2p: Allow 1P1C to fetch parent from compact block extra_txn"
(https://github.com/bitcoin/bitcoin/pull/30032)
One relatively common pattern of 1P1C relay is receiving
a just-below-minfee parent, dropping it and marking it
as reconsiderable, then fetching it again from the peer
once the child is added to the orphanage.

A cache of dropped parents would be useful, and it turns
out we're already opportunistically storing transactions
like this for compact blocks as "extra transactions".
Use this size-limited cache to potentially fetch a
reconsiderable parent, and submit for validation.

💬 vostrnad commented on pull request "test: remove duplicate `WITNESS_SCALE_FACTOR` constant defination":
(https://github.com/bitcoin/bitcoin/pull/30029#issuecomment-2093314146)
nit: typo in PR name (defination -> definition)

💬 fjahr commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093325471)
> @fjahr's earlier code (https://github.com/bitcoin/bitcoin/pull/29775#pullrequestreview-2035943330) did not change consensus.powLimit but instead changed GetNextWorkRequired to enforce this. As a consequence the initial blocks after genesis could have difficulty 1, but once the difficulty goes above a typical S9, it can no longer drop below that.

I did implement an exception to allow the difficulty to drop below the adjustment (1M in this case), see my comment on this in the old commit: http
...

💬 fjahr commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#discussion_r1589417605)
Added, sorry I forgot about that.

💬 achow101 commented on pull request "test: remove duplicate `WITNESS_SCALE_FACTOR` constant definition":
(https://github.com/bitcoin/bitcoin/pull/30029#issuecomment-2093367695)
ACK af3c18169a075222fe0795ab24b8b20ad5e30ae4

🚀 achow101 merged a pull request: "test: remove duplicate `WITNESS_SCALE_FACTOR` constant definition"
(https://github.com/bitcoin/bitcoin/pull/30029)

💬 achow101 commented on pull request "doc: replace remaining "520" magic nums with MAX_SCRIPT_ELEMENT_SIZE":
(https://github.com/bitcoin/bitcoin/pull/30024#issuecomment-2093369038)
ACK ffc674595cb19b2fdc5705b355bdd3e7f724b860

🚀 achow101 merged a pull request: "doc: replace remaining "520" magic nums with MAX_SCRIPT_ELEMENT_SIZE"
(https://github.com/bitcoin/bitcoin/pull/30024)

💬 furszy commented on pull request "net: don't lock cs_main while reading blocks in net processing":
(https://github.com/bitcoin/bitcoin/pull/26326#discussion_r1589443852)
> I just meant to check whether we're running in pruning mode, so the block could have been pruned theoretically.

Just in case, it should also check that the block is further than the pruning threshold.

> So, if reading the block fails, we retake cs_main and determine if the block was pruned out from under us. If so, we log and return early. Otherwise, we assert as before.

For now (at least in this PR), we should maintain the current network behavior if the assert is replaced. This mean
...

🤔 furszy reviewed a pull request: "rpc, wallet: fix incorrect segwit redeem script size limit"
(https://github.com/bitcoin/bitcoin/pull/28307#pullrequestreview-2038687143)
sad rebase after #30024 merge.

💬 fanquake commented on pull request "depends: swap some cctools tools for LLVM tools":
(https://github.com/bitcoin/bitcoin/pull/29739#issuecomment-2093465723)
Guix Build (aarch64)
```bash
6a215012d268b68b25d3120c63f7154169061d71bef8e3a434dc44d6e2c8bf06 guix-build-4313febae66b/output/aarch64-linux-gnu/SHA256SUMS.part
7469b754ce7632c175116ffb1490771b9a4b635c33ccf711fd5df2cf08c6d6d4 guix-build-4313febae66b/output/aarch64-linux-gnu/bitcoin-4313febae66b-aarch64-linux-gnu-debug.tar.gz
7ffd30c4e1894555a1172e13106d8fbf6291f357073fb17840e653f98fe3599f guix-build-4313febae66b/output/aarch64-linux-gnu/bitcoin-4313febae66b-aarch64-linux-gnu.tar.gz
f8d0a35
...

💬 pinheadmz commented on pull request "rpc, wallet: fix incorrect segwit redeem script size limit":
(https://github.com/bitcoin/bitcoin/pull/28307#issuecomment-2093475353)
I wrote a test for RPC `signrawtransactionwithkey` that covers legacy P2SH with 15 and 16 public keys. Both calls succeed even though the latter produces a scriptSig that exceeds `MAX_STANDARD_SCRIPTSIG_SIZE` and if it ever made it into a block, would exceed `MAX_SCRIPT_ELEMENT_SIZE`

This test behaves the same on master! So, that is potentially a footgun although not an easy one for a user to pull off and also would not result in any loss of funds.

https://gist.github.com/pinheadmz/ca8ed75
...

💬 jlopp commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093478851)
> Where does the public key come from?

@Sjors I just grabbed a random public key from one of my testnet wallets; unclear if there's any significance to the public key used for the genesis block.

> By the way, I noticed that src/bitcoin-cli -testnet4 -generate 1 1000000000 does not find a block if called a dozen times, even at difficulty 1. I'm not sure if that's expected because the mining code is inefficient (single CPU thread) or if there's a bug. I worked around it by temporarily settin
...

💬 ryanofsky commented on pull request "refactor: Use util::Result class for wallet loading":
(https://github.com/bitcoin/bitcoin/pull/25722#issuecomment-2093499563)
Rebased 2385cb37dbbe00004f8bffe1d1d784778d89a21e -> 987b28bbc991868ed305dbfc8f0846dd8b0b893c ([`pr/bresult-load.21`](https://github.com/ryanofsky/bitcoin/commits/pr/bresult-load.21) -> [`pr/bresult-load.22`](https://github.com/ryanofsky/bitcoin/commits/pr/bresult-load.22), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/bresult-load.21-rebase..pr/bresult-load.22)) to use newer result API in #25722.
Updated 987b28bbc991868ed305dbfc8f0846dd8b0b893c -> 548bf508e26aae39c732b3e61861d5c2966
...

💬 Sjors commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093516015)
> I don't have S9s lying around unfortunately

I do, special discount for genesis blocks :-)

> use the 20min rule for mining their fancy non-standard transactions etc

When a miner reorgs a block, do non-standard transactions end up in its mempool or are they forgotten? The latter is probably safest, but we could allow it on testnet for this use case.

We made `acceptnonstdtxn=0` the default for testnet3 in #28354. We could flip it back on. Or we could make it easier to preferentially p
...

💬 itornaza commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#issuecomment-2093526057)
concept ACK

After being caught out of guard due to the short notice on this PR at the Bitcoin Review Club, I took time to review the code changes and read the comments above.

To my understanding, we need to check the `wtxid` for screening transactions for inclusion in the orphanage in order to catch witness malleations as well. This was not previously possible because we where only checking against `txid` that does not include the `[witness]` section of a transaction as defined in [BIP141
...

💬 itornaza commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589579918)
imo `wtxid` and `txid` being double SHA256 outputs and wtxid being essentially a superset of txid, makes this blind conversion legitimate.

💬 itornaza commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589581014)
imo wtxid and txid being double SHA256 outputs and wtxid being essentially a superset of txid, makes this blind conversion legitimate.

💬 itornaza commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589584199)
imo `wtxid` and `txid` being double SHA256 outputs and `wtxid` being essentially a superset of `txid`, makes this blind conversion legitimate.

🤔 glozow reviewed a pull request: "p2p: Allow 1P1C to fetch parent from compact block extra_txn"
(https://github.com/bitcoin/bitcoin/pull/30032#pullrequestreview-2038784020)
Nice. Have you tried running this to see how often it hits?