Feature request: generate 2nd seed that produces XOR result with a valid checksum

[GregTonoski]

Generate the 2nd seed which XOR'd with the 1st one results in the one which is complete (with correct checksum/last 4 bits) so that there isn't the need calculate SHA256 checksum: "If you intend to recover your original seed by hand in future using SeedXOR, you should make a note of the original seed's final word because the chances are that you will not be able to calculate the last word by hand using XOR & SHA256."

There is 1/4^2=6.25% chance to generate such a seed so brute-force could be implemented to achieve it.

[SuperPhatArrow]

@GregTonoski I'm sorry but I don't understand this feature request.

Feature request: generate seed that produces XOR result with a valid checksum

Seed tool already does this

Generate the 2nd seed which XOR'd with the 1st one results in the one which is complete (with correct checksum/last 4 bits) so that there isn't the need calculate SHA256 checksum: "If you intend to recover your original seed by hand in future using SeedXOR, you should make a note of the original seed's final word because the chances are that you will not be able to calculate the last word by hand using XOR & SHA256."

There are multiple correct final words from the checksum. From the spec:

• It's not possible to calculate the checksum of the final seed phrase on paper (needs SHA256).

• But it must start with the indicated digit(s). If using 24 words XOR, there will be only one suitable choice offered by the Coldcard in that range (x00 to xFF), once you have entered the other 23 words.

• The checksum of each of the XOR-parts protects the final result, assuming your XOR math is correct.

While it is technically possible to do SHA256 calculations on paper, it's quite complicated and not encouraged. We coded seed tool to provide the same final word as cold card so as to match them.

Please can you explain clearly exactly what feature you are requesting?

Thanks.

[GregTonoski]

There is the explanation by the example below.

Pre-condition:

1) "legal winner thank year wave sausage worth useful legal winner thank yellow" loaded as the mnemonic seed. It's binary representation: 01111111011111110111111101111111011111110111111101111111011111110111111101111111011111110111111101111111011111110111111101111111 1000

Step:

1) Click "Recalculate" after selecting the Seed XOR from the Bitcoin tool field.

Actual result:

"Seed 2 of 2" (randomly generated): "zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo wrong" 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 0101 (result of the XOR of the last 4 bits of the seeds here and in the pre-condition is: 1101. It doesn't match the value of the last 4 bits of the seed "XOR Result" which is: 0100 below). "XOR Result": "letter advice cage absurd amount doctor acoustic avoid letter advice cage above" 10000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000 0100.

Expected result:

"Seed 2 of 2" (randomly generated and under the condition that the last 4 out of 132 bits will result in valid SHA256 checksum of the "XOR Result"): "zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo zoo toe" 11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111110001 1100 "XOR Result": "letter advice cage absurd amount doctor acoustic avoid letter advice cage above" 10000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000100000001000000010000000 0100 (instead of calculating SHA256 checksum, user may XOR the last 4 out of 132 bits of the preceding seeds because the result is the same).

[SuperPhatArrow]

Thanks for this, I believe I understand you now. Let me try to repeat back in my own words to see if we are on the same page.

GregXOR (or whatever you want to call your invention!) is a subset of seedXOR where all the bits, including the checksums, can be calculated on paper without the need for checksum culculation & SHA256.

In order to do this, the user supplies a seed (part 1) and then instructs seed tool to find parts 2 & 3 (both being valid seeds) such that part 3 is the XOR of parts 1 & 2, including the checksum.

In order to find this combination, seed tool should, generate random bits for the words of part 2, generate a checksum and XOR parts 1 & 2. If part 3 is a valid seed, success, else first flip the optional last word bits and calculate a checksum then XOR again to generate a part 3. Test the validity of part 3 and if a valid checksum, success, else keep flipping bits as before.

With 12 words we have 128 valid last words, with 24 there are only 8, so we may not find a valid GregXOR on the first run. So we generate a new part 2 and repeat this process.

PROS:

1. Being able to brute force a valid GregXOR means you can do the calculation entirely on paper when you want to reconstitute 2 parts later to get a third.

CONS:

1. The reduction in entropy, particularly on 12 words, reduces your security.
2. There may be a lot of brute forcing to do to find a match and you are basically turning your browser into a miner-like machine to mine you the right combination of parts. While this is not infinitely recursive, it might take a while to find a match. If there are limited matches, this reduces the security as well, but probably in a similar way.

I'm interested to see what this is like though as it is an fascinating idea.

Have I describes this correctly in the way you meant?

[GregTonoski]

Thanks for the follow-up.

Yes, that's the accurate description of the idea.

[GregTonoski]

There is the reference implementation (in Bash shell): "https://github.com/GregTonoski/BIP39-XOR".