search

iancoleman / bip39

A web tool for converting BIP39 mnemonic codes
https://iancoleman.io/bip39/
MIT License
3.52k stars 1.44k forks source link

[Suggestion] Transparency and customization of the coin address derivation process via network parameters #398

Open scscgit opened 4 years ago

scscgit commented 4 years ago

I would like to formally propose an intention towards increasing the transparency of the cryptocurrency address derivation process (from either BIP32 keys or private/public keys). There are two separate issues:

This is a follow up to some ideas mentioned in and after my https://github.com/iancoleman/bip39/issues/378#issuecomment-561595912. My idea is that this tool is slowly gaining the responsibility over teaching the basic guidelines of how the wallets work, including it being the only "proper open-source and offline" tool to derive, and also generate (using a custom entropy with the option of not trusting any single RNG - e.g. my idea is to XOR multiple providers yourself) all of the keys required to operate and backup wallets, using the HD best practices (which also enables sharing a single seed to be used for multiple coins - though this idea doesn't seem to be promoted, because after all, importing an important seed to a third party wallet app isn't intrinsically safe - maybe unless you use a hardened child key directly, which doesn't seem to be advised either). This project is even referenced in The Bitcoin Book: Mastering Bitcoin as a de-facto standard solution.

As far as I know, there are two separate concerns when considering the usage of a new coin (I'm not an expert, so I'm looking forward to a confirmation), and the user should be able to completely verify all of them (e.g. via official coin documentation) without trusting any third party (alternatively, they can do a dry run to test both public and private keys of some low-value wallet using a wallet app):

The second requirement is straightforward, but this also shows the ever-increasing need to consider the first concern. For example, there's a SmartCash coin based on Keccak (SHA-3). They have made their own fork of this project at github.com/xdustinface/bip39-smart, which is also hosted at hdwallet.smartcash.cc or hdwallet.dustinface.me. After a Discord discussion of the option to back-integrate their project, I've found out that it's not a simple matter of changing the network parameters, as they have their own JavaScript to derive this address. Thus, I was thinking that this coin could serve as a test to validate both of my requirements.

Considering that it could be dangerous to back-integrate random third party scripts in the future though, I also have one more question: is there a way to sandbox the script such that, for example, it cannot access anything but a single Public Key? I'm sure some people would appreciate the option to maximize the security, even if only for explicitly manual purposes (I'm sure the well known algorithms will need to be integrated anyway).

Thanks for your time, and please correct me if I'm missing some easier solution :)

I'll also provide some random references for people interested in this topic, as I had to spend a great deal of time before having found out that it's not as intuitive as it seems, and there's no starting point:

iancoleman commented 4 years ago

it's not a simple matter of changing the network parameters, as they have their own JavaScript to derive this address.

See ripple, ethereum, stellar and others in libs directory for others that have this issue and have found ways to solve it.

Generally I'm happy to include third party libraries, since the npm and github reporting of affected versions is good.

it could be dangerous to back-integrate random third party scripts in the future

Yes I have always felt this, so I'm very open to ideas around how to improve this.

is there a way to sandbox the script such that, for example, it cannot access anything but a single Public Key?

Not that I know of.

I'm sure some people would appreciate the option to maximize the security

From my perspective this comes from the surrounding environment (OS, browser, offline, memory wipe on reboot etc). The tool can never really be fully trusted since it's extremely difficult to audit the entire codebase and the entire toolchain.

As a general comment I agree it would be good to streamline the process of adding new networks.

It may also be possible to allow users to add their own custom parameters in the UI but I feel that's a last ditch thing. My feeling is if a coin community can't put in the effort to submit a PR they're probably not a community that should be using this tool.

scscgit commented 4 years ago

Personally I'd really prefer the option to use the custom parameters, mainly because I feel that nothing should be a black box when it comes to cryptocurrencies. I know it shouldn't really be your responsibility, but it's exactly the consequence of the cryptocurrency community looking at such transparency as a last ditch thing :P Even if the coin is already supported, I'd still prefer to have the option of entering its parameters myself. There's also the motivation to (subconsciously) educate users, because there's (generally in software) currently a dangerous trend of hiding any real "issues" along with vital facts, and forcing inexperienced users to use inferior workflows as a default, so they don't even know what they're doing. I've hoped in evolution of cryptocurrencies in the opposite way, such that it'd be easier for example to use cold wallets to sign, or even create transactions, and use open-source tools to verify and transmit the tx without ever exposing the seed to them... Nowadays you're lucky if a client works offline at all.

Either way, exposing the network parameters is only the first step, because it would make using private/public keys way more obvious. For example, if they have some hardened derivation key, users should be able to conceptually understand which keys are able to be used to derive addresses (it should be easy if they know all of the coin parameters), and which of them could be used to manipulate with their wallet (e.g. as long as official wallets use a WIF format, it would be nice to provide transformation steps at least for well known coins, though the perfect solution would be if the wallet apps supported private keys directly). I could also imagine various private (blockchain) projects, or experimental projects that are currently under development. Last but not least, there are projects just like this SmartCash, which don't really care about being back-integrated, because they don't share (my) transparency ideals, and their viewpoint is this simple: "Most users will probably use the web version." I believe there'll always be many projects that prioritize use-cases of masses, and will rely on their own implementations, which nobody will ever complain about. That's why I believe it should be up to users if they want an absolute security, and not up to the good will and free time of developers of the coin :)

When it comes to integrating algorithms like Keccak, if it isn't really reasonable to provide any sandbox, then any simple deterministic PR guideline could be enough (such that even people like me, who haven't worked with Keccak at all, will find it easy to merge a third party project). As long as the algorithm is a public parameter though, I have an idea that the JS could be at least included dynamically (e.g. after refreshing a page) and unloaded after switching to a different algorithm. This could even enable a workflow of copying a public key, loading a script, and translating the key to an address. Though such a paranoid approach may be an overkill, after all, this script is supposed to be used offline :) But I think that exposing algorithms via single \<select> tag wouldn't have any downsides. I hope this can be easy to implement in a near future :)

iancoleman commented 4 years ago

Some other things I want to add (just making a note for myself for later) regarding quality control