Bitcoin Wiki - User contributions [en]

Deterministic wallet tools

2020-09-19T14:37:20Z

Lopp: /* Online Services */ remove dead link to bitcore playground

List of tools/services for working with Hierarchical Deterministic Wallets, aka hd-wallets aka bip32 wallets.

Tools listed on this page can typically perform some form of key derivation and list hd-wallet addresses.

'''Warning: You should never give an online service your master extended private key (xprv) as they could use it to drain your entire wallet'''. Even sharing an extended public key [[#Risks of Sharing an Extended Public Key (xpub)|entails risks]]. If using an online hosted javascript tool, be careful to work with it offline only.

See also [[Deterministic Wallet]].

=== Online Services ===
* [https://bitaps.com/bip32 bitaps.com/bip32]: BIP32 calculator. Calculate addresses and keys from BIP32 extended private or public keys.
* [https://bitaps.com/mnemonic bitaps.com/mnemonic]: Mnemonic tools. Create, verify or restore wallet using BIP39 mnemonic code. Split mnemonic with threshold secrets or combine secrets with Shamir secret sharing.
* [https://blockpath.com/wallets/new?action=appxpub Blockpath]: Automatically scan all derivation paths for an xPub/yPub/zPub and view the balance of each used address, or generate all addresses and export them as text.
* [http://bip32.org/ bip32.org]: A tool for displaying information derived from bip32 extended key, or nmenonic phrase. Appears to list only the first address.
* [https://iancoleman.github.io/bip39/ Mnemonic Code Converter]: A tool for listing keys and addresses from a bip39 mnemonic phrase. The tool can be saved as a file and used without any internet connection.
* [https://webhdwallet.github.io/ WebHDWallet]: Implementing the Hierarchical Deterministic Wallet proposal BIP32, with the aim of creating easy to use, secure, and powerful tools for managing HD wallets and the funds within.
* [https://mybitprices.info/hd-wallet-addrs.html mybitprices.info]: A tool that can derive all used wallet addresses from an extended public key and can further lookup historic price information for all wallet transactions and create gain/loss reports.
* [https://jlopp.github.io/xpub-converter/ xpub version converter]: Convert an extended public key between xpub / ypub / zpub etc.

=== Offline Command-line software ===

* [https://github.com/trezor/python-mnemonic python-mnemonic]: Reference implementation of BIP-0039: Mnemonic code for generating deterministic keys
* [https://github.com/dan-da/hd-wallet-derive hd-wallet-derive]: A command-line tool that derives bip32 addresses and private keys from bip32 extended keys or mnemonic, and can generate new master keys as well. Supports segwit (p2sh,bech32) and hundreds of altcoins.
* [https://github.com/dan-da/hd-wallet-addrs hd-wallet-addrs]: A command-line tool for finding bitcoin hd-wallet addresses that have actually received funds, including change addresses. (note: key derivation occurs offline, but funds lookup requires internet connection.)
* [https://github.com/vbuterin/pybitcointools pybitcointools]: Simple, common-sense Bitcoin-themed Python ECC library. by Vitalik Buterin.
* [https://github.com/trezor/python-trezor python-trezor]: Client side implementation for TREZOR-compatible Bitcoin hardware wallets.

=== Risks associated with sharing extended keys with a third party ===

==== Risks of Sharing an Extended Private Key (xprv) DO-NOT-DO-THIS!!! ====

# '''The recipient can spend (steal) all your wallet funds.'''
# The recipient can obtain all your wallet keys and addresses, private and public.
# The recipient can identify and view all your historic transactions.
# The recipient can link all your wallet transactions together, possibly linking anonymous transactions with those associated with your identity.

==== Risks of Sharing an Extended Public Key (xpub) ====

In general it is safest NOT to share an extended public key.

# The recipient can obtain all your wallet public keys and addresses, but not your private keys.
# The recipient can identify and view all your historic transactions.
# The recipient can link all your wallet transactions together, possibly linking anonymous transactions with those associated with your identity.
# If, and only if, the recipient ''also'' obtains a single private key from your wallet, the recipient can obtain all your private keys and steal your funds, just as if they had your xprv key.

[[Category:Wallets]]

Deterministic wallet tools

2020-09-19T14:33:54Z

Lopp: /* Online Services */ add xpub converter

List of tools/services for working with Hierarchical Deterministic Wallets, aka hd-wallets aka bip32 wallets.

Tools listed on this page can typically perform some form of key derivation and list hd-wallet addresses.

'''Warning: You should never give an online service your master extended private key (xprv) as they could use it to drain your entire wallet'''. Even sharing an extended public key [[#Risks of Sharing an Extended Public Key (xpub)|entails risks]]. If using an online hosted javascript tool, be careful to work with it offline only.

See also [[Deterministic Wallet]].

=== Online Services ===
* [https://bitaps.com/bip32 bitaps.com/bip32]: BIP32 calculator. Calculate addresses and keys from BIP32 extended private or public keys.
* [https://bitaps.com/mnemonic bitaps.com/mnemonic]: Mnemonic tools. Create, verify or restore wallet using BIP39 mnemonic code. Split mnemonic with threshold secrets or combine secrets with Shamir secret sharing.
* [https://blockpath.com/wallets/new?action=appxpub Blockpath]: Automatically scan all derivation paths for an xPub/yPub/zPub and view the balance of each used address, or generate all addresses and export them as text.
* [http://bip32.org/ bip32.org]: A tool for displaying information derived from bip32 extended key, or nmenonic phrase. Appears to list only the first address.
* [https://iancoleman.github.io/bip39/ Mnemonic Code Converter]: A tool for listing keys and addresses from a bip39 mnemonic phrase. The tool can be saved as a file and used without any internet connection.
* [https://webhdwallet.github.io/ WebHDWallet]: Implementing the Hierarchical Deterministic Wallet proposal BIP32, with the aim of creating easy to use, secure, and powerful tools for managing HD wallets and the funds within.
* [https://mybitprices.info/hd-wallet-addrs.html mybitprices.info]: A tool that can derive all used wallet addresses from an extended public key and can further lookup historic price information for all wallet transactions and create gain/loss reports.
* [https://bitcore.io/playground/#/hdkeys bitcore playground]: Derive HD keys from a private or public extended key and a path.
* [https://jlopp.github.io/xpub-converter/ xpub version converter]: Convert an extended public key between xpub / ypub / zpub etc.

=== Offline Command-line software ===

* [https://github.com/trezor/python-mnemonic python-mnemonic]: Reference implementation of BIP-0039: Mnemonic code for generating deterministic keys
* [https://github.com/dan-da/hd-wallet-derive hd-wallet-derive]: A command-line tool that derives bip32 addresses and private keys from bip32 extended keys or mnemonic, and can generate new master keys as well. Supports segwit (p2sh,bech32) and hundreds of altcoins.
* [https://github.com/dan-da/hd-wallet-addrs hd-wallet-addrs]: A command-line tool for finding bitcoin hd-wallet addresses that have actually received funds, including change addresses. (note: key derivation occurs offline, but funds lookup requires internet connection.)
* [https://github.com/vbuterin/pybitcointools pybitcointools]: Simple, common-sense Bitcoin-themed Python ECC library. by Vitalik Buterin.
* [https://github.com/trezor/python-trezor python-trezor]: Client side implementation for TREZOR-compatible Bitcoin hardware wallets.

=== Risks associated with sharing extended keys with a third party ===

==== Risks of Sharing an Extended Private Key (xprv) DO-NOT-DO-THIS!!! ====

# '''The recipient can spend (steal) all your wallet funds.'''
# The recipient can obtain all your wallet keys and addresses, private and public.
# The recipient can identify and view all your historic transactions.
# The recipient can link all your wallet transactions together, possibly linking anonymous transactions with those associated with your identity.

==== Risks of Sharing an Extended Public Key (xpub) ====

In general it is safest NOT to share an extended public key.

# The recipient can obtain all your wallet public keys and addresses, but not your private keys.
# The recipient can identify and view all your historic transactions.
# The recipient can link all your wallet transactions together, possibly linking anonymous transactions with those associated with your identity.
# If, and only if, the recipient ''also'' obtains a single private key from your wallet, the recipient can obtain all your private keys and steal your funds, just as if they had your xprv key.

[[Category:Wallets]]

Links to Storage Methods

2020-06-06T20:51:59Z

Lopp: improve casa description, fix link

This page reviews published methods for backing up and storing bitcoin wallets.

== Cold Storage Methods ==

=== Glacier protocol ===

https://glacierprotocol.org/

The glacier protocol is a cold storage scheme. It teaches how to use multiple computers made by different manufacturers which help resist attacks like malicious firmware. The multiple computers are given the same entropy and the user checks that they result in the same bitcoin addresses and private keys. Users are advised to avoid sidechannels like audio, power, magnetic and radio.

The tutorial teaches users to deal with raw private keys and write them down on paper. [[Deterministic wallet]]s are not used, nor are [[full node]]s. Users are instructed to look up their balances on a blockchain explorer website which damages the user's privacy and makes them trust the website for verifying the rules of bitcoin.

=== SmartCustody's Simple Self-Custody Cold Storage ===

[https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md github.com/BlockchainCommons/SmartCustodyWhitePapers]

This guide show how to store coins in a cold storage situation with the ability for heirs to recover your funds if you die. The guide is a bit hard to read with many optional steps, and the "basic scenario" uses 2 hardware wallets with the same seed for some reason. It recommends putting information in a safe deposit box that is enough to steal funds, so you're putting a lot of trust in the safe deposit box. There are Alternate scenarios, but they don't make themselves very clear.

===Yeticold ===

https://yeticold.com/

This website helps you set up an ubuntu machine that you then can run a utility from to create a wallet. It can create hot, warm, or cold wallets. The project is still in Beta and has limited information on how it works.

=== Casa ===

[https://docs.keys.casa/wealth-security-protocol/ Casa] is a multisig system that uses geographically distributed keys on different hardware devices. It is unique in that it recommends against backing up seed phrases, instead offering functionality to easily replace compromised / unusable keys.

=== [[Electrum]]'s cold storage guide ===

https://electrum.readthedocs.io/en/latest/coldstorage.html

The wallet features [[seed phrase]]s, [[Deterministic wallet|deterministic wallets]], offline signing. Unsigned transactions can be transferred with QR codes and saving to a file (which can be put on a USB flash drive or any other transfer method). The wallet can be backed by a [[full node]] if the user connects [[Electrum#Server software|to their own server]], but this is optional and does not happen by default.

The tutorial does not aim to discuss anything about creating a secure offline computer.

=== Rusty Russell's "Remarkably Unreliable Guide To Bitcoin Storage" ===

https://github.com/rustyrussell/bitcoin-storage-guide

The tutorial teaches how to use a laptop as the secure offline computer. It uses ubuntu OS, and Bitcoin Core as the bitcoin wallet. The private key material is stored in raw private key format, not seed phrases (which bitcoin core doesn't support) and so the guide does not benefit from [[Deterministic wallet|deterministic wallets]]. QR codes are used to transfer transactions between the offline and online computers. As the tutorial uses Bitcoin Core it enjoys the benefits of a [[full node]] wallet.

However, it recommends naively splitting keys (without using a secure key-splitting algorithm like [[Shamir's secret sharing|Shamir's secret sharing algorithm]]), and so is insecure and certainly not well vetted.

=== Alexandr Nellson's Scheme ===

[https://medium.com/@nellsonx/how-to-properly-store-bitcoins-and-other-cryptocurrencies-14e0db1910d medium.com/@nellsonx/how-to-properly-store-bitcoins]

This method is relatively basic, glossing over important steps like how to properly airgap a machine, how to create and handle a strong passphrase, and how to back up your seed. It uses usb drives to boot the machine and transfer transaction information, which is a significant attack vector. It also isn't open source and is definitely not well vetted.

=== Cold Wasabi ===

https://docs.wasabiwallet.io/using-wasabi/ColdWasabi.html

This is a pretty basic guide that focuses on using the Wasabi wallet to mix your coins before sending them to a hardware wallet. There is supplementary information about how to setup a hardware wallet and backup your seed, but this doesn't make for a complete or easy-to-use guide. It is open source, and so might be somewhat vetted.

== Other Storage Methods ==

=== Bitgoldwallet's Storage Methods ===

https://www.bitgoldwallet.com/how-to-store-bitcoin.html

This site has a number of different storage methods of both the hot and cold variety. The methods are detailed and complex, and somewhat hard to read. It seems to have some odd recommendations, like using password protected PDF files and Zorin OS. ''More review required.''

== Storage Method Components ==

The items in this section are methods that do not outline a complete backup or storage mechanism, and thus must be combined with other techniques in order to create a security backup or storage mechanism.

* A small paper on bitcoin storage best practices - [https://github.com/devrandom/btc-papers/blob/master/storage-best-practices.md github.com/devrandom/../storage-best-practices.md]
* Pamela Morgan's guides to bitcoin inheritance planning - [https://medium.com/@pamelawjd medium.com/@pamelawjd]
** https://medium.com/@pamelawjd/inheritance-planning-for-cryptocurrencies-3-steps-in-3-minutes-83ebb3e916a2
** https://www.youtube.com/watch?v=ddwWNWg8YSQ&feature=youtu.be
** https://empoweredlaw.com/

Multi-signature

2018-11-15T16:19:28Z

Lopp: add casa multisig wallet

Multisignature (multisig) refers to requiring more than one key to authorize a Bitcoin [[transaction]]. It is generally used to divide up responsibility for possession of bitcoins.

Standard transactions on the Bitcoin network could be called “single-signature transactions,” because transfers require only one signature — from the owner of the private key associated with the Bitcoin address. However, the Bitcoin network supports much more complicated transactions that require the signatures of multiple people before the funds can be transferred. These are often referred to as M-of-N transactions. The idea is that Bitcoins become “encumbered” by providing addresses of multiple parties, thus requiring cooperation of those parties in order to do anything with them. These parties can be people, institutions or programmed scripts.

Consider the following scenario:<blockquote>Suppose I am working with a company that wants to accept Bitcoin for international trades.

The company, for security reasons, would not want a single one of its employees to have access to the company BTC wallet's password. Any transaction would have to meet the approval of more than one employee.

Is this possible already? If not, how could it be implemented with public-key cryptography?<ref>https://bitcointalk.org/index.php?topic=507297.msg5594085</ref></blockquote>

==Implementations==
Shamir's [https://en.wikipedia.org/wiki/Secret_sharing Secret Sharing] Scheme (ssss)<ref>https://point-at-infinity.org/ssss/</ref> is a general software implementation of multisig.

Specific to Bitcoin, [[GreenAddress|GreenAddress.it]], for example, has 2-of-2 and 2-of-3 accounts (requiring at least two keys to authorize a transaction). [[Electrum]] allows a multisig wallet made of any combination of m-of-n. [[Coinbase (business)|Coinbase]] also offers 2-of-3 and 3-of-5 multisig, which they call [https://support.coinbase.com/customer/portal/articles/1743782-what-is-the-multisig-vault- Vault]. [[Blocktrail]] offers 2-of-3 multisig.

This javascript page can create and spend from multisig addresses: https://coinb.in/ But see the warnings about [[Javascript cryptography]].

See also the [[Electrum]] tutorial: http://docs.electrum.org/en/latest/multisig.html

== Multisignature Applications ==

* 1-of-2: Husband and wife petty cash joint account — the signature of either spouse is sufficient to spend the funds.

* 2-of-2: Husband and wife savings account — both signatures are required to spend the funds, preventing one spouse from spending the money without the approval of the other

* 2-of-3: Parents’ savings account for child — the kid can spend the money with the approval of either parent, and money cannot be taken away from the child unless both parents agree

* 2-of-2: Two-factor authentication wallet: One private key is on your primary computer, the other on your smartphone — the funds cannot be spent without a signature from both devices. Thus, an attacker must gain access to both devices in order to steal your funds (much more difficult than one device)

* 3-of-5: Low-trust donation address - five trusted people from a project each hold a private key. Three people are required to actually spend the money but anybody can donate to the project's address. Reduces the risk of embezzlement, hacking/malware or loss due to a single person losing interest in the project. Which private key was used in the final signature is visible on the blockchain which aids accountability.

* 2-of-3: Buyer-seller with trustless escrow - buyer commits money into a 2-of-3 address with the seller and a third-party arbitrator. If transaction goes smoothly, then both buyer and seller sign the transaction to forward the money to the seller. If something goes wrong, they can sign a transaction to refund the buyer. If they cannot agree, they both appeal to the third-party who will arbitrate and provide a second signature to the party that it deems deserves it. The arbitrator cannot steal the money as they have only one key.

* 2-of-3: A board of three directors maintaining funds for their organization — those funds cannot be spent unless any two of those directors agrees. Bigger multi-signature transactions are possible for bigger organizations, such as 3-of-5, 5-of-9, etc.

* 2-of-3: Improved [[hot wallet]] security for businesses - A bitcoin business such as an exchange holds one private key online and one private key as paper backup. A separate bitcoin security firm holds the third key online and will only sign transactions after checking certain conditions (blacklists, whitelists, not more than X withdrawn per time period, two-factor authentication, comply with regulatory environment, etc). If the bitcoin business or the security firm's hot wallets individually get hacked, the bitcoins cannot be stolen. If the bitcoin security firm disappears the business can use the paper backup to access coins.

* 2-of-3: Decentralized [[cold storage]] vault - One of the keys is held in your own home, the second in a bank safe deposit box and copies of the third key are distributed to a close friend, a relative and stored in the office. The home vault is not vulnerable to raiding or burglary because spending the money requires a visit to either the friend, bank or office. Losing the safe deposit box also doesn't result in loss.

* 2-of-2: Smart [[contract]]s building block such as tumblebit, coinswap and [[Lightning Network]].

See also: [[Storing_bitcoins#Multisignature_wallets]]

==History of Multisignature==
Multisignature has been used for thousands of years to protect the security of crypts holding the most precious relics of saints. The superior of a monastery would give monks only partial keys for gaining access to the precious relics. Thus, no single monk could gain access to and possibly steal the relics.<ref>[https://www.youtube.com/watch?v=YcmWQe29zro#t=10m27s Monks at Mt. Athos continue to use "hard" "multisignature" security today.]</ref>

==Multisignature Wallets==

A number of companies have developed multisig wallets:<ref>https://www.reddit.com/r/Bitcoin/comments/4eabpi/multisig_wallets_review_coinkite_alternatives_and/</ref>
* [[Armory]]
* [[CarbonWallet]]
* [[Copay]]
* [[Bitgo]]
* [[Blocktrail]]
* [[GreenAddress]]
* [https://keys.casa Casa]
* [[Coinbase]]
* [[Electrum]]
* [[Xapo]]
* [[Coinkite]]

===Creating a Multisignature Address with Bitcoin-Qt===
A 2of3 multisig address can be created by following these steps:<ref>https://bitcoin.stackexchange.com/a/10593/4334</ref>

<blockquote><ol><li>Gather (or generate) 3 bitcoin addresses, on whichever machines will be participating, using getnewaddress or getaccountaddress RPC commands (or copy and paste from the GUI).</li>
<li>Get their public keys using the <tt>validateaddress</tt> [[API_reference_%28JSON-RPC%29|RPC]] command 3 times.</li>
<li>Then create a 2-of-3 multisig address using addmultisigaddress; e.g.<blockquote><code>bitcoind addmultisigaddress 2 '["044322868cb17d64dcc22185ae2d4493111d73244c3668f8ac79ecc79c0ba8d30a6756d0fa20157 709af3281cc721c7f53321a8cabda29b77900b7e4fe0174b114","..second pubkey..","..third pubkey.."]'</code></blockquote></li></ol><tt>addmultisigaddress</tt> returns the multisignature address. Be a little careful, the public keys are raw hexadecimal and don't contain checksums like bitcoin addresses do. You can then send funds into that 2-of-3 transaction using the normal sendtoaddress/sendmany RPC commands, or the GUI (or anything that's been updated to recognize multisig addresses).<ref>https://bitcointalk.org/index.php?topic=82213.msg906833#msg906833</ref></blockquote>

Gavin Andresen has an example of using multisig with bitcoin-qt [[Raw Transactions]]: https://gist.github.com/gavinandresen/3966071

== Notable examples in practice ==

* The cold storage wallet of the [[Bitfinex]] exchange is a single 3-of-6 multisig address <code>3D2oetdNuZUqQHPJmcMDDHYoqkyNVsFk9r</code> which as of December 2017 contains '''141 177 btc''' ($1.5 billion). Presumably the keys are kept very safe by Bitfinex's operators.

==References==
<references />

* [https://bitcoinmagazine.com/11108/multisig-future-bitcoin/ How To Create A Bitcoin Multisig Wallet]

User:Lopp

2018-09-06T19:52:05Z

Lopp: Created page with "https://lopp.net"

https://lopp.net

Bech32 adoption

2018-09-06T19:44:53Z

Lopp: add misc mobile wallets

[[Bech32]] is a new bitcoin [[address]] format specified by [[BIP 0173]]. This page tracks the adoption of [[Bech32]].

Ideally wallets would first support ''sending to'' bech32 addresses. After almost every wallet can send then people may be willing to adopt bech32 widely for receiving.

The amount of bech32 addresses is tracked on this website: https://p2sh.info/dashboard/db/bech32-statistics?orgId=1

{| class="wikitable"
|-
| {{No}} ||
|-
| {{Evaluating|??}} || Maybe / Haven't checked / placeholder
|-
| {{Planned}} || The developers said they plan to
|-
| {{Acceptable|PR Merged}} || In the case of software, code has been written and merged, and it will be in next release.
|-
| {{Yes}} || Feature has been released
|}

=== Software Wallets ===
{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Bitcoin Core || {{Yes}} || {{Yes}} ||
|-
| Bitcoin Knots || {{Yes}} || {{Yes}} ||
|-
| Electrum || {{Yes}} || {{Yes}} ||
|-
| Armory || {{Evaluating|??}} || {{No}} ||
|-
| JoinMarket || {{Yes}} || {{No}} ||
|-
| GreenAddress || {{Yes}} || {{Planned}} ||
|-
| Breadwallet || {{Yes}} || {{No}} || https://twitter.com/udiWertheimer/status/975810157941796864
|-
| Samourai Wallet || {{Yes}} || {{Yes}} ||
|-
| Coinomi || {{Yes}} || {{Yes}} || [https://www.reddit.com/r/Bitcoin/comments/865qn1/coinomi_wallet_beta_has_segwit_support/ reddit source]
|-
| BTC.com || {{Yes}} || {{No}} ||
|-
| Casa || {{Yes}} || {{No}} ||
|-
| Mycelium || {{No}} || {{No}} ||
|-
| Bitcoin Wallet for Android || {{No}} || {{No}} ||
|}

=== Hardware Wallets ===

Hardware wallet manufacturers typically publish a web wallet or browser add-on wallet for use with their hardware. Users can also sometimes connect their hardware wallet to a software wallet like [[Electrum]].

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Trezor web wallet || {{Acceptable|PR Merged}} || {{No}} ||
|-
| Ledger chrome app || {{No}} || {{No}} ||
|-
| KeepKey chrome app || {{No}} || {{No}} ||
|-
| Digital Bitbox Qt app || {{No}} || {{No}} ||
|-
| Trezor + Electrum || {{Yes}} || {{Yes}} ||
|-
| Ledger + Electrum || {{Yes}} || {{Yes}} ||
|-
| Digital Bitbox + Electrum || {{Yes}} || {{Yes}} ||
|-
| KeepKey + Electrum || {{No}} || {{No}} ||
|}

=== Web Wallets ===

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| Coinapult || {{Evaluating|??}} || {{No}} ||
|-
| Coin.Space || {{Evaluating|??}} || {{No}} ||
|-
| BitGo || {{Evaluating|??}} || {{No}} ||
|-
| blockchain.info web wallet || {{Evaluating|??}} || {{No}} ||
|-
| HolyTransaction || {{Yes}} || {{No}} ||
|-
| [https://coinb.in Coinb.in] || {{Yes}} || {{Yes}} || open source JavaScript implementation
|}

=== Exchanges ===



{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| 1Fox || {{Yes}} || {{No}} || https://1fox.com/?c=en/content/blog&id=12
|-
| Anycoin Direct || {{Yes}} || {{No}} || https://anycoindirect.eu/en/news/details/segwit-activated
|-
| BitBargain.co.uk || {{Yes}} || {{No}} ||
|-
| Bitcoin.de || {{Yes}} || {{No}} || https://bitcoinblog.de/2018/08/10/bitcoin-de-aktiviert-segwit-kunden-sparen-gebuehren/
|-
| Bitfinex || {{No}} || {{No}} ||
|-
| BitMEX || {{Evaluating|??}} || {{No}} ||
|-
| Bittylicious || {{Yes}} || {{No}} || https://twitter.com/Bittylicious_/status/998881327347888128
|-
| Bitstamp || {{No}} || {{No}} ||
|-
| Bitwage || {{Evaluating|??}} || {{No}} ||
|-
| Bisq || {{Evaluating|??}} || {{No}} || https://github.com/bisq-network/bisq-desktop/issues/1139
|-
| Coinbase.com || {{Yes}} || {{No}} || https://twitter.com/diogorsergio/status/983052769262292992
|-
| CoinFalcon || {{Yes}} || {{No}} ||
|-
| Coinfloor || {{Evaluating|??}} || {{No}} ||
|-
| Flyp.me || {{Yes}} || {{No}} ||
|-
| GDax || {{Yes}} || {{No}} || https://www.reddit.com/r/Bitcoin/comments/8c738k/coinbase_gdax_already_allows_sending_to_bc1/
|-
| Gemini || {{No}} || {{No}} ||
|-
| Genesis || {{Evaluating|??}} || {{No}} ||
|-
| Hodl Hodl || {{Yes}} || {{No}} || https://medium.com/@hodlhodl/hodl-hodl-segwit-compatible-exchange-a2231968ac56
|-
| Itbit || {{Evaluating|??}} || {{No}} ||
|-
| Kraken || {{No}} || {{No}} ||
|-
| Liberalcoins || {{Yes}} || {{Yes}} || https://liberalcoins.com
|-
| Localbitcoins.com || {{No}} || {{No}} ||
|-
| Walltime || {{Yes}} || {{Yes}} || https://walltime.info
|}

=== Bitcoin ATM Models ===

Hopefully when a model updates then all its ATMs everywhere will gain that feature. See https://coinatmradar.com/shop/buy-bitcoin-atm/

{| class="wikitable sortable"
|-
! Name !! Send to !! Create/receive !! Notes
|-
| GenesisCoin || {{No}} || {{No}} ||
|-
| General Bytes || {{No}} || {{No}} ||
|-
| Lamassu Douro || {{No}} || {{No}} ||
|}

=== Blockchain Explorers ===

For trying these out you can use mainnet TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.

Some blockchain explorers can only parse the bech32 address and display it, they don't build an index so users cannot search for bech32 addresses.

See also: https://en.bitcoin.it/wiki/Category:Block_chain_browsers

{| class="wikitable sortable"
|-
! Name !! Display !! Index !! Notes
|-
| Blockchair || {{Yes}} || {{Yes}} || https://blockchair.com/
|-
| Blockonomics || {{Yes}} || {{Yes}} || https://www.blockonomics.co
|-
| Bitflyer || {{Yes}} || {{Yes}} || https://chainflyer.bitflyer.jp/
|-
| OXT || {{Yes}} || {{Yes}} || https://oxt.me/
|-
| chaindex || {{Yes}} || {{Yes}} || https://chaindex.com/blockchain/
|-
| blockchain.info || {{Yes}} || {{No}} ||
|-
| Insight || {{No}} || {{No}} || Open source explorer, instances are https://insight.bitpay.com/ and https://chain.localbitcoins.com/
|-
| Blockcypher || {{No}} || {{No}} || https://live.blockcypher.com/btc
|-
| Tradeblock || {{No}} || {{No}} || https://tradeblock.com/bitcoin
|}

=== Payment Processors ===



{| class="wikitable sortable"
|-
! Name !! Invoice addresses !! Withdrawal addresses !! Notes
|-
| [https://coingate.com CoinGate] || {{No}} || {{Yes}} ||
|}

=== Other Services ===

Casinos, marketplaces, etc that let users withdraw money

{| class="wikitable sortable"
|-
! Name !! Withdrawals !! Notes
|-
| 1Broker || {{Yes}} ||
|-
| Crypto-Games.net || {{Yes}} || [https://bitcointalk.org/index.php?topic=750760.msg31421151#msg31421151 bitcointalk source]
|-
| YOLOdice || {{Yes}} || A popular dice site https://yolodice.com
|}

=== References ===

[[Category:Software]]

Running Bitcoin

2017-04-01T19:34:40Z

Lopp: add link to config file generator

There are two variations of the original bitcoin program available; one with a graphical user interface (usually referred to as just “Bitcoin”), and a 'headless' version (called [[bitcoind]]). They are completely compatible with each other, and take the same command-line arguments, read the same configuration file, and read and write the same data files. You can run one copy of either Bitcoin or bitcoind on your system at a time (if you accidently try to launch another, the copy will let you know that Bitcoin or bitcoind is already running and will exit).

__TOC__

==Linux Quickstart==

The simplest way to start from scratch with the command line client, automatically syncing blockchain and creating a wallet, is to just run this command (without arguments) from the directory containing your bitcoind binary:

./bitcoind

To run with the standard GUI interface:

./bitcoin-qt

==Command-line arguments==

These commands are accurate as of Bitcoin Core version '''v0.12.0rc1'''.

{| style="valign:top;"
! scope="col" style="width: 20pt;border: 0px" |
! scope="col" style="width: 150pt;" | Command
! scope="col" | Description
|-
| || -? || This help message
|-
| || -alerts || Receive and display P2P network alerts (default: 1)
|-
| || -alertnotify=<cmd> || Execute command when a relevant alert is received or we see a really long fork (%s in cmd is replaced by message)
|-
| || -blocknotify=<cmd> || Execute command when the best block changes (%s in cmd is replaced by block hash)
|-
| || -checkblocks=<n> || How many blocks to check at startup (default: 288, 0 = all)
|-
| || -checklevel=<n> || How thorough the block verification of -checkblocks is (0-4, default: 3)
|-
| || -conf=<file> || Specify configuration file (default: bitcoin.conf)
|-
| || -datadir=<dir> || Specify data directory
|-
| || -dbcache=<n> || Set database cache size in megabytes (4 to 16384, default: 100)
|-
| || -loadblock=<file> || Imports blocks from external blk000??.dat file on startup
|-
| || -maxorphantx=<n> || Keep at most <n> unconnectable transactions in memory (default: 100)
|-
| || -maxmempool=<n> || Keep the transaction memory pool below <n> megabytes (default: 300)
|-
| || -mempoolexpiry=<n> || Do not keep transactions in the mempool longer than <n> hours (default: 72)
|-
| || -par=<n> || Set the number of script verification threads (-2 to 16, 0 = auto, <0 = leave that many cores free, default: 0)
|-
| || -prune=<n> || Reduce storage requirements by pruning (deleting) old blocks. This mode is incompatible with -txindex and -rescan. Warning: Reverting this setting requires re-downloading the entire blockchain. (default: 0 = disable pruning blocks, >550 = target size in MiB to use for block files)
|-
| || -reindex || Rebuild block chain index from current blk000??.dat files on startup
|-
| || -txindex || Maintain a full transaction index, used by the getrawtransaction rpc call (default: 0)
|-
|-
| colspan="3" | '''Connection options:'''
|-
| || -addnode=<ip> || Add a node to connect to and attempt to keep the connection open
|-
| || -banscore=<n> || Threshold for disconnecting misbehaving peers (default: 100)
|-
| || -bantime=<n> || Number of seconds to keep misbehaving peers from reconnecting (default: 86400)
|-
| || -bind=<addr> || Bind to given address and always listen on it. Use [host]:port notation for IPv6
|-
| || -connect=<ip> || Connect only to the specified node(s)
|-
| || -discover || Discover own IP addresses (default: 1 when listening and no -externalip or -proxy)
|-
| || -dns || Allow DNS lookups for -addnode, -seednode and -connect (default: 1)
|-
| || -dnsseed || Query for peer addresses via DNS lookup, if low on addresses (default: 1 unless -connect)
|-
| || -externalip=<ip> || Specify your own public address
|-
| || -forcednsseed || Always query for peer addresses via DNS lookup (default: 0)
|-
| || -listen || Accept connections from outside (default: 1 if no -proxy or -connect)
|-
| || -listenonion || Automatically create Tor hidden service (default: 1)
|-
| || -maxconnections=<n> || Maintain at most <n> connections to peers (default: 125)
|-
| || -maxreceivebuffer=<n> || Maximum per-connection receive buffer, <n>*1000 bytes (default: 5000)
|-
| || -maxsendbuffer=<n> || Maximum per-connection send buffer, <n>*1000 bytes (default: 1000)
|-
| || -onion=<ip:port> || Use separate SOCKS5 proxy to reach peers via Tor hidden services (default: -proxy)
|-
| || -onlynet=<net> || Only connect to nodes in network <net> (ipv4, ipv6 or onion)
|-
| || -permitbaremultisig || Relay non-P2SH multisig (default: 1)
|-
| || -peerbloomfilters || Support filtering of blocks and transaction with bloom filters (default: 1)
|-
| || -port=<port> || Listen for connections on <port> (default: 8333 or testnet: 18333)
|-
| || -proxy=<ip:port> || Connect through SOCKS5 proxy
|-
| || -proxyrandomize || Randomize credentials for every proxy connection. This enables Tor stream isolation (default: 1)
|-
| || -seednode=<ip> || Connect to a node to retrieve peer addresses, and disconnect
|-
| || -timeout=<n> || Specify connection timeout in milliseconds (minimum: 1, default: 5000)
|-
| || -torcontrol=<ip>:<port> || Tor control port to use if onion listening enabled (default: 127.0.0.1:9051)
|-
| || -torpassword=<pass> || Tor control port password (default: empty)
|-
| || -upnp || Use UPnP to map the listening port (default: 0)
|-
| || -whitebind=<addr> || Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
|-
| || -whitelist=<netmask> || Whitelist peers connecting from the given netmask or IP address. Can be specified multiple times. Whitelisted peers cannot be DoS banned and their transactions are always relayed, even if they are already in the mempool, useful e.g. for a gateway
|-
| || -whitelistalwaysrelay || Always relay transactions received from whitelisted peers (default: 1)
|-
| || -maxuploadtarget=<n> || Tries to keep outbound traffic under the given target (in MiB per 24h), 0 = no limit (default: 0)
|-
| colspan="3" | '''Wallet options:'''
|-
| || -disablewallet || Do not load the wallet and disable wallet RPC calls
|-
| || -keypool=<n> || Set key pool size to <n> (default: 100)
|-
| || -fallbackfee=<amt> || A fee rate (in BTC/kB) that will be used when fee estimation has insufficient data (default: 0.0002)
|-
| || -mintxfee=<amt> || Fees (in BTC/kB) smaller than this are considered zero fee for transaction creation (default: 0.00001)
|-
| || -paytxfee=<amt> || Fee (in BTC/kB) to add to transactions you send (default: 0.00)
|-
| || -rescan || Rescan the block chain for missing wallet transactions on startup
|-
| || -salvagewallet || Attempt to recover private keys from a corrupt wallet.dat on startup
|-
| || -sendfreetransactions || Send transactions as zero-fee transactions if possible (default: 0)
|-
| || -spendzeroconfchange || Spend unconfirmed change when sending transactions (default: 1)
|-
| || -txconfirmtarget=<n> || If paytxfee is not set, include enough fee so transactions begin confirmation on average within n blocks (default: 2)
|-
| || -maxtxfee=<amt> || Maximum total fees (in BTC) to use in a single wallet transaction; setting this too low may abort large transactions (default: 0.10)
|-
| || -upgradewallet || Upgrade wallet to latest format on startup
|-
| || -wallet=<file> || Specify wallet file (within data directory) (default: wallet.dat)
|-
| || -walletbroadcast || Make the wallet broadcast transactions (default: 1)
|-
| || -walletnotify=<cmd> || Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)
|-
| || -zapwallettxes=<mode> || Delete all wallet transactions and only recover those parts of the blockchain through -rescan on startup (1 = keep tx meta data e.g. account owner and payment request information, 2 = drop tx meta data)
|-
| colspan="3" | '''Debugging/Testing options:'''
|-
| || -debug=<category> || Output debugging information (default: 0, supplying <category> is optional). If <category> is not supplied or if <category> = 1, output all debugging information.<category> can be: addrman, alert, bench, coindb, db, lock, rand, rpc, selectcoins, mempool, mempoolrej, net, proxy, prune, http, libevent, tor, zmq, qt.
|-
| || -gen || Generate coins (default: 0)
|-
| || -genproclimit=<n> || Set the number of threads for coin generation if enabled (-1 = all cores, default: 1)
|-
| || -help-debug || Show all debugging options (usage: --help -help-debug)
|-
| || -logips || Include IP addresses in debug output (default: 0)
|-
| || -logtimestamps || Prepend debug output with timestamp (default: 1)
|-
| || -printtoconsole || Send trace/debug info to console instead of debug.log file
|-
| || -shrinkdebugfile || Shrink debug.log file on client startup (default: 1 when no -debug)
|-
| colspan="3" | '''Chain selection options:'''
|-
| || -testnet || Use the test chain
|-
| colspan="3" | '''Node relay options:'''
|-
| || -minrelaytxfee=<amt> || Fees (in BTC/kB) smaller than this are considered zero fee for relaying, mining and transaction creation (default: 0.00001)
|-
| || -limitfreerelay=<n> || Rate-limit free transactions to <n>*1000 bytes per minute (default: 15)
|-
| || -bytespersigop || Minimum bytes per sigop in transactions we relay and mine (default: 20)
|-
| || -datacarrier || Relay and mine data carrier transactions (default: 1)
|-
| || -datacarriersize || Maximum size of data in data carrier transactions we relay and mine (default: 83)
|-
| colspan="3" | '''Block creation options:'''
|-
| || -blockminsize=<n> || Set minimum block size in bytes (default: 0)
|-
| || -blockmaxsize=<n> || Set maximum block size in bytes (default: 750000)
|-
| || -blockprioritysize=<n> || Set maximum size of high-priority/low-fee transactions in bytes (default: 0)
|-
| colspan="3" | '''RPC server options:'''
|-
| || -server || Accept command line and JSON-RPC commands
|-
| || -rest || Accept public REST requests (default: 0)
|-
| || -rpcbind=<addr> || Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6. This option can be specified multiple times (default: bind to all interfaces)
|-
| || -rpcuser=<user> || Username for JSON-RPC connections
|-
| || -rpcpassword=<pw> || Password for JSON-RPC connections
|-
| || -rpcauth=<userpw> || Username and hashed password for JSON-RPC connections. The field <userpw> comes in the format: <USERNAME>:<SALT>$<HASH>. A canonical python script is included in share/rpcuser. This option can be specified multiple times
|-
| || -rpcport=<port> || Listen for JSON-RPC connections on <port> (default: 8332 or testnet: 18332)
|-
| || -rpcallowip=<ip> || Allow JSON-RPC connections from specified source. Valid for <ip> are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This option can be specified multiple times
|-
| || -rpcthreads=<n> || Set the number of threads to service RPC calls (default: 4)
|-
| colspan="3" | '''UI Options:'''
|-
| || -choosedatadir || Choose data directory on startup (default: 0)
|-
| || -lang=<lang> || Set language, for example "de_DE" (default: system locale)
|-
| || -min || Start minimized
|-
| || -rootcertificates=<file> || Set SSL root certificates for payment request (default: -system-)
|-
| || -splash || Show splash screen on startup (default: 1)
|-
| || -resetguisettings || Reset all settings changes made over the GUI
|}

Many of the boolean options can also be set to off by specifying them with a "no" prefix: e.g. -nodnseed.

==Bitcoin.conf Configuration File==
All command-line options (except for -conf) may be specified in a configuration file, and all configuration file options may also be specified on the command line. Command-line options override values set in the configuration file.

The configuration file is a list of setting=value pairs, one per line, with optional comments starting with the '#' character.

The configuration file is not automatically created; you can create it using your favorite plain-text editor. A user-friendly configuration file generator is [https://jlopp.github.io/bitcoin-core-config-generator/ available here]. By default, Bitcoin (or bitcoind) will look for a file named 'bitcoin.conf' in the bitcoin [[data directory]], but both the data directory and the configuration file path may be changed using the -datadir and -conf command-line arguments.
{|
! Operating System
! Default bitcoin datadir
! Typical path to configuration file
|-
| Windows
| %APPDATA%\Bitcoin\
| C:\Users\username\AppData\Roaming\Bitcoin\bitcoin.conf
|-
| Linux
| $HOME/.bitcoin/
| /home/username/.bitcoin/bitcoin.conf
|-
| Mac OSX
| $HOME/Library/Application Support/Bitcoin/
| /Users/username/Library/Application Support/Bitcoin/bitcoin.conf
|}

Note: if running Bitcoin in testnet mode, the sub-folder "testnet" will be appended to the data directory automatically.

==Sample Bitcoin.conf==

Copied from https://github.com/bitcoin/bitcoin/blob/master/contrib/debian/examples/bitcoin.conf:

<pre>
##
## bitcoin.conf configuration file. Lines beginning with # are comments.
##

# Network-related settings:

# Run on the test network instead of the real bitcoin network.
#testnet=0

# Run a regression test network
#regtest=0

# Connect via a SOCKS5 proxy
#proxy=127.0.0.1:9050

# Bind to given address and always listen on it. Use [host]:port notation for IPv6
#bind=<addr>

# Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
#whitebind=<addr>

##############################################################
## Quick Primer on addnode vs connect ##
## Let's say for instance you use addnode=4.2.2.4 ##
## addnode will connect you to and tell you about the ##
## nodes connected to 4.2.2.4. In addition it will tell ##
## the other nodes connected to it that you exist so ##
## they can connect to you. ##
## connect will not do the above when you 'connect' to it. ##
## It will *only* connect you to 4.2.2.4 and no one else.##
## ##
## So if you're behind a firewall, or have other problems ##
## finding nodes, add some using 'addnode'. ##
## ##
## If you want to stay private, use 'connect' to only ##
## connect to "trusted" nodes. ##
## ##
## If you run multiple nodes on a LAN, there's no need for ##
## all of them to open lots of connections. Instead ##
## 'connect' them all to one node that is port forwarded ##
## and has lots of connections. ##
## Thanks goes to [Noodle] on Freenode. ##
##############################################################

# Use as many addnode= settings as you like to connect to specific peers
#addnode=69.164.218.197
#addnode=10.0.0.2:8333

# Alternatively use as many connect= settings as you like to connect ONLY to specific peers
#connect=69.164.218.197
#connect=10.0.0.1:8333

# Listening mode, enabled by default except when 'connect' is being used
#listen=1

# Maximum number of inbound+outbound connections.
#maxconnections=

#
# JSON-RPC options (for controlling a running Bitcoin/bitcoind process)
#

# server=1 tells Bitcoin-Qt and bitcoind to accept JSON-RPC commands
#server=0

# Bind to given address to listen for JSON-RPC connections. Use [host]:port notation for IPv6.
# This option can be specified multiple times (default: bind to all interfaces)
#rpcbind=<addr>

# You must set rpcuser and rpcpassword to secure the JSON-RPC api
#rpcuser=Ulysseys
#rpcpassword=YourSuperGreatPasswordNumber_DO_NOT_USE_THIS_OR_YOU_WILL_GET_ROBBED_385593

# How many seconds bitcoin will wait for a complete RPC HTTP request.
# after the HTTP connection is established.
#rpcclienttimeout=30

# By default, only RPC connections from localhost are allowed.
# Specify as many rpcallowip= settings as you like to allow connections from other hosts,
# either as a single IPv4/IPv6 or with a subnet specification.

# NOTE: opening up the RPC port to hosts outside your local trusted network is NOT RECOMMENDED,
# because the rpcpassword is transmitted over the network unencrypted.

# server=1 tells Bitcoin-Qt to accept JSON-RPC commands.
# it is also read by bitcoind to determine if RPC should be enabled
#rpcallowip=10.1.1.34/255.255.255.0
#rpcallowip=1.2.3.4/24
#rpcallowip=2001:db8:85a3:0:0:8a2e:370:7334/96

# Listen for RPC connections on this TCP port:
#rpcport=8332

# You can use Bitcoin or bitcoind to send commands to Bitcoin/bitcoind
# running on another host using this option:
#rpcconnect=127.0.0.1

# Transaction Fee Changes in 0.10.0

# Send transactions as zero-fee transactions if possible (default: 0)
#sendfreetransactions=0

# Create transactions that have enough fees (or priority) so they are likely to begin confirmation within n blocks (default: 1).
# This setting is over-ridden by the -paytxfee option.
#txconfirmtarget=n

# Miscellaneous options

# Pre-generate this many public/private key pairs, so wallet backups will be valid for
# both prior transactions and several dozen future transactions.
#keypool=100

# Pay an optional transaction fee every time you send bitcoins. Transactions with fees
# are more likely than free transactions to be included in generated blocks, so may
# be validated sooner.
#paytxfee=0.00

# User interface options

# Start Bitcoin minimized
#min=1

# Minimize to the system tray
#minimizetotray=1
</pre>

==Platforms==
===Windows===

====Start automatically====
To configure the Bitcoin client to start automatically:

You might use the configuration-file, or the GUI-Settings:

Settings -> Options

then mark the checkbox titled:
[X] Start Bitcoin on system startup

[[{{ns:file}}:Client_Settings_Options_windows.png]]

====Batch automation====
To work with batch, you have to start the daemon (bitcoind.exe). The bitcoin.exe run with option "-server" will respond with GUI-messages you are not able to process its answers.

===Mac===
[[{{ns:file}}:MacBitcoinStartOnLogin.png]]

===Linux===
[[{{ns:file}}:Client_Settings_Options.png]]

==See Also==

* [[Data directory]]

[[es:Ejecución de Bitcoin]]

[[Category:Technical]]
[[Category:Developer]]

{{Bitcoin Core documentation}}