Skip to content

elip-0150: encode single private blinding keys in hex - #9

Merged
apoelstra merged 3 commits into
ElementsProject:mainfrom
LeoComandini:2023-11-elip150-view-key-no-version
Dec 20, 2023
Merged

elip-0150: encode single private blinding keys in hex#9
apoelstra merged 3 commits into
ElementsProject:mainfrom
LeoComandini:2023-11-elip150-view-key-no-version

Conversation

@LeoComandini

@LeoComandini LeoComandini commented Nov 24, 2023

Copy link
Copy Markdown
Collaborator

WIF format is inconvenient since it has:

  • its own network byte which corresponds to a
    different enum than that of the xprv/xpub network;
  • a "public key" format with no network byte at all.

Just use hex for single private blinding keys which
matches the format used by single public keys.

@LeoComandini
LeoComandini force-pushed the 2023-11-elip150-view-key-no-version branch from a781ab2 to 5650391 Compare November 24, 2023 08:59
@LeoComandini LeoComandini changed the title WIP: elip-0150: only allow hex bare/view blinding keys elip-0150: only allow hex bare/view blinding keys Nov 24, 2023
@apoelstra

Copy link
Copy Markdown
Member
  • the extended key will never be BIP 32 derived, only the
    public/private key is tweaked

We should definitely support BIP32-deriving view keys. Supporting this was one of the primary goals of this ELIP.

If this forces us to deal with network bytes in descriptors then maybe we just have to bite the bullet.

@LeoComandini

Copy link
Copy Markdown
Collaborator Author
  • the extended key will never be BIP 32 derived, only the
    public/private key is tweaked

We should definitely support BIP32-deriving view keys. Supporting this was one of the primary goals of this ELIP.

If this forces us to deal with network bytes in descriptors then maybe we just have to bite the bullet.

I can rework this PR to allow for BIP32 extended keys as descriptor blinding keys.

Currently (ie ignoring this PR) a bare/view blinding key could be:

  • a single private key (a WIF key)
  • a single public key (66 hex chars)
  • a xprv (b58 string + optional keyorigin)
  • a xpub (b58 string + optional keyorigin)

Should we only change single private key to be encoded in hex rather than WIF?

Anyway this

  • deriving a bare/view key from a BIP 32 seed is not compatible
    with HWWs. Since they don't export private keys, we won't be
    able to get the view key and derive the output blinding keys.

would still apply, and that was the main rationale to remove support for them.

@apoelstra

Copy link
Copy Markdown
Member

Should we only change single private key to be encoded in hex rather than WIF?

Yeah, I'm happy with this change. Non-BIP32 private keys are a weird edge case and I don't think it's too inconvenient not to allow WIF. Since WIF (a) has its own network byte which corresponds to a different enum than that of the xprv/xpub network; (b) has a "public key" format with no network byte at all.

deriving a bare/view key from a BIP 32 seed is not compatible with HWWs. Since they don't export private keys, we won't be able to get the view key and derive the output blinding keys.

Ledger, for example, will export certain private keys IIRC, under a specific path for a specific vendor. Or something like that. So we shouldn't rule out the possibility that HWWs could support exporting a subset of privkeys.

@LeoComandini
LeoComandini force-pushed the 2023-11-elip150-view-key-no-version branch from 5650391 to 656a25b Compare November 29, 2023 14:46
@LeoComandini LeoComandini changed the title elip-0150: only allow hex bare/view blinding keys elip-0150: encode single private blinding keys in hex Nov 29, 2023
WIF format is inconvenient since it has:
* its own network byte which corresponds to a
  different enum than that of the xprv/xpub network;
* a "public key" format with no network byte at all.

Just use hex for single private blinding keys which
matches the format used by single public keys.
@LeoComandini
LeoComandini force-pushed the 2023-11-elip150-view-key-no-version branch from 656a25b to 0ddbaaa Compare November 29, 2023 14:47
@LeoComandini

LeoComandini commented Nov 29, 2023

Copy link
Copy Markdown
Collaborator Author

Should we only change single private key to be encoded in hex rather than WIF?

Yeah, I'm happy with this change.

Updated PR, text, title and related PR in elements-miniscript (# 64)

@jgriffiths

Copy link
Copy Markdown
Collaborator

Ledger, for example, will export certain private keys IIRC, under a specific path for a specific vendor. Or something like that. So we shouldn't rule out the possibility that HWWs could support exporting a subset of privkeys.

FYI Legder allows you to fetch the blinding pubkey and the computed blinding nonces, but not any private key.

@apoelstra

Copy link
Copy Markdown
Member

Ok, 0ddbaaa looks great to me. Would like an ACK from somebody else as well.

Comment thread elip-0150.mediawiki Outdated
* View Descriptor 2: <code>ct(L3jXxwef3fpB7hcrFozcWgHeJCPSAFiZ1Ji2YJMPxceaGvy3PC1q,elwpkh(021a8fb6bd5a653b021b98a2a785725b8ddacfe3687bc043aa7f4d25d3a48d40b5))#stngzuwt</code>
** Descriptor blinding private key: <code>L3jXxwef3fpB7hcrFozcWgHeJCPSAFiZ1Ji2YJMPxceaGvy3PC1q</code>
* View Descriptor 2: <code>ct(c25deb86fa11e49d651d7eae27c220ef930fbd86ea023eebfa73e54875647963,elwpkh(021a8fb6bd5a653b021b98a2a785725b8ddacfe3687bc043aa7f4d25d3a48d40b5))#c2kx9zll</code>
** Descriptor blinding private key: <code><c25deb86fa11e49d651d7eae27c220ef930fbd86ea023eebfa73e54875647963/code>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

typo: position of the <

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

fixed in a separate commit

@RCasatta

RCasatta commented Dec 20, 2023

Copy link
Copy Markdown
Contributor

0ddbaaa looks good to me (except the typo)

@apoelstra apoelstra left a comment

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.

ACK bf51db9

@apoelstra
apoelstra merged commit b7648ca into ElementsProject:main Dec 20, 2023
apoelstra added a commit to ElementsProject/elements-miniscript that referenced this pull request Dec 20, 2023
81a4a83 CT descriptor: use hex for single private view keys (Leonardo Comandini)

Pull request description:

  Changes related to ElementsProject/ELIPs#9

ACKs for top commit:
  RCasatta:
    ACK 81a4a83 checked that test cases matches the ones in ElementsProject/ELIPs@0ddbaaa
  apoelstra:
    ACK 81a4a83

Tree-SHA512: 3c96fbf6fef8f333457e70da6c1b180dc5df10f473f04317e6c34bc2e453e94ce24355179a3d25adf434a9ee83ab0d9aaa1158398c518472a5d596dca8b34230
@LeoComandini
LeoComandini deleted the 2023-11-elip150-view-key-no-version branch February 7, 2024 16:05
42Pupusas added a commit to 42Pupusas/ELIPs that referenced this pull request Jul 29, 2026
…esses

Addresses review point ElementsProject#9 (test vector coverage gaps). The BIP-352 label
mechanism was previously unimplemented and untested in the reference despite
the ELIP claiming to inherit it 'exactly' from BIP-352; peg-in input
eligibility was specified in the mediawiki (previous commit) but had no
corresponding test; and testnet/regtest address sharing of tlqsp was only
implicitly covered via test_address_round_trip's 'liquid-testnet' case with
no explicit regtest check.

reference.py: added label_tweak, labeled_spend_pubkey, and
labeled_output_spend_privkey (B_m = B_spend + label_tweak(b_scan, m)*G, per
BIP-352's Address encoding / Labels section, unchanged on Liquid).

test_vectors.py: three new tests.
- test_labels: sender/receiver spend-key agreement for a labeled address
  across several m values, plus m=0 (change) distinctness from m=1.
- test_pegin_input_excluded_from_shared_secret: a peg-in's private key never
  enters the aggregate a_sum/A, but its outpoint can still be the
  lexicographically-smallest outpoint_L, changing input_hash even though it
  contributes nothing to the shared secret.
- test_testnet_and_regtest_addresses: explicit assertion that
  'liquid-testnet' and 'liquid-regtest' encode/decode identically under
  tlqsp, and both remain distinct from mainnet's lqsp.

README.md: updated coverage list.

Verified: 8/8 tests pass (up from 5/5), including the 3 new ones.
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.

4 participants