elip-0150: encode single private blinding keys in hex - #9
Conversation
a781ab2 to
5650391
Compare
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:
Should we only change single private key to be encoded in hex rather than WIF? Anyway this
would still apply, and that was the main rationale to remove support for them. |
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.
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. |
5650391 to
656a25b
Compare
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.
656a25b to
0ddbaaa
Compare
Updated PR, text, title and related PR in elements-miniscript (# 64) |
FYI Legder allows you to fetch the blinding pubkey and the computed blinding nonces, but not any private key. |
|
Ok, 0ddbaaa looks great to me. Would like an ACK from somebody else as well. |
| * 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> |
There was a problem hiding this comment.
fixed in a separate commit
|
0ddbaaa looks good to me (except the typo) |
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
…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.
WIF format is inconvenient since it has:
different enum than that of the xprv/xpub network;
Just use hex for single private blinding keys which
matches the format used by single public keys.