Bitcoin Forum
May 07, 2024, 09:49:38 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Why Core does not allow to use words to "spawn" your wallet?  (Read 279 times)
takuma sato (OP)
Sr. Member
****
Offline Offline

Activity: 295
Merit: 425


View Profile
July 29, 2021, 07:14:05 PM
 #21

Im still not 100% sure as to why this idea was discarded in Core. I've read some other claims regarding how it was discarded because people may by accident and due lack of information use a non secure seed, for instance, removing words to make it easier to remember, thus compromising the security.

@achow101 posts here. Could you possibly explain this in detail?
1715118578
Hero Member
*
Offline Offline

Posts: 1715118578

View Profile Personal Message (Offline)

Ignore
1715118578
Reply with quote  #2

1715118578
Report to moderator
Make sure you back up your wallet regularly! Unlike a bank account, nobody can help you if you lose access to your BTC.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715118578
Hero Member
*
Offline Offline

Posts: 1715118578

View Profile Personal Message (Offline)

Ignore
1715118578
Reply with quote  #2

1715118578
Report to moderator
1715118578
Hero Member
*
Offline Offline

Posts: 1715118578

View Profile Personal Message (Offline)

Ignore
1715118578
Reply with quote  #2

1715118578
Report to moderator
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3388
Merit: 6631


Just writing some code


View Profile WWW
July 29, 2021, 11:51:00 PM
Merited by takuma sato (5)
 #22

I was not around when BIP 39 was first specified, so I cannot say why it was not implemented then, but I can speculate based on what I know. However I can say why it is still not implemented today.

Firstly, Bitcoin Core is an open source software where the developers work on things that they care about. There is no roadmap nor is there a project manager saying "go implement that". So if no developer wants to implement a feature, then the feature does not become implemented. So clearly, developers do not want to work on BIP 39. So we need to see why multiple independent developers do not want to implement BIP 39.

When BIP 39 first came out, Bitcoin Core had not yet implemented BIP 32, which is a prerequisite for using BIP 39. BIP 32 was first specified in 2012, but the Bitcoin Core wallet did not receive support for it until 4 years later in 2016. In that time, there had been multiple attempts to implement BIP 32, but those were much more complicated. What ended up being merged was the absolute bare minimum that could be considered BIP 32 support. The wallet was able to generate private keys deterministically, and that was about it. It did not allow users to set the BIP 32 seed, users could not import xprvs or xpubs, and users could not change the derivation path used. It ended up being this bare minimum and taking so long just for the bare minimum simply due to how the wallet is structured. It would take a lot of work to overhaul the wallet structure to actually support BIP 32 properly, so what we got was the absolute bare minimum, and that's what we have even till today, for the most part.

Only after BIP 32 was implemented could we start looking at BIP 39. The technical challenge post BIP 32 is not the big, although BIP 39 would still require significant changes to support. However by this time (in 2016), BIP 39 was already showing its weaknesses. Electrum used BIP 39 for some time, but they moved to their own mnemonic system (which is not really specified). One of the major issues of BIP 39 is that it is touted as a full wallet backup but fails to provide several key pieces of information. BIP 39 fails to provide the derivation paths used, and it fails to provide the type of scripts and addresses to use. The latter point was less evident prior to Segwit, but when Segwit was released in 2016, people began to realize the importance of specifying address types in backups.

People often point out the lack of version numbers in BIP 39, and usually this is referenced as a solution to the aforementioned derivation paths and address types. Personally, I don't think that versioning would help with that, but versioning would certainly help if there were improvements to BIP 39 such as using a different KDF.

Another frequently mentioned issue is the choice of KDF. The authors of BIP 39 chose to use PBKDF2, however this has long been considered to be a fairly weak KDF. I have heard some developers (of other wallets) indicate they don't want to use BIP 39 because of this, but I don't have a strong opinion on that.

There is also the fact that BIP 39 itself says that software should still accept mnemonics with invalid checksums, which is a really weird design decision to make. The checksum could definitely be better and the BIP should not be recommending that invalid checksums be basically ignored.

Lastly, the other main reason that Electrum moved away from BIP 39 was due to the requirement of fixed wordlists. In order for BIP 39 to generate the BIP 32 seed to use, it uses PBKDF2 on the mnemonic itself. This means that the mnemonic isn't really an encoding of the raw entropy used to generate it and that the same entropy used to create mnemonics with different wordlists (e.g. for other languages) would result in different wallets. This significantly reduces the portability and usability of BIP 39.

So with all of these shortcomings in mind, BIP 39 is not really the ideal single string wallet backup solution that people want, and so many developers feel like it is not worth it to invest the time to implement something that has been shown to be insufficient.

Now the question is what will we implement in lieu of BIP 39. This is something that I have been actively working on for the past several years. Pieter Wuille came up with the idea of strings of text called Output Script Descriptors which describe everything needed for a wallet to actually regenerate all of its keys and addresses. Unlike BIP 39, descriptors explicitly specifies the type of addresses (output scripts really, hence the name) to generate. They also explicitly provide the BIP 32 derivation paths. These two facts resolve the two major complains with BIP 39 - the lack of derivation paths , and the lack of address types. Furthermore, descriptors can be extended in the future with new types of descriptors. This can be done easily and was recently done to add taproot support. Bitcoin Core's wallet was completely overhauled so that we could use these descriptors as the basis of the wallet itself.

Currently, descriptors are not like BIP 39 in that they are much longer and aren't a mnemonic. I intend on proposing a generic mnemonic scheme which would allow for descriptors to be represented as a mnemonic, but that's still a ways off. There is still work to be done with descriptors themselves. BIP 39 is also insufficient for a generic mnemonic scheme since the way it is specified is really specific to entropy and generating a random seed for use in something like BIP 32. We would have to make a wholly new mnemonic scheme.

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!