AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 27 Bitcoin

descriptor: support elements confidential wallet policies

Public commit record

What the developer wrote

Authored by Jon Griffiths

78/100 · Adequate
descriptor: support elements confidential wallet policies

These are the same as existing wallet policies except that the blinding
key placeholder must be '@B`, which must be given first in the policy
key map when parsing.

This allows the blinding scheme and key to be presented separately from
the rest of the policy which will then be identical (modulo el-prefixes)
between elements and bitcoin for the same wallet structure.

This also allows the distinction between blinding keys and policy keys
to remain intact. Blinding keys are qualitatively different from
derivation keys; they may for example be a real pubkey, raw entropy,
and/or/in addition to an algorithm that operates on the result of the
policy for given derivation indices (in the case of deterministic
blinding). For these reasons blinding keys remain outside standard key
iteration in a parsed descriptor.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds support in libwally-core for a new Elements/Liquid confidential-wallet policy format. It lets wallet policies include a special '@B' blinding key placeholder, kept separate from ordinary derivation keys. The change is a feature addition with embedded validation rules; it does not appear to fix a known vulnerability, but it does touch sensitive descriptor-parsing code that handles cryptographic keys. There is no vendor statement that this is a security fix, and no independent researcher is credited.

Recommended action

Review the new validation paths for off-by-one errors and ensure the '@B' blinding key is consistently excluded from standard key iteration. If this commit is being backported, verify that the non-Elements BUILD_ELEMENTS guard correctly rejects Elements policies and that no code path bypasses the new checks. Consider requesting test vectors and a security note from the project maintainers.

Security signals we found

01

Descriptor/miniscript parsing code modified

02

Cryptographic key validation logic changed

03

New input validation rules added for '@B' blinding key

04

Non-Elements builds now explicitly reject Elements policy maps

05

Policy with no substitutions now rejected

06

ct() policies with SLIP77/ELIP150 features require a blinding key

Risk score

Why this scored 27/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 3/15
Affected reach 5/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.