Bitcoin Wiki - User contributions [en]

Vanitygen

2012-08-20T05:18:48Z

Doca: /* Expected keysearch rate */ see also Fistbits

Vanitygen is a command-line vanity bitcoin address generator.

If you're tired of the random, cryptic addresses generated by regular bitcoin clients, you can use vanitygen to create a more personalized address. Add unique flair when you tell people to send bitcoins to 1stDownqyMHHqnDPRSfiZ5GXJ8Gk9dbjL. Alternatively, vanitygen can be used to generate random addresses offline.

Vanitygen accepts as input a pattern, or list of patterns to search for, and produces a list of addresses and private keys. Vanitygen's search is probabilistic, and the amount of time required to find a given pattern depends on how complex the pattern is, the speed of your computer, and whether you get lucky.

The example below illustrates a session of vanitygen. It is typical, and took about 10 sec to finish, using my Core 2 Duo E6600 CPU on x86-64 Linux:
<syntaxhighlight lang="bash">
$ ./vanitygen 1Boat
Difficulty: 4476342
Pattern: 1Boat
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS
</syntaxhighlight>

Vanitygen includes components to perform address searching on your CPU (vanitygen) and your OpenCL-compatible GPU (oclvanitygen). Both can be built from source, and both are included in the Windows binary package. Also included is oclvanityminer, the vanity address mining client. Oclvanityminer can be used to automatically claim bounties on sites such as ThePiachu's vanity pool.

Current version: 0.20

Windows x86+x64 binaries [https://github.com/downloads/samr7/vanitygen/vanitygen-0.20-win.zip here]. PGP signature [http://insight.gotdns.org/~samr7/vanitygen-0.20-win.zip.asc here].

Get the source from [https://github.com/samr7/vanitygen GitHub]. Includes Makefiles for Linux and Mac OS X.

Main discussion at [https://bitcointalk.org/index.php?topic=25804.0 BitCoinTalk]

== Expected keysearch rate ==
Main article: [[Vanitygen keysearch rate]]

What key search rate can I expect from hardware X?

Detailed list forthcoming. Some ballpark estimates are listed below.

Dual-core desktop CPUs, 32-bit mode: 100-250 Kkey/s.
Dual-core desktop CPUs, 64-bit mode: 150-450 Kkey/s.
Quad-core desktop CPUs, 32-bit mode: 200-400 Kkey/s.
Quad-core desktop CPUs, 64-bit mode: 300-750 Kkey/s.
NVIDIA GT200 GPUs: up to 6.5 Mkey/s
AMD Radeon 58XX, 68XX GPUs: up to 23.5 Mkey/s.
AMD Radeon 69XX GPUs: up to 19.5 Mkey/s.

As vanitygen performs a lot of large integer arithmetic, running it in 64-bit mode makes a huge difference in key search rate, easily a 50% improvement over 32-bit mode. If you are using a 64-bit edition of Windows, and not using a GPU, be sure to use vanitygen64.exe.

Radeon 58XX outperforms Radeon 69XX by a very comfortable margin. Oclvanitygen is sensitive to integer multiply throughput, and Radeon 58XX can multiply concurrently with other operations. At similar clocks, a hobbled Radeon 5830 will outperform a Radeon 6970.

In custom builds, CPU performance will be less than expected if the OpenSSL library is an older version (<1.0.0d) or is not built with the appropriate optimizations enabled.

== See also ==
* [[Firstbits]]

Firstbits

2012-08-20T05:17:32Z

Doca: reference to vanitygen

'''Firstbits''' refers to the practice of abbreviating a [[Bitcoin address]] such that only enough of the initial characters of the address are given so that the full address can be identified from the [[block chain]]. It also refers to the website http://www.Firstbits.com.

The term Firstbits was popularized by the Firstbits website, which was provided with the intent of a "Bitcoin address shortener", working similar to a URL shortener. Firstbits.com performs a lookup service, giving the full address from the block chain from the initial portion of an address. Anyone with access to a complete copy of the block chain can independently perform the same lookup done by Firstbits.com.

Any time a Bitcoin address is used for transactional purposes and appears in the block chain, its firstbits - or the prefix that uniquely identifies that address within the block chain - are considered assigned at that time. If another address is created and used with the same prefix at a later time, the firstbits of that new address will be at least one character longer, as the shorter prefix remains reserved for the address that used it first. No action on the part of any user is required for firstbits to be assigned - any transaction activity (receiving or sending) for an address for the first time results in firstbits becoming automatically assigned.

Unlike Bitcoin addresses, firstbits are deemed assigned in a '''case-insensitive''' manner.

The firstbits of the very first address to be used by [[Satoshi]] in the [[genesis block]] of the [[block chain]] will have been '''"1"'''.

==Criticism==
Firstbits is generally considered to be a bad idea because it encourages transaction spam.
This position is held by most, if not all, of Bitcoin developers.{{Citation needed}}

== See also ==
* [[vanitygen]]

Vanitygen keysearch rate

2012-08-20T04:55:01Z

Doca: initial real test data

What key search rate can I expect from hardware X?

Detailed list forthcoming. Some ballpark estimates are listed below.

Dual-core desktop CPUs, 32-bit mode: 100-250 Kkey/s.
Dual-core desktop CPUs, 64-bit mode: 150-450 Kkey/s.
Quad-core desktop CPUs, 32-bit mode: 200-400 Kkey/s.
Quad-core desktop CPUs, 64-bit mode: 300-750 Kkey/s.
NVIDIA GT200 GPUs: up to 6.5 Mkey/s
AMD Radeon 58XX, 68XX GPUs: up to 23.5 Mkey/s.
AMD Radeon 69XX GPUs: up to 19.5 Mkey/s.

As [[vanitygen]] performs a lot of large integer arithmetic, running it in 64-bit mode makes a huge difference in key search rate, easily a 50% improvement over 32-bit mode. If you are using a 64-bit edition of Windows, and not using a GPU, be sure to use vanitygen64.exe.

Radeon 58XX outperforms Radeon 69XX by a very comfortable margin. Oclvanitygen is sensitive to integer multiply throughput, and Radeon 58XX can multiply concurrently with other operations. At similar clocks, a hobbled Radeon 5830 will outperform a Radeon 6970.

In custom builds, CPU performance will be less than expected if the OpenSSL library is an older version (<1.0.0d) or is not built with the appropriate optimizations enabled.

== Keysearch Rates ==
{| class="wikitable sortable"
|-
! CPU !! GPU !! keys/s !! Comment
|-
| Core2 Duo 6600 || nVidia GTX 285 || 3.5 Mkey/s || 100% CPU / 90% GPU [https://bitcointalk.org/index.php?topic=25804.msg378114#msg378114]
|-
| Sempron 140 || AMD 5830 || 5.5 Mkey/s || 100% CPU / 60% GPU [https://bitcointalk.org/index.php?topic=25804.msg378114#msg378114]
|-
| Core i5 750 @2.67 GHz || nVidia GTS 250 || 1.54 Mkey/s || 110% CPU [https://bitcointalk.org/index.php?topic=25804.msg378820#msg378820]
|}

Vanitygen keysearch rate

2012-08-20T04:20:53Z

Doca: backlink to vanitygen

Vanitygen keysearch rate

2012-08-20T02:32:59Z

Doca: initial

Vanitygen

2012-08-20T02:32:32Z

Doca: /* Expected keysearch rate */ typo corrected

Vanitygen

2012-08-20T02:32:02Z

Doca: /* Expected keysearch rate */ reference to vanitygen keysearch rate

Vanitygen is a command-line vanity bitcoin address generator.

If you're tired of the random, cryptic addresses generated by regular bitcoin clients, you can use vanitygen to create a more personalized address. Add unique flair when you tell people to send bitcoins to 1stDownqyMHHqnDPRSfiZ5GXJ8Gk9dbjL. Alternatively, vanitygen can be used to generate random addresses offline.

Vanitygen accepts as input a pattern, or list of patterns to search for, and produces a list of addresses and private keys. Vanitygen's search is probabilistic, and the amount of time required to find a given pattern depends on how complex the pattern is, the speed of your computer, and whether you get lucky.

The example below illustrates a session of vanitygen. It is typical, and took about 10 sec to finish, using my Core 2 Duo E6600 CPU on x86-64 Linux:
<syntaxhighlight lang="bash">
$ ./vanitygen 1Boat
Difficulty: 4476342
Pattern: 1Boat
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS
</syntaxhighlight>

Vanitygen includes components to perform address searching on your CPU (vanitygen) and your OpenCL-compatible GPU (oclvanitygen). Both can be built from source, and both are included in the Windows binary package. Also included is oclvanityminer, the vanity address mining client. Oclvanityminer can be used to automatically claim bounties on sites such as ThePiachu's vanity pool.

Current version: 0.20

Windows x86+x64 binaries [https://github.com/downloads/samr7/vanitygen/vanitygen-0.20-win.zip here]. PGP signature [http://insight.gotdns.org/~samr7/vanitygen-0.20-win.zip.asc here].

Get the source from [https://github.com/samr7/vanitygen GitHub]. Includes Makefiles for Linux and Mac OS X.

Main discussion at [https://bitcointalk.org/index.php?topic=25804.0 BitCoinTalk]

== Expected keysearch rate ==
Main article: [Vanitygen keysearch rate]

What key search rate can I expect from hardware X?

Detailed list forthcoming. Some ballpark estimates are listed below.

Dual-core desktop CPUs, 32-bit mode: 100-250 Kkey/s.
Dual-core desktop CPUs, 64-bit mode: 150-450 Kkey/s.
Quad-core desktop CPUs, 32-bit mode: 200-400 Kkey/s.
Quad-core desktop CPUs, 64-bit mode: 300-750 Kkey/s.
NVIDIA GT200 GPUs: up to 6.5 Mkey/s
AMD Radeon 58XX, 68XX GPUs: up to 23.5 Mkey/s.
AMD Radeon 69XX GPUs: up to 19.5 Mkey/s.

As vanitygen performs a lot of large integer arithmetic, running it in 64-bit mode makes a huge difference in key search rate, easily a 50% improvement over 32-bit mode. If you are using a 64-bit edition of Windows, and not using a GPU, be sure to use vanitygen64.exe.

Radeon 58XX outperforms Radeon 69XX by a very comfortable margin. Oclvanitygen is sensitive to integer multiply throughput, and Radeon 58XX can multiply concurrently with other operations. At similar clocks, a hobbled Radeon 5830 will outperform a Radeon 6970.

In custom builds, CPU performance will be less than expected if the OpenSSL library is an older version (<1.0.0d) or is not built with the appropriate optimizations enabled.

Vanitygen

2012-08-20T01:13:00Z

Doca: keysearch rate

Vanitygen is a command-line vanity bitcoin address generator.

If you're tired of the random, cryptic addresses generated by regular bitcoin clients, you can use vanitygen to create a more personalized address. Add unique flair when you tell people to send bitcoins to 1stDownqyMHHqnDPRSfiZ5GXJ8Gk9dbjL. Alternatively, vanitygen can be used to generate random addresses offline.

Vanitygen accepts as input a pattern, or list of patterns to search for, and produces a list of addresses and private keys. Vanitygen's search is probabilistic, and the amount of time required to find a given pattern depends on how complex the pattern is, the speed of your computer, and whether you get lucky.

The example below illustrates a session of vanitygen. It is typical, and took about 10 sec to finish, using my Core 2 Duo E6600 CPU on x86-64 Linux:
<syntaxhighlight lang="bash">
$ ./vanitygen 1Boat
Difficulty: 4476342
Pattern: 1Boat
Address: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
Privkey: 5J4XJRyLVgzbXEgh8VNi4qovLzxRftzMd8a18KkdXv4EqAwX3tS
</syntaxhighlight>

Vanitygen includes components to perform address searching on your CPU (vanitygen) and your OpenCL-compatible GPU (oclvanitygen). Both can be built from source, and both are included in the Windows binary package. Also included is oclvanityminer, the vanity address mining client. Oclvanityminer can be used to automatically claim bounties on sites such as ThePiachu's vanity pool.

Current version: 0.20

Windows x86+x64 binaries [https://github.com/downloads/samr7/vanitygen/vanitygen-0.20-win.zip here]. PGP signature [http://insight.gotdns.org/~samr7/vanitygen-0.20-win.zip.asc here].

Get the source from [https://github.com/samr7/vanitygen GitHub]. Includes Makefiles for Linux and Mac OS X.

Main discussion at [https://bitcointalk.org/index.php?topic=25804.0 BitCoinTalk]

== Expected keysearch rate ==
What key search rate can I expect from hardware X?

Detailed list forthcoming. Some ballpark estimates are listed below.

Dual-core desktop CPUs, 32-bit mode: 100-250 Kkey/s.
Dual-core desktop CPUs, 64-bit mode: 150-450 Kkey/s.
Quad-core desktop CPUs, 32-bit mode: 200-400 Kkey/s.
Quad-core desktop CPUs, 64-bit mode: 300-750 Kkey/s.
NVIDIA GT200 GPUs: up to 6.5 Mkey/s
AMD Radeon 58XX, 68XX GPUs: up to 23.5 Mkey/s.
AMD Radeon 69XX GPUs: up to 19.5 Mkey/s.

As vanitygen performs a lot of large integer arithmetic, running it in 64-bit mode makes a huge difference in key search rate, easily a 50% improvement over 32-bit mode. If you are using a 64-bit edition of Windows, and not using a GPU, be sure to use vanitygen64.exe.

Radeon 58XX outperforms Radeon 69XX by a very comfortable margin. Oclvanitygen is sensitive to integer multiply throughput, and Radeon 58XX can multiply concurrently with other operations. At similar clocks, a hobbled Radeon 5830 will outperform a Radeon 6970.

In custom builds, CPU performance will be less than expected if the OpenSSL library is an older version (<1.0.0d) or is not built with the appropriate optimizations enabled.

Vanitygen

2012-08-20T01:10:28Z

Doca: links to windows binaries, PGP signature, GitHub repository

Armory

2012-08-20T01:06:23Z

Doca: /* Features */ vanitygen link

An open-source, python-based, wallet-management application for the Bitcoin network.

At the alpha-level stage, Armory is a proof-of-concept release. It is very resource-intensive and thus will not be usable by everyone. The beta version of the project is being crowdfunded<ref>[http://www.rockethub.com/projects/6056-armory-bitcoin-development-funding Armory Bitcoin Development Funding]</ref>.

Available for Windows and Linux. Armory can be built for OS X but does not (yet) have OS X binaries.

Armory is licensed under the AGPL.

==Features==

* Encrypted wallet (optional)
* Maintain offline wallets for 100% security from online attackers.
* Import addresses created with [[vanitygen|VanityGen]] or sweep funds from Casascius physical Bitcoins.
* Toggle between “Standard” and “Advanced” modes to guarantee an appropriate set of options and information.
And more -- see the [http://bitcointalk.org/index.php?topic=56424.0 project's forum thread] for full details.

==History==

The Armory project was announced January 3rd, 2012<ref>[http://bitcointalk.org/index.php?topic=56424.0 Armory - The most advanced Bitcoin Client in existence!]</ref>.

==See Also==

* [[Thin Client Security]]

==External Links==

* [http://bitcoinarmory.com Amory]] Project page

==References==
<references />

[[Category:Clients]]
[[Category:Open Source]]

BIP 0015

2012-08-20T01:05:02Z

Doca: /* FirstBits */ link to vanitygen

{{bip}}

<pre>
BIP: 15
Title: BIP Aliases
Author: Amir Taaki <genjix@riseup.net>
Status: Deferred
Type: Standards Track
Created: 10-12-2011
</pre>

Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.

This document aims to layout through careful argument, a bitcoin alias system. This is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure.

== Schemes ==

Here are a few different proposals and the properties of each system.

=== FirstBits ===

FirstBits is a proposal for using the blockchain as an address book.

When bitcoins are sent to an address, that address becomes recorded in the blockchain. It is therefore known that this address exists or did exist by simply seeing that there was a payment to that address. FirstBits is a method to have a memorable alias. One first converts the address to lower-case, then takes the first few unique characters. This is your FirstBits alias.

As an example, brmlab hackerspace in Prague has an address for purchasing food or drink, or making donations:

1BRMLAB7nryYgFGrG8x9SYaokb8r2ZwAsX

Their FirstBits alias becomes:

1brmlab

It is enough information to be given the FirstBits alias ''1brmlab''. When someone wishes to make a purchase, without FirstBits, they either have to type out their address laboriously by hand, scan their QR code (which requires a mobile handset that this author does not own) or find their address on the internet to copy and paste into the client to send bitcoins. FirstBits alleviates this impracticality by providing an easy method to make payments.

Together with [[vanitygen|Vanitygen (vanity generator)]], it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.

However FirstBits has its own problems. One is that the possible aliases one is able to generate is limited by the available computing power available. It may not be feasible to generate a complete or precise alias that is wanted- only approximates may be possible. It is also computationally resource intensive which means a large expenditure of power for generating unique aliases in the future, and may not scale up to the level of individuals at home or participants with hand-held devices in an environment of ubiquitous computing.

FirstBits scales extremely poorly as the network grows. Each indexer or lookup node needs to keep track of every bitcoin address ever in existence and provide a fast lookup from the aliases to those addresses. As the network grows linearly, the number of addresses should grow exponentially (assuming a networked effect of (n-1)*(n-2)/2) rapidly making this scheme unfeasible.

Light clients of the partial merkle root types become dependent on a trusted third party for their alias lookups. The cost of storing every bitcoin address is too high considering their typical use-case on low-resource devices. This factor more than the others, means this scheme is sub-optimal and must be rejected.

=== DNS TXT Records ===

DNS allows TXT records to be created containing arbitrary data. In a bitcoin alias system, a custom format mutually agreed upon by a BIP standard would be used to store mappings to bitcoin addresses from domain names. How such a format would look is out of the scope of this document.

An issue is that it requires people who wish to create such mappings to be familiar with configuring DNS records, and be able to run the necessary toolsets to insert the correct data. Although not a huge concern, it is a usability issue.

Security wise, DNS is unsafe and insecure by design. It is possible to spoof records by being on the same network as another host. A number of revisions to mitigate the issue under the guise of DNSSEC have been in the works since the 1990s and are still being rolled out.

As of Dec 2011, DNSSEC is still not yet a defacto standard on the internet. Should a participant in the bitcoin network wish to use DNS TXT records, they would in addition to having to configure DNS, be able to setup DNSSEC. This may not be feasible, especially where some registrars provide access to DNS through a web interface only.

The disadvantage of DNS TXT records is that updating a record takes time. This encourages people to not use new addresses per transaction which has certain security issues.

=== Server Service ===

Aside from using DNS TXT records, another possibility is using the domain name system to lookup hosts and then contact a service running on a predefined port to get the bitcoin address.

# User wishes to send to foo@bar.net
# Client uses DNS to find the IP address of bar.net: 123.123.123.123
# Client connects to port 123.123.123.123:4567 and requests the bitcoin address for the user ''foo''
# Server responds with the address or error code and terminates the connection.
# Client sends the funds to the address

The service would be responsible for providing the mechanisms for changing and storing the mappings on their service. A front-end web interface could be provided to users wishing to use the service and customise their accounts on the server.

This approach has the positive aspect of providing the best flexibility for the implementer to store the records however they wish in a database or plaintext file, and then serve them up quickly using a small server side daemon typically written in C. This approach is highly scalable.

However this approach also suffers the problem of being reliant on DNS and hence also being vulnerable to spoofing. Hence DNSSEC is also required. This approach is slightly better than the DNS TXT records though since it makes inserting new users and modifying aliases very easy which allows people to run these server services more cheaply.

=== HTTPS Web Service ===

HTTPS provides an additional layer of security by encrypting the connection, providing much needed privacy for users. Together with using Certificate Authorities, it fixes the issue with using DNSSEC since an error would be thrown up were someone to try to spoof a domain name on the local network.

When trying to send to:

genjix@foo.org

The request is broken into the handle (genjix) and domain (foo.org) at the last occurrence of the @. The client then constructs a request that will query for the address.

https://foo.org/bitcoin-alias/?handle=genjix

bitcoin-alias has been chosen as the query suffix because it allows this system to co-exist easily within another web root without the fear of name clashes.

The query will then return an address which is used to make the payment.

1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ

The details of whether a unique address is returned per query, whether an address is fetched from a pre-existing pool of addresses, and so on is an implementation detail unique to every server. How alias to address mappings are setup is dependent on the site which could have a web-interface and be providing a free service to users or be a private customised service serving pre-existing addresses. This is left up to sysop policy, and deliberately not defined here.

A web service is trivial to setup and the cost is low. There are many free out of the box providers on the net that allows anyone with the most basic knowledge of web technologies to create their own website. By providing users with a package, anybody can quickly set themselves up with a bitcoin alias. It could be something as simple as a PHP script that the user edits with their custom settings and uploads themselves to their website.

It also scales reasonably- anybody wishing to run a naming service can attach a backend with a variety of database technologies then provide a web frontend for users to customise and create their own aliases.

A naive implementation is provided below as an example.

<source lang="cpp">
// resolv.h
#ifndef NOMRESOLV_H__
#define NOMRESOLV_H__

#include <string>
#include "curl/curl.h"

using std::string;

/*

This class resolves against a server to lookup addresses.
To not conflict with the bitcoin addresses, we refer here to people's handles.
A handle is of the form:

genjix@foo.org

Most characters are valid for the username + password (and handled accordingly), but the domain follows usual web standards. It is possible to affix a path if needed,

genjix@bar.com/path/to/

*/

class NameResolutionService
{
public:
NameResolutionService();
~NameResolutionService();

// Three main methods map to RPC actions.
string FetchAddress(const string& strHandle, string& strAddy);

private:
// A POST block
class PostVariables
{
public:
PostVariables();
~PostVariables();
// Add a new key, value pair
bool Add(const string& strKey, const string& strVal);
curl_httppost* operator()() const;
private:
// CURL stores POST blocks as linked lists.
curl_httppost *pBegin, *pEnd;
};

// Explodes user@domain => user, domain
static void ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain);
// Perform the HTTP request. Returns true on success.
bool Perform();

// CURL error message
char pErrorBuffer[CURL_ERROR_SIZE];
// CURL response
string strBuffer;
// CURL handle
CURL *curl;
};

#endif
</source>

<source lang="cpp">
// resolv.cpp
#include "resolv.h"

#include <boost/lexical_cast.hpp>

#include "access.h"

// callback used to write response from the server
static int writer(char *pData, size_t nSize, size_t nNmemb, std::string *pBuffer)
{
int nResult = 0;
if (pBuffer != NULL)
{
pBuffer->append(pData, nSize * nNmemb);
// How much did we write?
nResult = nSize * nNmemb;
}
return nResult;
}

NameResolutionService::NameResolutionService()
{
// Initialise CURL with our various options.
curl = curl_easy_init();
// This goes first in case of any problems below. We get an error message.
curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, pErrorBuffer);
// fail when server sends >= 404
curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1);
curl_easy_setopt(curl, CURLOPT_HEADER, 0);
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1);
curl_easy_setopt(curl, CURLOPT_POSTREDIR, CURL_REDIR_POST_302);
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writer);
curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_TRY);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);
// server response goes in strBuffer
curl_easy_setopt(curl, CURLOPT_WRITEDATA, &strBuffer);
pErrorBuffer[0] = '\0';
}
NameResolutionService::~NameResolutionService()
{
curl_easy_cleanup(curl);
}

void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain)
{
// split address at @ furthrest to the right
size_t nPosAtsym = strHandle.rfind('@');
strNickname = strHandle.substr(0, nPosAtsym);
strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size());
}
bool NameResolutionService::Perform()
{
// Called after everything has been setup. This actually does the request.
CURLcode result = curl_easy_perform(curl);
return (result == CURLE_OK);
}

string NameResolutionService::FetchAddress(const string& strHandle, string& strAddy)
{
// GET is defined for 'getting' data, so we use GET for the low risk fetching of people's addresses
if (!curl)
// For some reason CURL didn't start...
return pErrorBuffer;
// Expand the handle
string strNickname, strDomain;
ExplodeHandle(strHandle, strNickname, strDomain);
// url encode the nickname for get request
const char* pszEncodedNick = curl_easy_escape(curl, strNickname.c_str(), strNickname.size());
if (!pszEncodedNick)
return "Unable to encode nickname.";
// construct url for GET request
string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + pszEncodedNick;
// Pass URL to CURL
curl_easy_setopt(curl, CURLOPT_URL, strRequestUrl.c_str());
if (!Perform())
return pErrorBuffer;
// Server should respond with a JSON that has the address in.
strAddy = strBuffer;
return ""; // no error
}

NameResolutionService::PostVariables::PostVariables()
{
// pBegin/pEnd *must* be null before calling curl_formadd
pBegin = NULL;
pEnd = NULL;
}
NameResolutionService::PostVariables::~PostVariables()
{
curl_formfree(pBegin);
}
bool NameResolutionService::PostVariables::Add(const string& strKey, const string& strVal)
{
// Copy strings to this block. Return true on success.
return curl_formadd(&pBegin, &pEnd, CURLFORM_COPYNAME, strKey.c_str(), CURLFORM_COPYCONTENTS, strVal.c_str(), CURLFORM_END) == CURL_FORMADD_OK;
}

curl_httppost* NameResolutionService::PostVariables::operator()() const
{
return pBegin;
}
</source>

<source lang="cpp">
// rpc.cpp
...

const Object CheckMaybeThrow(const string& strJsonIn)
{
// Parse input JSON
Value valRequest;
if (!read_string(strJsonIn, valRequest) || valRequest.type() != obj_type)
throw JSONRPCError(-32700, "Parse error");
const Object& request = valRequest.get_obj();
// Now check for a key called "error"
const Value& error = find_value(request, "error");
// It's an error JSON! so propagate the error.
if (error.type() != null_type)
throw JSONRPCError(-4, error.get_str());
// Return JSON object
return request;
}

const string CollectAddress(const string& strIn)
{
// If the handle does not have an @ in it, then it's a normal base58 bitcoin address
if (strIn.find('@') == (size_t)-1)
return strIn;

// Open the lookup service
NameResolutionService ns;
// We established that the input string is not a BTC address, so we use it as a handle now.
string strHandle = strIn, strAddy;
string strError = ns.FetchAddress(strHandle, strAddy);
if (!strError.empty())
throw JSONRPCError(-4, strError);

const Object& request(CheckMaybeThrow(strAddy));
// Get the BTC address from the JSON
const Value& address = find_value(request, "address");
if (address.type() != str_type)
throw JSONRPCError(-32600, "Server responded with malformed reply.");
return address.get_str();
}

// Named this way to prevent possible conflicts.
Value rpc_send(const Array& params, bool fHelp)
{
if (fHelp || params.size() != 2)
throw runtime_error(
"send <name@domain or address> <amount>\n"
"<amount> is a real and is rounded to the nearest 0.01");

// Intelligent function which looks up address given handle, or returns address
string strAddy = CollectAddress(params[0].get_str());
int64 nAmount = AmountFromValue(params[1]);
// Do the send
CWalletTx wtx;
string strError = SendMoneyToBitcoinAddress(strAddy, nAmount, wtx);
if (!strError.empty())
throw JSONRPCError(-4, strError);
return wtx.GetHash().GetHex();
}

...
</source>

=== IP Transactions ===

An IP transaction is an old transaction format in bitcoin that is disabled and possibly could be deprecated. It involves being given an IP address to make payment to. Upon connecting to the node and requesting their public key using "checkorder", they will respond with a script in the form:

<public key> OP_CHECKSIG

Similar to coinbase output transactions. IP transactions have the advantage of being able to contain additional metadata which can be useful in many transactions. Currently no authentication is done making the scheme insecure against man in the middle (MITM) attacks.

This proposal seeks to enable DNS lookups for IP transactions.

The "checkorder" message would contain a destination account, which could map to different isolated sets of keypairs/wallets running under the same host. The exact mapping from the checkorder reference info to the local system is implementation defined.

By using DNS lookups, the MITM problem with IP transactions could be mitigated by storing a public key in a DNS TXT record. This public key would be used for all future "reply" messages originating from that host. First time use would require a confirmation for acceptance of that public key; like with SSH. Should the "reply" message not match the accepted public key, then the host will be given an error.

[[Category:BIP|E]]

=== Namecoin ID ===

This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retreives the structured data containing the bitcoin address(es) associated with this alias.

Using a decentralised domain name system like Namecoin, means no external server or entity needs to be trusted unlike the other proposals listed here. This indicates a system with the advantage of having a high availability and ease of entry (no restrictions for users to create aliases).

Two examples are presented below. The first shows a simpler format, while the second shows several Bitcoin addresses in a structured format.

$ namecoind name_show id/khal
{
"bitcoin" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T"
}

$ namecoind name_show id/khal
{
"bitcoin" :
{
"default" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
"donation": "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4"
}
}

'''More possibilities :'''

* Allow to securely use '''unsecured channels'''
You can put an url and a bitcoin address that will be used to sign the result. It means that a query to this url will return a bitcoin address and a signature. Bitcoin can then check (with the verify_message function) that the returned address has not been replaced by another one.
$ namecoind name_show id/khal
{
"bitcoin" :
{
"url" : "http://merchant.com/bitcoin/getnewaddres/",
"signedWith" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T"
}
}

* Allow to get a different address each time, or per user, per order, etc
$ namecoind name_show id/khal
{
"bitcoin" :
{
"url" : "http://merchant.com/bitcoin/getaddres/{Your customer id}",
"signedWith" : "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
"useOnce": false
}
}
In the above example, bitcoin will ask the user for "Your customer id" and replace that value in the url before making the http request. The merchant will receive the request and give the user a payment address associated with that customer.

Any text can be put into the brackets, allowing merchants to adapt it to all their needs.

* Specification is extensible

New features can be added later to support uncovered cases.

See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations.

Vanitygen

2012-08-20T01:02:55Z

Doca: initial

In Person Traders

2011-12-15T03:34:45Z

Doca:

<div style="background:#dddddd;border:solid gray 1px;width:70%;margin:auto;">
This page is a map of people trading bitcoins in person in the real world. (Person to Person transactions) These are usually done using cash. If you have no bitcoins and are new to this, the trader is likely able to help you with the transaction and setting up a wallet.
<br/>
Feel free to add yourself to the map by editing this page, and include some form of contact information. Also, you can include the calculation for your buy/sell prices and how much you are willing to buy/sell. <br/>
</div>
<br/>
<div style="border:solid gray 1px;width:250px;">
Legend
*[[Image:Green_marker.png|15px]] This person is Buying Bitcoins
*[[Image:Blue_marker.png|15px]] This person is Selling Bitcoins.
*[[Image:Red_marker.png|15px]] This person is Buying & Selling
</div>
There is also this site: http://btcnearme.com/ that does the same thing as this page (and has some more traders)

<br/>

<display_points height=700 >
45.444785, -122.831282|Robert Kohr| email my gmail account - robkohr. I will sell at mtgox*1.15 and buy at mtgox*1.0 |File:Red_marker.png
45.5366557, -122.9570263|Robert Kohr| email my gmail account - robkohr. I will sell at mtgox*1.15 and buy at mtgox*1.0 |File:Red_marker.png
53.52505, -113.52068|Andrew| I sell at the up-to-the-minute Mt Gox Ask Price + 1% fee for Mt Gox code or 2% for plain bitcoin. My gmail account is onelineproof |File:Blue_marker.png
19.50050, -99.13088|BitcoinMX| Contact via https://bitcoinmx.appspot.com/ |File:Red_marker.png

</display_points>

===See Also===
* [[Trade]]
* [[:Category:Local]]

[[Category:Local]]

Securing your wallet

2011-09-09T05:06:59Z

Doca: bigger size for backup - 1000MB

==Introduction==

Wallet security can be broken down into two independent goals:
# Protecting your wallet against loss.
# Protecting your wallet against theft.

In the case that your current wallet hasn't been protected adequately (e.g. put online with a weaker password):
# Making a new secure wallet, using appropriate long-term protection.

''For a brief overview see also: [[Wallet Security Dos and Don'ts (Windows)|Wallet Security Dos and Don'ts]]''

==Technical Background==

Bitcoin transactions send Bitcoins to a specific public key. A Bitcoin address is an encoded hash of a public key. In order to use received Bitcoins, you need to have the private key matching the public key you received with. This is sort of like a super long password associated with an account (the account is the public key). Your Bitcoin wallet contains all of the private keys necessary for spending your received transactions. If you delete your wallet without a backup, then you no longer have the authorization information necessary to claim your coins, and the coins associated with those keys are lost forever.

The wallet contains a pool of queued keys. By default there are 100 keys in the [[key pool]]. The size of the pool is configurable using the "-keypool" command line argument. When you need an address for whatever reason (send, “new address”, generation, etc.), the key is not actually generated freshly, but taken from this pool. A brand new address is generated to fill the pool back to 100. So when a backup is first created, it has all of your old keys plus 100 unused keys. After sending a transaction, it has 99 unused keys. After a total of 100 new-key actions, you will start using keys that are not in your backup. Since the backup does not have the private keys necessary for authorizing spends of these coins, restoring from the old backup will cause you to lose Bitcoins.

Creating a new address generates a new pair of public and private keys, which are added to your wallet. Each keypair is mostly random numbers, so they cannot be known prior to generation. If you backup your wallet and then create more than 100 new addresses, the keypair associated with the newest addresses will not be in the old wallet because the new keypairs are only known after creating them. Any coins received at these addresses will be lost if you restore from the backup.

The situation is made somewhat more confusing because the receiving addresses shown in the UI are not the only keys in your wallet. Each Bitcoin generation is given a new public key, and, more importantly, each sent transaction also sends some number of Bitcoins back to yourself at a new key. When sending Bitcoins to anyone, you generate a new keypair for yourself and simultaneously send Bitcoins to your new public key and the actual recipient's public key. This is an anonymity feature – it makes tracking Bitcoin transactions much more difficult.

So if you create a backup, do more than 100 things that cause a new key to be used, and then restore from the backup, some Bitcoins will be lost. Bitcoin has not deleted any keys (keys are never deleted) – it has created a new key that is not in your old backup and then sent Bitcoins to it.

== Making a new wallet ==

In the case that a wallet has been distributed, or stored, in a (real or potential) compromised state, it is wise to create a new wallet and transfer the full balance of Bitcoins to an address contained only in the newly created wallet.

For example, this will be necessary if one created a wallet with a password of 12 characters, as suggested. However a few years have passed and the wallet is now more easily compromised. Just re-encrypting isn't secure. One needs to make a new wallet and make the old wallet worthless (spending the funds to the new wallet).

==Making a secure workspace==

===Linux===

The first step is to make a [http://www.howtogeek.com/howto/ubuntu/add-a-user-on-ubuntu-server/ new user,] so run:

<code>adduser new_user_name</code>

as root. When you get to the prompt 'Enter the new value, or press ENTER for the default', just keep hitting ENTER.

Then switch user to the new user. To get to the new user you can use the switch user icon for your system, which on Ubuntu is in the 'System/Quit' screen, or if there is no switch icon on your system you can log out and log back in as the new user. Then click on a folder in the new user to display the file browser, then keep going up folders until you see the new user home directory, then right click to bring up the Properties dialog, then click on the Permissions tab, then in the Others section, set the folder access to None.

For secure browsing, open Firefox, and then go into the Edit menu and click Preferences. Starting from the left, click on the General tab, and in the 'Startup/When Firefox starts' pop up menu, choose 'Show a Blank Page'. Then click on the Content tab, and deselect 'Load images automatically' and deselect 'Enable Javascript'. Then click on the Privacy tab, and in the 'History/Firefox will' pop up menu, choose 'Never remember history'. Then click on the Security tab, and in the Passwords section, deselect 'Remember passwords for sites' and deselect 'Use a master password'. Then click on the Advanced tab, then click on the Update tab, and then in the 'Automatically check for updates to' section, deselect 'Add-ons' and 'Search Engines'.

When javascript is disabled, the [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/bitcoin-0.3.23-linux.tar.gz/download linux download page] will not download automatically, so you'll have to click on the 'direct link' part of the "Problems with the download? Please use this 'direct link' or try another mirror." line.

After you've made your secure new user, to maintain security you should use it only for bitcoin.

It's also a good idea to encrypt the Home directory of whatever user you run Bitcoin under using ecryptfs-utils. To do this:
# If the Home directory is not empty you should back it up first, by just copying the data to an external drive or something.
# install ecryptfs-utils (on Ubuntu: sudo apt-get install ecryptfs-utils)
# log out of X (graphical system) and press Ctrl+Alt+F1 to login to the command shell (you must be logged out or some files will be open and the tool won't be able to encrypt your data)
# change directory to something that's not in your home folder (ex: cd / )
# run the migration tool (on Ubuntu: sudo ecryptfs-migrate-home -u username)
# if it's successful, you can now press ALT+F8 to go back to the GUI and login
# run 'ecryptfs-unwrap-passphrase' and '''WRITE DOWN OR SAVE THE CODE IT RETURNS''' because you will need it if you ever have to pull your data off while the OS is not working. (You can run it again later if you need to, but run it now so that you can get your data if your Linux install gets botched.)
# run 'ecryptfs-setup-swap' to encrypt your swap partition (the encrypted folder data is not encrypted while it's in memory, and so if it's ever sent to the swap partition it can be stolen from there unless that too is encrypted - be aware that this will mean you cannot use Hibernate anymore, as the bootloader won't be able to restore the hibernation data)
(instructions from [http://bodhizazen.net/Tutorials/Ecryptfs/#Migrate])

===Mac===

=====Backup all data (1000MB)=====
Follow these instructions to backup all the bitcoin data (wallet and block chains) to an encrypted disk image.
# Open Disk Utility
# Click New Image and choose 1000MB, 128-bit or 256-bit (faster or more secure) encryption and single partition.
# Save it somewhere you won't lose it (like your Wuala, Dropbox, Strongspace or whatever)
# Choose a safe and strong password
# Move everything from ~/Library/Application Support/Bitcoin/ to the image
# Symlink it back so the app would be able to use it
:::ln -s /Volumes/Bitcoin ~/Library/Application Support/Bitcoin

Don't forget to mount your image before using Bitcoin and unmount after quitting it.

=====Backup just wallet.dat (40MB)=====
Follow these instructions to backup just the wallet.dat file. This results in a smaller disk image, but it's more complicated to do.
# Open Disk Utility
# Click New Image and choose 40MB, 128-bit or 256-bit (faster or more secure) encryption and single partition.
# Save it somewhere you won't lose it (like your Wuala, Dropbox, Strongspace or whatever)
# Choose a safe and strong password
# Move your wallet.dat file to the image
# Symlink it back so the app would be able to use it
:::ln -s /Volumes/Bitcoin/wallet.dat ~/Library/Application Support/Bitcoin/wallet.dat

[[File:MountWalletAndLauchnBitcoin_OSX_Automator.png|thumbnail|150px|Mount Wallet and launch Bitcoin]]
Don't forget to mount your image before using Bitcoin and unmount after quitting it.

'''Note''': If you start the Bitcoin application without having the image mounted, the application will overwrite your symlink with a new wallet. If that happens, don't panic. Just delete the new wallet.dat, mount the image, and recreate the symlink like above.

'''Automation''': You can create a small application using [http://en.wikipedia.org/wiki/Automator_%28software%29 Automator] (included in OS X) to automatically mount the wallet and then launch Bitcoin App. See the Screenshot on how to do this.

If one ''doesn't'' want to use encrypted Disk images, then a '''small shell script''' can be used instead that takes care of decrypting the wallet, launching bitcoin client, and encrypting it after the client exits. This script works on both OSX and Linux: [http://lorelei.kaverit.org/bitcoin.sh bitcoin-launch-script]

===Windows===

If you are using Windows XP or Windows 7, you can keep your wallet on an encrypted disk image created by third-party software, such as [http://www.truecrypt.org/ TrueCrypt] (open source) or [http://www.jetico.com/encryption-bestcrypt/ Jetico BestCrypt] (commercial). You can probably do the same with Windows Vista or Windows 2000.

'''NOTE:''' You should configure Bitcoin in this manner only on computers where you use Bitcoin, but do not use that computer to mine. For example, this is a good configuration for a notebook or tablet computer.

Assuming that you have installed the Windows Bitcoin client and run it at least once, the process is described below.

<p><b>To mount the Bitcoin data directory on an encrypted drive</b></p>
<ol start=1 type=1>
<li>Use the third-party disk image encryption program of your choice to create and mount an encrypted disk image of at least 100 MB in size.</li>
<li>Locate the Bitcoin data directory, and copy the directory with all contents to the encrypted drive.
<p>For help finding this directory, see <b>[[Securing_your_wallet#Locating_Bitcoin_s_data_directory|Locating Bitcoin's Data Directory]]</b>.</p></li>
<li>Create a Windows shortcut that starts Bitcoin with the <code>-datadir</code> parameter and specifies the encrypted drive and directory.
<p>For example, if you installed Bitcoin in the default directory, mounted your Bitcoin encrypted drive as <code>E:\</code>, and stored your Bitcoin data directory on it as <code>Bitcoin</code>, you would type the following command as the shortcut Target:</p>
<blockquote><code>C:\Program Files\Bitcoin\bitcoin.exe -datadir=E:\Bitcoin</code></blockquote></li>
<li>Open Bitcoin's settings and configure it <b>NOT</b> to start automatically when you start Windows.
<p>This is to allow you to mount the Bitcoin encrypted disk image before starting Bitcoin.</p></li>
<li>Shut down Bitcoin, and then restart it from the new shortcut.</li>
</ol>

After doing this, any time you want to use Bitcoin, you must first mount the Bitcoin encrypted disk image using the same drive designation, and then run Bitcoin from the shortcut that you created, so that it can find its data and your wallet. :-)

== Locating Bitcoin's data directory ==

The [[data directory]] is the location where Bitcoin's data files are stored, including the wallet data file.

=== Windows ===

Go to Start -> Run (or press WinKey+R) and run this:

explorer %APPDATA%\Bitcoin

Bitcoin's data folder will open. For most users, this is the following locations:

C:\Documents and Settings\YourUserName\Application data\Bitcoin (XP)

C:\Users\YourUserName\Appdata\Roaming\Bitcoin (Vista and 7)

"AppData" and "Application data" are hidden by default.

=== Linux ===

By default Bitcoin will put its data here:

~/.bitcoin/

You need to do a "ls -a" to see directories that start with a dot.

If that's not it, you can do a search like this:

find / -name wallet.dat -print 2>/dev/null

=== Mac ===

By default Bitcoin will put its data here:

~/Library/Application Support/Bitcoin/

==Backup==

'''Note''': I would strongly recommend against using a service like Dropbox to back up your Bitcoin data due to [http://en.wikipedia.org/wiki/Dropbox_(service)#Criticism security concerns] such as:
# the fact that they store your encryption key (meaning that a disgruntled Dropbox employee or an attacker who gained access to the system could decrypt your Dropbox data and steal your Bitcoins)
# the fact that the Dropbox client only needs a password for the first login. After it authenticates once, the server assigns it a token which it uses to show that, at one time, its user knew the password rather than sending the actual password (meaning that if you ever use the Dropbox client on another PC, that PC's users can access your Dropbox - even if you change your password - and can steal your Bitcoins or get a virus that will steal your Bitcoins).

For these reasons, I personally prefer to use Wuala, which does not store your encryption key and requires a password each time (the client can be set to remember your password, but the server will check each time to make sure that the client is sending the correct password). Like Dropbox, the basic, lowest-storage-space account with Wuala is free of charge, and coincidentally, Wuala [http://www.wuala.com/en/bitcoin is experimenting with allowing users to pay for "upgraded" plans using Bitcoin.]

In fact, whether you use Dropbox as your backup or not, use what Steve Gibson calls "pre-Internet encryption" (which he actually [http://itknowledgeexchange.techtarget.com/security-corner/cloud-security-and-privacy-do-they-exist/ discussed in the context of Dropbox's security concerns]) and use some form of encryption on the files before you back them up, just in case someone other than yourself ever gains access to that backup. Make sure to pick a password that's memorable but secure.

The only file you need to back up is "wallet.dat". Ensure that Bitcoin is closed, copy this file somewhere else, encrypt it, and put it somewhere safe. Ideally, you would put this file in two places: one nearby, and one 100+ miles away.

You can use the [[api|backupwallet]] JSON-RPC command to back up without shutting down Bitcoin.

=== General Solutions ===

Your wallet.dat file is not encrypted by Bitcoin. Anyone who can access it can easily steal all of your coins. Use one of these encryption programs if there is any chance someone might stumble upon your wallet.
* [http://www.7-zip.org/ 7-zip] - Supports strongly-encrypted archives.
* [http://www.axantum.com/axcrypt/ AxCrypt by Axantum]
* [http://lrzip.kolivas.org lrzip] - Compression software for Linux and OSX that supports very high grade password protected encryption
* [http://www.truecrypt.org/ TrueCrypt] - Volume-based on-the-fly encryption (for advanced users)
* [http://www.rarlab.com/ WinRar] - Commonly used archive software that supports verification records and encryption.

There is also a list of [[OpenSourceEncryptionSoftware|open source encryption software.]]

Decrypting and encrypting the wallet.dat every time you start or quit the Bitcoin client can be ''tedious'' (and outright error-prone). If you want to keep your wallet encrypted (except while you're actually running the Bitcoin client), it's better to relegate the automation to a [http://lorelei.kaverit.org/bitcoin.sh small shell script] that handles the en/decryption and starting up Bitcoin client for you (Linux and OSX).

There is also a method to Print out and encrypt your Wallet.dat as a special barcode. See details here: [[WalletPaperbackup]]

==== Password Strength ====
Brute-force password cracking has come a long way. A password of random [a-Z] [0-9] [!-~] of 8 characters long was previously thought secure but can be trivially solved now (using appropriate hardware). The recommended length is '''at least''' 12 characters long. You can also use a multi-word password. [http://www.baekdal.com/tips/password-security-usability The Usability of Passwords]

However, simply using dictionary words is also insecure as it opens you up to a dictionary attack. If you use dictionary words, be sure to throw random symbols and numbers in the mix as well.

A good way to create secure but easy-to-remember passwords is to pick a password (ex: d0g) and pad it with a good number of repeated characters afterward (such as 10 $ signs - so d0g becomes d0g$$$$$$$$$$) - this is just as cryptographically secure as a random password of equal length so long as the attacker does not know which symbol you are following your "word" with and how many times it is repeated. ([https://www.grc.com/haystack.htm source])

If you use keyfiles in addition to a password, it is unlikely that your encrypted file can ever be cracked using brute force methods, even 10 years from now when even a 12 character password might be too short.

Assume that any encrypted files you store online (eg. gmail, Dropbox) will be stored somewhere forever and can never be erased.

===== Choosing Your Password =====
Make sure you pick at least one character in each group:<br />

Lowercase: abcdefghijklmnopqrstuvwxyz
Uppercase: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Number: 1234567890
Symbol: `~!@#$%^&*()-_=+\|[{]};:'",<.>/? (space)

>9 char = unsuitable for use
09 char = insecure
10 char = low security
11 char = medium security
12 char = good security (good enough for your wallet)
13 char = very good, enough for anything.

==== Storage of Archive ====
One of the most simple methods for storing a appropriately '''encrypted''' archive of your wallet.dat file is to send the archive as an email attachment to your own e-mail address. Services like gmail.com use very comprehensive distributed networks that make the loss of data very unlikely. One can even obfuscate the name of the files within the archive, and name the archive something less inviting, such as: 'personal notes' or 'car insurance'.

Another solution is to use a file storage service like [http://www.wuala.com/bitcoin Wuala] ( encrypted, [http://www.bitcoin.org/smf/index.php?topic=5817.0 instructions]), [http://www.dropbox.com Dropbox] and [http://en.wikipedia.org/wiki/Comparison_of_online_backup_services others], including the more secure [http://www.spideroak.com SpiderOak].

=== Linux solution ===

Linux users can setup backups using cron by telling it to run a backup script at set intervals of time. Run 'crontab -e' and add this line near the bottom:

01 */1 * * * /usr/local/bin/backupwallet.sh

This cron line will run the /usr/local/bin/backupwallet.sh script at the 01 minute of every hour. Remember to add a newline after the last line of the crontab file, or else the last line won't run. You may also wish to ignore the script's output by appending " > /dev/null 2>&1" to the line (this will also prevent emails from being sent).

Create /usr/local/bin/backupwallet.sh:

#!/bin/bash
# /usr/local/bin/backupwallet.sh
#
# Performs backup of bitcoin wallet.
#
# Written by: https://en.bitcoin.it/wiki/Securing_your_wallet

#
# Standard Options
#
TS=$(date "+%Y%m%d-%H%M")
WALLET=/tmp/wallet-${TS}
WALLET_E=/tmp/wallet-${TS}.crypt
BITCOIN=bitcoind # /path/to/bitcoind
GPG=gpg # /path/to/gpg
GPG_USER=username # Username of gpg recipient. User should have gpg setup.
RM=rm
RM_OPTS='--force'
USE_SHRED=0 # Flip to 1 to use `shred` instead of `rm`.
SHRED=shred
SHRED_OPTS='--force --iterations=9 --zero --remove'

#
# Storage Options
# Only 1 set of options should be un-commented (the last one will be used).
# Update CP_DEST paths as neccessary.
#
# CP - Storage on a local machine. Could be Dropbox/Wuala folder.
#CP=cp
#CP_DEST='/var/data/backups/' # '~/Dropbox/', etc.
#
# SSH - Storage on a remote machine.
CP=scp
CP_DEST='remoteuser@example.com:~/wallets/'
#
# S3 - Storage on Amazon's S3. Be sure s3cmd is installed and properly setup.
# You may need "s3cmd put --force" if you use a sub-directory in CP_DEST.
#CP=s3cmd put
#CP_DEST='s3://bucket'

do_clean() {
# Remove temporary wallets.
if [ 1 -eq $USE_SHRED ]; then
$SHRED $SHRED_OPTS $WALLET $WALLET_E
else
$RM $RM_OPTS $WALLET $WALLET_E
fi
}

do_fail() {
do_clean
echo failed!
exit 1
}

# Perform the backup.
echo -n Making backup...
$BITCOIN backupwallet $WALLET
[ ! -s "$WALLET" ] && do_fail # If the backup does not exist or is empty, fail.
echo done.
echo -n Encrypting backup...
$GPG -r $GPG_USER --output $WALLET_E --encrypt $WALLET
[ 0 -ne $? ] && do_fail # If gpg returns a non-zero result, fail.
echo done.
echo -n Copying to backup location...
$CP $WALLET_E "$CP_DEST"
[ 0 -ne $? ] && do_fail # If the $CP command returns a non-zero result, fail.
echo done.
do_clean

exit 0

The shell script:

* Calls bitcoind backupwallet to create a time/date-stamped wallet.
* GPG encrypts the wallet with your public key.
* Copies the result using one of several storage options (cp, scp, and s3cmd).
* Uses the rm or shred command to remove the temporary wallet files.

Be sure to modify the script options to fit your setup. After you save, make sure the file can be executed properly by the cron user. Common permissions for files in /usr/local/bin/ can be applied using (verify with your distribution!):

cd /usr/local/bin/ && chown root:root backupwallet.sh && chmod 755 backupwallet.sh

[[Category:Technical]]

==Restore==

Assuming your backup is recent enough that you haven't used up all of your key pool... restoring a wallet to a new (or old) location and rescanning the block chain should leave you with all your coins. Just follow these steps:
* Quit bitcoin(d).
* Copy your backed up wallet.dat into your bitcoin profile directory.
* If copying into existing profile, delete file ''blkindex.dat'' and ''blk0001.dat'' to make the client re-scan the block chain.

And you'll be good as new.

==Erasing Plain Text Wallets==

A good practice is to keep at least two wallets, one as a "current account" for everyday transactions and one as a "savings account" where you store the majority of your Bitcoins.

The "savings account" wallet should be backed up in encrypted form only and all plaintext copies of this wallet should be erased. In case someone gains unauthorised access to your computer (either by physically stealing it or by exploiting a system vulnerability via the internet), they will only be able to spend the coins in your "current account" wallet.

In most operating systems, including Windows, Linux, and Mac OS X, simply deleting a wallet.dat file will ''not'' generally destroy it. It is likely that advanced tools can still be used to recover the wallet.dat file, even after it has been deleted.

The Linux '''shred''' command can be used to overwrite the wallet file with random data prior to deleting; this particular copy of the file will then be practically impossible to recover. Using shred (and similar tools on Windows) however does not guarantee that still other copies don't exist somewhere hidden on your HD. That will depend on your system configuration and what packages you have installed. Some system restore and backup tools, for instance, create periodic snapshots of your filesystem, duplicating your wallet.dat.

In Mac OS, the equivalent of '''shred''' is '''srm''' (introduced in Leopard). Using the Finder to remove files, clicking "Secure Empty Trash" in the Finder menu will shred the contents of the trash can. As with any OS this doesn't guarantee that there are not other copies elsewhere on your system.

For Windows, the built-in command ''cipher /W'' will shred all previously-deleted files. [http://www.cylog.org/utilities/cybershredder.jsp CyberShredder] can securely deleted individual files.

==eWallet==

Storing bitcoins with an [[eWallet]] provider incurs risks as well. Basically you grant the third party, in this case eWallet, full access to your wallet. These eWallets, or Electronic Wallets have a number of pros and cons. For example, you can access your wallet on any computer in the world, but the wallet can be forged or hacked and your bitcoins could be lost. You can also get eWallet applications for your Android phone, which also download the block chain like the normal client but allow the user to send bitcoins by QR code or NFC. The problem with this is that Bitcoins can be intercepted through means of mobile hacking.

==See Also==

* [[Data directory]]
* [http://startbitcoin.com/how-to-create-a-secure-bitcoin-wallet/ Secure Bitcoin Wallet Tutorial]
* [[How to set up a secure offline savings wallet]]
* [http://arimaa.com/bitcoin/ Bitcoin Gateway - A Peer-to-peer Bitcoin Vault and Payment Network]

[[de:Sichere deine Geldbörse]]
[[zh-cn:保护你的钱包]]