Skip to content

Additional sighash cache index bit - #1581

Open
tomt1664 wants to merge 2 commits into
ElementsProject:masterfrom
tomt1664:sighashcache_rangeproof_update
Open

Additional sighash cache index bit#1581
tomt1664 wants to merge 2 commits into
ElementsProject:masterfrom
tomt1664:sighashcache_rangeproof_update

Conversation

@tomt1664

Copy link
Copy Markdown
Member

Additional cache index bit added for sighash combination with SIGHASH_RANGEPROOF

@apoelstra

Copy link
Copy Markdown
Member

utACK 0a0dd9b

FWIW I think you could change the size of the cache_entries table to 14. Probably not worth the extra thinking and risk of OOB access to save a couple entries.

tomt1664 and others added 2 commits August 13, 2026 14:33
…PROOF keying

Backport of bitcoin/bitcoin#32473 as integrated on elements-23.x
(eb64d24), reapplied against master's tree.

The SIGHASH_RANGEPROOF (0x40) bit changes the sighash preimage: segwit v0
appends hashRangeproofs, and the legacy serializer appends each output's
rangeproof and surjectionproof. It is therefore part of the cache key, and
the table has 16 entries rather than upstream's 6. Dropping that term is a
consensus split with deployed elements-23.x in both directions.

Upstream added SigHashCache as a pure addition, so a merge of this file will
auto-merge without prompting for the Elements adaptation. Hence the explicit
markers.
Github-Pull: #32473
Rebased-From: 9014d40
(cherry picked from commit 5a0506e)
(cherry picked from commit b4780f0d87b173f6ca4a14104e127aa8dfe75208)
@tomt1664
tomt1664 force-pushed the sighashcache_rangeproof_update branch from 0a0dd9b to 1484750 Compare August 13, 2026 14:21
@tomt1664
tomt1664 changed the base branch from elements-29.x to master August 13, 2026 14:21
// because no input can simultaneously use both.
// ELEMENTS: SIGHASH_RANGEPROOF changes the preimage (segwit v0 appends hashRangeproofs; the
// legacy serializer appends each output's rangeproof and surjectionproof), so it must be a
// dimension of the cache key. Removing this term is a consensus split with elements-23.x.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In 903be1e:

This comment is a bit confusing. Removing this term would break the caching logic, but it wouldn't be a "consensus split with elements 23" in particular. It'd just be wrong.

Comment thread src/script/interpreter.h
* optionally store a scriptCode which the hash is for, plus a midstate for the SHA256
* computation just before adding the hash_type itself. */
// ELEMENTS: the SIGHASH_RANGEPROOF (0x40) bit changes the sighash preimage, so it is part of
// the cache key and the table has 16 entries rather than upstream's 6. Do not drop this when

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In 903be1e:

Fine to leave as-is, but the old table had 6 elements and we're adding 8 to it, so 14 is the correct number.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right. I will leave as is though, as it is (again incorrectly) 16 in 23.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants