Topic: Decentralized Wallet (Read 1397 times)

It's ok, this is helping me clarify the concept for myself as well.

I'm focused on recovery of wallet information rather than explicit storage of the wallet.dat file. I agree that having the private keys in the cloud is redundant, but there's a subtle difference in restoring wallet information - the deterministic method relies primarily on an algorithm while distributing keys relies mainly on the network. The former uses a passcode to reconstruct the wallet while the latter uses a tag/passcode combination to reconstitute it; rebuilding vs. unlocking. The end result is the same - the wallet can be recovered.

I really like the deterministic approach - IMO it's an essential feature for integration into the main Bitcoin client, though I don't see how it can cope with rapidly-changing contents. If that's true, it may be best suited for stable wallets with a low frequency of disparate transactions (savings account). Searching for tags/keys would still require downloading the blockchain, but all of the relevant information can be obtained. That might be more appropriate for protecting against loss of a high-frequency wallet (checking account).

Part of my reasoning is that I trust the Bitcoin network because of its structure. Even doing everything carefully, hosting a wallet introduces at least one new potential point of failure (the entire Bitcoin network could fail, but that's far less likely) with numerous other trust factors to consider.

Minimum requirements to recover wallet information (to my knowledge):

Method	|Wallet.dat	|Determ. Server	|BTC Network
Encrypted Wallet	| X	|	|
Deterministic Algo	|	| X	|
Distributed Keys	|	|	| X

I'm sorry, I still don't understand. In the super-thin client approach (webcoin,bccapi,electrum) the wallet simply contains keys and nothing else. Putting that into "the cloud" does not make a whole lot of sense. You have to encrypt the keys with .... more keys. If you really want your keys to be hosted elsewhere, a BitBank is the way to go as they can put whatever security you want (passwords, 2-factor auth, etc) in front of them.

In lightweight but not super-lightweight clients like with BitCoinJ, you need the transactions in the wallet as well (technically just the outputs). That isn't exactly a huge burden, whilst today you have to download whole blocks to find them, in future the filtering could easily be performed by the remote nodes themselves.

Very nice work on Electrum. It would be great to see something similar to Bitcoin Spinner using it eventually. The fully-open nature is appealing as well.

Slush mentioned implementation of a 'wallet in the cloud' - I haven't looked at the code yet, but I assume the server must be present for wallet reconstruction?


With Electrum, ThomasV noted the private keys are not stored in the blockchain. With the proposal, the private keys are encrypted and stored in the blockchain.

To retrieve the keys, the blockchain would need to be searched through to find associated tags, then decrypted for use. It's far more computationally intensive for the node, but doesn't rely on a dedicated Electrum server - only the Bitcoin network. A trade-off is the potential for lessened security. The two approaches mostly overlap in the functionality provided.




It would probably make more sense when thinking of a contract as a URL, so information about a trust might be located at https://durangofamilytrust.bit/. Then looking for the transactions associated with that trust could be done by searching for a hash formed from the URL. If the transactions have been appropriately tagged by the trust administration and you've used the correct hashing method on the URL, the relevant transactions will be found in the blockchain. This might be useful for third-party audit.

In this manner, as long as the Bitcoin network is functioning, the assets can be located and/or retrieved. No need for access to the Namecoin wallet - anything could be designated as the tag (the example could've been a .com instead). I just like figuring out ways of using decentralized systems in conjunction.


Yes, I wasn't too clear about that. It's generally an alternative to the server-based wallet-management technique used by BCCAPI and Electrum.

Using the blockchain to store encrypted private keys with their associated addresses would allow for a 'wallet in the cloud' using the Bitcoin network instead of self-hosted or managed solutions. It is also possible that thin clients could engage in limited activities without needing a dedicated server. If the tag/key pair is used and the owner is unable to update security methods (individual died?), it could be possible to recover lost coins.

Initially, I had thought using the comment field might work, but that doesn't seem feasible at present. If it were, this functionality could be implemented exclusively in a client rather than at the protocol level. Again, use of the feature would be entirely optional, though I've been interested in such a capability and keep seeing the issue brought up by others. Since the debacle of MyBitcoin, it's been difficult to garner much faith in hosted solutions.

What problem are you trying to solve here? I don't understand the point of this proposal.

Hey buddy, can I borrow a Namecoin? I don't have my wallet.
It wouldn't do much good if you don't have your namecoin wallet either. That's why I like the idea of physical bitcoin for walking around money.
I like the concept of this idea. It could serve as a decentralized vault. Namecoin will have valuable uses one day.

Good idea for recover deleted wallet.

the private keys are derived from a 128 bits seed, using a deterministic algorithm.
see http://en.wikipedia.org/wiki/PBKDF2

the seed is not stored in the blockchain. it is stored by the user.

There's a couple of things I don't understand.

1. Are you saying that we can create transactions with a message and that message could be an necrypted private key. Therefore we store private keys in the blockchain ?

2. If that's the case I didn't understand how we would retrieve the keys.

what I do not like about BCCAPI is that it is not really open source:
only the client is open source, the server is controlled by a single individual.

check Electrum: http://ecdsa.org/electrum/
it allows you to store your wallet with a 12-words passphrase

After searching through the forums and other sources, the closest to a realistic decentralized/distributed wallet concept is one from casascius. While it's an excellent method, it is not practical for more than a handful of addresses. Another close solution is the BCCAPI library created by Jan that aims at thin clients and could work in a complementary fashion.

The Bitcoin system's use of a locally-stored wallet.dat file can be supplemented with addition of the accompanying key for each respective address. In the protocol specification, the message structure payload should be able to have an encrypted private key appended to it without adverse effects, that I can see. Since the transactions will be in the blockchain, they will obviously be accessible by all.

This is potentially dangerous, but risks can be largely mitigated by using various methods (salting, n-factor authentication, etc) and it would also provide a means of recovering lost transactions should a wallet.dat become irreparably corrupted or otherwise unavailable. This functionality need not be used and can remain fully optional in any supporting nodes, as this is more an extension to the protocol than a radical modification. If the security method needs to be changed, all that's required is a transaction.

A password or other signing method is necessary to appropriately secure the address-associated private key. It will also be necessary to have a means of identifying which transactions are the owner's - tagged somehow. This could be done by attaching the hash of an owner-specified phrase or keyword with an appended or prepended counter, incremented for each separate transaction (replacement is another concern). To distinguish between the end of the Bitcoin address (which can vary) and the key/tag pair, a character separator would be needed. For argument, the pipe '|' symbol will be used.

The order of key/tag insertion can be made significant as well, such that tags may come before keys. During retrieval, the blockchain can be searched using the tag string hashes. Once a tag is located, the remaining content after the separator (private key) is decrypted. The key and/or tag can be encoded using various methods. Mass utilization would increase the size of the blockchain but not to an unmanageable level, especially with continuing advances in data storage, processing and networking speed. Finding the transactions occurs only on the node, using a local copy of the blockchain.

Example:


There are more effective ways of achieving secure results; these examples are just meant to outline the process. It also doesn't fully eliminate the potential for lost coins/transactions. In the absence of wallet.dat the owner must commit to memory both the encrypted key's password/signature as well as the tag phrase/string. If any obscure or non-standard methods of encoding or encrypting are used, those must all be recalled.

Responsibility remains squarely with the owner; this affords another option. The most important aspect is not necessarily the password/signature/phrase/tag/etc - the combination of methods used to secure the private key may be more critical.

There are no major backward-compatibility or integration issues that I can see with this approach, but obviously more eyes might find something I've overlooked. Any insight or advice would be appreciated.

An interesting potential for if/when namecoin matures might be using a NMC address as a tag, especially when considering the possibility of Bitcoin-based contracts...