Randomly picking 24 words from the BIP39 wordlist

[pooya87]

I then compare them. I see they are the same. no mistakes were made. we know that with 100% certainty. No need for any checksum. The eyes are good enough.

The checksum is not meant for you and your eyes. It is meant for the application so that whenever a user enters the checksum incorrectly into that tool's textbox it can automatically detect if there were any mistakes in the input so that the application can inform the user that something is wrong.

[1714482600]

1714482600

[1714482600]

1714482600

[1714482600]

1714482600

[larry_vw_1955]

The checksum is not meant for you and your eyes. It is meant for the application so that whenever a user enters the checksum incorrectly into that tool's textbox it can automatically detect if there were any mistakes in the input so that the application can inform the user that something is wrong.

but we still need a way to make sure we wrote it down correctly. and you just admitted as much. since just by looking at 12 words, you can't tell whether there is any discrepancy in them or not.

also, they'll definitely know something is wrong whether the software detects it or not. when their balance doesn't show up.

[hosseinimr93]

but we still need a way to make sure we wrote it down correctly.

There's a very easy way for that. Double check (or triple check) what you wrote down.
You can also recover your wallet from the seed before sending any fund to that to make sure the seed phrase is correct and it generates the same addresses.

[PrimeNumber7]

The checksum is not meant for you and your eyes. It is meant for the application so that whenever a user enters the checksum incorrectly into that tool's textbox it can automatically detect if there were any mistakes in the input so that the application can inform the user that something is wrong.

but we still need a way to make sure we wrote it down correctly. and you just admitted as much. since just by looking at 12 words, you can't tell whether there is any discrepancy in them or not.

also, they'll definitely know something is wrong whether the software detects it or not. when their balance doesn't show up.

You seem to have made a solid argument against using paper wallets, particularly paper wallets in which the secret (seed) is written by hand.

to further counter your argument, it would be possible to manually check if the checksum is valid “by hand”.

[o_e_l_e_o]

First of all. It is not just a missing last word that has 128 possibilities. Every word has 128 possibilities if it is missing, assuming that no others are also wrong or missing.

That's not quite right. Only the last word has exactly 128 possibilities, since for every final seven bits of entropy the last word provides, there will be exactly one word out of the 16 possibilities which has the correct checksum. When swapping out any other word, since the checksum is already fixed, there will be 128 possibilities on average (as opposed to exactly 128 words), since you cannot predict exactly how many possibilities will hash to the already fixed checksum.

why? why is sha-256 an appropriate choice for a checksum? it was not designed for that purpose. all it has the ability to do is detect errors but not correct them right? so how is that appropriate? not being able to correct a certain minimal number of errors. it can do zero in that regard.

Arguably, you only want error detection and not error correction. The checksum used in Bech32 addresses can provide error correction, but no piece of wallet software implements it. The reason behind this is explained in BIP173. In short, you don't want an error to accidentally be corrected to the wrong address, resulting in loss of funds.

[larry_vw_1955]

Some wallet usually ask their user to re-enter partial or all generated 12/24 words from previous step of wallet creation.

that's not foolproof though. in fact, it's kind of worthless. just because you have 3 or 4 of the words correct doesn't mean you have all of them. i think it give people a false sense of security. plus lets be honest most people probably skip over that step if it's not required.  

There's a very easy way for that. Double check (or triple check) what you wrote down.

if it was that simple people wouldn't come on to this forum saying their seed phrase isnt "working". maybe they should use a computer printer to print it out that way they are guaranteed to not make any transcription mistakes. the probability of making a transcription error is much greater than any security risk that might occur by using a computer printer at home.

Arguably, you only want error detection and not error correction. ... In short, you don't want an error to accidentally be corrected to the wrong address, resulting in loss of funds.

well here is what they said:


This implements a BCH code that guarantees detection of any error affecting at most 4 characters and has less than a 1 in 109 chance of failing to detect more errors.

that is the part that sounds good. the part that sounds bad is the following:


Error correction

One of the properties of these BCH codes is that they can be used for error correction. An unfortunate side effect of error correction is that it erodes error detection: correction changes invalid inputs into valid inputs, but if more than a few errors were made then the valid input may not be the correct input. Use of an incorrect but valid input can cause funds to be lost irrecoverably. Because of this, implementations SHOULD NOT implement correction beyond potentially suggesting to the user where in the string an error might be found, without suggesting the correction to make.

being able to detect up to 4 characters that are in error sounds good but if it can't fix it too then i'm not sure how useful it is. might as well just use a simpler checksum mechanism. one that can't fix anything just detect.

You seem to have made a solid argument against using paper wallets, particularly paper wallets in which the secret (seed) is written by hand.

well if you read carefully, I said that you need to write it out twice. and then compare them visually to make sure they are the same thing. so it's not an argument against paper wallets that one might generate by rolling dice or flipping coins but you have to be REALLY careful.

[pooya87]

@larry_vw_1955
What you are forgetting is that adding any more error detection/correction algorithm in the seed phrase algorithms makes them that much more complicated and it could also increase the size of the final phrase. Complication is also not a good thing since it makes implementation harder and more error prone.

[larry_vw_1955]

@larry_vw_1955
What you are forgetting is that adding any more error detection/correction algorithm in the seed phrase algorithms makes them that much more complicated

you mean like the bech32 situation? it seems way more complicated than the sha256. why it needs to be, i don't know.

and it could also increase the size of the final phrase. Complication is also not a good thing since it makes implementation harder and more error prone.

you must have heard of the bech32 length extension mutation weakness  the tldr on that is that it was such a complicated thing that they couldn't foresee these type of issues in advance. not a good thing at all.

[o_e_l_e_o]

plus lets be honest most people probably skip over that step if it's not required.  

Exactly. Just like most people would skip over writing down their seed phrase twice like you suggest. They can't skip a hard coded checksum, however.

if it was that simple people wouldn't come on to this forum saying their seed phrase isnt "working".

And if checksums didn't exist, and someone comes saying their seed phrase isn't working, you have no idea if it is a problem with the seed phrase itself or if it is a problem with something they are doing with the seed phrase (passphrase, derivation path, etc.) By having a checksum, you can immediately narrow down the problem.

being able to detect up to 4 characters that are in error sounds good but if it can't fix it too then i'm not sure how useful it is.

Extremely useful. You don't want your wallet software accepting an incorrect address and allowing you to sign transactions to that incorrect address. And by showing you have an error, you know you've made a mistake in your process somewhere or have some malware and can re-examine your process before losing your coins to an incorrect address.

[pooya87]

you mean like the bech32 situation? it seems way more complicated than the sha256. why it needs to be, i don't know.

Bech32 is not really that complicated, in a way it is simpler to implement since it uses a multiple of 2 (32 as opposed to 58) so there is no need for an external library or a class like BigInteger for its computation.

you must have heard of the bech32 length extension mutation weakness  the tldr on that is that it was such a complicated thing that they couldn't foresee these type of issues in advance. not a good thing at all.

It is not really a serious thing considering all bitcoin addresses have been fixed length (P2WPKH and P2WSH and even the Taproot addresses). It also didn't happen because of "being complicated" it was a simple unforeseen case.

[odolvlobo]

@larry_vw_1955

If you strongly believe that you have a better method, then the best thing to do would be to publish a BIP so that everyone can see the merits of your proposal. Those who like your proposal will adopt it, and those who don't will not.

That's one of the beauties of open source development -- you can implement anything you want without the permission or approval of anyone else.

[larry_vw_1955]

Exactly. Just like most people would skip over writing down their seed phrase twice like you suggest. They can't skip a hard coded checksum, however.

yeah i guess that's true.

And if checksums didn't exist, and someone comes saying their seed phrase isn't working, you have no idea if it is a problem with the seed phrase itself or if it is a problem with something they are doing with the seed phrase (passphrase, derivation path, etc.) By having a checksum, you can immediately narrow down the problem.

Yeah I guess i didn't think about it that way. But it would be nice if important details like the derivation path was somehow possible to be encoded into the seed phrase. Because from what I seen alot of cases that's where the problem is. they don't know the derivation path. and if you don't know that, you don't know anything. so not only does someone need to store their seed, they need to store the derivation path along with it (and make sure they wrote that down correctly too). with that said though, i think electrum stores the derivation path so the user doesn't have to worry about it. so that's cool.

Extremely useful. You don't want your wallet software accepting an incorrect address and allowing you to sign transactions to that incorrect address.

no i would not want it doing that. but what if i entered something that wasn't my address and it actually passed the checksum? hopefully the probability of that is on the order of 1 in trillions or even more.
 

Bech32 is not really that complicated, in a way it is simpler to implement since it uses a multiple of 2 (32 as opposed to 58) so there is no need for an external library or a class like BigInteger for its computation.

so you've written a bech32 checksum tool? you must be a genius then.

If you strongly believe that you have a better method, then the best thing to do would be to publish a BIP so that everyone can see the merits of your proposal. Those who like your proposal will adopt it, and those who don't will not.

apparently a huge amount of computer cpu time was spent on optimizing bech32. to make it as efficient as possible. it's on a different level than sha256 but even so, i have no idea how it works. 

That's one of the beauties of open source development -- you can implement anything you want without the permission or approval of anyone else.

of course.

[o_e_l_e_o]

But it would be nice if important details like the derivation path was somehow possible to be encoded into the seed phrase.

As you point out, Electrum seed phrases do this. Basically, when Electrum generates a seed phrase, it then hashes it and checks if the hash starts with the correct version number. If not, it increments the entropy by 1 and tries again, until it reaches a seed phrase whose hash does start with the correct version number. That version number tells Electrum which script type and derivation path to use, which is why Electrum seed phrases are either legacy or segwit and will only ever recover one wallet, as opposed to BIP39 seed phrases which can use any script type at any derivation path and restore a near infinite number of wallets.

they need to store the derivation path along with it

A better option is for the majority of users to just stick to the BIP44/49/84 standards and not mess around with custom derivation paths unless they really understand what they are doing.

no i would not want it doing that. but what if i entered something that wasn't my address and it actually passed the checksum? hopefully the probability of that is on the order of 1 in trillions or even more.

For legacy addresses, the chance of an incorrect address with the correct checksum is 1 in 4,294,967,296. For segwit addresses, the checksum is guaranteed to detect any error effecting up to 4 characters, and has less than 1 in a billion chance of failing to detect more than that. So not quite 1 in trillions, but still incredibly safe.

[larry_vw_1955]

A better option is for the majority of users to just stick to the BIP44/49/84 standards and not mess around with custom derivation paths unless they really understand what they are doing.

the majority of users have to go with whatever their wallet software decided for them. and unfortunately, it's not always obvious what exact derivation path is being used. but that's probably the first question they should ask. and then if it's not as you stated, they need to write the derivation path down along with their seed phrase, might need another titanium plate to record that. but it's surely better than not being able to retrieve your money.

For legacy addresses, the chance of an incorrect address with the correct checksum is 1 in 4,294,967,296. For segwit addresses, the checksum is guaranteed to detect any error effecting up to 4 characters, and has less than 1 in a billion chance of failing to detect more than that. So not quite 1 in trillions, but still incredibly safe.

so there must have not been anyone ever come here on the forum who said they put in their address and sent money to it but then found out they made a typo and the money is sitting there on the blockchain...the probability of that happening is too small to have ever happened.  good to know.

[pooya87]

so you've written a bech32 checksum tool? you must be a genius then.

It's basically a simple for loop bro, it is not rocket science!

and unfortunately, it's not always obvious what exact derivation path is being used.

Wrong. Any decent open source wallet has that information either already documented or it is easily extractable from the code. For example we already know what derivation paths bitcoin core and electrum use which are 2 good open source wallets.
If it is not "obvious" what derivation path a wallet is using that is because it is closed source and something that should not be used in first place.

[o_e_l_e_o]

the majority of users have to go with whatever their wallet software decided for them. and unfortunately, it's not always obvious what exact derivation path is being used.

Yeah, I would echo what pooya87 has said above. If your wallet software is not clear which derivation path it is using, then you shouldn't be using that software, exactly because you will likely run in to problems trying to recover access to your coins on a different piece of software in the future. Stick to reputable open source wallet software and you will not run in to such problems.

they need to write the derivation path down along with their seed phrase, might need another titanium plate to record that.

This should really only be necessary if you are using a really weird derivation path, which as I said above, the vast majority of users should never do. There are tools out there which will scan the most common alternative derivation paths automatically for you in order to try to recover your coins. Electrum itself offers this functionality for BIP39 seed phrases.

so there must have not been anyone ever come here on the forum who said they put in their address and sent money to it but then found out they made a typo and the money is sitting there on the blockchain...the probability of that happening is too small to have ever happened.  good to know.

Not as far as I know. Any time someone has sent money to the wrong address it has either been they copied the entirely wrong address or they were subjected to clipboard malware, and did not bother to double check before hitting send.

[larry_vw_1955]

so you've written a bech32 checksum tool? you must be a genius then.

It's basically a simple for loop bro, it is not rocket science!

there's a vast difference between a 10 or 20 line for loop that you might come up with off the seat of your pants to sort a list and this thing the length of the code is not a barometer of how much knowledge is required to fully understand the algorithm.

Yeah, I would echo what pooya87 has said above. If your wallet software is not clear which derivation path it is using, then you shouldn't be using that software, exactly because you will likely run in to problems trying to recover access to your coins on a different piece of software in the future. Stick to reputable open source wallet software and you will not run in to such problems.

in an ideal world yes, i don't disagree to steer clear of wallet software that is not open source and fully documented. thats best practice.

Not as far as I know. Any time someone has sent money to the wrong address it has either been they copied the entirely wrong address or they were subjected to clipboard malware, and did not bother to double check before hitting send.

what about someone accidentally typing in the wrong 24 or 12 word seed phrase but it is still valid? what's the chances of that? hopefully that's in the same 1 in 4 billion probability area too. if not then...not good.

[larry_vw_1955]

Based on checksum length, the chance is 1 in 2^4 for 12 words and 1 in 2^8 for 24 words. If you want 1 in 4 billion chance, the checksum length should be 36-bit which equal 3.2727 4 words.

wait so it is useless as an error detection tool? any mistake you make in one of the words there's a 1 in 16/1 in 256 chance it will not raise any flag and be happy to let you use that set of words. if that's the case then i'm not sure what purpose it serves.

[pooya87]

wait so it is useless as an error detection tool? any mistake you make in one of the words there's a 1 in 16/1 in 256 chance it will not raise any flag and be happy to let you use that set of words. if that's the case then i'm not sure what purpose it serves.

Checksum in mnemonic algorithms serve more purpose than just error detection. For example in BIP39 it also works as padding since each word is 11 bits and 12 words would be 132 bits while it is easier to generate entropy that is multiple of 8-bit. And in Electrum they act as the version to announce the child address type that has to be derived and their derivation path.

[o_e_l_e_o]

It also serves to discourage people from just opening up the wordlist and picking 12 or 24 words they like the look of, which as we all know is an incredibly insecure way of generating a seed phrase, but is one that we see people discussing as a possibility over and over again.

With a seed phrase, the words themselves serve as a sort of checksum. For example, compare these two addresses which have 1 character swapped:

Code:

bc1qyt4n4qvg86y33qfa7zts0wa8kv6ls47kmuyw5e, bc1qyt4n4qvq86y33qfa7zts0wa8kv6ls47kmuyw5e

And now look at this seed phrase, which has the exact same character swap:

Code:

decorate cactus vivid amazing endorse banana pipe train lazy viable ceilinq suffer

It is significantly easier to immediately spot the mistake in the seed phrase than it is in the address.