Bitcoin Wiki - User contributions [en]

BIP 0032

2013-06-22T18:13:11Z

Ahazred8oc: /* Abstract */ link to Deterministic Wallet

{{bip}}

RECENT CHANGES:
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)
* [25 May 2013] Added test vectors

<pre>
BIP: 32
Title: Hierarchical Deterministic Wallets
Author: Pieter Wuille
Status: Accepted
Type: Informational
Created: 11-02-2012
</pre>

==Abstract==

This document describes [[Deterministic Wallet|hierarchical determinstic wallets]] (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.

The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients.

The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.

==Motivation==

The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well.

Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).

However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customer's payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.

==Specification: Key derivation==

===Conventions===

In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters defined by secp256k1 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.
* byte sequences

We shall denote the compressed form of point P by χ(P), which for secp256k1 will always be 33 bytes long.

Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.

===Extended keys===

In what follows, we will define a function that derives a number of child keys from a parent key. In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.

We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = k*G and c the chain code.

===Child key derivation functions===

We allow for two different types of derivation: private and public.
* Private derivation: knowledge of the private key kpar and cpar is required to compute both ki and Ki.
* Public derivation: knowledge of the public key Kpar and cpar suffices to compute Ki (but not ki).

We define the private and public child key derivation functions:
* CKD((kpar, cpar), i) → (ki, ci), defined for both private and public derivation.
* CKD'((Kpar, cpar), i) → (Ki, ci), defined only for public derivation.

We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.

====Private child key derivation====

To define CKD((kpar, cpar), i) → (ki, ci):
* Check whether the highest bit (0x80000000) of i is set:
** If 1, private derivation is used: let I = HMAC-SHA512(Key = cpar, Data = 0x00 || kpar || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]
** If 0, public derivation is used: let I = HMAC-SHA512(Key = cpar, Data = χ(kpar*G) || i)
* Split I = IL || IR into two 32-byte sequences, IL and IR.
* ki = IL + kpar (mod n).
* ci = IR.
In case IL ≥ n or ki = 0, the resulting key is invalid, and one should proceed with the next value for i.
[Note: this has probability lower than 1 in 2127.]

====Public child key derivation====

To define CKD'((Kpar, cpar), i) → (Ki, ci):
* Check whether the highest bit (0x80000000) of i is set:
** If 1, return error
** If 0, let I = HMAC-SHA512(Key = cpar, Data = χ(Kpar) || i)
* Split I = IL || IR into two 32-byte sequences, IL and IR.
* Ki = (IL + kpar)*G = IL*G + Kpar
* ci = IR.
In case IL ≥ n or Ki is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.

Note that the extended public key corresponding to the evaluation of CKD(kext, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(Kext, i), with Kext the extended public key corresponding to kext. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.

The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].

===The key tree===

The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.

Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant public keys derived using public derivation.

===Key identifiers===

Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself).

The first 32 bits of the identifier are called the fingerprint.

===Serialization format===

Extended public and private keys are serialized as follows:
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, ....
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)
* 4 bytes: child number. This is the number i in xi = xpar/i, with xi the key being serialized. This is encoded in MSB order. (0x00000000 if master key)
* 32 bytes: the chain code
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)

This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of up to 112 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet.

Note that the fingerprint of the parent only serves as a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.

When importing a serialized extended public key, implementations must verify whether the X coordinate in the public key data corresponds to a point on the curve. If not, the extended public key is invalid.

===Master key generation===

The total number of possible extended keypairs is almost 2^512, but the produced keys are only 256 bits long, and offer about half of that in terms of security. Therefore, master keys are not generated directly, but instead from a potentially short seed value.

* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)
* Split I into two 32-byte sequences, IL and IR.
* Use IL as master secret key, and IR as master chain code.
In case IL is 0 or >=n, the master key is invalid.

[[File:BIP32-derivation.png]]

==Specification: Wallet structure==

The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimick it for compatibility, even if not all features are supported.

An HDW is organized as several 'accounts'. Accounts are numbered, the default account ("") being number 0. Clients are not required to support more than one account - if not, they only use the default account.

Each account is composed of two keypair chains: an internal and an external one. The external keychain is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything.

* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.

===Use cases===

====Full wallet sharing: m====

In cases where two systems need to access a single shared wallet, and both need to be able to perform spendings, one needs to share the master private extended key. Nodes can keep a pool of N look-ahead keys cached for external chains, to watch for incoming payments. The look-ahead for internal chains can be very small, as no gaps are to be expected here. An extra look-ahead could be active for the first unused account's chains - triggering the creation of a new account when used. Note that the name of the account will still need to be entered manually and cannot be synchronized via the block chain.

====Audits: M====

In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.

====Per-office balances: m/i'====

When a business has several independent offices, they can all use wallets derived from a single master. This will allow the headquarters to maintain a super-wallet that sees all incoming and outgoing transactions of all offices, and even permit moving money between the offices.

====Recurrent business-to-business transactions: M/i'/0====

In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i'/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment.
Such a mechanism could also be used by mining pool operators as variable payout address.

====Unsecure money receiver: M/i'/0====

When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be used to receive payments. The webserver only needs to know the public extended key of the external chain of a single account. This means someone illegally obtaining access to the webserver can at most see all incoming payments, but will not (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.

==Compatibility==

To comply with this standard, a client must at least be able to import an extended public or private key, to give access to its direct descendants as wallet keys. The wallet structure (master/account/chain/subchain) presented in the second part of the specification is advisory only, but is suggested as a minimal structure for easy compatibility - even when no separate accounts or distinction between internal and external chains is made. However, implementations may deviate from it for specific needs; more complex applications may call for a more complex tree structure.

==Security==

In addition to the expectations from the EC public-key cryptography itself:
* Given a public key K, an attacker cannot find the corresponding private key more efficiently than by solving the EC discrete logarithm problem (assumed to require 2128 group operations).
the intended security properties of this standard are:
* Given a child extended private key (ki,ci) and the integer i, an attacker cannot find the parent private key kpar more efficiently than a 2256 brute force of HMAC-SHA512.
* Given any number (2 <= N <= 232-1) of (index, extended private key) tuples (ij,(pj,cj)), with distinct ij's, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (ppar,cpar) such that for each j in [0..N-1] CKD((ppar,cpar),ij)=(pj,cj)), cannot be done more efficiently than a 2256 brute force of HMAC-SHA512.
Note however that the following properties does not exist:
* Given a parent extended public key (Kpar,cpar) and a child public key (Ki), it is hard to find i.
* Given a parent extended public key (Kpar,cpar) and a child private key (ki) using public derivation, it is hard to find kpar.

Private and public keys must be kept safe as usual. Leaking a private key means access to coins - leaking a public key can mean loss of privacy.

Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.

==Test Vectors==

For more detailed information about these (such as intermediate values and other representations), see [[BIP_0032_TestVectors]]

Test vector 1

Master (hex): 000102030405060708090a0b0c0d0e0f
* [Chain m]
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi
* [Chain m/0']
* ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw
* ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7
* [Chain m/0'/1]
* ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ
* ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs
* [Chain m/0'/1/2']
* ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5
* ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM
* [Chain m/0'/1/2'/2]
* ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV
* ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334
* [Chain m/0'/1/2'/2/1000000000]
* ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy
* ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76

Test vector 2

Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542
* [Chain m]
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U
* [Chain m/0]
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt
* [Chain m/0/2147483647']
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9
* [Chain m/0/2147483647'/1]
* ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon
* ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef
* [Chain m/0/2147483647'/1/2147483646']
* ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL
* ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc
* [Chain m/0/2147483647'/1/2147483646'/2]
* ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt
* ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j

==Acknowledgements==

* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.

Deterministic wallet

2013-05-24T17:20:57Z

Ahazred8oc: /* Types of deterministic wallet in use */ twelve word passphrase common format

A deterministic wallet is a wallet where private and public keys are all derived from a starting seed value. This could be a long passcode/password, or be a random series of letters and numbers.

== Benefits ==

A typical wallet creates private and public keys on demand for the user. This means that the wallet needs to be backed up frequently, otherwise coins may be lost. Also, having multiple machines with wallets on them means it is difficult to manage all of your coins together.

A deterministic wallet can be backed up by simply copying the starting seed value to a secure location, and this only needs to be done once. If the wallet ever gets lost, all private and public keys can be regenerated from the initial seed.

Also, multiple devices could host the same wallet based off of the same seed and automatically stay in sync with eachother. Non-critical information such as address books would need to be stored and copied between wallets.

==Drawbacks==

If the initial seed value was either guessed or taken, the attacker could take all of the coins from the wallet. Also, they could retain that seed value, and wait until some future date to take all of the coins.

==Passwords vs Random Strings==

The passcode/password has the benefit of being memorizable by the user, but at the expense of being either forgotten, or weak enough that the password could be guessed or brute forced. If a user used a password such as abc123, and an attacker might simply go through a list of common passwords, create wallets for them, and see if the public addresses match anything currently in the blockchain.

A long string of letters and numbers would be a way to prevent a brute force attack. This has the drawback of having to be actually stored somewhere. If this code was ever lost, the wallet would be lost forever.

==Types of deterministic wallet in use==
Each implementer of deterministic wallets should make sure that this article leads to a publicly available reference describing how to reconstitute the deterministic wallet from its seed.

===Type 1 deterministic wallet===
A Type 1 deterministic wallet is created from a string. Simply take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed. This simple type of wallet can be created by Casascius Bitcoin Address Utility.

===Type 2 deterministic wallet===
Not sure on the details, but mention was made of a "type-2 deterministic wallet" in [[BIP 0032]] and credited to Gregory Maxwell, so this is a placeholder to describe that implementation. The relevant form topic is [https://bitcointalk.org/index.php?topic=19137.0 here].

===BIP 0032 deterministic wallet===
Described in [[BIP 0032]] (currently a draft) and described as a ''hierarchical deterministic'' (HD) wallet, a BIP 0032 deterministic wallet allows sharing smaller deterministic wallets that are subportions of a larger one.

===Twelve Word Passphrase deterministic wallet===
A common format shared by Brainwallet.org, CarbonWallet.org and [[Electrum]]. The same 12-word passphrase gives access to the same bitcoin addresses when used with any of the services.

===Electrum deterministic wallet===
[[Electrum]] implements a Type-2 deterministic wallet format based on a 128-bit seed. It uses a word list and converts the seed to a twelve word passphrase as an aid to help the user record the seed.

===CarbonWallet deterministic wallet===
[[CarbonWallet]] also implements a Type-2 deterministic wallet format based on a 128-bit seed. It uses the same word list as Electrum and is therefore compatible with Electrum twelve word passphrases.

===Armory deterministic wallet===
[[Armory]] has its own Type-2 deterministic wallet format based on a "root key" and a "chain code." The Armory client has a "Paper Backup" screen that allows the user to print these data or copy it down by hand. Earlier versions of Armory required backing up both the "root key" and "chaincode," while newer versions start deriving the chaincode from the private key in a non-reversible way. These newer Armory wallets (0.89+) only require the single, 256-bit root key.

User:TecKhan54

2013-05-17T16:35:10Z

Ahazred8oc: removed categories

'''Bold text'''TecKhan Wallet for Android
BIP: 1
Title: BIP Infrastructure and Guidelines
Author:Duchess B. Breinstein<a55dayidream@gmail.com>
Status: Active
Type: Standards Track
Created: 01-14-2013

___________
| |--(p2p protocol)---ooooooooooooooo
| Peer/Node |--(p2p protocol)--o Other Peers o
|___________|--(p2p protocol)---ooooooooooooooo
|
(p2p protocol)
_____|_____ _________
| | | |
| Wallet |--(wallet protocol)--| TecKhan54 |
|___________| |_________|
|
(wallet protocol)
_____|__________
| |
| User Interface |
|________________|

code_string = "njH4Agfbgcev51clm7fmCUBR2DRRBa9ha"
x = convert_bytes_to_big_integer(hash_result)

output_string = ""

while(x > 0)
{
(x, remainder) = divide(x, 58)
output_string.append(code_string[remainder])
}

repeat(number_of_leading_zero_bytes_in_hash)
{
output_string.append(code_string[0]);
}

output_string.reverse();
[edit] Version bytesHere are some common version bytes:

Decimal version Leading symbol Use
0 1 Bitcoin pubkey hash
5 3 Bitcoin script hash
21 4 Bitcoin (compact) public key (proposed)
52 M or N Namecoin pubkey hash
128 5 Private key
111 m or n Bitcoin testnet pubkey hash
196 2 Bitcoin testnet script hash

List of address prefixes is a more complete list.

[edit] Source https://github.com/bitcoin/bitcoin/blob/master/src/base58

TecKhan Wallet for Android is a design document infrastructure providing education to the Bitcoin community,or describing Bitcoin virtual environments.

https://en.bitcoin.it/wiki/Donation-accepting_organizations_and_projects

https://en.bitcoin.it/wiki/Stuff_Exists

Copyright © 2007 Author:Duchess B.Breinstein

All rights reserved.

Meetups

2013-05-17T16:30:12Z

Ahazred8oc: /* See Also */ added category:Meetups

Don't add everyone who's going in the "Who?" column, just prominent Bitcoin members and organizers. Also see [http://bitcoin.meetup.com bitcoin.meetup.com]. Also see [[Conferences]].

Keep an eye on the [http://bitcointalk.org/index.php?board=86.0 Meetups] forum board on BitcoinTalk for announcements.

{| class="wikitable"
|-
! Group
! When?
! Where?
! Who?
! Other Notes
|-
| [http://www.meetup.com/bitcoins/ Bitcoin NYC]
| monthly
| [http://www.xcubicle.com/ xCubicle Hackerspace - New York, NY]
| Any and all Bitcoin aficionados.
|
|-
|-
| [http://hitspace.org/ HIT Space - Hack it Together]
| monthly
| [http://hitspace.org/where-we-are/ HIT Space - Porto, Portugal]
| Hackerspace members and anyone who want to join us
| send us an email geral[at]hitspace.org
|-
|-
| [http://metalab.at/wiki/Bitcoins Vienna, Austria]
| monthly - check the [http://metalab.at/wiki/Bitcoins wiki] or subscribe to the [http://lists.keisanki.net/listinfo/bitcoin mailinglist]
| [http://metalab.at/wiki/Lage Metalab], Vienna hacker space, Rathausstraße 6, 1010 Wien
| Bitcoin Group Austria
|
|-
| [http://brmlab.cz brmlab, prague hackerspace]
| 14th Nov 2011
28th Nov 2011
([http://brmlab.cz/event/bitcoin_seminar])
| [http://brmlab.cz/place Brmlab, Bubenska 1]
| brmlab crew, slush, genjix
|
|-
| [http://www.facebook.com/groups/175596065827848/ Bitcoin Boston]
| Bi-weekly on Saturday or Sunday ([http://www.facebook.com/groups/175596065827848/ See Facebook page])
| Starbucks, Harvard Square
| Anyone who wants to come!
| So far our meetings have been pretty sporadic, but we hope to gain some regularity soon...
|-
| [http://www.meetup.com/bitcoin New York Bitcoin Users]
| 6:00 PM, 3rd Sunday of every month ([http://www.meetup.com/bitcoin/events/past past meetings])
| OnlyOneTV Studios - 290 Fifth Ave New York, NY
| Bruce Wagner (Organizer) and others
|
|-
|-
| [http://www.meetup.com/bitcoin New York Bitcoin Users]
| 6:00 PM, every Wednesday of every month ([http://www.meetup.com/bitcoin/events/past past meetings])
| Just Sweet Dessert House - 83 Third Ave New York, NY
| Yifu Guo (Organizer) and crew
| hosted by Bitsyncom, the people behind [[Bitnavigator]], walk-ins welcome;
|-
|[http://www.meetup.com/MichiganBitcoinMeetup Michigan Bitcoin Meetup]
|
|
|Kinnard Hockenhull (Organizer)
|Sponsored by [[BitBox]]
|-
| [http://www.meetup.com/PhillyBitcoin Philadelphia Bitcoin User Group]
| TBD
| TBD
| Brian Cohen (Organizer) and others
|
|-
| [http://www.meetup.com/BitcoinDC Washington, DC Bitcoin Users]
| 7:00 PM, 1st Monday of every month ([http://www.meetup.com/BitcoinDC/#past past meetings])
| Northside Social, 3211 Wilson Blvd Arlington, VA
| [[User:Dduane|Darrell Duane]] (Organizer) and others
|
|-
| [http://www.meetup.com/Silicon-Valley-Bitcoin-Users Silicon Valley Bitcoin Users]
| 7:00 PM, Tuesday, June 14, 2011 ([http://www.meetup.com/Silicon-Valley-Bitcoin-Users/events/past past meetings])
| 140B S Whisman Road Mountain View, CA
| Brian Mcqueen and others
|
|-
| [http://www.meetup.com/BitcoinChicago Chicago]
| No regular schedule yet ([http://www.meetup.com/BitcoinChicago/events/past past meetings])
| Sunnyvale Art Gallery Cafe, 251 W El Camino Real Sunnyvale, CA
| Igor
|
|-
| [http://www.meetup.com/denver-bitcoin Denver]
| First meeting June 4th, 2011 ([http://www.meetup.com/denver-bitcoin/events/past past meetings])
| Gypsy House Cafe - 1279 Marion St Denver, CO
| bearbones
|
|-
| [http://www.meetup.com/bitcoinSF Bitcoin SF]
| Saturday, June 4, 2011 ([http://www.meetup.com/bitcoinSF past meetings])
| SFSU - 1600 Holloway Ave. San Francisco, CA
| Brian Mcqueen and others
|
|-
| [http://www.meetup.com/Los-Angeles-Digital-Currency-Innovators-Group Los Angeles Digital Currency Innovators]
| Thursday July 7th, 2011, 7 PM
| (mt)/Media Temple, Culver City, CA
| [[User:sgornick|Stephen Gornick]] (Interim organizer) and others
| Seeking meetup coordinator
|-
| [http://www.meetup.com/Las-Vegas-Bitcoin-Users Las Vegas Bitcoin Users]
| Monthly, check calendar ([http://www.meetup.com/Las-Vegas-Bitcoin-Users/#upcomming meetings])
| Putters, 6945 South Rainbow Boulevard, Las Vegas, NV
| Mark Russell, Julian Tosh
|
|-
| [https://www.facebook.com/groups/195492163844669/ Free State Bitcoin Consortium]
| Every Saturday, at 6:30 PM
| Strange Brew Tavern, Manchester, NH
| ben-abuya (organizer)
| Weekly
|-
| [https://www.facebook.com/groups/195492163844669/ Twin Cities Users]
| Friday, June 10, 2011, 6:30 PM
| Joule - 1200 Washington Ave S Minneapolis, MN
| Mac Manson
|
|-
| [http://www.meetup.com/Portland-Bitcoin-Meetup-Users Portland Bitcoin Users Meetup Group]
| forming
|
| Steven Wagner
|
|-
| [http://www.meetup.com/Bitcoin-Orlando Bitcoin Orlando]
| ([http://www.meetup.com/Bitcoin-Orlando#past past meetings])
| Frank & Steins 150 S. Magnolia Ave, Orlando, FL
| Antonio Gallippi
|
|-
| [http://www.hive13.org/?p=310 Hive13 Hackerspace]
| Bitcoin Exchange, Every Tuesday, 7:30 PM
| Hive13 - 2929 Spring Grove Avenue, Cincinnati, OH
|
|
|-
| [https://www.facebook.com/bitcoinaus Bitcoin Australia]: Melbourne
| [https://www.facebook.com/events/345430765511234/ Wednesday, 23 May 2012, 18:45]
| Melbourne CBD(TBA)
| Facebook, IRC, Bitcointalk Forum...
|
|-
| [[Bitcoin:Tokyo meetup|Tokyo]]
| Usually first monday of the month
| Shibuya
| Roger Ver (Organizer) and others
|
|-
| [http://meetup.com/Bitcoin-Canada Vancouver Canada]
| ([http://www.meetup.com/Bitcoin-Canada/#past past meetings])
| The Brickhouse - 730 Main St.
| humble (and others)
|
|-
| [https://groups.google.com/d/forum/bitcoin-switzerland Zurich/Geneva Switzerland]
| Semi-regular, about once a month
| Oliver Twist Pub, Zurich; Lord Nelson Pub, Geneva
| Stefan Thomas (WeUseCoins), Mike Hearn (BitcoinJ), bitdragon, Luzius (Wuala), more ...
|
|-
| Seattle Bitcoin Meetup
| [http://www.meetup.com/SeattleBitCoin/ Semi-regularly].
| [http://maps.google.com/maps?q=cafe+solstice&daddr=4116+University+Way,+Seattle,+WA+98105-6214&hl=en&ll=47.657424,-122.31313&spn=0.007328,0.01929&gl=us&view=map&geocode=CRT9Bdg7zX3vFdcx1wIdWqa1-CFcJ9qrr9CcEQ&t=h&z=16 Solstice Cafe, 2pm]
| [https://bitcointalk.org/index.php?action=profile;u=36217 indolering]
|
|-
| [https://bitcointalk.org/index.php?topic=42262.0 Munich Germany]
| Semi-regular, about once a month
| Optimolwerke
|
|
|-
| [http://www.meetup.com/bitcoin-il/ Israel Bitcoin Meetup Group]
| Occasional
| TBD
| Meni Rosenfeld
|
|-
| [http://www.meetup.com/Dallas-Bitcoin-User-Meetup/ Dallas Bitcoin Meetup Group]
| Biweekly on Saturdays, 6:00PM
| [http://freemandallas.com/ The Free Man Cajun Cafe]
| Justus Ranvier (organizer)
|
|-
| [https://en.bitcoin.it/wiki/Cafe Café Bitcoin Sevilla]
|
| Seville, Spain
| Randy Brito (rdymac / btcven), Eduardo (bitcoin.com.es), Jorge and Alfredo
| http://cafebitcoin.com
|-
|}

==See Also==

* [http://hackerspaces.org/wiki/List_of_Hacker_Spaces List of Hacker Spaces]

[[Category:Local]]
[[Category:Meetups]]

[[de:Treffen]]

Vanitygen

2013-05-17T16:18:10Z

Ahazred8oc: added category: Vanity address

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 [[User:ThePiachu|ThePiachu]]'s [[Vanity Pool]].

Current version: 0.22

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]]
* [[Bitcoin Vanity Generation Website]]

[[Category:Vanity address]]

Cafe

2013-05-17T16:04:16Z

Ahazred8oc: /* Café Bitcoin */ English language summary

===Café Bitcoin===

Somos un grupo de usuarios especializados en distintos campos con el objetivo de dar a conocer Bitcoin. Organizamos charlas, reuniones y conferencias en la ciudad de Sevilla y alrededores.

Si estás interesado en organizar una charla introductoria sobre Bitcoin y te gustaría contar con nosotros, estamos a tu disposición.

(We are a specialized group of users in different fields in order to raise awareness of Bitcoin. We organize lectures, meetings and conferences in the city of Seville and surroundings.)

* Twitter https://twitter.com/cafebitcoin

* Website http://cafebitcoin.com

* Email contacto@cafebitcoin.com

* Charlas https://en.bitcoin.it/wiki/Cafe

* Colaborar [bitcoin:1cafeCoDyG9aYpiJeP6S92YFrFPxCZ3V9 '''1cafe'''CoDyG9aYpiJeP6S92YFrFPxCZ3V9]

==Próximas charlas==
====Curso online Primeros pasos con un monedero Bitcoin====

Clase gratuita online para explicar el monedero Electrum. Aprenderás a guardar los bitcoins de una forma segura.

*Lugar: Google Hangout (video-conferencia / online)
*Fecha: 11 / Mayo / 2013
*Hora: 11:00
*Enlace: http://www.floqq.com/course/electrum-un-monedero-bitcoin
*Precio: Gratuito

==Charlas pasadas==

====Taller Cliente Bitcoin: Electrum====

Taller de iniciación sobre el cliente Bitcoin, Electrum. Introducción a la gestión de carteras, realizar y recibir pagos con Bitcoin.

*Lugar: workINcompany
*Dirección: Calle Rioja 13, 1ºC. 41001 - Sevilla - [https://maps.google.es/maps?f=q&source=embed&hl=es&geocode=&q=Coworking+Sevilla+::+workincompany&aq=&sll=37.390073,-5.997527&sspn=0.012122,0.019205&ie=UTF8&hq=Coworking+Sevilla+::+workincompany&hnear=&t=m&ll=37.389118,-6.000338&spn=0.013639,0.01708&z=14 ver mapa]
*Fecha: 15 / Abril / 2013
*Hora: 16:30 a 21:00
*Apuntarse
**Lista: http://d.pr/WO4I
**Evento de Facebook: http://d.pr/3FXw
*Precio: Entrada gratuita

Docs: [http://cafebitcoin.com/docs/Cafe_Bitcoin-Taller_Cliente_Bitcoin_Electrum_15-04-2013.html Bitcoin y Electrum]

====Primer Bitcoin Café====

Encuentro para personas interesadas en Bitcoin, Internet, OpenPGP, Diseño, e-commerce, Tor...

Al ser una charla, todos podemos participar y discutir los temas libremente, el objetivo es estudiar los distintos puntos de vista de cada uno para cada tema a tratar. En esta charla conseguiremos resolver dudas que no nos habíamos planteado individualmente y que además nos servirá para conocer personas interesadas en este sector.

¿Qué es Bitcoin? http://youtu.be/PN0oqKUk7kY

*Lugar: VIPS
*Dirección: Calle Enramadilla s/n, Viapol, 41018 Sevilla
*Fecha: 22 / Febrero / 2013
*Hora: a partir de las 18:00
*Apuntarse:
**Lista: http://bit.ly/BTCCafe
**Evento de Facebook: https://www.facebook.com/events/140167789479847

Bitcoin symbol

2013-05-17T15:50:24Z

Ahazred8oc: /* Existing Unicode symbol */ identify "IDENTICAL TO" symbol (three bars)

== Currency code ==
The [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_4217 currency code] for Bitcoin is '''BTC'''. However, at the moment it is an [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_4217#Without_currency_code unofficial code] according to the ISO 4217 standard but the official code according to the Bitcoin community.

A [https://bitcointalk.org/index.php?topic=7205.msg112577 request] has been made at the [http://www.six-group.com/ organization] maintaining the currency codes in the ISO 4217 standard to support BTC. This has been declined mainly on bases that organizations such as [https://secure.wikimedia.org/wikipedia/en/wiki/Reuters Reuters] and [https://secure.wikimedia.org/wikipedia/en/wiki/Bloomberg Bloomberg] are not reporting on the Bitcoin currency. When this changes, a request can be resubmitted.

== Currency sign ==

B⃦ has been the standard currency sign for BTC for a long time. Some existing Unicode symbols have been proposed but also serious work is being done on creating a custom Bitcoin sign with its own official [https://secure.wikimedia.org/wikipedia/en/wiki/Unicode Unicode] that is recognized by the [https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_Consortium Unicode Consortium]. Note that a currency sign is more complex than creating a logo as will be explained below.

[[File:Example-unicode-reference-currency-signs.png|256px|thumb|right|Examples of Unicode currency sign reference glyphs]]

=== New Unicode symbol ===

In some discussions [https://bitcointalk.org/index.php?topic=41.0 41], [https://bitcointalk.org/index.php?topic=369.0 369] and [https://bitcointalk.org/index.php?topic=7215.0 7215] on the bitcoin forum several designs of an official Bitcoin sign have been proposed. This section on the Wiki is intended to streamline the process of arriving at an official Bitcoin currency sign with its own Unicode character code.

==== Goal ====
Having a unique Bitcoin currency sign will allow typographers to add their currency sign design in their fonts. This is similar as implementing support for the euro sign. Each font has its own version of the euro sign that fits with the style observed in the characters in the rest of the fonts of their typefaces. Note that the Unicode Consortium does not endorse Bitcoin in any way by assigning a Unicode character code, however, having a Unicode for the Bitcoin sign will also be good for PR and help having Bitcoin be taken more seriously.

==== Requirements and criteria ====

A reference Bitcoin sign could/should/must be:
* recognizable as a [https://secure.wikimedia.org/wikipedia/en/wiki/Currency_sign currency sign] such as $ € ¥ £ ¢ (e.g. with one or two vertical or horzontal bars)
* not confusing with existing currency sign such as Thai Baht ฿
* build from recognizable existing characters found on most [https://secure.wikimedia.org/wikipedia/en/wiki/Keyboard_layout#United_States QWERTY keyboards] such as bar |, minus -, hash # and/or capital B referring to currencies and '''B'''itcoin
* easy to use in handwriting
* easy to compose with one or more [https://help.ubuntu.com/community/GtkComposeTable#The%20Gtk%20Compose%20Table compose seuquences] that are still free and refer to the elements recognizable in the sign (For example the euro sign can be composed from = and C even though the = and C are not part of how it is pronounced.)
* ''possible'' to implement in [https://secure.wikimedia.org/wikipedia/en/wiki/Serif serif and sans-serif] (Most of the [http://www.unicode.org/charts/PDF/U20A0.pdf Unicode reference implementations] are made with serifs but sans-serif also exist in sans-serif fonts. So a reference implementation in serif to what is found in the PDF is preferred.)
* ''possible'' to implement in regular, italic, bold and bold italic (for sans-serif the italic will simply be a slanted version)
* in [https://secure.wikimedia.org/wikipedia/en/wiki/SVG SVG] and use this [http://pastebin.com/raw.php?i=FVY8W1W3 template] (save as bitcoin-sign-20110719-template.svg) with updated metadata and public domain or similar free/open/libre license

Note that a reference Bitcoin sign will only be used as a reference by the Unicode Consortium and it is up to typographers to implement their version matching the style of their typefaces and fonts.

==== Submissions====

It is possible to submit proposals for a '''reference implementation''' below until (community must determine date). They will be judged by (community must form committee for this). If you have problems submitting your design, ask a friend with knowledge on editing wikipedia for help.

{| class="wikitable sortable"
|-
! Preview !! Handwritten !! Associations !! Compose sequence(s) !! Designer !! Link to SVG file !! Notes
|-
| [[File:Bitcoin-proposal-1.png|128px]]
|| [[File:Hashbtc.jpg|128px]]
|| hash (#), numeral three (3)
|| B#, #B, 3#, #3
|| Wareen
|| [http://pastebin.com/raw.php?i=MRfcm0Cn Bitcoin-proposal-1.svg]
|| proposal based on original design idea from [https://bitcointalk.org/index.php?topic=41.msg348274#msg348274 RylandAlmanza] and [https://bitcointalk.org/index.php?topic=25102.msg325489#msg325489 netrin]
|-
| [[File:Bitcoin-sign-20110719.png|128px]]
|| [[file:Img075.jpg|128px]]
|| double barred dollar sign ($), capital b (B)
|| B|, |B, B=, =B
|| Pander
|| [http://pastebin.com/raw.php?i=XYsc9DeS bitcoin-sign-20110719.svg]
|| example submission based on [[File:F33980a445.png]]
|}

=== Existing Unicode symbol ===

There is a discussion over [https://bitcointalk.org/index.php?topic=369.0 which Unicode symbol might be the best suited] for bitcoin.

To type Unicode characters, refer to:

* [[Microsoft Windows Unicode Input]]
* [[How to easily type the circled B symbol on a Mac]]

It has led to the following options:

{| class="wikitable sortable"
|-
! Proposed character !! Description & Pros & Cons !! Unicode name !! Unicode decimal input !! Unicode hex input
|-
|<center><big>฿</big></center> ||
* Pros: Displayed correctly on all known OSes
* Cons: It is already used as the Thai Baht (THB) symbol
|| THAI CURRENCY SYMBOL BAHT || || Alt +0E3F
|-
|<center><big>Ƀ</big></center>||
*Pros: Displayed correctly on all known OSes; standard Latin Extended-B character; [http://www.ecogex.com/bitcoin/ See the project Ƀ Another Bitcoin identity]
|| LATIN CAPITAL LETTER B WITH STROKE || ||Alt +0243
|-
|<center><big>ᗸ</big></center>|| Resembles the striked B while being different from Baht symbol ||CANADIAN SYLLABICS CARRIER KHEE || || Alt +15F8
|-
|<center><big>B⃦</big></center>||
*Pros: Similar to current bitcoin.org logo
|| LATIN CAPITAL LETTER B + COMBINING DOUBLE VERTICAL STROKE OVERLAY || || U+0042 U+20E6
|-
|<center><big>B⃫</big></center>||
|| LATIN CAPITAL LETTER B + COMBINING LONG DOUBLE SOLIDUS OVERLAY || || U+0042 U+20EB
|-
|<center><big>Ⓑ</big></center>||
*Pros: Similar to current bitcoin.org logo
|| CIRCLED LATIN CAPITAL LETTER B || || Alt +24B7
|-
|<center><big>ⓑ</big></center>||
*Pros: Small b represent the unit bit in computer where capital B is Byte
* Cons: Small fonts are harder to read
|| CIRCLED LATIN SMALL LETTER B || ||Alt +24D1
|-
|<center><big>ᴃ</big></center>|| || LATIN LETTER SMALL CAPITAL BARRED B || ||Alt +1D03
|-
|<center><big>␢</big></center>|| || (Unicode Block: Control Pictures) BLANK SYMBOL (graphic for space) || || Alt +2422
|-
|<center><big>β</big></center>||
*Pros: Fluid look and easy to write; Lowercase 
*Cons: Languages that use this character don't consider it a B. in Greek it's a V, and the German character it resembles is a hard S.
|| GREEK SMALL LETTER BETA || ||Alt +03B2
|-
|<center><big>∆</big></center>|| delta for "digital" || Greek capital Delta. (In Greek it's pronounced as the "th" in "then" and not like "d" in "digital". || || U+0394
|-
|<center><big>ɸ</big></center>|| contains 0 and I || Greek small Phi || || U+0278
|-
|<center><big>币</big></center>|| pronounced "bi", combines "b", turned "c" and "T", many Chinese users, also 网民币 - Wangminbi, "The Netizen's Currency" (pun on Renminbi) || Chinese for "Currency" || || U+5E01
|-
|<center><big>¤</big></center>|| || CURRENCY SIGN ||Alt 0164 ||Alt +00A4
|-
|<center><big>Ƅ</big></center>|| || LATIN CAPITAL LETTER TONE SIX || ||Alt +0184
|-
|<center><big>∄</big></center>|| || (Unicode Block: Mathematical Operators) THERE DOES NOT EXIST || ||Alt +2204
|-
|<center><big>≡</big></center>|| three bars like three bits
* Cons: this resembles the letter ksi (Ξ) in Greek and it sounds like "x" in "axiom".
|| (Unicode Block: Mathematical Operators) IDENTICAL TO || || U+2261
|-
|<center><big>ઘ</big></center>|| || GUJARATI LETTER GHA (Indo-Aryan language) || ||Alt +0A98
|-
|<center><big>ϭ</big></center>|| || (Unicode Block: Greek and Coptic) COPTIC SMALL LETTER SHIMA || ||Alt +03ED
|-
|<center><big>ⓢ</big></center>|| Purposed as a smaller unit of bitcoin. E.g. A hundredth of a bitcoin || CIRCLED LATIN SMALL LETTER S || || Alt +24E2
|-
|<center><big>◪</big></center>|| || (Unicode Block: Geometric Shapes) SQUARE WITH LOWER RIGHT DIAGONAL HALF BLACK || || Alt +25EA
|-
|<center><big>☺</big></center>|| ||WHITE SMILING FACE|| || Alt +263A
|-
|<center><big>☻</big></center>|| ||BLACK SMILING FACE|| || Alt +263B
|-
|<center><big>㋡</big></center>|| ||CIRCLED KATAKANA TU' (Japanese)|| || Alt +32E1
|-
|<center>[[Image:Bat.png|24px|alt=The b'at]] 
the b'at</center>
||
* Pros: Is round like a coin. Contains the B for Bitcoin. Borrows a style widelly associated with the internet. Not used for other meanings.
* Cons: Does not exist in the Unicode standard
* Cons: Very similar to the existing trademarked Broad logo [[http://www.broad.com/]]
|| n/a || ||
|-
|<center>[[Image:Bitcoin Symbol Suggestion circled struck-through B.png|24px]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|-
|<center>[[Image:Bitcoin Symbol Suggestion rotated power.png|24px]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|-
|<center>A 'C' with '1' and '0' inside [[http://img829.imageshack.us/img829/8840/bitcoinlogodraft.png]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|-
|<center>A 'C' with a 'circle' and 'dot' inside [[http://img836.imageshack.us/img836/6006/bitcoinlogodraftii.png]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|-
|<center>B-T-C monogram [[http://hosting11.imagecross.com/image-hosting-61/2381unicode1s.png]][[http://hosting11.imagecross.com/image-hosting-61/162bitcoin_uni_s.png]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|}

==See Also==

* [[Promotional graphics]]

[[Category:Introduction]]

Bitcoin symbol

2013-05-16T22:51:27Z

Ahazred8oc: /* Existing Unicode symbol */ make the symbols <big>

== Currency code ==
The [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_4217 currency code] for Bitcoin is '''BTC'''. However, at the moment it is an [https://secure.wikimedia.org/wikipedia/en/wiki/ISO_4217#Without_currency_code unofficial code] according to the ISO 4217 standard but the official code according to the Bitcoin community.

A [https://bitcointalk.org/index.php?topic=7205.msg112577 request] has been made at the [http://www.six-group.com/ organization] maintaining the currency codes in the ISO 4217 standard to support BTC. This has been declined mainly on bases that organizations such as [https://secure.wikimedia.org/wikipedia/en/wiki/Reuters Reuters] and [https://secure.wikimedia.org/wikipedia/en/wiki/Bloomberg Bloomberg] are not reporting on the Bitcoin currency. When this changes, a request can be resubmitted.

== Currency sign ==

B⃦ has been the standard currency sign for BTC for a long time. Some existing Unicode symbols have been proposed but also serious work is being done on creating a custom Bitcoin sign with its own official [https://secure.wikimedia.org/wikipedia/en/wiki/Unicode Unicode] that is recognized by the [https://secure.wikimedia.org/wikipedia/en/wiki/Unicode_Consortium Unicode Consortium]. Note that a currency sign is more complex than creating a logo as will be explained below.

[[File:Example-unicode-reference-currency-signs.png|256px|thumb|right|Examples of Unicode currency sign reference glyphs]]

=== New Unicode symbol ===

In some discussions [https://bitcointalk.org/index.php?topic=41.0 41], [https://bitcointalk.org/index.php?topic=369.0 369] and [https://bitcointalk.org/index.php?topic=7215.0 7215] on the bitcoin forum several designs of an official Bitcoin sign have been proposed. This section on the Wiki is intended to streamline the process of arriving at an official Bitcoin currency sign with its own Unicode character code.

==== Goal ====
Having a unique Bitcoin currency sign will allow typographers to add their currency sign design in their fonts. This is similar as implementing support for the euro sign. Each font has its own version of the euro sign that fits with the style observed in the characters in the rest of the fonts of their typefaces. Note that the Unicode Consortium does not endorse Bitcoin in any way by assigning a Unicode character code, however, having a Unicode for the Bitcoin sign will also be good for PR and help having Bitcoin be taken more seriously.

==== Requirements and criteria ====

A reference Bitcoin sign could/should/must be:
* recognizable as a [https://secure.wikimedia.org/wikipedia/en/wiki/Currency_sign currency sign] such as $ € ¥ £ ¢ (e.g. with one or two vertical or horzontal bars)
* not confusing with existing currency sign such as Thai Baht ฿
* build from recognizable existing characters found on most [https://secure.wikimedia.org/wikipedia/en/wiki/Keyboard_layout#United_States QWERTY keyboards] such as bar |, minus -, hash # and/or capital B referring to currencies and '''B'''itcoin
* easy to use in handwriting
* easy to compose with one or more [https://help.ubuntu.com/community/GtkComposeTable#The%20Gtk%20Compose%20Table compose seuquences] that are still free and refer to the elements recognizable in the sign (For example the euro sign can be composed from = and C even though the = and C are not part of how it is pronounced.)
* ''possible'' to implement in [https://secure.wikimedia.org/wikipedia/en/wiki/Serif serif and sans-serif] (Most of the [http://www.unicode.org/charts/PDF/U20A0.pdf Unicode reference implementations] are made with serifs but sans-serif also exist in sans-serif fonts. So a reference implementation in serif to what is found in the PDF is preferred.)
* ''possible'' to implement in regular, italic, bold and bold italic (for sans-serif the italic will simply be a slanted version)
* in [https://secure.wikimedia.org/wikipedia/en/wiki/SVG SVG] and use this [http://pastebin.com/raw.php?i=FVY8W1W3 template] (save as bitcoin-sign-20110719-template.svg) with updated metadata and public domain or similar free/open/libre license

Note that a reference Bitcoin sign will only be used as a reference by the Unicode Consortium and it is up to typographers to implement their version matching the style of their typefaces and fonts.

==== Submissions====

It is possible to submit proposals for a '''reference implementation''' below until (community must determine date). They will be judged by (community must form committee for this). If you have problems submitting your design, ask a friend with knowledge on editing wikipedia for help.

{| class="wikitable sortable"
|-
! Preview !! Handwritten !! Associations !! Compose sequence(s) !! Designer !! Link to SVG file !! Notes
|-
| [[File:Bitcoin-proposal-1.png|128px]]
|| [[File:Hashbtc.jpg|128px]]
|| hash (#), numeral three (3)
|| B#, #B, 3#, #3
|| Wareen
|| [http://pastebin.com/raw.php?i=MRfcm0Cn Bitcoin-proposal-1.svg]
|| proposal based on original design idea from [https://bitcointalk.org/index.php?topic=41.msg348274#msg348274 RylandAlmanza] and [https://bitcointalk.org/index.php?topic=25102.msg325489#msg325489 netrin]
|-
| [[File:Bitcoin-sign-20110719.png|128px]]
|| [[file:Img075.jpg|128px]]
|| double barred dollar sign ($), capital b (B)
|| B|, |B, B=, =B
|| Pander
|| [http://pastebin.com/raw.php?i=XYsc9DeS bitcoin-sign-20110719.svg]
|| example submission based on [[File:F33980a445.png]]
|}

=== Existing Unicode symbol ===

There is a discussion over [https://bitcointalk.org/index.php?topic=369.0 which Unicode symbol might be the best suited] for bitcoin.

To type Unicode characters, refer to:

* [[Microsoft Windows Unicode Input]]
* [[How to easily type the circled B symbol on a Mac]]

It has led to the following options:

{| class="wikitable sortable"
|-
! Proposed character !! Description & Pros & Cons !! Unicode name !! Unicode decimal input !! Unicode hex input
|-
|<center><big>฿</big></center> ||
* Pros: Gives a currency-like look (it is the symbol for an existing currency, the Thai Baht, but other currency symbols often get reused, like the $); displayed correctly on all known OSes
* Cons: It is already used for the Thai currency, and might confuse people
|| THAI CURRENCY SYMBOL BAHT || || Alt +0E3F
|-
|<center><big>Ƀ</big></center>||
*Pros: [http://www.ecogex.com/bitcoin/ See the project Ƀ Another Bitcoin identity]
|| LATIN CAPITAL LETTER B WITH STROKE || ||Alt +0243
|-
|<center><big>Ⓑ</big></center>||
*Pros: Similar to current bitcoin.org logo
|| CIRCLED LATIN CAPITAL LETTER B || || Alt +24B7
|-
|<center><big>ᗸ</big></center>|| Resembles the striked B while being different from Baht symbol ||CANADIAN SYLLABICS CARRIER KHEE || || Alt +15F8
|-
|<center><big>B⃫</big></center>||
|| LATIN CAPITAL LETTER B + COMBINING LONG DOUBLE SOLIDUS OVERLAY || || U+0042 U+20EB
|-
|<center><big>B⃦</big></center>||
*Pros: Similar to current bitcoin.org logo
|| LATIN CAPITAL LETTER B + COMBINING DOUBLE VERTICAL STROKE OVERLAY || || U+0042 U+20E6
|-
|<center><big>ⓑ</big></center>||
*Pros: Small b represent the unit bit in computer where capital B is Byte
* Cons: Small fonts are harder to read
|| CIRCLED LATIN SMALL LETTER B || ||Alt +24D1
|-
|<center><big>ᴃ</big></center>|| || LATIN LETTER SMALL CAPITAL BARRED B || ||Alt +1D03
|-
|<center><big>␢</big></center>|| || (Unicode Block: Control Pictures) BLANK SYMBOL (graphic for space) || || Alt +2422
|-
|<center><big>币</big></center>|| pronounced "bi", combines "b", turned "c" and "T", many Chinese users, also 网民币 - Wangminbi, "The Netizen's Currency" (pun on Renminbi) || Chinese for "Currency" || || U+5E01
|-
|<center><big>β</big></center>||
*Pros: Fluid look and easy to write; Lowercase 
*Cons: Languages that use this character don't consider it a B. in Greek it's a V, and the German character it resembles is a hard S.
|| GREEK SMALL LETTER BETA || ||Alt +03B2
|-
|<center><big>¤</big></center>|| || CURRENCY SIGN ||Alt 0164 ||Alt +00A4
|-
|<center><big>Ƅ</big></center>|| || LATIN CAPITAL LETTER TONE SIX || ||Alt +0184
|-
|<center><big>∄</big></center>|| || (Unicode Block: Mathematical Operators) THERE DOES NOT EXIST || ||Alt +2204
|-
|<center><big>ઘ</big></center>|| || GUJARATI LETTER GHA (Indo-Aryan language) || ||Alt +0A98
|-
|<center><big>ϭ</big></center>|| || (Unicode Block: Greek and Coptic) COPTIC SMALL LETTER SHIMA || ||Alt +03ED
|-
|<center><big>ɸ</big></center>|| contains 0 and I || Greek small Phi || || U+0278
|-
|<center><big>∆</big></center>|| delta for "digital" || Greek capital Delta. (In Greek it's pronounced as the "th" in "then" and not like "d" in "digital". || || U+0394
|-
|<center><big>ⓢ</big></center>|| Purposed as a smaller unit of bitcoin. E.g. A hundredth of a bitcoin || CIRCLED LATIN SMALL LETTER S || || Alt +24E2
|-
|<center><big>◪</big></center>|| || (Unicode Block: Geometric Shapes) SQUARE WITH LOWER RIGHT DIAGONAL HALF BLACK || || Alt +25EA
|-
|<center><big>☺</big></center>|| ||WHITE SMILING FACE|| || Alt +263A
|-
|<center><big>☻</big></center>|| ||BLACK SMILING FACE|| || Alt +263B
|-
|<center><big>㋡</big></center>|| ||CIRCLED KATAKANA TU' (Japanese)|| || Alt +32E1
|-
|<center><big>B⃦</big></center>|| || ? || ||
|-
|<center><big>≡</big></center>|| three bars like three bits
* Cons: this resembles the letter ksi (Ξ) in Greek and it sounds like "x" in "axiom".
|| ? || || Alt + 240
|-
|<center>[[Image:Bat.png|32x32px|alt=The b'at]] 
the b'at</center>
||
* Pros: Is round like a coin. Contains the B for Bitcoin. Borrows a style widelly associated with the internet. Not used for other meanings.
* Cons: Does not exist in the Unicode standard
* Cons: Very similar to the existing trademarked Broad logo [[http://www.broad.com/]]
|| n/a || ||
|-
|<center>A 'C' with '1' and '0' inside [[http://img829.imageshack.us/img829/8840/bitcoinlogodraft.png]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|-
|<center>A 'C' with a 'circle' and 'dot' inside [[http://img836.imageshack.us/img836/6006/bitcoinlogodraftii.png]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|-
|<center>[[Image:Bitcoin Symbol Suggestion circled struck-through B.png|20px]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|-
|<center>[[Image:Bitcoin Symbol Suggestion rotated power.png|20px]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|-
|<center>[[http://hosting11.imagecross.com/image-hosting-61/2381unicode1s.png]][[http://hosting11.imagecross.com/image-hosting-61/162bitcoin_uni_s.png]]</center>||
* Cons: Does not exist in the Unicode standard
|| n/a || ||
|}

==See Also==

* [[Promotional graphics]]

[[Category:Introduction]]

GetBitcoin

2013-05-14T14:15:01Z

Ahazred8oc: GetBitcoin is no longer operating

GetBitcoin was an [[currency exchange|exchange]] service operating from July 2011 to September 2012.

==History==

The service was launched July 3, 2011<ref>[http://forum.bitcoin.org/index.php?topic=25528.0 GetBitcoin - New Site For Exchanging Bitcoin/USD]</ref>. The company GetBitcoin LLC is (?) registered entity in the State of Delaware (File# 4997818). Complaints began in September 2012 and the website has been down since then.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [http://www.thebitcoinreview.com/site.php?site_id=5 thebitcoinreview thread]
* [https://www.get-bitcoin.com Get-Bitcoin.com] (web site down since September 2012)

==References==
<References />

[[Category:Exchanges]]

Payment methods

2013-05-09T22:52:17Z

Ahazred8oc: regroup good methods and bad methods

When trading bitcoins for other currencies, one issue that frequently comes up is the mismatch between the hardness (non-reversibility) of bitcoin, and the softness (reversibility) of many of other payment methods. This page lists a number of payment methods, hardness ratings, and more detailed info in the notes field. There is a separate section for virtual currencies at the bottom of the page.

Hardness goes from 0 (extremely soft) to 10 (completely non-reversible).

{| style="border: 1px solid #c6c9ff; border-collapse: collapse;" cellspacing="0" cellpadding="10" border="1"
|- style="text-align: center; background-color: #f0f0ff;"
! Method !! Currencies !! Hardness || Notes
|-
| [[Bank wire]] || Various || 10 || Very good match for trading bitcoin. Quick (but expensive) transfers that are not reversible. (Note: be sure the wire has fully cleared. Also can't hurt to confirm with your bank that they won't yank it upon sender request without asking your permission.)
|-
| Euro SEPA transfer || EUR || 8 || Usually free wire transfer between European banks. Cleared in one working day after the transaction is done. Unauthorized transfers can be reversed. One trader got his bank account closed and an entry in the database of financially unreliable people after receiving a fraudulent transfer.
|-
| [[OKPay]] || USD, EUR, GBP, RUB, CHF, CZK, AUD, CAD, JPY etc || 10 || Simple Bitcoin processing service. Completely non-reversible. Support of 19 world currencies.
|-
| [[Perfect Money]] || EUR, USD, XAU || 10 || Very good match for trading bitcoin. Absolutely no chargebacks. Funding of Perfect Money e-currency is possible via Bank Transfer and using other methods via third-party exchangers. There is built-in Credit Exchange inside Perfect Money.
|-
| [[Liberty Reserve]] || EUR, USD || 10 || Very good match for trading bitcoin. However, it is difficult to get LR funded - it is only possible through third-party exchangers.
|-
| Webmoney || USD, RUB, BYR, EUR, XAU || 10 || Very good match for trading bitcoin. Requires funding by bank wire though, which may be expensive for small amounts.
|-
| Western Union Money Transfer || ? || 9 || A money transfer can be stopped but once funds are withdrawn as cash there's little risk<ref>[http://www.ehow.com/how_8059315_stop-payment-via-western-union.html How to Stop Payment Via Western Union]</ref>.
|-
| [[Redeemable code]] from an exchange || USD, BTC || ? || These are generally bearer instruments so the "hardness" would seem to approach a 10 however each exchange that issues a redeemable code may have its own policy. As these are a fairly new tool, it is not known if any exchanges will refuse to honor a code of their own (e.g., customer claims that the code had been stolen).
|-
| [[PayPal]] - regular || Most world currencies || 0 || Extremely easy to charge back. Also, since trading bitcoin is against their ToS, good luck disputing the chargeback. Do not use.
|-
| Paypal - personal || Most world currencies || 1-5 || If funded via bank, requires person to dispute the ACH, which may be more arduous. If funded via credit card, requires person to dispute the CC charge, which is pretty easy. Since there's no way to tell what the funding source was... it's a gamble. Also, if paypal account is reported stolen, paypal will probably attempt to claw back the money.
|-
| Paypal - masspay || Most world currencies || 7? || Mass pay requires funding from paypal balance. Generally much harder to reverse, but not impossible. Probably your biggest worry here is an actual stolen account.
|-
| Cash in mail || Any currency || 10 || No chargebacks, obviously. Just check for counterfeit paper.
|-
| Cash at bank || Any currency || n/a || Some exchanges (e.g., [[Virtex]] and OTC traders accept cash deposited to an account at a bank.
|-
| Check at bank || Any currency || n/a || Some exchanges accept a check deposited to an account at a bank.
|-
| Bitcoin || BTC || 10 || While the bitcoin network has no concept of a bitcoin transaction being reversed, there could be the possibility of an exchange or merchant refusing to accept a bitcoin for various reasons (e.g., funds were stolen).
|-
| Intra-bank transfer || Any currency || n/a ||
|-
| AliPay || CNY || n/a || Though reports of reversed AliPay payments can be found on the Internet, the operator of [[Bitcoinica]] asserts that AliPay transaction are "non-reversible"<ref>[http://bitcointalk.org/index.php?topic=65003.msg763730#msg763730 Bitcoinica now supports Alipay deposit!]</ref>.
|-
| [[UKash]] || many || n/a || A cash-based voucher system.
|-
| [[CashU]] || many || n/a || A cash-based prepaid card / redeemable code.
|-
| [[TransferWise]] || GBP to EUR || ? ||
|-
| Neteller || ? || ? ||
|-
| [[MoneyPak]] || USD || 7 || MoneyPaks are reversible if claimed stolen. There have been reports where the party attempting to redeem a MoneyPak number has been asked to provide a copy of the receipt used to purchase the MoneyPak. Ask for a copy of the receipt when accepting MP to protect yourself.
|-
| Money Order || Many currencies || 5 || A money order can be lost or stolen and there are procedures for reporting that. Losses could occur even weeks after the check has cleared<ref>[http://www.ehow.com/how_7319971_stop-payment-money-order.html How to Stop Payment on a Money Order]</ref>.
|-
| Personal check || Any currency || 5 || At least in the USA, once a check clears, it is hard to claw back except when fraud is alleged.
|-
| Bank ACH || USD || 5 || Sometimes referred to a type of ACH transaction, a direct deposit. Though not very easily, ACH can actually be clawed back if the transaction was the result of fraud.
|-
| [[Popmoney]] ACH || USD || 5 || Since Popmoney transfers occur via ACH, Popmoney will reverse payments if the funds were the result of fraud.
|-
| [[ING Person2Person]] || USD || 5 || Since Person2Person transfers occur via ACH, ING will reverse payments if the funds were the result of fraud.
|-
| [[Pingit]] || UK || 5 || Barclays will reverse payments if the funds were the result of fraud.
|-
| Interac e-Transfer || CAD || 3 || A funds transfer service between personal and business accounts at participating
Canadian financial institutions. In cases of identity theft the transfer may be reversed, especially if both parties are with the same financial institution<ref>[http://bitcointalk.org/index.php?topic=118631.0 Is Interac e-transfer a good way of trading bitcoins?]</ref>.
|-
| Chase QuickPay || USD || 3 || Chase has reversed legitimate transactions as the result of anti-fraud measures<ref>[http://forum.bitcoin.org/index.php?topic=11494.0 Chase QuickPay NOT RECOMMENDED]</ref> requiring the sender to be trusted to re-pay. The sender can also request a reversal after submitting an affidavit alleging that fraud occurred.
|-
| Amazon Gift Card || various || ? || 4. Fraud.
Amazon.com will have the right to close customer accounts and bill alternative forms of payment if a fraudulently obtained Amazon.com Gift Card is redeemed and/or used to make purchases on amazon.com or any of its affiliated websites set forth above. (http://www.amazon.com/gp/gc)
|-
| [[Dwolla]] || USD || 3? || Since Dwolla amounts are funded via ACH, Dwolla will now reverse payments if the funds were the result of fraud. Additionally, Dwolla's Terms and Conditions now state that peyments received are subject to chargebacks as the result of their internal dispute resolution process<ref>[http://www.bitcoinmoney.com/post/8067352221 Dwolla's New Terms: "receiving party may be subject to chargebacks"]</ref>.
|-
| [[Serve]]|| USD || 0 || Extremely easy to charge back.
|-
| [[AlertPay]]|| Many currencies || 1 || Because payment may be made using a credit card a charge back is easy. Doing so however will cause the account to be closed.
|-
| [[Skrill|Skrill (Moneybookers)]] || ? || 0 || Chargebacks are possible. Accounts have been terminated when this payment method was used for a Bitcoin trade.
|-
| gift cards || various || 0 || Chargebacks are possible. Applies to retail store, VISA, and most other gift cards. Do not use.
|-
| Credit / Debit card || Any currency || 0 || Dead easy to charge back<ref>[http://blog.unibulmerchantservices.com/visa-chargeback-reason-codes-and-time-limits Visa Chargeback Reason Codes and Time Limits]</reF>, <ref>[http://blog.unibulmerchantservices.com/mastercard-chargeback-reason-codes MasterCard Chargeback Reason Codes]</ref>. Do not use.
|-
|}

=== Virtual Currencies ===
{| style="border: 1px solid #c6c9ff; border-collapse: collapse;" cellspacing="0" cellpadding="10" border="1"
|- style="text-align: center; background-color: #f0f0ff;"
! Method !! Currencies !! Hardness || Notes
|-
| In-game || SLL || 5 || There may or may not be a dispute process if a user claims a transfer was done against the TOS. SLL originally bought from unauthorized sources (stolen CC, hacked PP) may be deducted from a users SLL balance.
|-
|}

==See Also==

* [[Secure Trading]]
* [[Digital currency]]
* [[:Category:Money transmitters|Money transmitters]]
* [http://stakeventures.com/articles/2012/03/07/the-may-scale-of-money-hardness-and-bitcoin The May Scale of Money Hardness and BitCoin]
* [[Mobile Payment Apps]]

==References==
<references />

[[Category:Financial]]

BIP 0039

2013-05-04T06:01:56Z

Ahazred8oc: wikifying / BIPifying the stub

{{bip}}

<pre>
BIP: BIP-0039
Title: Mnemonic code for deterministic keys
Author: Pavol Rusnak <stick@gk2.sk>, Marek Palatinus <info@bitcoin.cz>
Status: Draft
Type: Standards Track
Created: 14-02-2013
</pre>

==Abstract==

This BIP proposes a scheme for translating binary data (usually master seeds for deterministic keys, but it can be applied to any binary data) into a group of easy to remember words also known as mnemonic code or mnemonic sentence.

==Motivation==

Such mnemonic code or mnemonic sentence is much easier to work with than working with the binary data directly (or its hexadecimal interpretation). The sentence could be writen down on paper (e.g. for storing in a secure location such as safe), told over telephone or other voice communication method, or memorized in ones memory (also called as brainwallet).

Draft and reference implementation is under construction here: https://github.com/prusnak/mnemonic/blob/master/BIP_0039.txt

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

Talk:Bit Gold proposal

2013-05-03T05:28:05Z

Ahazred8oc: /* Nick Szabo's place in the timeline */ new section

How to transfer and prevent double-spending is described in a linked article [http://szabo.best.vwh.net/securetitle.html secure property titles.] This describes a Byzantine-replicated chain of transfers.

== Nick Szabo's place in the timeline ==

Szabo says he worked on the concept "in 1998 (at the same time and on the same private mailing list where Dai was coming up with b-money -- it's a long story)", and described it again in December 2005: http://web.archive.org/web/20060329122942/http://unenumerated.blogspot.com/2005/12/bit-gold.html http://unenumerated.blogspot.com/2011/05/bitcoin-what-took-ye-so-long.html - [[User:Ahazred8oc|Ahazred8oc]] ([[User talk:Ahazred8oc|talk]]) 05:28, 3 May 2013 (GMT)

User:Ahazred8oc

2013-05-02T22:07:56Z

Ahazred8oc: Created page with "helloworld (leave a message)"

helloworld (leave a message)