💬 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.
(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.
(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.
(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?
(https://github.com/bitcoin/bitcoin/pull/30032#pullrequestreview-2038784020)
Nice. Have you tried running this to see how often it hits?
💬 glozow commented on pull request "p2p: Allow 1P1C to fetch parent from compact block extra_txn":
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589595727)
Feels inefficient/expensive to construct a package + call these checks for every tx every time there's a missing input. Maybe parameterize by the txid of the missing parent (i.e. just 1 exists) and first check that the txid matches?
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589595727)
Feels inefficient/expensive to construct a package + call these checks for every tx every time there's a missing input. Maybe parameterize by the txid of the missing parent (i.e. just 1 exists) and first check that the txid matches?
💬 glozow commented on pull request "p2p: Allow 1P1C to fetch parent from compact block extra_txn":
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589595916)
nice :brain:
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589595916)
nice :brain:
💬 glozow commented on pull request "p2p: Allow 1P1C to fetch parent from compact block extra_txn":
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589590238)
needs comment
(https://github.com/bitcoin/bitcoin/pull/30032#discussion_r1589590238)
needs comment
💬 instagibbs commented on pull request "p2p: Allow 1P1C to fetch parent from compact block extra_txn":
(https://github.com/bitcoin/bitcoin/pull/30032#issuecomment-2093553813)
> Nice. Have you tried running this to see how often it hits?
I'll do some logging :+1: I suspect it'll be quite above non-0 because from my log-reading just-below-minfee is quite commonly a reason for missing the parent.
(https://github.com/bitcoin/bitcoin/pull/30032#issuecomment-2093553813)
> Nice. Have you tried running this to see how often it hits?
I'll do some logging :+1: I suspect it'll be quite above non-0 because from my log-reading just-below-minfee is quite commonly a reason for missing the parent.
💬 jlopp commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093554109)
> Does your node still have network adjusted time?
That could explain it. IIRC I was originally using v25.
I can generate a genesis block in about 15 minutes so no biggie to try variations.
Here's an alternate genesis block with a zeroed out pubkey:
```
./generate-genesis -timestamp 1714658825 -pubkey 000000000000000000000000000000000000000000000000000000000000000000 -psz "CCN 02/May/2024 Bitcoin Testnet Could Need Reset"
Ctrl Hash: 0x00000000fa64304c1e2ebace74844da4a1a7fecca7fb94a0f
...
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2093554109)
> Does your node still have network adjusted time?
That could explain it. IIRC I was originally using v25.
I can generate a genesis block in about 15 minutes so no biggie to try variations.
Here's an alternate genesis block with a zeroed out pubkey:
```
./generate-genesis -timestamp 1714658825 -pubkey 000000000000000000000000000000000000000000000000000000000000000000 -psz "CCN 02/May/2024 Bitcoin Testnet Could Need Reset"
Ctrl Hash: 0x00000000fa64304c1e2ebace74844da4a1a7fecca7fb94a0f
...
📝 willcl-ark opened a pull request: "ci: add markdown link check job"
(https://github.com/bitcoin/bitcoin/pull/30034)
Potential followup to: #30025
This should prevent us reintroducing broken markdown links.
It does not test "online" (external) links, only those within this repo. Both relative and absolute links are parsed successfully if they resolve.
(https://github.com/bitcoin/bitcoin/pull/30034)
Potential followup to: #30025
This should prevent us reintroducing broken markdown links.
It does not test "online" (external) links, only those within this repo. Both relative and absolute links are parsed successfully if they resolve.
💬 willcl-ark commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2093636778)
Without #30025 (or alternative fix) the new action being added here will fail.
It takes ~11s to run:
- [example pass](https://github.com/willcl-ark/bitcoin/actions/runs/8943826589)
- [example fail](https://github.com/willcl-ark/bitcoin/actions/runs/8943826087)
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2093636778)
Without #30025 (or alternative fix) the new action being added here will fail.
It takes ~11s to run:
- [example pass](https://github.com/willcl-ark/bitcoin/actions/runs/8943826589)
- [example fail](https://github.com/willcl-ark/bitcoin/actions/runs/8943826087)
📝 instagibbs converted_to_draft 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 from memory, and submit for validation.
...
(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 from memory, and submit for validation.
...
👍 TheCharlatan approved a pull request: "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set"
(https://github.com/bitcoin/bitcoin/pull/25972#pullrequestreview-2038887677)
ACK f0e22be69a15248c42964d57f44ce8c37a36081d
(https://github.com/bitcoin/bitcoin/pull/25972#pullrequestreview-2038887677)
ACK f0e22be69a15248c42964d57f44ce8c37a36081d
📝 paplorinc opened a pull request: "test: Add a few more corner cases to the base58 test suite"
(https://github.com/bitcoin/bitcoin/pull/30035)
Split out the additional tests from the base58 optimization PR, see: https://github.com/bitcoin/bitcoin/pull/29473#discussion_r1526210147
(https://github.com/bitcoin/bitcoin/pull/30035)
Split out the additional tests from the base58 optimization PR, see: https://github.com/bitcoin/bitcoin/pull/29473#discussion_r1526210147
🤔 sr-gi reviewed a pull request: "p2p: index TxOrphanage by wtxid, allow entries with same txid"
(https://github.com/bitcoin/bitcoin/pull/30000#pullrequestreview-2038712299)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/30000#pullrequestreview-2038712299)
Concept ACK
💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589529436)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d
This is only used for logging now. Do we care about logging the `txid` now that the map is keyed by `wtxid`?
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589529436)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d
This is only used for logging now. Do we care about logging the `txid` now that the map is keyed by `wtxid`?
💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589549760)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d
Same here, do we still care about logging `txids`? I guess this applies to all the file, so not pointing it out again
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589549760)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d
Same here, do we still care about logging `txids`? I guess this applies to all the file, so not pointing it out again
💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589569008)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d
This should not be called `orphanHash` anymore, but also, this could be inlined
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589569008)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d
This should not be called `orphanHash` anymore, but also, this could be inlined
💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589547282)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d
nit: `nErased` is a counter right? Shouldn't this read `txs` instead?
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589547282)
In 646aa4da91c03a0e72d086cae281aa0688f2f41d
nit: `nErased` is a counter right? Shouldn't this read `txs` instead?
💬 sr-gi commented on pull request "p2p: index TxOrphanage by wtxid, allow entries with same txid":
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589571339)
Also, in L231:
`for (const auto& orphanHash : vOrphanErase)` -> `for (const auto& wtxid : vOrphanErase)`
(https://github.com/bitcoin/bitcoin/pull/30000#discussion_r1589571339)
Also, in L231:
`for (const auto& orphanHash : vOrphanErase)` -> `for (const auto& wtxid : vOrphanErase)`