24 word seed question : is splitting it in half dangerous?

[NotATether]

In both instances, you still need to bruteforce 12 words to get the actual seed phrase... So, you're working with a 2028^12 search space... which is 5444517870735015415413993718908291383296.

I don't think we can call it the same. If the total words are 12 and you are missing all 12 then the search space is 2¹²⁸. But if the total words are 24 and you have 12 then you still have half of the entropy and depending on which half it could be a lot simpler. For example if you have the second half of the words then the bulk of the search space is suddenly reduced by roughly 94% because of the checksum.

I think this is incorrect.

When someone knows the last 12 words of the 24 phrase, they know 132 bits. But since 8 bits are for the checksum, they gain only 124 bits of information. So, there are still 256 - 124 = 132 bits left to attack. Now, the brute attacker knows the checksum, so we need to understand how many combinations among the 2^132 generate the same checksum: those that don't can be immediately discarded. The combinations that yield the same CS are about 2^124 (2^132 / 2^8).
Instead for an unknown 12-word phrase, the search space is 2^128. So, the former is slightly less secure, but negligibly so.

That's actually assuming the checksum is 8 bits long. It doesn't necessarily have to be, as the checksum length can be set to an arbitrary value that satisfies the formula in https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#user-content-Generating_the_mnemonic (where MS=24 is the length of the resulting mnemonic phrase). But as far as I know, all of the wallets I know of use 8 bit checksums, and I haven't heard of a situation where a larger checksum length might be required to prevent checksum collision.

*OK, I realized that even the checksum and thereby the mnemonic phrase length is constrained by the entropy, so this doesn't actually hold, but it does raise the question on whether 8 bits of entropy will be enough to prevent a checksum collision from happening, particularly in a mass-adoption scenario where trillions of wallets are generated per day by businesses, software, apps, etc.

Then there is always the possibility of writing gibberish words in front of the mnemonic to make it appear like it's longer & non-standard.

[1715230377]

1715230377

[1715230377]

1715230377

[1715230377]

1715230377

[1715230377]

1715230377

[1715230377]

1715230377

[elliptic joe]

In both instances, you still need to bruteforce 12 words to get the actual seed phrase... So, you're working with a 2028^12 search space... which is 5444517870735015415413993718908291383296.

I don't think we can call it the same. If the total words are 12 and you are missing all 12 then the search space is 2¹²⁸. But if the total words are 24 and you have 12 then you still have half of the entropy and depending on which half it could be a lot simpler. For example if you have the second half of the words then the bulk of the search space is suddenly reduced by roughly 94% because of the checksum.

I think this is incorrect.

When someone knows the last 12 words of the 24 phrase, they know 132 bits. But since 8 bits are for the checksum, they gain only 124 bits of information. So, there are still 256 - 124 = 132 bits left to attack. Now, the brute attacker knows the checksum, so we need to understand how many combinations among the 2^132 generate the same checksum: those that don't can be immediately discarded. The combinations that yield the same CS are about 2^124 (2^132 / 2^8).
Instead for an unknown 12-word phrase, the search space is 2^128. So, the former is slightly less secure, but negligibly so.

That's actually assuming the checksum is 8 bits long. It doesn't necessarily have to be, as the checksum length can be set to an arbitrary value that satisfies the formula in https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#user-content-Generating_the_mnemonic (where MS=24 is the length of the resulting mnemonic phrase). But as far as I know, all of the wallets I know of use 8 bit checksums, and I haven't heard of a situation where a larger checksum length might be required to prevent checksum collision.

*OK, I realized that even the checksum and thereby the mnemonic phrase length is constrained by the entropy, so this doesn't actually hold, but it does raise the question on whether 8 bits of entropy will be enough to prevent a checksum collision from happening, particularly in a mass-adoption scenario where trillions of wallets are generated per day by businesses, software, apps, etc.

Then there is always the possibility of writing gibberish words in front of the mnemonic to make it appear like it's longer & non-standard.

I don't understand this.
In the documentation it is clearly written: 256 bit of entropy + 8 bit of CS.

I don't even understand why you talk of CS collision... CS collision is sure: given a known CS, there are about 2^248 combo (2^256 / 2^8) that give the same CS.

[NotATether]

I don't even understand why you talk of CS collision... CS collision is sure: given a known CS, there are about 2^248 combo (2^256 / 2^8) that give the same CS.

The reason I brought it up is that obtaining the second half of the mnemonic with a hypothetically larger seed would reduce its usefulness (while making the first half more useful), but then I realized that the CS is not an independent variable which can be modified without changing the entropy.