build(deps): bump the all-dependencies group with 2 updates

[dependabot]

Bumps the all-dependencies group with 2 updates: go.sia.tech/core and go.sia.tech/coreutils.

Updates go.sia.tech/core from 0.13.1 to 0.13.2

Release notes

Sourced from go.sia.tech/core's releases.

0.13.2 (2025-06-14)

Features

• Add (ElementAccumulator).ValidateTransactionElements

Changelog

Sourced from go.sia.tech/core's changelog.

0.13.2 (2025-06-14)

Features

• Add (ElementAccumulator).ValidateTransactionElements

Commits

• 03828c3 Merge pull request #321 from SiaFoundation/release
• f3df075 chore: prepare release 0.13.2
• 25f426e add changelog
• c49e3c1 consensus: Add (ElementAccumulator).ValidateTransactionElements
• 62d750c Merge pull request #319 from SiaFoundation/dependabot/go_modules/all-dependen...
• 30983aa build(deps): bump the all-dependencies group with 2 updates
• See full diff in compare view

Updates go.sia.tech/coreutils from 0.16.0 to 0.16.1

Release notes

Sourced from go.sia.tech/coreutils's releases.

0.16.1 (2025-06-14)

Fixes

• Added defer recover to prevent nodes from panicking due to uncaught bugs.
• Fixed a panic when attempting to update element proofs.
• Update core to v0.13.2

TxPool fixes

#260 by @​lukechampine

In the course of writing a test for full txpool behavior, I found a bug in the index handling: all of the transactions were being assigned an index of len(txpool.txns), instead of sequential ones! This was almost certainly the result of copy-pasting the m.txpool.indices[txid] = len(m.txpool.txns) from AddPoolTransactions; it breaks in revalidatePool because we're appending to filtered, not m.txpool.txns directly.

This is probably the root cause of SiaFoundation/coreutils#256. We had been blaming parentMap for that, so I ripped it out. I think it should stay ripped out, though, since benchmarks show that the operation it's optimizing is not particularly slow in the first place.

I also added an important validation step to updateV2TransactionProofs. This should prevent the panic seen in SiaFoundation/coreutils#254.

Changelog

Sourced from go.sia.tech/coreutils's changelog.

0.16.1 (2025-06-14)

Fixes

• Added defer recover to prevent nodes from panicking due to uncaught bugs.
• Fixed a panic when attempting to update element proofs.
• Update core to v0.13.2

TxPool fixes

##260 by @​lukechampine

In the course of writing a test for full txpool behavior, I found a bug in the index handling: all of the transactions were being assigned an index of len(txpool.txns), instead of sequential ones! This was almost certainly the result of copy-pasting the m.txpool.indices[txid] = len(m.txpool.txns) from AddPoolTransactions; it breaks in revalidatePool because we're appending to filtered, not m.txpool.txns directly.

This is probably the root cause of SiaFoundation/coreutils#256. We had been blaming parentMap for that, so I ripped it out. I think it should stay ripped out, though, since benchmarks show that the operation it's optimizing is not particularly slow in the first place.

I also added an important validation step to updateV2TransactionProofs. This should prevent the panic seen in SiaFoundation/coreutils#254.

Commits

• 43ec14b Merge pull request #255 from SiaFoundation/release
• 2f1f508 chore: prepare release 0.16.1
• ecc0f97 Merge pull request #263 from SiaFoundation/nate/update-core
• f11339d update core
• b6ecc61 Merge pull request #262 from SiaFoundation/txpool-race
• 0c2ef6d chain: Fix TxPool race
• 059d6d9 Merge pull request #260 from SiaFoundation/parent-map
• d81e4c1 rhp/v4: Add Renewal immediately prior to signing
• 133a68a chain: Validate v2 txns before updating their proofs
• ea93b7b Auto generate changeset
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions