Transposed ec-to-ek version column values

[skaht]

Was trying to recreate results for https://github.com/aantonop/bitcoinbook/blob/develop/ch04.asciidoc#encrypted-private-keys-bip0038 and ran across the ec-to-ek issue below...

Current Behaviors:

% bx ec-to-ek -v 0 "MyTestPassphrase" 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
6PYJzKy76VEwRK87u9gx78w1FXGK7yRFbq13ZqjEpheRYfdHHwrvgRVCDd

% bx ec-to-ek -u -v 0 "MyTestPassphrase" 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
6PRTHL6mWa48xSopbU1cKrVjpKbBZxcLRRCdctLJ3z5yxE87MobKoXdTsJ

Per Altcoin Version Mappings, the version should be extracted from the "version_WIF" column, not the "version_ptpkh" column. Operating on private keys, not public addresses; hence, version selected should be from version_WIF.

Behaviors Should Be:

% bx ec-to-ek -v 128 "MyTestPassphrase" 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
6PYJzKy76VEwRK87u9gx78w1FXGK7yRFbq13ZqjEpheRYfdHHwrvgRVCDd

% bx ec-to-ek -u -v 128 "MyTestPassphrase" 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
6PRTHL6mWa48xSopbU1cKrVjpKbBZxcLRRCdctLJ3z5yxE87MobKoXdTsJ

[skaht]

The net result with issue #303 above is the Sample Map needs shifting. For example, 0x00 -> 6P... cfrm38V... should become 0x80 -> 6P... cfrm38V....

Upon further examination of existing Examples 6 and 7 from ec-to-ek with Sample Map made me wonder why the prefix starts with "8E" instead of "8F"? (111 = 0x6F which maps to 8F, while 110 maps to 8E)

For consistency with #303, Examples 6 and 7 from ec-to-ek should not be using 111 for testnet, but 238 (0xEF) instead from the version_wif column. Given the indexes at Sample Map need to be shifted 128. To calculate the anticipated prefix test (128+238)%256 = 110 which strangely enough maps back to "8E".

In summary, for Examples 6 and 7 should ultimately look like:

Example 6

bx ec-to-ek -v 238 "my passphrase" 261fc32e9f29c70e3d898aa7db028c81ede0658e8ff8ffab8160073c048ae83f

8EzHSxX3sfZp6NjYUdt7fZAPCKByrFDS12PHfdexFLSaSAfM7wM7tw3Hof

Example 7

bx ec-to-ek -u -v 238 "my passphrase" 261fc32e9f29c70e3d898aa7db028c81ede0658e8ff8ffab8160073c048ae83f

8EsMUV3Z5A9m8eA28nSYECHAmKmy4YsyCYpGNvzHocFJBFhVYZARNfrfnt

[skaht]

Results for Example Set 5 (5XCsGSbMhW6zisvPx7LUKHPUGTi21kdSVwc6HNM1Zurg9ENPiUVtzBZDho) at Altcoin Version Mappings will have to be tweaked. Looks like the prefix will start with "7F" instead of "5X".

[evoskuil]

I haven't had time go through this, but the most obvious issue I see is that there is some confusion above regarding which versions are mapped. BIP38 has a hard dependency on payment address versions, and as such the altchain extensions must be similarly coupled. See explanation here. So the statement that a WIF version should be used is a misinterpretation.

Also not here that it is called out that the testnet prefix byte will be either 8E or 8F. These values cannot be absolutely controlled, which is also the case with payment addresses.

[evoskuil]

Is this still an open question?

[skaht]

I won't be hard bent on which way the interface ultimately goes... I was being anal when hypothesizing a version extension to the the libbitcoin altcoin interface.

Once a convention takes hold (others having become heavily reliant upon on the interface for altcoins) it will stick whether version_WIF or version_p2pkh column is used. Was hoping the following one rule of three bullet version rules below the table would apply to ec-to-ek. If version_p2pkh applies, the simple hypothesized rule fails.

• Commands supporting version values associated with private key functionality for desired coin types will use values from the version_WIF column.

I know that it may seem weird the the default version for Bitcoin should be 128 and not 0 for ec-to-ek to achieve the 6P prefix, but that is the nature of the outcome by applying the suggested rule above.

Currently, there is an exception to the hypothesized rule version rule for ec-to-ek that will requiring an update the ec-to-ek bullet just below.

Your call as to how you want to close this issue. I'll reflect changes accordingly in the Wiki at my end.

[evoskuil]

The issue is that there is really no option. Payment address versions are hardwired into the BIP.