Bitcoin Wiki - User contributions [en]

Protocol documentation

2021-07-30T18:08:27Z

Fresheneesz: /* Common structures */ add that All field sizes are numbers of bytes.

This page ''describes'' the behavior of the [[Original Bitcoin client|reference client]]. The Bitcoin protocol is specified by the behavior of the reference client, not by this page. In particular, while this page is quite complete in describing the [[network]] protocol, it does not attempt to list all of the rules for block or transaction validity.

Type names used in this documentation are from the C99 standard.

For protocol used in mining, see [[getblocktemplate]].

==Common standards==

=== Hashes ===

Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).

Example of double-SHA-256 encoding of string "hello":

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)

For bitcoin addresses (RIPEMD-160) this would give:

hello
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)

=== Merkle Trees ===

Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.

If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.

First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.

Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.

This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.

For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is:

d1 = dhash(a)
d2 = dhash(b)
d3 = dhash(c)
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice

d5 = dhash(d1 concat d2)
d6 = dhash(d3 concat d4)

d7 = dhash(d5 concat d6)

where

dhash(a) = sha256(sha256(a))

''d7'' is the Merkle root of the 3 transactions in this block.

Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bytes need to be reversed before they are hashed, and again after the hashing operation.

=== Signatures ===

Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions.

For [[ECDSA]] the secp256k1 curve from http://www.secg.org/sec2-v2.pdf is used.

Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.

Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).

=== Transaction Verification ===
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.

Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.

Each ''output'' determines which Bitcoin address (or other criteria, see [[Script]]) is the recipient of the funds.

In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.

A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.

The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.

=== Addresses ===

A bitcoin address is in fact the hash of a ECDSA public key, computed this way:

Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)

The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.

== Common structures ==

Almost all integers are encoded in little endian. Only IP or port number are encoded big endian. All field sizes are numbers of bytes.

=== Message structure ===

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown
|-
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)
|-
| 4 || length || uint32_t || Length of payload in number of bytes
|-
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))
|-
| ? || payload || uchar[] || The actual data
|}

Known magic values:

{|class="wikitable"
! Network !! Magic value !! Sent over wire as
|-
| main || 0xD9B4BEF9 || F9 BE B4 D9
|-
| testnet/regtest || 0xDAB5BFFA || FA BF B5 DA
|-
| testnet3 || 0x0709110B || 0B 11 09 07
|-
| signet(default) || 0x40CF030A || 0A 03 CF 40
|-
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE
|}

=== Variable length integer ===

Integer can be encoded depending on the represented value to save space.
Variable length integers always precede an array/vector of a type of data that may vary in length.
Longer numbers are encoded in little endian.

{|class="wikitable"
! Value !! Storage length !! Format
|-
| < 0xFD || 1 || uint8_t
|-
| <= 0xFFFF || 3 || 0xFD followed by the length as uint16_t
|-
| <= 0xFFFF FFFF || 5 || 0xFE followed by the length as uint32_t
|-
| - || 9 || 0xFF followed by the length as uint64_t
|}

If you're reading the Satoshi client code (BitcoinQT) it refers to this encoding as a "CompactSize". Modern Bitcoin Core also has the VARINT macro which implements an even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). VARINT is not a part of the protocol.

=== Variable length string ===

Variable length string can be stored using a variable length integer followed by the string itself.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || length || [[Protocol_documentation#Variable_length_integer|var_int]] || Length of the string
|-
| ? || string || char[] || The string itself (can be empty)
|}

=== Network address ===

When a network address is needed somewhere, this structure is used. Network addresses are not prefixed with a timestamp in the version message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || time || uint32 || the Time (version >= 31402). '''Not present in version message.'''
|-
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]
|-
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supported IPv4 and only read the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).
|-
| 2 || port || uint16_t || port number, network byte order
|}

Hexdump example of Network address structure

<pre>
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .

Network address:
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1
20 8D - Port 8333
</pre>

=== Inventory Vectors ===

Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || type || uint32_t || Identifies the object type linked to this inventory
|-
| 32 || hash || char[32] || Hash of the object
|}

The object type is currently defined as one of the following possibilities:

{|class="wikitable"
! Value !! Name !! Description
|-
| 0 || ERROR || Any data of with this number may be ignored
|-
| 1 || MSG_TX || Hash is related to a transaction
|-
| 2 || MSG_BLOCK || Hash is related to a data block
|-
| 3 || MSG_FILTERED_BLOCK || Hash of a block header; identical to MSG_BLOCK. Only to be used in getdata message. Indicates the reply should be a merkleblock message rather than a block message; this only works if a bloom filter has been set. See BIP 37 for more info.
|-
| 4 || MSG_CMPCT_BLOCK || Hash of a block header; identical to MSG_BLOCK. Only to be used in getdata message. Indicates the reply should be a cmpctblock message. See BIP 152 for more info.
|-
| 0x40000001 || MSG_WITNESS_TX || Hash of a transaction with witness data. See BIP 144 for more info.
|-
| 0x40000002 || MSG_WITNESS_BLOCK || Hash of a block with witness data. See BIP 144 for more info.
|-
| 0x40000003 || MSG_FILTERED_WITNESS_BLOCK || Hash of a block with witness data. Only to be used in getdata message. Indicates the reply should be a merkleblock message rather than a block message; this only works if a bloom filter has been set. See BIP 144 for more info.
|}

Other Data Type values are considered reserved for future implementations.

=== Block Headers ===

Block headers are sent in a headers packet in response to a getheaders message.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Block version information (note, this is signed)
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>https://en.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time</ref>)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1+ || txn_count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0
|}

cf. [[Block hashing algorithm]]

=== Differential encoding ===
Several uses of CompactSize below are "differentially encoded". For these, instead of using raw indexes, the number encoded is the difference between the current index and the previous index, minus one. For example, a first index of 0 implies a real index of 0, a second index of 0 thereafter refers to a real index of 1, etc.

=== PrefilledTransaction ===

A PrefilledTransaction structure is used in HeaderAndShortIDs to provide a list of a few transactions explicitly.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| index || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1, 3 bytes || Compact Size, differentially encoded since the last PrefilledTransaction in a list || The index into the block at which this transaction is
|-
| tx || Transaction || variable || As encoded in [[Protocol_documentation#tx|tx messages]] || The transaction which is in the block at index index.
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== HeaderAndShortIDs ===

A HeaderAndShortIDs structure is used to relay a block header, the short transactions IDs used for matching already-available transactions, and a select few transactions which we expect a peer may be missing.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| header || Block header || 80 bytes || First 80 bytes of the block as defined by the encoding used by "block" messages || The header of the block being provided
|-
| nonce || uint64_t || 8 bytes || Little Endian || A nonce for use in short transaction ID calculations
|-
| shortids_length || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of short transaction IDs in shortids (ie block tx count - prefilledtxn_length)
|-
| shortids || List of 6-byte integers || 6*shortids_length bytes || Little Endian || The [[Protocol_documentation#Short_transaction_ID|short transaction IDs]] calculated from the transactions which were not provided explicitly in prefilledtxn
|-
| prefilledtxn_length || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of prefilled transactions in prefilledtxn (ie block tx count - shortids_length)
|-
| prefilledtxn || List of PrefilledTransactions || variable size*prefilledtxn_length || As defined by [[Protocol_documentation#PrefilledTransaction|PrefilledTransaction]] definition, above || Used to provide the coinbase transaction and a select few which we expect a peer may be missing
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== BlockTransactionsRequest ===

A BlockTransactionsRequest structure is used to list transaction indexes in a block being requested.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| blockhash || Binary blob || 32 bytes || The output from a double-SHA256 of the block header, as used elsewhere || The blockhash of the block which the transactions being requested are in
|-
| indexes_length || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of transactions being requested
|-
| indexes || List of [[Protocol_documentation#Variable_length_integer|CompactSizes]] || 1 or 3 bytes*indexes_length || [[Protocol_documentation#Differential_encoding|Differentially encoded]] || The indexes of the transactions being requested in the block
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== BlockTransactions ===

A BlockTransactions structure is used to provide some of the transactions in a block, as requested.

{|class="wikitable"
! Field Name !! Type !! Size !! Encoding || Purpose
|-
| blockhash || Binary blob || 32 bytes || The output from a double-SHA256 of the block header, as used elsewhere || The blockhash of the block which the transactions being provided are in
|-
| transactions_length || [[Protocol_documentation#Variable_length_integer|CompactSize]] || 1 or 3 bytes || As used to encode array lengths elsewhere || The number of transactions provided
|-
| transactions || List of Transactions || variable || As encoded in [[Protocol_documentation#tx|tx messages]] || The transactions provided
|}

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== Short transaction ID ===

Short transaction IDs are used to represent a transaction without sending a full 256-bit hash. They are calculated by:

# single-SHA256 hashing the block header with the nonce appended (in little-endian)
# Running SipHash-2-4 with the input being the transaction ID and the keys (k0/k1) set to the first two little-endian 64-bit integers from the above hash, respectively.
# Dropping the 2 most significant bytes from the SipHash output to make it 6 bytes.

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

== Message types ==

=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || [[#Network address|net_addr]] || The network address of the node receiving this message
|-
|colspan="4"| Fields below require version ≥ 106
|-
| 26 || addr_from || [[#Network address|net_addr]] || Field can be ignored. This used to be the network address of the node emitting this message, but most P2P implementations send 26 dummy bytes. The "services" field of the address would also be redundant with the second field of the version message.
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki User Agent] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
|colspan="4"| Fields below require version ≥ 70001
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037]
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|-
| 2 || NODE_GETUTXO || See [https://github.com/bitcoin/bips/blob/master/bip-0064.mediawiki BIP 0064]
|-
| 4 || NODE_BLOOM || See [https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki BIP 0111]
|-
| 8 || NODE_WITNESS || See [https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki BIP 0144]
|-
| 16 || NODE_XTHIN || Never formally proposed (as a BIP), and discontinued. Was historically sporadically seen on the network.
|-
| 64 || NODE_COMPACT_FILTERS || See [https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki BIP 0157]
|-
| 1024 || NODE_NETWORK_LIMITED || See [https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki BIP 0159]
|}

Hexdump example of version message (OBSOLETE EXAMPLE: This example lacks a checksum and user-agent):
<pre>
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,
0060 3A B4 57 13 00 55 81 01 00 :.W..U...

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
55 00 00 00 - Payload is 85 bytes long
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0
Version message:
9C 7C 00 00 - 31900 (version 0.3.19)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address
DD 9D 20 2C 3A B4 57 13 - Node random unique ID
00 - "" sub-version string (string is 0 bytes long)
55 81 01 00 - Last block sending node has is block #98645
</pre>

And here's a modern (60002) protocol version client advertising itself to a local peer...

Newer protocol includes the checksum now, this is from a mainline (satoshi) client during
an outgoing connection to another local client, notice that it does not fill out the
address information at all when the source or destination is "unroutable".

<pre>

0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..

Message Header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command
64 00 00 00 - Payload is 100 bytes long
35 8d 49 32 - payload checksum (internal byte order)

Version message:
62 EA 00 00 - 60002 (protocol version 60002)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address
3B 2E B3 5D 8C E6 17 65 - Node ID
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)
C0 3E 03 00 - Last block sending node has is block #212672
</pre>

=== verack ===

The ''verack'' message is sent in reply to ''[[#version|version]]''. This message consists of only a [[#Message structure|message header]] with the command string "verack".

Hexdump of the verack message:

<pre>
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......
0010 00 00 00 00 5D F6 E0 E2 ........

Message header:
F9 BE B4 D9 - Main network magic bytes
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command
00 00 00 00 - Payload is 0 bytes long
5D F6 E0 E2 - Checksum (internal byte order)
</pre>

=== addr ===

Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours

Payload:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of address entries (max: 1000)
|-
| 30x? || addr_list || (uint32_t + [[#Network address|net_addr]])[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).
|}

'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.

Hexdump example of ''addr'' message:
<pre>
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................
0030 FF 0A 00 00 01 20 8D ..... .

Message Header:
F9 BE B4 D9 - Main network magic bytes
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"
1F 00 00 00 - payload is 31 bytes long
ED 52 39 9B - payload checksum (internal byte order)

Payload:
01 - 1 address in this message

Address:
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)
20 8D - port 8333
</pre>

=== inv ===

Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.

Payload (maximum 50,000 entries, which is just over 1.8 megabytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getdata ===

getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).

Payload (maximum 50,000 entries, which is just over 1.8 megabytes):

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== notfound ===

notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries
|-
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors
|}

=== getblocks ===

Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first.

The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.

To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients may provide blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_documentation#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)
|}

To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:

<pre>
// From libbitcoin which is under AGPL
std::vector<size_t> block_locator_indexes(size_t top_height)
{
std::vector<size_t> indexes;

// Modify the step in the iteration.
int64_t step = 1;

// Start at the top of the chain and work backwards.
for (auto index = (int64_t)top_height; index > 0; index -= step)
{
// Push top 10 indexes first, then back off exponentially.
if (indexes.size() >= 10)
step *= 2;

indexes.push_back((size_t)index);
}

// Push the genesis block index.
indexes.push_back(0);
return indexes;
}
</pre>

Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.

=== getheaders ===

Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. Keep in mind that some clients may provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || the protocol version
|-
| 1+ || hash count || [[Protocol_documentation#Variable_length_integer|var_int]] || number of block locator hash entries
|-
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)
|-
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)
|}

For the block locator object in this packet, the same rules apply as for the [[Protocol_documentation#getblocks|getblocks]] packet.

=== tx ===

''tx'' describes a bitcoin transaction, in reply to ''[[#getdata|getdata]]''. When a bloom filter is applied ''tx'' objects are sent automatically for matching transactions following the <code>merkleblock</code>.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || uint32_t || Transaction data format version
|-
| 0 or 2 || flag || optional uint8_t[2] || If present, always 0001, and indicates the presence of witness data
|-
| 1+ || tx_in count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of Transaction inputs (never zero)
|-
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins
|-
| 1+ || tx_out count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of Transaction outputs
|-
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins
|-
| 0+ || tx_witnesses || tx_witness[] || A list of witnesses, one for each input; omitted if ''flag'' is omitted above
|-
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is unlocked:
{|class="wikitable"
! Value !! Description
|-
| 0 || Not locked
|-
| < 500000000 || Block number at which this transaction is unlocked
|-
| >= 500000000 || UNIX timestamp at which this transaction is unlocked
|}
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).

|}

TxIn consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure
|-
| 1+ || script length || [[Protocol_documentation#Variable_length_integer|var_int]] || The length of the signature script
|-
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization
|-
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.
|}

The OutPoint structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 32 || hash || char[32] || The hash of the referenced transaction.
|-
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.
|}

The Script structure consists of a series of pieces of information and operations related to the value of the transaction.

(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)

The TxOut structure consists of the following fields:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || value || int64_t || Transaction Value
|-
| 1+ || pk_script length || [[Protocol_documentation#Variable_length_integer|var_int]] || Length of the pk_script
|-
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.
|}

The TxWitness structure consists of a [[Protocol_documentation#Variable_length_integer|var_int]] count of witness data components, followed by (for each witness data component) a [[Protocol_documentation#Variable_length_integer|var_int]] length of the component and the raw component data itself.

Example ''tx'' message:
<pre>
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......

Message header:
F9 BE B4 D9 - main network magic bytes
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command
02 01 00 00 - payload is 258 bytes long
E2 93 CD BE - payload checksum (internal byte order)

Transaction:
01 00 00 00 - version

Inputs:
01 - number of transaction inputs

Input 1:
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29
00 00 00 00

8B - script is 139 bytes long

48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04
2F 46 61 4A 4C 70 C0 F1 4B EF F5

FF FF FF FF - sequence

Outputs:
02 - 2 Output Transactions

Output 1:
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)
19 - pk_script is 25 bytes long

76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script
A9 D9 EA 1A FB 22 5E 88 AC

Output 2:
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)
19 - pk_script is 25 bytes long

76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script
FD A0 B7 8B 4E CC 52 88 AC

Locktime:
00 00 00 00 - lock time
</pre>

=== block ===

The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Block version information (note, this is signed)
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)
|-
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 1+ || txn_count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of transaction entries
|-
| ? || txns || tx[] || Block transactions, in format of "tx" command
|}

The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.
See [[Block hashing algorithm]] for details and an example.

=== headers ===

The ''headers'' packet returns block headers in response to a ''getheaders'' packet.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of block headers
|-
| 81x? || headers || [[Protocol_documentation#Block_Headers|block_header]][] || [[Protocol_documentation#Block_Headers|Block headers]]
|}

Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers that are hashed by miners.

=== getaddr ===

The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.

No additional data is transmitted with this message.

=== mempool ===

The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.

No additional data is transmitted with this message.

It is specified in [https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki BIP 35]. Since [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 37], if a [[Protocol_documentation#filterload.2C_filteradd.2C_filterclear.2C_merkleblock|bloom filter]] is loaded, only transactions matching the filter are replied.

=== checkorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== submitorder ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== reply ===

This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.

=== ping ===

The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || random nonce
|}

=== pong ===

The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 8 || nonce || uint64_t || nonce from ping
|}

=== reject===

The ''reject'' message is sent when messages are rejected.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 1+ || message || var_str || type of message rejected
|-
| 1 || ccode || char || code relating to rejected message
|-
| 1+ || reason || var_str || text version of reason for rejection
|-
| 0+ || data || char || Optional extra data provided by some errors. Currently, all errors which provide this field fill it with the TXID or block header hash of the object being rejected, so the field is 32 bytes.
|}

CCodes

{|class="wikitable"
! Value !! Name !! Description
|-
| 0x01 || REJECT_MALFORMED||
|-
| 0x10 || REJECT_INVALID ||
|-
| 0x11 || REJECT_OBSOLETE ||
|-
| 0x12 || REJECT_DUPLICATE ||
|-
| 0x40 || REJECT_NONSTANDARD ||
|-
| 0x41 || REJECT_DUST ||
|-
| 0x42 || REJECT_INSUFFICIENTFEE ||
|-
| 0x43 || REJECT_CHECKPOINT ||
|}

=== filterload, filteradd, filterclear, merkleblock ===

These messages are related to Bloom filtering of connections and are defined in [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037].

The <code>filterload</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.
|-
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.
|-
| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.
|-
| 1 || nFlags || uint8_t || A set of flags that control how matched items are added to the filter.
|}

See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.

Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm.

The <code>filteradd</code> command is defined as follows:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || data || uint8_t[] || The data element to add to the current filter.
|}

The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).

The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).

The <code>filterclear</code> command has no arguments at all.

After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Block version information, based upon the software version creating this block (note, this is signed)
|-
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references
|-
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block
|-
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)
|-
| 4 || bits || uint32_t || The calculated difficulty target being used for this block
|-
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes
|-
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)
|-
| 1+ || hash_count || [[Protocol_documentation#Variable_length_integer|var_int]] || The number of hashes to follow
|-
| 32x? || hashes || char[32] || Hashes in depth-first order
|-
| 1+ || flag_bytes || [[Protocol_documentation#Variable_length_integer|var_int]] || The size of flags (in bytes) to follow
|-
| ? || flags || byte[] || Flag bits, packed per 8 in a byte, least significant bit first. Extra 0 bits are padded on to reach full byte size.
|}

After a <code>merkleblock</code>, transactions matching the bloom filter are automatically sent in ''[[#tx|tx]]'' messages.

A guide to creating a bloom filter, loading a merkle block, and parsing a partial merkle block tree can be found in the [https://bitcoin.org/en/developer-examples#creating-a-bloom-filter Developer Examples].

=== alert ===

'''Note:''' Support for [[Alert system|alert messages]] has been removed from bitcoin core in March 2016. Read more [https://bitcoin.org/en/alert/2016-11-01-alert-retirement here]

An [[Alert system|'''alert''']] is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.

Alert format:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| ? || payload || uchar[] || Serialized alert payload
|-
| ? || signature || uchar[] || An ECDSA signature of the message
|}

The developers of Satoshi's client use this public key for signing alerts:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s

The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || Version || int32_t || Alert format version
|-
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert
|-
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored
|-
| 4 || ID || int32_t || A unique ID number for this alert
|-
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future
|-
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above
|-
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.
|-
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.
|-
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.
|-
| 4 || Priority || int32_t || Relative priority compared to other alerts
|-
| ? || Comment || string || A comment on the alert that is not displayed
|-
| ? || StatusBar || string || The alert message that is displayed to the user
|-
| ? || Reserved || string || Reserved
|}

Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])

Sample alert (no message header):
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1

Version: 1
RelayUntil: 1329620535
Expiration: 1329792435
ID: 1010
Cancel: 1009
setCancel: <empty>
MinVer: 10000
MaxVer: 61000
setSubVer: <empty>
Priority: 100
Comment: <empty>
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"
Reserved: <empty>

=== sendheaders ===

Request for Direct headers announcement.

Upon receipt of this message, the node is be permitted, but not required, to announce new blocks by '''headers''' command (instead of '''inv''' command).

This message is supported by the protocol version >= 70012 or Bitcoin Core version >= 0.12.0.

See [https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki BIP 130] for more information.

No additional data is transmitted with this message.

=== feefilter ===

The payload is always 8 bytes long and it encodes 64 bit integer value (LSB / little endian) of '''feerate'''.
The value represents a minimal fee and is expressed in satoshis per 1000 bytes.

Upon receipt of a "feefilter" message, the node will be permitted, but not required, to filter transaction invs for transactions that fall below the feerate provided in the feefilter message interpreted as satoshis per kilobyte.

The fee filter is additive with a bloom filter for transactions so if an SPV client were to load a bloom filter and send a feefilter message, transactions would only be relayed if they passed both filters.

Inv's generated from a mempool message are also subject to a fee filter if it exists.

Feature discovery is enabled by checking protocol version >= 70013

See [https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki BIP 133] for more information.

=== sendcmpct ===

# The sendcmpct message is defined as a message containing a 1-byte integer followed by a 8-byte integer where pchCommand == "sendcmpct".
# The first integer SHALL be interpreted as a boolean (and MUST have a value of either 1 or 0)
# The second integer SHALL be interpreted as a little-endian version number. Nodes sending a sendcmpct message MUST currently set this value to 1.
# Upon receipt of a "sendcmpct" message with the first and second integers set to 1, the node SHOULD announce new blocks by sending a cmpctblock message.
# Upon receipt of a "sendcmpct" message with the first integer set to 0, the node SHOULD NOT announce new blocks by sending a cmpctblock message, but SHOULD announce new blocks by sending invs or headers, as defined by BIP130.
# Upon receipt of a "sendcmpct" message with the second integer set to something other than 1, nodes MUST treat the peer as if they had not received the message (as it indicates the peer will provide an unexpected encoding in
# cmpctblock, and/or other, messages). This allows future versions to send duplicate sendcmpct messages with different versions as a part of a version handshake for future versions.
# Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.
# Nodes MUST NOT send a request for a MSG_CMPCT_BLOCK object to a peer before having received a sendcmpct message from that peer.

This message is only supported by protocol version >= 70014

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== cmpctblock ===

# The cmpctblock message is defined as as a message containing a serialized [[Protocol_documentation#HeaderAndShortIDs|HeaderAndShortIDs]] message and pchCommand == "cmpctblock".
# Upon receipt of a cmpctblock message after sending a sendcmpct message, nodes SHOULD calculate the [[Protocol_documentation#Short_transaction_ID|short transaction ID]] for each unconfirmed transaction they have available (ie in their mempool) and compare each to each short transaction ID in the cmpctblock message.
# After finding already-available transactions, nodes which do not have all transactions available to reconstruct the full block SHOULD request the missing transactions using a getblocktxn message.
# A node MUST NOT send a cmpctblock message unless they are able to respond to a getblocktxn message which requests every transaction in the block.
# A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing chain with a valid proof-of-work. A node MAY send a cmpctblock before validating that each transaction in the block validly spends existing [[UTXO]] set entries.

This message is only supported by protocol version >= 70014

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== getblocktxn ===

# The getblocktxn message is defined as as a message containing a serialized [[Protocol_documentation#BlockTransactionsRequest|BlockTransactionsRequest]] message and pchCommand == "getblocktxn".
# Upon receipt of a properly-formatted getblocktxnmessage, nodes which recently provided the sender of such a message a cmpctblock for the block hash identified in this message MUST respond with an appropriate [[Protocol_documentation#blocktxn|blocktxn]] message. Such a blocktxn message MUST contain exactly and only each transaction which is present in the appropriate block at the index specified in the getblocktxn indexes list, in the order requested.

This message is only supported by protocol version >= 70014

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

=== blocktxn ===

# The blocktxn message is defined as as a message containing a serialized [[Protocol_documentation#BlockTransactions|BlockTransactions]] message and pchCommand == "blocktxn".
# Upon receipt of a properly-formatted requested blocktxn message, nodes SHOULD attempt to reconstruct the full block by:
# Taking the prefilledtxn transactions from the original [[Protocol_documentation#cmpctblock|cmpctblock]] and placing them in the marked positions.
# For each short transaction ID from the original [[Protocol_documentation#cmpctblock|cmpctblock]], in order, find the corresponding transaction either from the blocktxn message or from other sources and place it in the first available position in the block.
# Once the block has been reconstructed, it shall be processed as normal, keeping in mind that short transaction IDs are expected to occasionally collide, and that nodes MUST NOT be penalized for such collisions, wherever they appear.

This message is only supported by protocol version >= 70014

See [https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki BIP 152] for more information.

== Scripting ==

See [[script]].

==See Also==

* [[Network]]
* [[Protocol rules]]
* [[Hardfork Wishlist]]
* [https://bitcoin.org/en/developer-documentation Developer Documentation on bitcoin.org]
* Bitcoin dissectors for Wireshark: https://github.com/lbotsch/wireshark-bitcoin https://github.com/op-sig/bitcoin-wireshark-dissector

==References==
<references />

[[zh-cn:协议说明]]
[[Category:Technical]]
[[Category:Developer]]

{{Bitcoin Core documentation}}

Talk:Segregated Witness

2021-06-24T16:24:27Z

Fresheneesz: Created page with "## What flaw? The article currently says "by exploiting a flaw in the BIP 9 activation mechanism". What flaw exactly? This should either be clarified or removed. ~~~~"

## What flaw?

The article currently says "by exploiting a flaw in the BIP 9 activation mechanism". What flaw exactly? This should either be clarified or removed. [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 16:24, 24 June 2021 (UTC)

Script

2021-04-18T21:29:44Z

Fresheneesz: /* Stack */ Clarifying description of op_rot in a way more consistent with other definitions (and not using the word "left" which makes no sense in a stack)

Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, '''Script''' is simple, stack-based, and processed from left to right. It is intentionally not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to prove ownership of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several keys, or even no keys at all.

A transaction is valid if nothing in the combined script triggers failure and the top stack item is True (non-zero) when the script exits. The party that originally ''sent'' the Bitcoins now being spent dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in the combined script completing execution with a true value on the top of the stack.

This document is for information purposes only. De facto, Bitcoin script is defined by the code run by the network to check the validity of blocks.

The stacks hold byte vectors.
When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer.
Thus 0x81 represents -1.
0x80 is another representation of zero (so called negative 0).
Positive 0 is represented by a null-length vector.
Byte vectors are interpreted as Booleans where False is represented by any representation of zero and True is represented by any representation of non-zero.

Leading zeros in an integer and negative zero are allowed in blocks but get rejected by the stricter requirements which standard full nodes put on transactions before retransmitting them.
Byte vectors on the stack are not allowed to be more than 520 bytes long. Opcodes which take integers and bools off the stack require that they be no more than 4 bytes long, but addition and subtraction can overflow and result in a 5 byte integer being put on the stack.

== Opcodes ==
This is a list of all Script words, also known as opcodes, commands, or functions.

There are some words which existed in very early versions of Bitcoin but were removed out of concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT that could crash any Bitcoin node if exploited and by other bugs that allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled", but this is something of a misnomer because there is ''absolutely no way'' for anyone using Bitcoin to use these opcodes (they simply ''do not exist anymore'' in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here for historical interest only.

New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.

Zero, negative zero (using any number of bytes), and empty array are all treated as false. Anything else is treated as true.

=== Notation on this page ===

In the tables below, the inputs and outputs are both described by items as if they were pushed on the stack in that order. So for example, "x1 x2" indicates pushing value x1 on the stack, then x2, such that x1 is at the bottom of the stack, and x2 is at the top.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not False, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
|If the top stack value is False, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / ''fail''
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.
|-
|[[OP_RETURN]]
|106
|0x6a
|Nothing
|''fail''
|'''Marks transaction as invalid'''. Since bitcoin 0.9, a standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by data. Such outputs are provably unspendable and specially discarded from storage in the UTXO set, reducing their cost to the network. Since [https://bitcoin.org/en/release/v0.12.0#relay-any-sequence-of-pushdatas-in-opreturn-outputs-now-allowed 0.12], standard relay rules allow a single output with OP_RETURN, that contains any sequence of push statements (or OP_RESERVED<ref>see code for IsPushOnly [https://github.com/bitcoin/bitcoin/blob/bccb4d29a8080bf1ecda1fc235415a11d903a680/src/script/script.cpp#L232]</ref>) after the OP_RETURN provided the total scriptPubKey length is at most 83 bytes.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The 3rd item down the stack is moved to the top.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

=== Splice ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|style="background:#D97171;"|Concatenates two strings. ''disabled.''
|-
|OP_SUBSTR
|127
|0x7f
|in begin size
|out
|style="background:#D97171;"|Returns a section of a string. ''disabled.''
|-
|OP_LEFT
|128
|0x80
|in size
|out
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''
|-
|OP_RIGHT
|129
|0x81
|in size
|out
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Pushes the string length of the top element of the stack (without popping it).
|}

=== Bitwise logic ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|Nothing / ''fail''
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''
|-
|OP_2DIV
|142
|0x8e
|in
|out
|style="background:#D97171;"|The input is divided by 2. ''disabled.''
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|style="background:#D97171;"|a is multiplied by b. ''disabled.''
|-
|OP_DIV
|150
|0x96
|a b
|out
|style="background:#D97171;"|a is divided by b. ''disabled.''
|-
|OP_MOD
|151
|0x97
|a b
|out
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|Nothing / ''fail''
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|Nothing / ''fail''
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|Nothing / ''fail''
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

=== Locktime ===
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
|177
|0xb1
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065].
|-
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
|178
|0xb2
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 0068] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 0112].
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VER
|98
|0x62
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VERIF
|101
|0x65
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_VERNOTIF
|102
|0x66
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_RESERVED1
|137
|0x89
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1, OP_NOP4-OP_NOP10
|176, 179-185
|0xb0, 0xb3-0xb9
|The word is ignored. Does not mark transaction as invalid.
|}

== Script examples ==
The following is a list of interesting scripts.
When notating scripts, data to be pushed to the stack is generally enclosed in angle brackets
and data push commands are omitted.
Non-bracketed words are opcodes.
These examples include the “OP_” prefix, but it is permissible to omit it.
Thus
“<pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG”
may be abbreviated to
“<pubkey1> <pubkey2> 2 CHECKMULTISIG”.
Note that there is a small number of standard script forms that are relayed from node to node;
non-standard scripts are accepted if they are in a block, but nodes will not relay them.

=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
<pre> 76 A9 14
OP_DUP OP_HASH160 Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre>

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

Here is how each word is processed:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Obsolete pay-to-pubkey transaction ===

OP_CHECKSIG is used directly without first hashing the public key.
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.
The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Provably Unspendable/Prunable Outputs ===

The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:

scriptPubKey: OP_RETURN {zero or more ops}

OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the [[UTXO|UTXO set]] even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.

=== Freezing funds until a time in the future ===

Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.

scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey> <expiry time>
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <expiry time>
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is checked against the current time or block height.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is removed.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Transaction puzzle ===

Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
scriptSig: <data>

To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<data> OP_HASH256 <given_hash> OP_EQUAL
|
|-
|<data>
|OP_HASH256 <given_hash> OP_EQUAL
|scriptSig added to the stack.
|-
|<data_hash>
|<given_hash> OP_EQUAL
|The data is hashed.
|-
|<data_hash> <given_hash>
|OP_EQUAL
|The given hash is pushed to the stack.
|-
|true
|Empty.
|The hashes are compared, leaving true on the stack.
|}

This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash in the script was the genesis block header hashed twice with SHA-256. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.

=== Incentivized finding of hash collisions ===

In 2013 Peter Todd created scripts that result in true if a hash collision is found. Bitcoin addresses resulting from these scripts can have money sent to them. If someone finds a hash collision they can spend the bitcoins on that address, so this setup acts as an incentive for somebody to do so.

For example the SHA1 script:

scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL
scriptSig: <preimage1> <preimage2>

See the bitcointalk thread <ref>[https://bitcointalk.org/index.php?topic=293382.0 bitcointalk forum thread on the hash collision bounties]</ref> and reddit thread<ref>https://www.reddit.com/r/Bitcoin/comments/1mavh9/trustless_bitcoin_bounty_for_sha1_sha256_etc/</ref> for more details.

In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.

==See Also==

* [[Transactions]]
* [[Contracts]]

== External Links ==
*[https://bitcoin.sipa.be/miniscript] - Miniscript: a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE] – Bitcoin Script for dummies
*[https://webbtc.com/script Bitcoin Debug Script Execution] – web tool which executes a script opcode-by-opcode
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript
*[https://bitauth.com/ide BitAuth IDE] — an Integrated Development Environment for Bitcoin Authentication
(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")

==References==
<references />

[[Category:Technical]]
[[Category:Vocabulary]]

{{Bitcoin Core documentation}}

Talk:Script

2021-04-18T19:10:43Z

Fresheneesz:

{{WikiProject|Protocol|quality=QNR|importance=TOP}}
xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.

Shouldn't it be: "If the input is true, duplicate it."?
--[[User:ThePiachu|ThePiachu]] 11:37, 20 December 2011 (GMT)

The byte vectors in the stack are specified as being signed integers of variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. For this to be the case, the elements should be represented in an old binary format called sign-magnitude, which is important to state explicitly, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero. There's even another representation, one's complement, where negative zero looks like 0xff.

Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.

It seems to me that, at best, variable-length sign-magnitued integer format is only used for testing for truth, although I haven't read all the code yet.

--[[User:Jpierre|Jean-Pierre Rupp]] 10:43, 4 March 2012 (GMT)

== Provably Unspendable/Prunable Outputs ==

If im not mistaken this kind of transaction would not result in donating the output to the miner. It would instead make the output unusable by anyone forever. In my opinion the best and easiest way to donate to miner is just transfer BTC between your own addresses and set a high fee. [[User:Norill|Norill]] ([[User talk:Norill|talk]]) 22:32, 14 April 2013 (GMT)

:norill: Fixed wording for OP_RETURN; it is mining fee in the example because the output value is zero, not 0.125BTC as I think you thought. Sorry about that.
:[[User:Petertodd|Peter Todd]] ([[User talk:Petertodd|talk]]) 02:51, 23 July 2013 (GMT)

== Common confusion on Turing-completeness. ==

Script isn't turing-complete under the precise definition of the term because it executes with bounded time and memory.

But by the precise definition a conventional desktop computer is also not "turing-complete": there are functions a universal turing machine can compute that a desktop cannot because the desktop computer runs out of memory first.

The precise definition isn't terribly useful for most people, since it excludes most things we think of as computers. Many people read the "not Turing-complete" as a statement that Script is only as expressive as a regular language or only capable of expressing monotone functions or something like that. Not so, if you ignore the time/memory bounds script is technically universal for computation. Consider the fragment "2 OP_PICK OP_IF OP_SWAP OP_ENDIF": This implements a [http://en.wikipedia.org/wiki/Fredkin_gate fredkin gate] which is universal and could just be wired up and repeated up to the operation limit Q.E.D.

It's absolutely important for the Bitcoin system that script's execution has an quickly checkable, bounded, and very short runtime. The relevance of turing completeness to any of that is easily and often overstated. The greater limits of script's expressiveness come from the computation bound, not the computational model. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 05:47, 28 March 2015 (UTC)
: I think that often when people talk about "Turing completeness", they mean that any program written in a normal programming language can ~always be compiled into any "Turing complete" language, even though this isn't really the definition of Turing completeness. You can write a program in C to calculate pi to the nth digit, and even if you were using regular C integers n could be pretty large without needing to modify the program. But the equivalent Script program would need to increase in size every time you increase the maximum size of n by 1, and this is what makes Script much weaker than C or any other normal programming language. [[User:Theymos|theymos]] ([[User talk:Theymos|talk]]) 18:32, 28 March 2015 (UTC)

== OP_xVERIFY output is Nothing ==

The commands OP_CHECKSIGVERIFY, OP_CHECKMULTISIGVERIFY, OP_VERIFY, OP_EQUALVERIFY, OP_NUMEQUALVERIFY shows a boolean output on the table of this page, however the output is Nothing. Is that correct? --[[User:Thelink2012|Thelink2012]] ([[User talk:Thelink2012|talk]]) 16:57, 15 November 2015 (UTC)

== Order of inputs and outputs is not explained ==

The way the inputs and outputs are listed isn't intuitive and isn't explained on this page. For example, for OP_SUB, it shows inputs as "x1 x2 x3" and outputs as "x2 x3 x1". I would have expected that x1 would indicate the top of the stack, but instead it seems to indicate the first item pushed onto the stack (and therefore, the bottom of the stack). The outputs are described in the same way, which is even more unintuitive, since the outputs aren't pushed onto the stack individually but are just moved around. So the way to understand the way its written here is that the outputs are as if they were pushed in the order given (or to just understand that the top of the stack is the last item listed).

I think we should reverse this so that the top of the stack is listed first. It would be a lot more intuitive I think. Alternatively, we can change the notation so that "x1" indicates the top of the stack, then writing "x3 x2 x1" would be easier to read intuitively either way - ie you clearly see the order they're pushed, but you can also look at the numbers to check their position on the stack. This could also be reversed so "x3 x2 x1" means that x3 is on the top of the stack (but was pushed third).

Thoughts?

Also it looks like OP_PICK and OP_ROLL are writing these values in a way that's not consistent with the rest of the page. Eg ROLL has inputs "xn ... x2 x1 x0 <n>". It looks like its using 0-based indexes instead of the 1-based indexes the rest of the page uses, and it isn't numbering the xs in order of being pushed. But then again, this is a case where using this notation is useful - and I think it might make sense to change the rest of the page to using this convention.

[[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 19:10, 18 April 2021 (UTC)

Script

2021-04-18T19:04:36Z

Fresheneesz: /* Opcodes */ Adding explanation of inputs and outputs ordering.

Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, '''Script''' is simple, stack-based, and processed from left to right. It is intentionally not Turing-complete, with no loops.

A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to prove ownership of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several keys, or even no keys at all.

A transaction is valid if nothing in the combined script triggers failure and the top stack item is True (non-zero) when the script exits. The party that originally ''sent'' the Bitcoins now being spent dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in the combined script completing execution with a true value on the top of the stack.

This document is for information purposes only. De facto, Bitcoin script is defined by the code run by the network to check the validity of blocks.

The stacks hold byte vectors.
When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer.
Thus 0x81 represents -1.
0x80 is another representation of zero (so called negative 0).
Positive 0 is represented by a null-length vector.
Byte vectors are interpreted as Booleans where False is represented by any representation of zero and True is represented by any representation of non-zero.

Leading zeros in an integer and negative zero are allowed in blocks but get rejected by the stricter requirements which standard full nodes put on transactions before retransmitting them.
Byte vectors on the stack are not allowed to be more than 520 bytes long. Opcodes which take integers and bools off the stack require that they be no more than 4 bytes long, but addition and subtraction can overflow and result in a 5 byte integer being put on the stack.

== Opcodes ==
This is a list of all Script words, also known as opcodes, commands, or functions.

There are some words which existed in very early versions of Bitcoin but were removed out of concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT that could crash any Bitcoin node if exploited and by other bugs that allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled", but this is something of a misnomer because there is ''absolutely no way'' for anyone using Bitcoin to use these opcodes (they simply ''do not exist anymore'' in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here for historical interest only.

New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.

Zero, negative zero (using any number of bytes), and empty array are all treated as false. Anything else is treated as true.

=== Notation on this page ===

In the tables below, the inputs and outputs are both described by items as if they were pushed on the stack in that order. So for example, "x1 x2" indicates pushing value x1 on the stack, then x2, such that x1 is at the bottom of the stack, and x2 is at the top.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not False, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
|If the top stack value is False, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without OP_IF earlier is also '''invalid'''.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / ''fail''
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.
|-
|[[OP_RETURN]]
|106
|0x6a
|Nothing
|''fail''
|'''Marks transaction as invalid'''. Since bitcoin 0.9, a standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by data. Such outputs are provably unspendable and specially discarded from storage in the UTXO set, reducing their cost to the network. Since [https://bitcoin.org/en/release/v0.12.0#relay-any-sequence-of-pushdatas-in-opreturn-outputs-now-allowed 0.12], standard relay rules allow a single output with OP_RETURN, that contains any sequence of push statements (or OP_RESERVED<ref>see code for IsPushOnly [https://github.com/bitcoin/bitcoin/blob/bccb4d29a8080bf1ecda1fc235415a11d903a680/src/script/script.cpp#L232]</ref>) after the OP_RETURN provided the total scriptPubKey length is at most 83 bytes.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

=== Splice ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|style="background:#D97171;"|Concatenates two strings. ''disabled.''
|-
|OP_SUBSTR
|127
|0x7f
|in begin size
|out
|style="background:#D97171;"|Returns a section of a string. ''disabled.''
|-
|OP_LEFT
|128
|0x80
|in size
|out
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''
|-
|OP_RIGHT
|129
|0x81
|in size
|out
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Pushes the string length of the top element of the stack (without popping it).
|}

=== Bitwise logic ===

If any opcode marked as disabled is present in a script, it must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|Nothing / ''fail''
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''
|-
|OP_2DIV
|142
|0x8e
|in
|out
|style="background:#D97171;"|The input is divided by 2. ''disabled.''
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|style="background:#D97171;"|a is multiplied by b. ''disabled.''
|-
|OP_DIV
|150
|0x96
|a b
|out
|style="background:#D97171;"|a is divided by b. ''disabled.''
|-
|OP_MOD
|151
|0x97
|a b
|out
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|Nothing / ''fail''
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|Nothing / ''fail''
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|Nothing / ''fail''
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

=== Locktime ===
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
|177
|0xb1
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065].
|-
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
|178
|0xb2
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 0068] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 0112].
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VER
|98
|0x62
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_VERIF
|101
|0x65
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_VERNOTIF
|102
|0x66
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''
|-
|OP_RESERVED1
|137
|0x89
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1, OP_NOP4-OP_NOP10
|176, 179-185
|0xb0, 0xb3-0xb9
|The word is ignored. Does not mark transaction as invalid.
|}

== Script examples ==
The following is a list of interesting scripts.
When notating scripts, data to be pushed to the stack is generally enclosed in angle brackets
and data push commands are omitted.
Non-bracketed words are opcodes.
These examples include the “OP_” prefix, but it is permissible to omit it.
Thus
“<pubkey1> <pubkey2> OP_2 OP_CHECKMULTISIG”
may be abbreviated to
“<pubkey1> <pubkey2> 2 CHECKMULTISIG”.
Note that there is a small number of standard script forms that are relayed from node to node;
non-standard scripts are accepted if they are in a block, but nodes will not relay them.

=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

To demonstrate how scripts look on the wire, here is a raw scriptPubKey:
<pre> 76 A9 14
OP_DUP OP_HASH160 Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre>

Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.

Here is how each word is processed:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Obsolete pay-to-pubkey transaction ===

OP_CHECKSIG is used directly without first hashing the public key.
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.
The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<sig> <pubKey> OP_CHECKSIG
|scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_CHECKSIG
|Constants are added to the stack.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Provably Unspendable/Prunable Outputs ===

The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:

scriptPubKey: OP_RETURN {zero or more ops}

OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the [[UTXO|UTXO set]] even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.

=== Freezing funds until a time in the future ===

Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.

scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey> <expiry time>
| OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <expiry time>
| OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is checked against the current time or block height.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is removed.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

=== Transaction puzzle ===

Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.

scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL
scriptSig: <data>

To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
|<data> OP_HASH256 <given_hash> OP_EQUAL
|
|-
|<data>
|OP_HASH256 <given_hash> OP_EQUAL
|scriptSig added to the stack.
|-
|<data_hash>
|<given_hash> OP_EQUAL
|The data is hashed.
|-
|<data_hash> <given_hash>
|OP_EQUAL
|The given hash is pushed to the stack.
|-
|true
|Empty.
|The hashes are compared, leaving true on the stack.
|}

This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash in the script was the genesis block header hashed twice with SHA-256. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.

=== Incentivized finding of hash collisions ===

In 2013 Peter Todd created scripts that result in true if a hash collision is found. Bitcoin addresses resulting from these scripts can have money sent to them. If someone finds a hash collision they can spend the bitcoins on that address, so this setup acts as an incentive for somebody to do so.

For example the SHA1 script:

scriptPubKey: OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL
scriptSig: <preimage1> <preimage2>

See the bitcointalk thread <ref>[https://bitcointalk.org/index.php?topic=293382.0 bitcointalk forum thread on the hash collision bounties]</ref> and reddit thread<ref>https://www.reddit.com/r/Bitcoin/comments/1mavh9/trustless_bitcoin_bounty_for_sha1_sha256_etc/</ref> for more details.

In February 2017 the SHA1 bounty worth 2.48 bitcoins was claimed.

==See Also==

* [[Transactions]]
* [[Contracts]]

== External Links ==
*[https://bitcoin.sipa.be/miniscript] - Miniscript: a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.
*[https://github.com/siminchen/bitcoinIDE Bitcoin IDE] – Bitcoin Script for dummies
*[https://webbtc.com/script Bitcoin Debug Script Execution] – web tool which executes a script opcode-by-opcode
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript
*[https://bitauth.com/ide BitAuth IDE] — an Integrated Development Environment for Bitcoin Authentication
(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")

==References==
<references />

[[Category:Technical]]
[[Category:Vocabulary]]

{{Bitcoin Core documentation}}

NSequence

2021-04-15T08:20:31Z

Fresheneesz: Correcting link

#REDIRECT [[Transaction#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin]]

NSequence

2021-04-15T08:19:56Z

Fresheneesz: Redirecting to the transaction format section that mentions the sequence no

#REDIRECT [[#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin]]

Storing bitcoins

2020-06-06T19:29:48Z

Fresheneesz: Adding see also section linking to the list of storage methods.

''This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].''

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

'''tl;dr''' The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). Ideally the wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''metal seed phrase backup''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they are genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

''Main article: [[Hardware wallet]]''

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

=== Multisignature wallets ===

''Main article: [[Multisignature]]''

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key. Such a wallet can be used for requiring agreement among multiple people to spend, can eliminate a single point of failure, and can be used as form of backup, among other applications.

These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop, and smartphone, any two of which are required to move the money, but the compromise or total loss of any one key does not result in loss of money, even if that key has no backups.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, and can be nearly as convenient since all keys are online and the wallet user interfaces are typically easy to use.

Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

=== Cold storage wallets ===

''Main article: [[Cold storage]]''

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

=== Hot wallets ===

''Main article: [[Hot wallet]]''

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

A user might have a ''spending account'' hot wallet for day-to-day convenient spending with the majority of their funds on a ''savings account'' which is stored with much more security (cold storage / hardware wallet / multisignature).

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

''The following is a quote of waxwing on reddit<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>:''

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor. Furthermore, there are a variety of ways in which 2FA can be compromised, in particular SMS-based 2FA, such as via a SIM-Swap.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/
* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

=== "Physical" Bitcoins ===

Physical Coins and other mechanism with a pre-manufactured key or seed are not a good way to store bitcoins because they keys are already potentially compromised by whoever created the key. You should not consider bitcoin yours if its stored on a key created by someone else. It only becomes yours when you transfer the bitcoin to a key that you own and exclusively control.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are multiple ways that can be utilized to beat this attack: by hiding, by defending yourself, by not letting others know your Bitcoin wealth or holdings, or by implementing security procedures which would prevent you from being able to surrender funds in such an attack, thereby reducing the appeal for an attacker to perform such an attack in the first place.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== See also ==

* [[Links to Storage Methods]]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

* [[Backup and Storage Methods]]

==References==
<references />

[[Category:Security]]
[[Category:Wallets| ]]

Links to Storage Methods

2020-05-27T18:46:18Z

Fresheneesz: casa keys

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 malicius 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 Keys ===

[Casa Keys](https://docs.keys.casa/wealth-security-protocol/) is a multisig wallet system that uses a mobile wallet, hardware wallet, and remote key.

=== [[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/

Schnorr

2020-05-25T19:17:41Z

Fresheneesz: Some details about the advantages of schnorr.

Bitcoin currently uses the [[ECDSA]] algorithm to generate cryptographic signatures for a given message and [[secp256k1]] keypair. Schnorr is an alternative algorithm with several advantages. One key advantage is that when multiple keys are used to sign the same message with Schnorr, the resulting signatures can be combined into a single signature. This can be used to significantly reduce the size of multisig payments and other multisig related transactions, for example lightning channel transactions.

The main reason that Bitcoin did not originally use Schnorr signatures is that Schnorr was not standardized, and was not available in common crypto libraries.

==Technical details==

Schnorr signatures are a proposed future extension that give a new way to generate signatures (R,s) on a hash h.

Given a hash value h, hash function f(), private key x, group generator G, and public key P=xG, we can generate a Schnorr signature on h as follows:

Choose a random nonce k. Let R=Gk, and let s = k - f(h . R . P)x. The Schnorr signature is the pair (R, s). Note that R is a public key, so would require 33 bytes to represent (32 bytes + 1 bit indicating "even" vs "odd").

To check the validity of a signature (R, s) against a public key P, do the following:

Note that sG = (k- f(h . R . P)x)G = kG - f(h . R . P)xG = R - f(h . R . P)P. So we simply compare sG + f(h . R . P)P to R to check the signature.

An advantage of this method is that, if parties cooperate, we can generate a single signature that validates two or more separate transactions.

Choose h1, h2, x1, x2, G, P1=Gx1, P2=Gx2. Each party chooses a nonce yielding k1 and k2, and publicly shares R1=Gk1, R2=Gk2.

Let R = R1+R2. Each signer generates an s, s1 = k1 - f(h . R . P)x1, s2 = k2 - f(h . R . P)x2. The signature (R, s) where s = s1 + s2 proves both transactions are signed.

Note that sG = (s1 + s2)G = s1G + s2G = (k1 - f(h . R . P)x1)G + (k2 - f(h . R . P)x2)G = k1G - f(h . R . P)x1G + k2G - f(h . R . P)x2G = R1 + R2 - f(h . R . P)(P1 + P2) = R - f(h . R . P)(P1 + P2)

To verify, check that sG +f(h . R . P)(P1+P2) is R.

This can be easily generalized from 2 to N.

==See also==
[https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki Draft Schnorr specification for future use in Bitcoin]

[[Category:Technical]]

Atomic multipath payments

2020-05-25T19:12:39Z

Fresheneesz: adding info about MPP and stage-three AMP

'''Atomic Multipath Payments''' ('''AMP''') are payments that use multiple paths to complete a transaction that either all complete successfully or none complete successfully.

One of the problems the lightning network has had is limited ability to send higher-value payments, because of limitations in channel capacity along possible routes to the payee. Using AMP, a payer can send a payment using many paths, which can make larger payments far more reliable.

== Roadmap ==

AMP is not yet available yet on any lightning implementation, but non-atomic multipath payments (MPP) have recently been implemented by LND in v0.10.0. MPP is the first stage in a three-stage process for AMP. The second stage is hash-based AMP, and the third step is a better form of AMP that uses points and scalars instead of hashes. The third stage requires [[Eltoo]] and [[Schnorr]].

Atomic multipath payments

2020-05-25T19:04:26Z

Fresheneesz:

'''Atomic Multpath Payments''' ('''AMP''') are payments that use multiple paths to complete a transaction that either all complete successfully or none complete successfully.

One of the problems the lightning network has had is limited ability to send higher-value payments, because of limitations in channel capacity along possible routes to the payee. Using AMP, a payer can send a payment using many paths, which can make larger payments far more reliable.

Atomic multi-path payments

2020-05-25T19:04:08Z

Fresheneesz: Redirected page to Atomic multipath payments

#REDIRECT [[Atomic multipath payments]]

AMP

2020-05-25T19:03:53Z

Fresheneesz: Redirected page to Atomic multipath payments

#REDIRECT [[Atomic multipath payments]]

Atomic multipath payments

2020-05-25T19:03:33Z

Fresheneesz: stub

''Atomic Multpath Payments'' (''AMP'') are payments that use multiple paths to complete a transaction that either all complete successfully or none complete successfully.

One of the problems the lightning network has had is limited ability to send higher-value payments, because of limitations in channel capacity along possible routes to the payee. Using AMP, a payer can send a payment using many paths, which can make larger payments far more reliable.

Talk:Links to Storage Methods

2020-05-24T08:24:45Z

Fresheneesz:

==Name of this page==
This page doesn't actually have much content about backup and storage methods (compare with [[Storing bitcoins]]). Perhaps it should be renamed to something like "links to storing bitcoin guides" or "external links to storing bitcoin tutorials". [[User:Belcher|Belcher]] ([[User talk:Belcher|talk]]) 16:34, 27 November 2019 (UTC)
: I think "Links to Storage Methods" isn't very accurate. This doesn't just list links. It evaluates and discusses published methods for storing bitcoin. I think this should be renamed to maybe something like "Discussion of Published Storage Methods" or something like that. [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 08:24, 24 May 2020 (UTC)

Links to Storage Methods

2020-05-24T08:21:50Z

Fresheneesz: /* https://yeticold.com/ Yeticold */

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 malicius 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.

=== [[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/

Links to Storage Methods

2020-05-24T08:21:37Z

Fresheneesz: /* Cold Storage Methods */ Adding Yeticold

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 malicius 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.

=== https://yeticold.com/ 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.

=== [[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/

Links to Storage Methods

2019-12-05T07:31:26Z

Fresheneesz: /* SmartCustody's Simple Self-Custody Cold Storage */

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 malicius 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|deterministic wallets]] 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. The information it recommends putting in a safe deposit box 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.

=== [[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/

Links to Storage Methods

2019-12-05T06:58:14Z

Fresheneesz: Adding SmartCustody's cold storage guide

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 malicius 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|deterministic wallets]] 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]

=== [[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/

Talk:Storing bitcoins

2019-12-05T06:48:28Z

Fresheneesz: Created page with "== Verifying that something looks/is genuine == @Belcher, you edited the text to say "you wouldn't accept [banknotes or gold coins] without inspecting them and verifying that..."

== Verifying that something looks/is genuine ==

@Belcher, you edited the text to say "you wouldn't accept [banknotes or gold coins] without inspecting them and verifying that they are genuine". However, most people would in fact accept banknotes without verifying that they are genuine. Often its simply infeasible to verify things like that. How do you verify a banknote is genuine and not a copy? If its a perfect copy, its impossible. If you think this nuance is important, maybe we can find a more accurate way to say it. But even with bitcoin, you can only verify it looks genuine from a number of angles. Verifying it is genuine for certain is not strictly possible. [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 06:48, 5 December 2019 (UTC)

Links to Storage Methods

2019-11-25T07:21:45Z

Fresheneesz: /* Storage Method Components */

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 malicius 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|deterministic wallets]] 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.

=== [[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/

Links to Storage Methods

2019-11-25T07:21:29Z

Fresheneesz: Adding Storage method components, wasabi wallet's "cold wasabi" guide, and a section on storage method components, including Pamela Morgan's guides to bitcoin inheritance planning

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 malicius 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|deterministic wallets]] 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.

=== [[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/

Cold storage

2019-11-25T07:21:13Z

Fresheneesz: Moving information about specific published cold storage guides to Backup And Storage Methods

'''Cold storage''' in the context of Bitcoin refers to [[Storing bitcoins|storing Bitcoins]] offline and spending without the [[private key]]s controlling them ever being online. This resists theft by hackers and malware, and is often a necessary security precaution especially dealing with large amounts of Bitcoin.

For example, a Bitcoin exchange which offers an instant withdrawal feature, and might be a steward over hundreds of thousands of Bitcoins. To minimize the possibility that an intruder could steal the entire reserve in a security breach, the operator of the website keeps the majority of the reserve in ''cold storage'', or in other words, not present on the web server or any other online computer. The only amount kept on the server is the amount needed to cover anticipated withdrawals in one day.

Special-purpose [[hardware wallet]]s are also a kind of cold storage solution but this article will mostly deal with cold storage using general purpose computing hardware.

See [[Backup and Storage Methods#Cold Storage Methods]] for a review of published cold storage methods.

== Conceptual How-to ==
# Set up an online computer which has an internet connection, and an offline computer which is securely [https://en.wikipedia.org/wiki/Air_gap_%28networking%29 airgapped].
# The offline computer must have bitcoin wallet software installed. Use the software to generate a wallet and write down its [[seed phrase]] on paper or another medium.
# Obtain the [[Deterministic wallet#Master public key|master public key]] of the wallet you just generated and transfer it to the online computer. Use it to create a watch-only wallet on the online computer.
# The watch-only wallet on the online computer can provide bitcoin [[address]]es used for receiving money, and can tell the user when [[transaction]]s are received and how many [[confirmation]]s they have.
# For spending have the watch-only wallet create an [[transaction]] without the signatures which makes it valid.
# Transfer the unsigned transaction to the offline computer and use the wallet software to sign the transaction.
# Transfer the now-fully-signed transaction to the online computer and broadcast it to the bitcoin network. The watch-only wallet will tell you when the transaction has [[confirmation]]s.

== Setting up a secure offline computer ==

A good solution for making a secure offline computer is to buy an old, used laptop or phone built by a reputable manufacturer. Then completely wipe it, do not connect to the internet and install only an operating system and bitcoin wallet from a USB drive<ref>https://twitter.com/peterktodd/status/1078350142644731904</ref>.

Another option is to use a live operating system as the offline computer. This option is perhaps less secure, as sophisticated malware may be able to survive the live OS boot, but the method may be more convenient.

For some people other attacks must be considered. Wiping a computer may not be enough to remove threats of HDD firmware reprogramming, BIOS reprogramming or any other memory which persists after a clean reinstallation of the system<ref>https://www.reddit.com/r/Bitcoin/comments/a8m031/proof_of_keys_proof_of_trust_bitcoin_independence/ecdz47t/</ref>.

If the offline and online computer are kept close together (in the same room) then theoretically information can still be transmitted past the air gap using certain sidechannels like: RF, audio, light, magnetic, thermal. For further details see the wikipedia article on [https://en.wikipedia.org/wiki/Air-gap_malware Air-gap malware]. For this reason it could be a good idea to keep the offline and online computers physically far apart, and unplug the power cable from the laptop so it runs on battery power only.

== Wallet software ==

The wallet software used for cold storage must support watch-only wallets and offline signing. Ideally the online wallet would be backed by a [[full node]] for the [[Full node#Why should you use a full node wallet|privacy, security and validation benefits]].

== Transferring data between offline and online ==

Cold storage requires on transferring master public keys and partially-signed transactions between the offline and online computers. There are several methods to do this:

=== USB flash drive ===

The data can be stored on a USB flash drive and passed between the computers. The advantages are speed and convenience. A disadvantage is that the USB interface still has an attack surface. Sophisiticated malware used in cyberwarface such as [https://en.wikipedia.org/wiki/Stuxnet Stuxnet] and [https://en.wikipedia.org/wiki/2008_cyberattack_on_United_States agent.btz] used USB flash drives to cross an airgap. These kind of attacks may not be a concern if the aim is to secure smaller amounts.

The [https://en.wikipedia.org/wiki/SecureDrop SecureDrop] platform for securely leaking documents to journalists also uses USB drives for secure communication.

=== QR codes ===

The data can be encoded into QR codes and each computer can be equipped with a camera for scanning them. Advantages are speed and conveniance; QR codes are also believed to have a smaller attack surface than USB flash drives. A major disadvantage is that QR codes have size limits and so may not be able to encode larger bitcoin transactions, although the transactions could be split up into multiple chunks and recombined at the other end.

=== Transcribing by hand ===

This method involves displaying the data on screen and either 1) typing it with the keyboard of the other computer or 2) writing it down on paper and then typing into the other computer. The advantage is that any security issues of USB interfaces or cameras are completely avoided. The disadvantage is speed as this method is very very slow; bitcoin transactions can be tens of kilobytes in size and each character would need to be carefully copied without mistakes.

== Private key backup storage ==

This article only recommends using [[seed phrase]]s (possibly with [[Seed phrase#Two-Factor Seed Phrases|encryption]]) to store private key backups. Seed phrases written into metal or on paper support [[Deterministic wallet|deterministic wallets]] and encryption. As seed phrases use natural language words, they have excellent error correction. Words written in bad handwriting can often still be read. If one or two letters are missing or unreadable the word can often still be deduced. The word list that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it.

Other methods are discussed here for completeness.

Raw [[private keys]] written on a piece of paper:
* Anyone who can see it, can steal it.
* Handwriting can be hard to read or completely illegible, especially when mixing upper and lower-case letters.
* Human error in transcription can cause errors on end product, many private key formats can fail even if a single letter is transcribed incorrectly.
* Paper can rot, be torn, burn, or be smoke damaged.
* Doesn't support [[Deterministic wallet|deterministic wallets]], only a single keypair is stored.

Printed on a piece of paper:
* Anyone who can see it, can steal it
* Non-laser printer ink can run if paper gets wet
* The printer itself is a security risk - some have internet connections, wifi, and disk memory.
* Paper can rot, be torn, burn, or be smoke damaged

On laminated paper:
* Anyone who can see it, can steal it
* Lamination is prone or degradation over time and puncture or cuts that could allow moisture to get trapped in the paper and cause deterioration or rotting in some circumstances - store in cool dry place
* Can burn or be smoke damaged
* 'Fireproof' & 'Fire-resistant' boxes can help protect paper in a small house fire but be warned that they can sometimes fall apart in the fire and get wet if the fire is put out with water.
* Remember people can just carry out a small safe.

Engraved / etched/ ablated / stamped on a piece of metal:
* Anyone who can see it, can steal it
* Some metals can deteriorate or corrode, choose a good metal; also store your metal away from direct contact other metals. Some metals that are corrosion resistant have low melting points, are extremely expensive, or hard to machine.
* Metals can still deform or melt from heat, destroying any engraved SK. "Most house fires do not burn hotter than 1,200 degrees Fahrenheit. This temperature is typically associated with the hottest portion of a home, which is in the roof area. Homes that burn for longer than 30 minutes or consist of multiple levels sometimes burn at higher temperatures."
* You want to pick a metal that won't be destroyed by a fire. So magnesium, tin, and lead are all out as engraving materials.
Silver, gold, copper, brass, bronze, nickel, cobalt, would survive the housefire fire unmelted. Some Aluminium alloys can survive but you have to have the right ones. At around 1500° Steel and Nickel should be okay. Titanium is above the housefire range and so is tungsten, however tungsten rings are known to shatter due to the brittle nature of the very hard metal.

Stored digitally on a computer:
* Computers can crash, making data recovery expensive
* Data can still technically be recovered after a system is abandoned by the user. In some cases data can be recovered after multiple overwriting attempts and physical destruction (as long as the attacker can get all or most the pieces) so if you copy files to a new computer and ditch the old one, be careful.
* Can burn or be smoke damaged
* A traditional hard disc drive can have data corrupted by powerful magnetic fields and can physically shatter
* A non-negligible amount of HDDs suffer from factory defects that will cause them to fail unexpectedly during their lifetime
* Accidents can happen that could result in loss of data
* Solid state drives (SSDs) will lose data if unpowered, they may last years before this becomes a problem but it is unwise to store long-term data in unpowered SSDs
* If connected to internet it is another attack vector and the safety is only as good as the encryption used; I don't know what I would recommend but it wouldn't be BitLocker. Someone could be trying to break into the computer constantly. Even with good encryption if the machine or location is compromised the key could be stolen as soon as it is decrypted.
* There are a lot of ongoing threats with computers, from 0-day exploits to firmware exploits and malicious USB cords
* External hdds are good for storage for a few years at least if stored properly
* If not connected to internet, safety is only as good as the physical protection encryption used; could someone break into the location and copy the data without anyone noticing?

Stored digitally on CD, floppy disk, laserdisc, or mini-disc
* Plastics break down over time and with exposure to heat, humidity, regular light, all sorts of chemicals, even the oxygen in the air. This can lead to the loss of your data when stored on a medium made of plastic or written/printed on plastic.
* Can burn or be smoke damaged
* Can be physically damaged, making data recovery expensive or even impossible
* Magnetic media (tapes, floppy disc) can be damaged by magnets
* Data can become difficult to recover if the software and/or hardware to decode is old, don't use proprietary formats

Stored digitally on a flash drive
* Can break and have to be physically repaired before use
* Rapidly changing magnetic fields (See MRIs) can damage the data stored on flash drives
* Can burn or be smoke damaged
* Can become corroded from salt water or some atmospheric conditions
* If they break apart, some lighting conditions can cause data corruption (you can also put them back together and often still get the data)
* Different devices are all different, even similar devices from the same production batch can be different. There are large quality differences in drives but I am assuming you aren't using these for anything but storage.
* There are some fake flash drives that look like they saved the data but you can't get it back later
* Flash drives are not advised for long term storage; they can be used as one part of a multi-medium-location-format plan.

== Comparison between [[multisignature]] and cold storage for security ==

Cold storage aims to reducing the chance of failure due to hackers or malware. [[Multisignature]] aims to avoid a single point of failure. It is entirely possible to combine the two techniques, and create cold storage [[multisignature]] wallets.

== See also ==
* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/
* [[BitKey]]
* [[How to set up a secure offline savings wallet]]
* [https://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne-stores-his-bitcoin/ How Jason Bourne Stores His Bitcoins]
* [http://codinginmysleep.com/bitcoin-cold-storage-in-plain-english Bitcoin Cold Storage In Plain English] by David Perry
* [http://www.offlineaddress.com/?site=about#security-risk Security of private key] offlineaddress.com

==References==
<references />
[[Category:Introduction]]
[[Category:Security]]

Storing bitcoins

2019-11-25T07:20:38Z

Fresheneesz: /* Bad wallet ideas */ adding "physical" bitcoins

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]]. See [[Backup and Storage Methods]] for a review of published storage methods that give instructions for how to store a wallet.

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

''Main article: [[Hardware wallet]]''

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

=== Multisignature wallets ===

''Main article: [[Multisignature]]''

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key. Such a wallet can be used for requiring agreement among multiple people to spend, can eliminate a single point of failure, and can be used as form of backup, among other applications.

These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop, and smartphone, any two of which are required to move the money, but the compromise or total loss of any one key does not result in loss of money, even if that key has no backups.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, and can be nearly as convenient since all keys are online and the wallet user interfaces are typically easy to use.

Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

=== Cold storage wallets ===

''Main article: [[Cold storage]]''

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

=== Hot wallets ===

''Main article: [[Hot wallet]]''

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

''The following is a quote of waxwing on reddit<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>:''

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/
* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

=== "Physical" Bitcoins ===

Physical Coins and other mechanism with a pre-manufactured key or seed are not a good way to store bitcoins because they keys are already potentially compromised by whoever created the key. You should not consider bitcoin yours if its stored on a key created by someone else. It only becomes yours when you transfer the bitcoin to a key that you own.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Links to Storage Methods

2019-11-25T06:56:23Z

Fresheneesz: /* Other Storage Methods */ rm paper wallets which had no content

Storing bitcoins

2019-11-25T06:55:56Z

Fresheneesz: Adding link to Backup and Storage Methods

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]]. See [[Backup and Storage Methods]] for a review of published storage methods that give instructions for how to store a wallet.

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

''Main article: [[Hardware wallet]]''

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

=== Multisignature wallets ===

''Main article: [[Multisignature]]''

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key. Such a wallet can be used for requiring agreement among multiple people to spend, can eliminate a single point of failure, and can be used as form of backup, among other applications.

These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop, and smartphone, any two of which are required to move the money, but the compromise or total loss of any one key does not result in loss of money, even if that key has no backups.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, and can be nearly as convenient since all keys are online and the wallet user interfaces are typically easy to use.

Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

=== Cold storage wallets ===

''Main article: [[Cold storage]]''

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

=== Hot wallets ===

''Main article: [[Hot wallet]]''

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

''The following is a quote of waxwing on reddit<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>:''

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Links to Storage Methods

2019-11-25T06:55:13Z

Fresheneesz: Creating this page with content moved from Cold storage as well as adding a couple additional published methods from Alexandr Nellson and Bitgoldwallet

Storing bitcoins

2019-11-25T04:37:09Z

Fresheneesz: /* "Isn't it just like keeping your money in a bank?" */

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

''Main article: [[Hardware wallet]]''

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

=== Multisignature wallets ===

''Main article: [[Multisignature]]''

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key. Such a wallet can be used for requiring agreement among multiple people to spend, can eliminate a single point of failure, and can be used as form of backup, among other applications.

These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop, and smartphone, any two of which are required to move the money, but the compromise or total loss of any one key does not result in loss of money, even if that key has no backups.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, and can be nearly as convenient since all keys are online and the wallet user interfaces are typically easy to use.

Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

=== Cold storage wallets ===

''Main article: [[Cold storage]]''

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

=== Hot wallets ===

''Main article: [[Hot wallet]]''

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

''The following is a quote of waxwing on reddit<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>:''

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Storing bitcoins

2019-11-25T04:35:16Z

Fresheneesz: /* Multisignature wallets */ Clarifying wording

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

''Main article: [[Hardware wallet]]''

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

=== Multisignature wallets ===

''Main article: [[Multisignature]]''

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key. Such a wallet can be used for requiring agreement among multiple people to spend, can eliminate a single point of failure, and can be used as form of backup, among other applications.

These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop, and smartphone, any two of which are required to move the money, but the compromise or total loss of any one key does not result in loss of money, even if that key has no backups.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, and can be nearly as convenient since all keys are online and the wallet user interfaces are typically easy to use.

Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

=== Cold storage wallets ===

''Main article: [[Cold storage]]''

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

=== Hot wallets ===

''Main article: [[Hot wallet]]''

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Multi-signature

2019-11-25T04:34:39Z

Fresheneesz: Adding sections with more details on each major type of application

Multisignature (multisig) refers to requiring multiple keys to authorize a Bitcoin [[transaction]], rather than a single signature from one key. It has a number of applications.

* Dividing up responsibility for possession of bitcoins among multiple people.
* Avoiding a single-point of failure, making it substantially more difficult for the wallet to be compromised.
* M-of-N backup where loss of a single seed doesn't lead to loss of the wallet.

== Use as a joint account ==

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.

== Use for increasing security ==

The private keys needed to spend from a wallet can be spread across multiple machines, eliminating any one of those machines as a single point of failure, with the rationale that malware and hackers are unlikely to infect all of them. The higher the number of keys required to spend the funds (ie the higher M is in M-of-N), the more difficult it would be for an attacker to successfully steal your funds, however the more cumbersome actually using that wallet becomes.

The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop, and smartphone, any two of which are required to move the money, but the compromise of any one key cannot result in theft.

This can be used in conjunction with hardware wallets. By requiring that keys from multiple hardware wallets sign transactions, it can vastly reduce the likelihood that a malicious party that handled your hardware wallet could steal your funds, because in order for it to do that, the malicious party would have to compromise multiple hardware wallets. If each hardware wallet you use in a multisig wallet is made by a different company, it would be incredibly difficult for them to secretly conspire on an attack.

== Use as a backup ==

Storing multiple keys to an M-of-N wallet in different locations can serve as a backup. For example, in a 2-of-3 multisig wallet, the loss of one key does not result in loss of the wallet, since the other two keys can be used to recover the funds. The redundancy of the backup is the difference N minus M, so for example a 3-of-5 multisig wallet (with no additional seed backups) has a redundancy of 2, meaning that the loss of any 2 keys can still be recovered from.

== Multisignature Application Examples ==

* 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]].

* 1 OR 3-of-4: Distributed Backup - The primary owner can use the wallet at will, but if that owner loses their private keys, they can recover with the help of 3 of the other 4 trusted friends/organizations. One key could be kept in a security deposit box at a bank, the other 3 could be distribute to friends. In the case of death of the owner, the security deposit box can be willed to one of the trusted friends or someone who can get the help of the trusted friends. More [https://bitcoin.stackexchange.com/questions/89589/is-it-possible-to-do-a-3-of-5-or-1-multi-sig-for-backup-purposes/89590?noredirect=1#comment102505_89590 complex] multisig wallets can be created if desired.

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 wallets have implemented multisig:<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]
* [[Electrum]] - [http://docs.electrum.org/en/latest/multisig.html See tutorial].
* [[Xapo]]
* [[Coinkite]]
* Coinb.in - (''See the warnings about [[Javascript cryptography]]'')

===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]
* [https://bitcointalk.org/index.php?topic=507297.msg5594085 Discussion of multi-sig on Bitcoin talk]

Multi-signature

2019-11-25T04:07:02Z

Fresheneesz: Adding a fuller list of types of uses at the top. Removing coinbase since it no longer supports creation of multisig "vaults". Merging the multisig wallets and implementation sections

Multisignature (multisig) refers to requiring multiple keys to authorize a Bitcoin [[transaction]], rather than a single signature from one key. It has a number of applications, including:

* Dividing up responsibility for possession of bitcoins among multiple people.
* Avoiding a single-point of failure, making it substantially more difficult for the wallet to be compromised.
* M-of-N backup where loss of a single seed doesn't lead to loss of the wallet.

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.

== 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]].

* 1 OR 3-of-4: Distributed Backup - The primary owner can use the wallet at will, but if that owner loses their private keys, they can recover with the help of 3 of the other 4 trusted friends/organizations. One key could be kept in a security deposit box at a bank, the other 3 could be distribute to friends. In the case of death of the owner, the security deposit box can be willed to one of the trusted friends or someone who can get the help of the trusted friends. More [https://bitcoin.stackexchange.com/questions/89589/is-it-possible-to-do-a-3-of-5-or-1-multi-sig-for-backup-purposes/89590?noredirect=1#comment102505_89590 complex] multisig wallets can be created if desired.

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 wallets have implemented multisig:<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]
* [[Electrum]] - [http://docs.electrum.org/en/latest/multisig.html See tutorial].
* [[Xapo]]
* [[Coinkite]]
* Coinb.in - (''See the warnings about [[Javascript cryptography]]'')

===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]
* [https://bitcointalk.org/index.php?topic=507297.msg5594085 Discussion of multi-sig on Bitcoin talk]

Multi-signature

2019-11-25T03:44:24Z

Fresheneesz: Shamir's secret sharing is not at all multi-sig. Removing it and its dead-link reference.

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==
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]].

* 1 OR 3-of-4: Distributed Backup - The primary owner can use the wallet at will, but if that owner loses their private keys, they can recover with the help of 3 of the other 4 trusted friends/organizations. One key could be kept in a security deposit box at a bank, the other 3 could be distribute to friends. In the case of death of the owner, the security deposit box can be willed to one of the trusted friends or someone who can get the help of the trusted friends. More [https://bitcoin.stackexchange.com/questions/89589/is-it-possible-to-do-a-3-of-5-or-1-multi-sig-for-backup-purposes/89590?noredirect=1#comment102505_89590 complex] multisig wallets can be created if desired.

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]

Storing bitcoins

2019-11-25T03:41:50Z

Fresheneesz: /* Multisignature wallets */ Removing note about paper backups, because the fact that multi-sig wallets can be backed up is irrelevant to the use of multisig. Other minor improvements. Removing incomplete information best left to the main article.

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

''Main article: [[Hardware wallet]]''

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

=== Multisignature wallets ===

''Main article: [[Multisignature]]''

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop, and smartphone, any two of which are required to move the money, but the compromise or total loss of any one key does not result in loss of money, even if that key has no backups.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, and can be nearly as convenient since all keys are online and the wallet user interfaces are typically easy to use. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

=== Cold storage wallets ===

''Main article: [[Cold storage]]''

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

=== Hot wallets ===

''Main article: [[Hot wallet]]''

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Storing bitcoins

2019-11-25T03:32:24Z

Fresheneesz: /* Types of wallets */ Moving main-article links to the section tops, as is standard on wikipedia

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

''Main article: [[Hardware wallet]]''

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

=== Multisignature wallets ===

''Main article: [[Multisignature]]''

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop and smartphone; any two are required to move the money but the loss of any one does not result in loss of money especially because they can be restored from paper backup.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, as well as being convenient as all keys are online and the wallet user interfaces are typically easy to use. Wallet software [[Electrum]] and [[Armory]] can create multisig wallets. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

=== Cold storage wallets ===

''Main article: [[Cold storage]]''

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

=== Hot wallets ===

''Main article: [[Hot wallet]]''

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Storing bitcoins

2019-11-25T03:21:23Z

Fresheneesz: /* Hardware wallets */ rewording to be a bit more specific and clear

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] holds the seed in its internal storage and is typically designed to be resistant to both physical and digital attacks. The device signs the transactions internally and only transmits the signed transactions to the computer, never communicating any secret data to the devices it connects to. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are one of the best ways to store bitcoins.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which give away that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still, physical access to a hardware wallet does not mean that the keys are easily compromised, even though it does make it easier to compromise the hardware wallet. The groups that have created the most popular hardware wallets have gone to great lengths to harden the devices to physical threats and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's consent. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

Main article: [[Hardware wallet]]

=== Multisignature wallets ===

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop and smartphone; any two are required to move the money but the loss of any one does not result in loss of money especially because they can be restored from paper backup.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, as well as being convenient as all keys are online and the wallet user interfaces are typically easy to use. Wallet software [[Electrum]] and [[Armory]] can create multisig wallets. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

Main article: [[Multisignature]]

=== Cold storage wallets ===

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

Main article: [[Cold storage]]

=== Hot wallets ===

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

Main article: [[Hot wallet]]

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Storing bitcoins

2019-11-25T02:57:53Z

Fresheneesz: /* Discussion of wallet solutions */

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Types of wallets ==

=== Hardware wallets ===

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] typically holds the private keys in its internal storage and is designed to be malware resistant. The device signs the transactions internally and only transmits the signed transactions to the computer. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are a top solution for holding private keys.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which prove that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still physical access to a hardware wallet, even though it reduces its security strength, does not mean that the keys are easily compromised. The companies creating them, have gone to great lengths to secure them and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's knowledge. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

Main article: [[Hardware wallet]]

=== Multisignature wallets ===

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop and smartphone; any two are required to move the money but the loss of any one does not result in loss of money especially because they can be restored from paper backup.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, as well as being convenient as all keys are online and the wallet user interfaces are typically easy to use. Wallet software [[Electrum]] and [[Armory]] can create multisig wallets. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

Main article: [[Multisignature]]

=== Cold storage wallets ===

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

Main article: [[Cold storage]]

=== Hot wallets ===

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

Main article: [[Hot wallet]]

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Storing bitcoins

2019-11-25T00:26:30Z

Fresheneesz: /* Protection from accidental loss */ Moving most content about storing the seed from this section to Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term as a more canonical location. Also adding information about redundancy in backups.

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, corrupted SSD devices, or numerous other slip ups.

The key to protecting yourself from data loss of any kind is to have redundant backups so that if one is lost or destroyed, you still have others you can use when you need them. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet as a backup, so that if your primary wallet is lost or damaged, you can use the seed recovery phrase to restore access to your coins. If you have more than one backup location, they should be in places where various disasters won't affect both of your backups. For example, its much better to store two backups in a home safe and in a safe deposit box (as long as your seed is protected by a passphrase) than to store two backups in your bedroom and one in your garage.

Also important is regularly verifying that your backup still exists and is in good condition. This can be as simple as ensuring your backups are still where you put them a couple times a year.

The best practices for backing up a seed is to store the seed using '''pencil and paper''' or '''stamped metal''' and storing in multiple secure locations. See [[Seed_phrase#Storing_Seed_Phrases_for_the_Long_Term]] for details.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Discussion of wallet solutions ==

=== Hardware wallets ===

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] typically holds the private keys in its internal storage and is designed to be malware resistant. The device signs the transactions internally and only transmits the signed transactions to the computer. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are a top solution for holding private keys.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which prove that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still physical access to a hardware wallet, even though it reduces its security strength, does not mean that the keys are easily compromised. The companies creating them, have gone to great lengths to secure them and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's knowledge. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

Main article: [[Hardware wallet]]

=== Multisignature wallets ===

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop and smartphone; any two are required to move the money but the loss of any one does not result in loss of money especially because they can be restored from paper backup.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, as well as being convenient as all keys are online and the wallet user interfaces are typically easy to use. Wallet software [[Electrum]] and [[Armory]] can create multisig wallets. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

Main article: [[Multisignature]]

=== Cold storage wallets ===

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

Main article: [[Cold storage]]

=== Hot wallets ===

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

Main article: [[Hot wallet]]

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Seed phrase

2019-11-25T00:26:27Z

Fresheneesz: /* Storing Seed Phrases for the Long Term */ Moving some content here from Storing bitcoins, some organization

A '''seed phrase''', '''seed recovery phrase''' or '''backup seed phrase''' is a list of words which [[Storing bitcoins|store]] all the information needed to recover a Bitcoin wallet. Wallet software will typically generate a seed phrase and instruct the user to write it down on paper. If the user's computer breaks or their hard drive becomes corrupted, they can download the same wallet software again and use the paper backup to get their bitcoins back.

Anybody else who discovers the phrase can steal the bitcoins, so it must be kept safe like jewels or cash. For example, it must not be typed into any website.

Seed phrases are an excellent way of backing up and [[storing bitcoins]] and so they are used by almost all well-regarded wallets.<ref>[https://bitcoin.org/en/choose-your-wallet Bitcoin.org: Choose your wallet]</ref>

== Example ==

An example of a seed phrase is:

witch collapse practice feed shame open despair creek road again ice least

The word order is important.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|none|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

== Explanation ==

A simplified explanation of how seed phrases work is that the wallet software has a list of words taken from a dictionary, with each word assigned to a number. The seed phrase can be converted to a number which is used as the seed integer to a [[Deterministic wallet|deterministic wallet]] that generates all the [[Private key|key pairs]] used in the wallet.

The English-language wordlist for the BIP39 standard has 2048 words, so if the phrase contained only 12 random words, the number of possible combinations would be 2048^12 = 2^132 and the phrase would have 132 bits of security. However, some of the data in a BIP39 phrase is not random,<ref>[https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic BIP39: Generating the mnemonic]</ref> so the actual security of a 12-word BIP39 seed phrase is only 128 bits. This is approximately the same strength as all Bitcoin private keys, so most experts consider it to be sufficiently secure.<ref>[https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Security BIP32: Security]</ref>

It is not safe to invent your own seed phrase because humans are bad at generating randomness. The best way is to allow the wallet software to generate a phrase which you write down.

As seed phrases use natural language words, they have excellent error correction. Words written in bad handwriting can often still be read. If one or two letters are missing or unreadable the word can often still be deduced. The [[#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it. This compares well with writing down a raw [[private key]] where a single letter being unreadable or incorrect can make the private key useless (depending on the serialization format).

== Two-Factor Seed Phrases ==

Seed phrases, like all backups, can store any amount of bitcoins. It's a concerning idea to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a password.

The password can be used to create a two-factor seed phrase where both ''"something you have"'' plus ''"something you know"'' is required to unlock the bitcoins.

This works by the wallet creating a seed phrase and asking the user for a password. Then both the seed phrase and extra word are required to recover the wallet. Electrum and some other wallets call the passphrase a '''"seed extension"''', '''"extension word"''' or '''"13th/25th word"'''. The BIP39 standard defines a way of passphrase-protecting a seed phrase. A similar scheme is also used in the Electrum standard. If a passphrase is not present, an empty string "" is used instead.

'''Warning''': Forgetting this password will result in the bitcoin wallet and any contained money being lost. Do not overestimate your ability to remember passphrases especially when you may not use it very often.

'''Warning''': The seed phrase password should not be confused with the password used to encrypt the wallet file on disk. This is probably why many wallets call it an extension word instead of a password.

== Storing Seed Phrases for the Long Term ==

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives, or corrupted SSD devices. It's also important to protect the seed from theft. It is best not to get creative with your security, and instead use tried and true methods.

It could be a good idea to write some words of explanation on the same paper as the seed phrase. If storing for the long term you may forget what a phrase is how it should be treated. A sample explanation that can be adapted is:

<blockquote>These twelve words have control over BITCOINS. Keep this paper safe and secret, like cash or jewelry. The bitcoin information on this paper is encrypted with a passphrase. It is part of a multisignature wallet and was made by Electrum bitcoin wallet software on 1/1/2019.</blockquote>

==== Paper and Pencil Backup ====

Through bitter experience it has been found that one of the most practical storage mediums is '''pencil and paper'''. The private keys of a bitcoin wallet are encoded into [[seed phrase|random words from a dictionary]] which can be written down. If your hard drive crashes, you can find the paper with the [[seed phrase]] and restore the entire wallet. As [[seed phrase]]s use natural language words, they have good error correction. Words written in bad handwriting can often still be read. If one or two letters are missing the word can often still be deduced. The [[Seed_phrase#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it.

For storing on paper writing with pencil is much better than pen
<ref>[http://www.joethorn.net/blog/2011/12/07/pencil-does-not-fade Pencil Does Not Fade]
</ref><ref>[https://www.quora.com/How-do-I-maintain-a-paper-notebook-that-can-remain-for-years How do I maintain a paper notebook that can remain for years?]
</ref>.
Paper should be acid-free or archival paper, and stored in the dark avoiding extremes of heat and moisture
<ref>[https://www.loc.gov/preservation/care/deterioratebrochure.html Essential facts about preservation of Paper]
</ref><ref>[https://www.quora.com/If-I-write-with-a-pencil-on-my-notebook-will-the-writing-last-for-a-long-time-say-50-years-or-will-it-just-fade-away-gradually Writing in a notebook with pencil]
</ref><ref>[http://copar.org/bulletin14.htm CoPAR: Creating records that will last]</ref>.

==== Stamped Metal Backup ====

Even better than paper, there are a number of more [https://blog.lopp.net/metal-bitcoin-seed-storage-stress-test--part-ii-/ durable seed storage methods], like stamped metal plates. These are far more durable and can last a lot longer than paper. One of these methods is certainly recommended for anyone storing a significant amount of bitcoin.

==== Methods that are not recommended ====

Some methods that are not recommended are: memorizing ([[Brainwallets]]), storing in a file on a computer (including online), or storing online.

Some people get the idea to split up their phrases, like storing 6 words in one location and the other 6 words in another location. This is a bad idea and should not be done, because if one set of 6 words is discovered then it becomes far easier to bruteforce the rest of the phrase. Storing bitcoins in multiple locations like this should be done via [[multisignature]] wallets instead. Note that [[Shamir's secret sharing]] algorithm is also theoretically a secure way to store a seed in parts, but that it is currently difficult to find good-quality tools for doing it and there are many pitfalls in implementing it. Also, multi-signature wallets are better in a lot of ways, and most of the benefits Sharmir's algorithm has over multisig at the moment will disappear once technologies like [[Schnorr|Schnorr signatures]] are released.

Another bad idea is to add random decoy words that are somehow meaningful to you, and later remove them to be left only with the 12 word phrase. The phrase words come from a known dictionary (see next section), so anybody can use that dictionary to weed out the decoy words.

== Word Lists ==

Generally a seed phrase only works with the same wallet software that created it. If storing for a long period of time it's a good idea to write the name of the wallet too.

The BIP39 English word list has each word being uniquely identified by the first four letters, which can be useful when space to write them is scarce.

* [https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md BIP39 wordlists]
* [https://github.com/spesmilo/electrum/blob/1.9.8/lib/mnemonic.py Electrum old-style wordlist]
* [https://github.com/spesmilo/electrum/blob/master/electrum/wordlist/english.txt Electrum new-style wordlist]

== Alternative name "Mnemonic Phrase" ==

Seed phrases are sometimes called "mnemonic phrases" especially in older literature. This is a bad name because the word mnemonic implies that the phrase should be memorized. It is less misleading to call them seed phrases.

== The power of backups ==

An especially interesting aspect in the power of paper backups is allowing your money to be two places at once. At the London Inside Bitcoin conference the keynote speaker showed 25 paper backups they were carrying -- all password-protected. With that one can carry $100,000 which can instantly be moved to a phone or transferred yet with total security. If it's stolen then there is no risk because it is backed up elsewhere. That is powerful.<ref>https://www.reddit.com/r/Bitcoin/comments/2hmnru/poll_do_you_use_paper_wallets_why_why_not_what/</ref>

== See Also ==

* [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP39 mnemonic phrase standard]
* [[Deterministic wallet]]
* [[Storing bitcoins]]
* [[Brainwallet]]
* [https://github.com/6102bitcoin/FAQ/blob/master/seed.md FAQ regarding bitcoin seeds]

==References==
<references />

[[Category:Technical]]

Talk:Shamir Secret Snakeoil

2019-11-25T00:20:20Z

Fresheneesz: Created page with "This article should be cleaned up to remove bias. I understand Greg Maxwell is well respected in terms of his cryptography knowledge, but its clear that this article is writte..."

This article should be cleaned up to remove bias. I understand Greg Maxwell is well respected in terms of his cryptography knowledge, but its clear that this article is written in a way that includes many [https://en.wikipedia.org/wiki/Weasel_word weasel words], including in the title itself. Shamir's secret sharing algorithm is, even by Greg Maxwell's own admission here, a perfectly valid and secure algorithm. The fact that many programmers have botched the implementation is not an indictment of the algorithm itself. This page should be upgraded to be a bit more professional and unbiased, noting the pitfalls as well as the downsides in comparison to multisig alternatives, but also being clear that it is a secure tool people can use as long as they find well vetted implementations (like anything in cryptography). [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 00:20, 25 November 2019 (UTC)

Talk:Javascript cryptography

2019-11-24T23:54:35Z

Fresheneesz: Created page with "I take issue with a lot of this. I think there is no reason that javascript should be seen as a bad language for cryptography. The reasoning here is quite weak. All modern bro..."

I take issue with a lot of this. I think there is no reason that javascript should be seen as a bad language for cryptography. The reasoning here is quite weak. All modern browsers come with secure encryption functions that can and have been used to create secure cryptographic functions and tools using javascript. Also, node.js has an enormous amount of well vetted code, including in the space of cryptography. Its a little bit absurd so say that because some people wrote bad cryptographic functions in javascript, no one should ever use cryptography in javascript. [[User:Fresheneesz|Fresheneesz]] ([[User talk:Fresheneesz|talk]]) 23:54, 24 November 2019 (UTC)

Storing bitcoins

2019-11-24T23:28:37Z

Fresheneesz: /* Protection from theft */ password -> passphrase and adding some nuaunces to the text about theft of a seed

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives or corrupted SSD devices. Through bitter experience it was found that one of the most practical storage mediums is '''pencil and paper'''. The private keys of a bitcoin wallet are encoded into [[seed phrase|random words from a dictionary]] which can be written down. If your hard drive crashes, you can find the paper with the [[seed phrase]] and restore the entire wallet. Even better than paper, there are a number of more [https://blog.lopp.net/metal-bitcoin-seed-storage-stress-test--part-ii-/ durable seed storage methods], like stamped metal plates. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet. It is a good idea to keep backup copies in several locations.

As [[seed phrase]]s use natural language words, they have good error correction. Words written in bad handwriting can often still be read. If one or two letters are missing the word can often still be deduced. The [[Seed_phrase#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, stealing your bitcoins. The average person's computer is usually vulnerable to malware, so that must be taken into account when deciding on storage solutions.

Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins if the seed isn't also protected by a secret passphrase. Even when using a passphrase, a seed should be kept safe and secret like jewels or cash. For example, no part of a seed should ever be typed into any website, and no one should store a seed on an internet-connected computer unless they are an advanced user who has researched what they're doing.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a passphrase. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Discussion of wallet solutions ==

=== Hardware wallets ===

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] typically holds the private keys in its internal storage and is designed to be malware resistant. The device signs the transactions internally and only transmits the signed transactions to the computer. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are a top solution for holding private keys.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which prove that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still physical access to a hardware wallet, even though it reduces its security strength, does not mean that the keys are easily compromised. The companies creating them, have gone to great lengths to secure them and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's knowledge. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

Main article: [[Hardware wallet]]

=== Multisignature wallets ===

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop and smartphone; any two are required to move the money but the loss of any one does not result in loss of money especially because they can be restored from paper backup.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, as well as being convenient as all keys are online and the wallet user interfaces are typically easy to use. Wallet software [[Electrum]] and [[Armory]] can create multisig wallets. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

Main article: [[Multisignature]]

=== Cold storage wallets ===

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

Main article: [[Cold storage]]

=== Hot wallets ===

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

Main article: [[Hot wallet]]

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Storing bitcoins

2019-11-24T23:17:37Z

Fresheneesz: /* Verification and privacy */ Removing misleading information about "counterfeit bitcoin", removing some redundant linking, and fixing some wording

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives or corrupted SSD devices. Through bitter experience it was found that one of the most practical storage mediums is '''pencil and paper'''. The private keys of a bitcoin wallet are encoded into [[seed phrase|random words from a dictionary]] which can be written down. If your hard drive crashes, you can find the paper with the [[seed phrase]] and restore the entire wallet. Even better than paper, there are a number of more [https://blog.lopp.net/metal-bitcoin-seed-storage-stress-test--part-ii-/ durable seed storage methods], like stamped metal plates. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet. It is a good idea to keep backup copies in several locations.

As [[seed phrase]]s use natural language words, they have good error correction. Words written in bad handwriting can often still be read. If one or two letters are missing the word can often still be deduced. The [[Seed_phrase#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without inspecting them and verifying that they look genuine. The same is true with bitcoin. Wallet software can automatically verify that a payment has been made and when that payment has been completed (by being mined into a number of blocks). The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. When receiving large volumes, it is essential to use wallet software that connects to a full node you run yourself. If bitcoin is digital gold, then a full node is your own personal digital goldsmith who checks that received bitcoin payments are actually real. [[Lightweight node|Lightweight wallets]] have a number of security downsides because they don't check all of bitcoin's rules, and so should only be used for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a full node avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The full node wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, effectively stealing your bitcoins. The average person's computer is usually vulnerable to malware so that must be taken into account when deciding on storage solutions. Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins, so it must be kept safe and secret like jewels or cash. In particular phrases should not be typed into any website.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a password. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Discussion of wallet solutions ==

=== Hardware wallets ===

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] typically holds the private keys in its internal storage and is designed to be malware resistant. The device signs the transactions internally and only transmits the signed transactions to the computer. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are a top solution for holding private keys.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which prove that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still physical access to a hardware wallet, even though it reduces its security strength, does not mean that the keys are easily compromised. The companies creating them, have gone to great lengths to secure them and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's knowledge. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

Main article: [[Hardware wallet]]

=== Multisignature wallets ===

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop and smartphone; any two are required to move the money but the loss of any one does not result in loss of money especially because they can be restored from paper backup.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, as well as being convenient as all keys are online and the wallet user interfaces are typically easy to use. Wallet software [[Electrum]] and [[Armory]] can create multisig wallets. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

Main article: [[Multisignature]]

=== Cold storage wallets ===

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

Main article: [[Cold storage]]

=== Hot wallets ===

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

Main article: [[Hot wallet]]

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Storing bitcoins

2019-11-24T23:04:10Z

Fresheneesz: /* Introduction */ Adding image of a seed stamped on metal

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

[[File:Blockplate_2.0.jpg|200px|thumb|alt=Example seed stamped on metal.|Example seed stamped on metal.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives or corrupted SSD devices. Through bitter experience it was found that one of the most practical storage mediums is '''pencil and paper'''. The private keys of a bitcoin wallet are encoded into [[seed phrase|random words from a dictionary]] which can be written down. If your hard drive crashes, you can find the paper with the [[seed phrase]] and restore the entire wallet. Even better than paper, there are a number of more [https://blog.lopp.net/metal-bitcoin-seed-storage-stress-test--part-ii-/ durable seed storage methods], like stamped metal plates. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet. It is a good idea to keep backup copies in several locations.

As [[seed phrase]]s use natural language words, they have good error correction. Words written in bad handwriting can often still be read. If one or two letters are missing the word can often still be deduced. The [[Seed_phrase#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without verifying that the banknotes were genuine and that the gold was real. The same is true with bitcoin. Payments must be genuine or else you may be slipped counterfeit bitcoins and be left out of pocket. The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. For receiving large volumes it is essential to use wallet software backed by a [[full node]]. If bitcoin is digital gold, then a [[full node]] is your own personal goldsmith who checks that received bitcoin payments are actually real. Lightweight wallets which don't check all of bitcoin's rules are only appropriate for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a [[full node]] avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The [[full node]] wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, effectively stealing your bitcoins. The average person's computer is usually vulnerable to malware so that must be taken into account when deciding on storage solutions. Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins, so it must be kept safe and secret like jewels or cash. In particular phrases should not be typed into any website.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a password. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Discussion of wallet solutions ==

=== Hardware wallets ===

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] typically holds the private keys in its internal storage and is designed to be malware resistant. The device signs the transactions internally and only transmits the signed transactions to the computer. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are a top solution for holding private keys.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which prove that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still physical access to a hardware wallet, even though it reduces its security strength, does not mean that the keys are easily compromised. The companies creating them, have gone to great lengths to secure them and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's knowledge. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

Main article: [[Hardware wallet]]

=== Multisignature wallets ===

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop and smartphone; any two are required to move the money but the loss of any one does not result in loss of money especially because they can be restored from paper backup.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, as well as being convenient as all keys are online and the wallet user interfaces are typically easy to use. Wallet software [[Electrum]] and [[Armory]] can create multisig wallets. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

Main article: [[Multisignature]]

=== Cold storage wallets ===

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

Main article: [[Cold storage]]

=== Hot wallets ===

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

Main article: [[Hot wallet]]

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

File:Blockplate 2.0.jpg

2019-11-24T23:02:31Z

Fresheneesz: A stamped Blockplate.

== Summary ==
A stamped Blockplate.
== Licensing ==
{{PD-ineligible}}

Storing bitcoins

2019-11-24T22:55:23Z

Fresheneesz: /* Protection from accidental loss */ adding mention of more durable seed storage and link to Jameson Lopp's stress tests

This page is a discussion of the different ways of storing bitcoins, whether for [[Bitcoin as an investment|investment purposes]] or as a [[Bitcoin as a medium of exchange|medium of exchange]].

As bitcoin is a digital asset, it can be very un-intuitive to store safely. Historically many people have lost their coins but with proper understanding the risks can be eliminated. If your bitcoins do end up lost or stolen then there's almost certainly nothing that can be done to get them back.

tl;dr The best way to store bitcoin is to either use a [[hardware wallet]], a [[Multisignature|multisignature wallet]] or a [[Cold storage|cold storage wallet]]. Have your wallet create a [[seed phrase]], write it down on paper and store it in a safe place (or several safe places, as backups). The wallet should be backed by your own [[full node]].

== Introduction ==

Storage of bitcoin can be broken down in a few independent goals:

* Protection against accidental loss
* Verification that the bitcoins are genuine
* Privacy and protection against spying
* Protection against theft
* Easy access for spending or moving bitcoins

The art and science of storing bitcoins is about keeping your private keys safe, yet remaining easily available to you when you want to make a transaction. It also requires verifying that you received real bitcoins, and stopping an adversary from spying on you.

[[File:Mnemonic-seed-still-life.jpg|300px|thumb|alt=An example seed phrase written on paper|Example seed phrase on paper.]]

=== Protection from accidental loss ===

In the past many people have accidentally lost bitcoins because of failed backups, mistyped letters, forgotten hard drives or corrupted SSD devices. Through bitter experience it was found that one of the most practical storage mediums is '''pencil and paper'''. The private keys of a bitcoin wallet are encoded into [[seed phrase|random words from a dictionary]] which can be written down. If your hard drive crashes, you can find the paper with the [[seed phrase]] and restore the entire wallet. Even better than paper, there are a number of more [https://blog.lopp.net/metal-bitcoin-seed-storage-stress-test--part-ii-/ durable seed storage methods], like stamped metal plates. All good wallet software asks their users to write down the [[seed phrase|seed recovery phrase]] of the wallet. It is a good idea to keep backup copies in several locations.

As [[seed phrase]]s use natural language words, they have good error correction. Words written in bad handwriting can often still be read. If one or two letters are missing the word can often still be deduced. The [[Seed_phrase#Word_Lists|word list]] that the seed phrase words are drawn from is carefully chosen so that the first four letters of each word are enough to uniquely identify it.

=== Verification and privacy ===

Storing a [[seed phrase]] only stores [[Private key|private keys]], but it cannot tell you if or how many bitcoins you have actually received. For that you need wallet software.

If you received cash banknotes or gold coins as payment, you wouldn't accept them without verifying that the banknotes were genuine and that the gold was real. The same is true with bitcoin. Payments must be genuine or else you may be slipped counterfeit bitcoins and be left out of pocket. The most secure kind of wallet is one which independently verifies ''all'' the rules of bitcoin, known as a [[full node]]. For receiving large volumes it is essential to use wallet software backed by a [[full node]]. If bitcoin is digital gold, then a [[full node]] is your own personal goldsmith who checks that received bitcoin payments are actually real. Lightweight wallets which don't check all of bitcoin's rules are only appropriate for receiving smaller amounts or when you trust the sender. See the article about [[full node|full nodes]].

Your wallet software will also need to learn the history and balance of its wallet. For a lightweight wallet this usually involves querying a third-party server which leads to a privacy problem as that server can spy on you by seeing your entire balance, all your transactions and usually linking it with your IP address. Using a [[full node]] avoids this problem because the software connects directly to the bitcoin p2p network and downloads the entire [[blockchain]], so any adversary will find it much harder to obtain information. See also: [[Anonymity]]

So for verification and privacy, a good storage solution should be backed by a [[full node]] under your own control for use when receiving payments. The [[full node]] wallet on an online computer can be a watch-only wallet. This means that it can detect transaction involving addresses belonging to the user and can display transaction information about them, but still does not have the ability to actually spend the bitcoins.

=== Protection from theft ===

Possession of bitcoins comes from your ability to keep the private keys under your exclusive control. In bitcoin, keys are money. Any malware or hackers who learn what your private keys are can create a valid bitcoin transaction sending your coins to themselves, effectively stealing your bitcoins. The average person's computer is usually vulnerable to malware so that must be taken into account when deciding on storage solutions. Anybody else who discovers a wallet's [[seed phrase]] can steal all the bitcoins, so it must be kept safe and secret like jewels or cash. In particular phrases should not be typed into any website.

[[Seed phrase]]s can store any amount of bitcoins. It doesn't seem secure to possibly have enough money to purchase the entire building just sitting on a sheet of paper without any protection. For this reason many wallets make it possible to encrypt a seed phrase with a password. See [[Seed phrase#Two-Factor_Seed_Phrases]]

=== Easy access ===

Some users may not need to actually move their bitcoins very often, especially if they [[Bitcoin as an investment|own bitcoin as an investment]]. Other users will want to be able to quickly and easily move their coins. A solution for storing bitcoins should take into account how convenient it is to spend from depending on the user's needs.

=== Summary ===

In summary: bitcoin wallets should be backed up by writing down their [[seed phrase]], this phrase must be kept safe and secret, and when sending or receiving transactions the wallet software should obtain information about the bitcoin network from your own [[full node]].

== Discussion of wallet solutions ==

=== Hardware wallets ===

[[Hardware wallet]]s are special purpose security-hardened devices for storing Bitcoins on a peripheral that is trusted to generate wallet keys and sign transactions.

A [[hardware wallet]] typically holds the private keys in its internal storage and is designed to be malware resistant. The device signs the transactions internally and only transmits the signed transactions to the computer. The separation of the private keys from the vulnerable environment allows the user to spend bitcoins without running any risk even when using an untrustworthy computer. Hardware wallets are relatively user-friendly and are a top solution for holding private keys.

Some downsides are that hardware wallets are recognizable physical objects which could be discovered and which prove that you probably own bitcoins. This is worth considering when for example crossing borders. They also cost more than software wallets. Still physical access to a hardware wallet, even though it reduces its security strength, does not mean that the keys are easily compromised. The companies creating them, have gone to great lengths to secure them and, though not impossible, only technically skilled people with specialized equipment have been able to get access to the private keys without the owner's knowledge. However, physically-powerful people such as armed border guards upon seeing the hardware wallet could force you to type in the PIN number to unlock the device and steal the bitcoins.

Main article: [[Hardware wallet]]

=== Multisignature wallets ===

A multisignature wallet is one where multiple private keys are required to move the bitcoins instead of a single key, avoiding a single point of failure. These private keys can be spread across multiple machines in various locations with the rationale that malware and hackers are unlikely to infect all of them. The multisig wallet can be of the m-of-n type where any m private keys out of a possible n are required to move the money. For example a 2-of-3 multisig wallet might have your private keys spread across a desktop, laptop and smartphone; any two are required to move the money but the loss of any one does not result in loss of money especially because they can be restored from paper backup.

Multisignature wallets have the advantage of being cheaper than hardware wallets since they are implemented in software and can be downloaded for free, as well as being convenient as all keys are online and the wallet user interfaces are typically easy to use. Wallet software [[Electrum]] and [[Armory]] can create multisig wallets. Hardware and multisignature wallets can be combined by having a multisignature wallet with the private keys held on hardware wallets; after all a single hardware wallet is still a single point of failure. Cold storage and multisignature can also be combined, by having the multisignature wallet with the private keys held in cold storage to avoid them being kept online.

Main article: [[Multisignature]]

=== Cold storage wallets ===

A cold wallet generates and stores private wallet keys offline on a clean, newly-installed [https://en.wikipedia.org/wiki/Air_gap_(networking) air-gapped] computer. Payments are received online with a watch-only wallet. Unsigned transactions are generated online, transferred offline for signing, and the signed transaction is transferred online to be broadcast to the Bitcoin network.

This allows funds to be managed offline in [[Cold storage]]. Used correctly a cold wallet is protected against online threats, such as viruses and hackers. Cold wallets are similar to hardware wallets, except that a general purpose computing device is used instead of a special purpose peripheral. The downside is that the transferring of transactions to and fro can be fiddly and unweilding, and less practical for carrying around like a hardware wallet.

Main article: [[Cold storage]]

=== Hot wallets ===

A hot wallet refers to keeping single-signature wallets with private keys kept on an online computer or mobile phone. Most bitcoin wallet software out there is a hot wallet. The bitcoins are easy to spend but are maximally vulnerable to malware or hackers. Hot wallets may be appropriate for small amounts and day-to-day spending.

Main article: [[Hot wallet]]

== Bad wallet ideas ==

=== Custodial wallets ===

Custodial wallets are where an exchange, broker or other third party holds your bitcoins in trust.

The number one rule to storing bitcoin is this: if you don’t hold the private keys, you don’t actually own the assets. There are many historical examples of loss due to custodial wallets: Bitcoinica, Silk Road, Bitfloor, [[Collapse of Mt. Gox|MTGOX]], Sheep Marketplace, BTC-e, Bitstamp, Bitfinex, Bithumb, Cryptsy, Bter, Mintpal and many more<ref>https://bitcointalk.org/index.php?topic=576337</ref>

==== "Isn't it just like keeping your money in a bank?" ====

:There are trade offs with everything, but trusting Coinbase with your Bitcoin is ''not'' the same as trusting a bank with your dollars:

:Suppose 5 people are needed to access the funds, within Coinbase, e.g. the CEO, the tech lead engineer and 3 other senior employees. Suppose one day they wake up and decide to be evil and move all the Bitcoin to some private account of theirs, and perhaps make up a story in the press about how they've been "hacked". You have a serious problem, as you might find there is a protracted legal battle (see MtGox), but you can't actually retrieve the funds unless in some way the company is re-stocked with Bitcoin, or perhaps an equivalent in fiat.

:If on the other hand you controlled the funds with a majority of keys in a multisig i.e. you own both of the two needed keys of a 2-of-3 multisig, then it would always effectively be your bitcoin, even though the third key may belong to a trusted third party custodian. But this also comes with the responsibility that if you get hacked, you lose all your funds. That is why it's prudent, in a 2-of-3 multisig where you have the two needed keys, to have them in separate systems/locations. If one of them fails, you can go to the custodian to supply the third key and transfer your funds again to safety. But the custodian alone, cannot touch your funds just by virtue of having the third key.

:Now, if your bank gets hacked similarly - 5 key operatives in the bank decide to swipe your money and pretend it was external hackers - SWIFT transfers are made to accounts in Russia and China. Here it will always ultimately be at the discretion of legal agencies whether you "actually" still have the money that is stolen. Because dollars are not real, they can be created at a whim<ref>https://en.wikipedia.org/wiki/Fractional-reserve_banking</ref>, and while reversing international transfers is not ''quite'' so simple, very often that reversal can be achieved (e.g. recent SWIFT hack at bangladesh<ref>https://www.wired.com/2016/05/insane-81m-bangladesh-bank-heist-heres-know/</ref><ref>https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery</ref> bank; $1 billion stolen, all but $80 million "recovered" (just means wire transfers reversed)). Added to that consider that fiat money is insured, so even when transfers can't be reversed, the money can be "recovered". If too many banks get hacked all at once the Federal Reserve and the government together can make up some "fund" that magically reassigns balances any time they like, with sufficient political will (that's essentially what was happening in 2008 TARP etc).

:So far no insurance company has ever paid out on a Bitcoin company's claim. Worth considering also.

:You might say, since it's risky both ways, why not trust Coinbase? Aren't they more competent in security than me?

:Almost certainly, but this argument has two massive holes in it: (1) because they ''concentrate'' funds they are a massive target for hackers, while you are not - at all. (2) they are a ''trusted third party'' so the situation is strictly worse - not only do you have to trust their security skills, but you also have to trust them not to steal (modulo multisig, as mentioned above) (edited to add: as well as literal stealing, there is things like political confiscation, don't forget).<ref>https://www.reddit.com/r/Bitcoin/comments/5py495/brian_armstrong_controlling_your_own_wealth_as_a/dcve9xx/?context=3</ref>

=== Web wallets ===

Web wallets have all the downsides of custodial wallets (no direct possession, private keys are held by a third party) along with all the downsides of hot wallets (exposed private keys), as well as all the downsides of lightweight wallets (not verifying bitcoin's rules, someone could send you a billion bitcoins and under certain conditions the dumb web wallet would happily accept it)

Someone who needs the easy access of a web wallet should download a lightweight wallet like [[Electrum]].

Main article: [[Browser-based wallet]]

=== Paper wallets ===

So-called [[paper wallets]] are an obsolete and unsafe method of storing bitcoin which should not be recommended to beginners. They simply store a single private/public keypair on paper. They promote [[address reuse]] and require unwieldy and complicated live OS system boots to be safe, they risk theft by printers, and typically rely on [[Javascript cryptography]].

Paper wallets also do not provide any method of displaying to the user when money has arrived. There's no practical way to use a [[full node]] wallet. Users are typically driven to use third-party blockchain explorers which can lie to them and spy on them.

A much better way to accomplish what paper wallets do is to use [[seed phrase]]s instead.

Main article: [[Paper wallets]]

=== Cloud storage ===

This means storing your encrypted (or not) wallet file on a cloud storage solution such as Dropbox, or emailing them to yourself on gmail. This very similar to trusting a custodial wallet service, and is not recommended for the same reasons<ref>https://www.reddit.com/r/Bitcoin/comments/8i6via/28_btc_stolen_10_btc_reward_please_help/</ref>. You might say you use encryption for two-factor authentication, but uploading the wallet to the cloud reduces this to one-factor.

=== Removable media ===

This refers to storing wallet files on removable media like SSD or hard drives.

Refer to the warnings from these two links:

* https://www.reddit.com/r/Bitcoin/comments/6nj0eb/reminder_beware_of_data_rot_always_make_paper/

* https://tedjonesweb.blogspot.co.uk/2017/08/do-not-use-flash-memory-ssd-drives.html

Those articles recommend using GPG for encryption or a printer, instead a better solution is [[seed phrase]]s.

== Other ideas ==

=== Time-locked wallets ===

An interesting unconventional solution. The idea is to use [[Timelock|time-lock contracts]] to create a wallet which cannot be spent from until a certain date. One possible use-case might be by a gambling addict who locks up money for paying bills for a month, after a month has passed and their time-lock wallet is opened they use that money for paying bills instead of gambling. This is the equivalent proposal towards compulsive shoppers to freeze their credit card in a block of ice, so when they feel the urge to immediately buy something they see on the TV, they will need to wait for the block to melt until they can retrieve the credit card to be able to place the order. This hopefully gives them the time to cool off, and reconsider an otherwise meaningless purchase.

Time lock wallets don't exist yet except for simple [https://coinb.in/#newTimeLocked javascript pages] which rely on [[Javascript cryptography]] and are therefore not safe.

=== Consulting ===

If you intend to store a very large amount of bitcoins, for example in a business, you should consider paying for security consulting.

== The 5 dollar wrench attack ==

[[File:Security.png|400px|none|alt=xkcd comic on the 5 dollar wrench attack.]]

It's sometimes said that all this security is worthless because the $5 wrench attack can be used.

There are two ways to beat this attack: by hiding or by defending yourself.

Stored bitcoins are not secured by [[seed phrase]]s, [[hardware wallet]]s, [[multisignature]], passwords, hash functions or anything like that; they are secured by ''people''.

Technology is never the root of system security. Technology is a tool to help people secure what they value. Security requires people to act. A server cannot be secured by a firewall if there is no lock on the door to the server room, and a lock cannot secure the server room without a guard to monitor the door, and a guard cannot secure the door without risk of personal harm.<ref>[https://github.com/libbitcoin/libbitcoin/wiki/Risk-Sharing-Principle Libbitcoin wiki Risk Sharing Principle]</ref>.

Bitcoin is no different. The technology discussed on this page is only a tool to tip the scales in the defender's favour. Following from this principle, the way to beat the $5 wrench attack is to bear arms. Either your own, or employ guards, or use a safety deposit box, or rely on the police forces and army; or whatever may be appropriate and proportionate in your situation. If someone physically overpowers you then no technology on Earth can save your bitcoins. You can't be your own bank without bank-level security.

See Also: [https://twitter.com/i/moments/942083114385281024 Guns + Bitcoin Hardware Wallets]

== Further reading ==

* [https://github.com/BlockchainCommons/SmartCustodyWhitePapers/blob/master/%23SmartCustody-_Simple_Self-Custody_Cold_Storage_Scenario.md SmartCustody: Simple Self-Custody Cold Storage Scenario]

* https://bitzuma.com/posts/a-gentle-introduction-to-bitcoin-cold-storage/

* https://medium.com/@lopp/thoughts-on-secure-storage-of-bitcoins-and-other-crypto-assets-210cadabb53d

* https://medium.com/@michaelflaxman/how-should-i-store-my-bitcoin-43874ac208e4

* Two-factor authentication on custodial wallets doesn't work as well as you might think https://medium.com/@CodyBrown/how-to-lose-8k-worth-of-bitcoin-in-15-minutes-with-verizon-and-coinbase-com-ba75fb8d0bac

* This is why you shouldn’t use texts for two-factor authentication https://www.theverge.com/2017/9/18/16328172/sms-two-factor-authentication-hack-password-bitcoin Hacking 2FA based on SMS is easy.

==References==
<references />

[[Category:Security]]

Hardware wallet

2019-10-14T06:10:45Z

Fresheneesz: /* Commercial hardware wallets (ordered chronologically) */ open source hardware for trezor

A '''hardware wallet''' is a special type of [[wallet|bitcoin wallet]] which stores the user's private keys in a secure hardware device.

They have major advantages over standard software wallets:

* private keys are often stored in a protected area of a microcontroller, and cannot be transferred out of the device in plaintext
* immune to computer viruses that steal from software wallets
* can be used securely and interactively, private keys never need to touch potentially-vulnerable software
* much of the time, the software is open source, allowing a user to validate the entire operation of the device

This page is an attempt to summarize all the known developments of hardware wallets that can use Bitcoin as part of their operation.

== Security risks ==

To date there have been no verifiable incidents of Bitcoins stolen from hardware wallets. Hardware wallets are relatively new, but at least for the time being they have maintained a good track record, unlike the numerous incidents of Bitcoin theft from Internet-connected computers.

However, it's important to understand that hardware wallets are a high value target and depend on various assumptions holding true to maintain security. They are not a silver bullet, and there are several realistic ways in which a hardware wallet can fail to protect your Bitcoin. These risks need to be carefully considered when deciding how much trust to place in a hardware wallet, and which hardware wallet to buy.

How a hardware wallet could fail to protect your Bitcoin:

# '''Malware swaps recipient Bitcoin addresses''': a hardware wallet won't protect you from being tricked into sending Bitcoin to the wrong address. For example, malware on a PC could monitor for high value transactions and then swap out the recipient's authentic Bitcoin address for an address controlled by the attacker. When the stakes are high, multi factor (e.g., over the phone) confirmation of a recipient's Bitcoin address is recommended.
# '''Insecure RNG ([https://en.wikipedia.org/wiki/Random_number_generation Random Number Generator])''': hardware wallets rely on the security of an RNG, often embedded in hardware, to generate your wallet's private keys securely. Unfortunately, it is notoriously difficult to verify the true randomness of the RNG. An insecure RNG may create wallet keys that can later be recreated by an attacker, by generating psuedo-randomness that would seem statistically indistinguishable from true randomness yet still be predictable to an advanced attacker. An RNG may become insecure as a result of malicious weakening or an unintentional mistake. This failure mode is common to any wallet generation procedure in which the true randomness of the source of entropy being used can not be verified.
# '''Imperfect implementation''': the security of all computing devices relies on the quality of their implementation. Hardware wallets are no exception. Bugs at the software, firmware or hardware level may allow attackers to break into a hardware wallet and gain unauthorized access to secrets. Even if the design is perfect, proving the security of a hardware or software implementation is a very hard, mostly unsolved problem. To date, no wallet in existence is implemented using provably correct software.
# '''Compromised production process''': even a perfect software and hardware implementation of a hardware wallet would be vulnerable to a corrupt production process that introduces intentional or unintentional holes into the final product. The introduction of hardware backdoors is a [https://www.wired.com/2016/06/demonically-clever-backdoor-hides-inside-computer-chip/ real concern] for high risk financial and military applications.
# '''Compromised shipping process''': a compromised fulfillment process may substitute or modify secure devices for superficially identical but insecure replacements. Government programs that intercept hardware and modify them in route to insert backdoors [https://arstechnica.com/.../photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ are known to exist].

In summary:

* While not a silver bullet hardware wallets can still be extremely useful, assuming you take care to use a good one: an authentic device manufactured by trustworthy, technically competent security experts with a good reputation (e.g., [[TREZOR]]).

* [[Cold storage]] solutions implemented with open source software and general purpose hardware (e.g., [[BitKey]], Pi Wallet), using a verifiable source of entropy such as physical dice may provide superior security for some use cases (e.g., long term savings).

== Connecting to a full node ==

By default, most hardware wallets instruct the user to connect to the manufacturer's own web interface. The web page cannot steal the user's private keys but can spy on them or trick them into accept fake payments.

Hardware wallets only keep the [[private keys]] safe and create spending transactions; they cannot tell you if you have actually received coins and in what quantity. Bitcoin's security model also requires that [[full node]] wallets are used. If not, somebody could pay you with a transaction of something other than bitcoin. If bitcoin is digital gold then a full node wallet is your own personal goldsmith who checks that the incoming payments are actually real. Also the third-party wallet will see all your [[Address|bitcoin addresses]] so this is very damaging to your privacy.

Most hardware wallets can be connected to [[Electrum]] bitcoin wallet. Electrum can be connected to your own [[Electrum#Electrum Personal Server|full node via a server]].

See also: [[Full node#Why should you use a full node wallet]]

== Commercial hardware wallets (ordered chronologically) ==

=== [[Trezor|Trezor One]] ===
[[File:Trezor-tx.jpg|300px|thumb|left|Confirming the transaction with Trezor]]

[[Trezor]] is a secure bitcoin storage and a transaction signing tool with open source hardware and software. The private keys are generated by the device and never leave it thus they cannot be accessed by a malware.

It uses a deterministic wallet structure which means it can hold an unlimited number of keys ([[BIP 0032]]/[[BIP 0044]]). A recovery seed is generated when the device is initialized. In case Trezor gets lost or stolen, all its contents can be recovered using this seed (private keys, bitcoin balance and transaction history) into a new device or another [[BIP 0039]]/[[BIP 0044]] compatible wallet.

Trezor also introduced a unique way of PIN entering preventing keyloggers from recording it even when entered on a compromised computer. An encryption passphrase can be set on top of the PIN protection. More passphrases can be used for plausible deniability.

Trezor One offers everything needed to protect cryptocurrency funds together with advanced features like [https://wiki.trezor.io/User_manual:Password_Manager Password manager] or [https://wiki.trezor.io/User_manual:Two-factor_Authentication_with_U2F U2F two-factor authorization].

''See also [[Hardware wallet#Trezor Model T|Trezor Model T - next-generation cryptocurrency hardware wallet]]''

[https://shop.trezor.io Trezor E-shop] | [https://wiki.trezor.io Trezor Wiki] | [https://trezor.io Trezor Homepage]

 

=== KeepKey: Your Private Bitcoin Vault ===
[[File:keepkey.jpg|300px|thumb|left|KeepKey showing a bitcoin transaction that needs to be manually approved.]]

KeepKey is a USB device that stores and secures your bitcoins. When you entrust KeepKey with your money, each and every bitcoin transaction you make must be reviewed and approved via it's OLED display and confirmation button.

KeepKey has a unique recovery feature utilizing a rotating cipher to restore private keys with a [[BIP 0039]] recovery seed. This means it is not necessary to store your private keys on KeepKey: the recovery process is secure enough so that KeepKey can be used as a transaction device for paper backups.

[https://www.keepkey.com keepkey.com]

 

=== Opendime: Bitcoin Credit Stick ===

[[file:Opendime.jpeg|400px|thumb|left|Opendime Package]]

The 1st Bitcoin Bearer Bond or just call it a "Bitcoin Stick"

Opendime is a small USB stick that allows you to spend Bitcoin like a dollar bill. Pass it along multiple times.
Connect to any USB to check balance. Unseal anytime to spend online. Trust no one.

It comes in the shape of a mini USB, and [[Opendime-ui.png|setting it up is astonishingly quick and simple]]. You plug OpenDime into a USB port, and it behaves just like a USB drive with a tiny amount of storage. In its folder, is a web page. You open the webpage in your browser, and there’s only one instruction to follow: “Drop a file onto the drive”. Once you do that, the OpenDime automagically generates a unique address for you to receive Bitcoin with.

[http://www.opendime.com Opendime.com]

* [https://opendime.com/#faq Opendime FAQ]
* You can watch a [https://www.youtube.com/watch?v=9UFF9d3Y1BY video here]
* Read this [https://medium.com/@beautyon_/exquisite-opendime-ad1195a2790e review]
* Multi-language user interface: 中文 • 日本語 • English • Portuguese • Français • Deutsch • Русский
* Works as USB drive with no need for software
* [https://github.com/opendime/electrum Opendime Electrum plugin]
* [https://github.com/opendime/ Opendime source files and key verification]

 

=== Coldcard: Ultra-secure Bitcoin Hardware Wallet ===

[[file:Coldcard.png|524px|thumb|left|Coldcard Front and Back]]

* Coldcard is an easy to use, ultra-secure, open-source and affordable hardware wallet that is easy to back up via an encrypted microSD card. Your private key is stored in a dedicated security chip. MicroPython software design allows you to make changes.
* BIP39 based, which means you can backup the secret words onto paper, and have lots of sub-accounts and unlimited independent payment addresses. Now with BIP39 passphrase support, unlocking up to 5.9e197 additional wallets from the same seed words! It knows how to understand transactions, so you can see what you are approving.
* The first "Partially Signed Bitcoin Transaction Format" - PSBT (BIP 174) native wallet which can be used completely offline for its entire lifecycle. See HWI for Bitcoin Core support!
* True air-gap cold operation via MicroSD sneakernet or standard via USB

[http://www.coldcardwallet.com Coldcardwallet.com]

* [https://coldcardwallet.com/faq Coldcard FAQ]
* [https://coldcardwallet.com/docs Coldcard Docs]
* [https://github.com/coldcard/firmware Coldcard Source Code]

 

=== CoolWallet: The Ultimate Bitcoin Safe ===


[[File:CoolWallet in the box.jpeg|300px|thumb|left|CoolWallet showing Launch App, waiting for user to connect with smartphone via Bluetooth]]

CoolWallet is a credit card sized Bluetooth device that stores and secures your bitcoins and private keys. It fits in your wallet and works wirelessly.

Every Bitcoin transaction must be manually confirmed and approved through its e-paper display and button.

CoolWallet only acknowledges the paired smartphone. Whoever stole the CoolWallet are not able to steal any bitcoins. Using recovery Seed can restore all your bitcoins in case you lost the device.

[https://coolbitx.com coolbitx.com] | [https://github.com/CoolBitX-Technology/coolwallet-ios Source and specifications]

 

=== BlochsTech card: Your user friendly Bitcoin wallet ===


[[file:BlochsTech Bitcoin card hardware wallet.jpg|300px|thumb|left|Graphic printed on front of BlochsTech cards.]]

The BlochsTech open Bitcoin card is an open protocol secure hardware Bitcoin wallet your grandmother could use.
For shops it's faster to accept than slow QR code based wallets and more reliable as it works offline.

Currently it's of course in a novelty phase like Casascius coins (of which thousands were sold),
however in the long run it is fully capable of functionally replacing the VISA system in all nations.

[http://www.BlochsTech.com BlochsTech.com]

 

=== BitLox Bitcoin Hardware Wallet ===
[[file:Bitlox.jpg|300px|thumb|left|BitLox Bitcoin Hardware Wallet]]

BitLox is a metal cased (aluminum or titanium) bitcoin hardware wallet that works with their own web based wallet by USB and apps for iPhone and Android using Bluetooth LE.

At present it is the only bitcoin hardware wallet you can buy that works with iPhone. The device weighs one ounce and is the size of a credit card 4 mm thick.

Bitlox allows you to set up hidden wallets. Unlike other hardware wallets your seed is never displayed on a connected computer or phone but only on the Bitlox. All your wallet, device and transaction PINs are only entered on the BitLox and never on any app.

BitLox has also implemented several advanced security features not available on any other bitcoin hardware wallet.

[http://www.bitlox.com bitlox.com]

 

=== Digital Bitbox ===
[[file:Digital-bitbox.png|thumb|left|Digital Bitbox Hardware Wallet]]

* Secure hardware RNG & key storage using [http://www.atmel.com/Images/Atmel-8914-CryptoAuth-ATAES132A-Datasheet.pdf crypto element] with 50 year lifespan and an epoxy-filled case.
* Offline backup and recovery of [[BIP_0032|BIP-32]] seed with a micro SD card rather than [[BIP_0039|BIP-39]] phrase written on paper as in Trezor.
* Native software wallet client and ability to use a mobile phone for 2FA and to verify transaction details.
* Multisig out-of-the-box including Copay support.
* [https://github.com/digitalbitbox Open Source] ([https://github.com/digitalbitbox/mcu#digital-bitbox-firmware firmware], [https://github.com/digitalbitbox/mcu/blob/bf48984fd4a47d9ebf6814f7d01b078964587c7c/src/bootloader.c bootloader], [https://github.com/digitalbitbox/dbb-app desktop client]).
* Full FIDO U2F support (https://en.wikipedia.org/wiki/Universal_2nd_Factor)
* Made in Switzerland (a country with strong privacy laws) by [[Bitcoin Core]] developer Jonas Schnelli.

[https://digitalbitbox.com digitalbitbox.com]

 

=== Ledger Nano S - USB Smartcard Hardware Wallet ===
[[File:ledger_wallet_nanos_photo.png|300px|thumb|left|Ledger Wallet Nano S]]

Ledger Nano S is a secure Bitcoin hardware wallet. It connects to any computer through USB and embeds a built-in OLED display to double-check and confirm each transaction with a single tap on its buttons. It is architectured around a Secure Element (ST31 family) and built on top of the BOLOS platform, a powerful and flexible Operating System allowing the secure execution of multiple Open Source applications in full isolation.

Main features:
* cryptographic secrets protected by a secure chip
* open source embedded Bitcoin app
* Confirmation of transactions on the embedded screen
* Built-in 4 digits PIN security lock
* Built-in onboarding (seed generation and recovery)
* BIP39 seed (12/18/24 words), easy backup and restoration
* Multi-apps support: FIDO U2F, GPG, SSH…
* USB connectivity
* Foldable and compact casing

[https://www.ledgerwallet.com/products/12-ledger-nano-s Ledger Nano S product page]

 

=== Secalot ===
[[File:secalot_wallet.png|300px|thumb|left|Secalot]]

Main features:
* Software and hardware are fully open sourced.
* Utilizes a secure microcontroller with a high performance dedicated cryptographic co-processor.
* Integrates with the popular Electrum wallet.
* PIN-code protected.
* Confirm transactions with a touch button press on the device.
* Supports P2PKH, P2SH, and segWit transactions.
* Updatable firmware.
* Extra functionality: OpenPGP smart card, FIDO U2F authenticator, one-time password generator.

Website: [https://www.secalot.com www.secalot.com]

 

=== ELLIPAL ===
[[File:Ellipal wallet.png|300px|thumb|left|ELLIPAL]]

ELLIPAL hardware wallet secures keys in cold storage without connections except LCD screen. It works with companion mobile App via QR code.

Main features:
* Working with mobile phone via QR code
* Internet Isolated Cold Wallet
* Multi-currency, cross-chain
* Supports P2PKH, P2SH, and segWit transactions
* 4" Screen with touch panel
* Support private key import
* PIN-code and gesture pattern protect
* Confirmation of transactions details on screen
* BIP32/BIP39/BIP44
* iPhone and Android companion App: account management, market info and coin exchange.

Website: [https://www.ellipal.com www.ellipal.com]

 

=== [[Trezor|Trezor Model T]] ===
[[File:Trezor-model-t-photo-front.jpg|300px|thumb|left|Trezor Model T]]

Trezor Model T is the premium version and next-generation cryptocurrency hardware wallet. In addition to the functionalities of Trezor One, it has a colored touchscreen for secure on-device input, modern design, an SD card slot, and some other more advanced features.
For more information see [https://wiki.trezor.io/Trezor_Model_T Trezor Model T] and this [https://trezor.io/#comparison comparison table]

[https://shop.trezor.io Trezor E-shop] | [https://wiki.trezor.io Trezor Wiki] | [https://trezor.io Trezor Homepage]

 

== Not purchasable hardware wallets ==

=== Ledger HW.1 - USB Smartcard Hardware Wallet ===
[[File:Btchip_dongle.jpg|220px|thumb|left|HW.1 inserted in a laptop]]

HW.1 is an implementation of a deterministic ([[BIP 0032]]) Hardware Wallet on a USB smartcard.

It is typically used as a blind secure device for multi signature transactions - holding a set of derived private keys and signing transactions without requiring user confirmation.

Power users can rely on it to confirm all transactions with a second factor scheme turning the dongle into a keyboard typing what the user is supposed to have signed, as a protection against malware.

It is also possible to customize HW.1 for more specific needs, such as creating a prepaid card without revealing the deterministic seed before it is received by the user, or securing bitcoin transactions on a server.

[https://www.ledgerwallet.com/products/3-ledger-hw-1 E-shop] | [https://ledgerhq.github.io/btchip-doc/bitcoin-technical.html Technical Documentation]

 

=== Ledger Nano - USB Smartcard Hardware Wallet ===
[[File:ledger_wallet_photo.jpg|300px|thumb|left|Ledger Wallet USB]]

Ledger Nano protects your Bitcoin data within a smartcard. Its micro-processor certified against all types of attacks (both physical and logical), and has been used in the banking industry for decades (think credit card chips). The device connects to your computer through the USB port and will do all the Bitcoin cryptographic heavy lifting such as signing transactions inside its secure environment. You can therefore use your Bitcoin account with maximum trust, even on an insecure or compromised computer.

The second factor verification of the transaction signature can be done either with a paired smartphone (Android, iOS) or a physical security card.

The Ledger Wallet Chrome application (available also on Chromium) provides an easy onboarding as well as a seamless user experience, and the Nano is compatible with numerous third party software: [[Electrum]], [[Mycelium]], [[GreenAddress]], Greenbits, [[Coinkite]] and Copay.

[https://www.ledgerwallet.com/products/1-ledger-nano Ledger Nano product page] | [https://github.com/LedgerHQ Source and specifications]

 

=== Ledger Unplugged - NFC Smartcard Hardware Wallet ===
[[File:ledger_unplugged_photo.jpg|300px|thumb|left|Ledger Unplugged NFC]]

The Ledger Unplugged is a credit card sized NFC hardware wallet. It embeds an open source Java Card app and is compatible with all NFC enabled Android phones.

The device can be used with Mycelium or Greenbits. In case of loss, you can restore it on any Ledger Wallet (Nano or another one) or all other compatible solutions (BIP 39).

[https://www.ledgerwallet.com/products/6-ledger-unplugged Ledger Unplugged product page] | [https://github.com/LedgerHQ/ledger-javacard Source code]

 

=== BWALLET TREZOR clone ===

[[File:BWALLET_Trezor_Clone.jpeg|200px|thumb|left|Chinese clone of Trezor]]

BWALLET is a clone of Trezor by a Chinese company.
Trezor code is open source and this device operates like a Trezor.
However, this product has been [https://www.reddit.com/r/Bitcoin/comments/2tyier/bwallet_review_by_trezor_developer/ reviewed by Marek aka Slush(Trezor developer)] and he has found some problems which makes this device less than 100% compatible, for example it doesn't work with [http://mytrezor.com myTREZOR.com] website and it does not work with Trezor official firmware.

[http://mybwallet.com MyBWALLET.com] | [http://www.bidingxing.com/en/bwallet Buy BWALLET]

 

=== Pi Wallet - cold storage ===
[[File:Piwallet.jpeg|300px|thumb|left|Pi-Wallet]]

The Pi-Wallet is a small computer with the [[Armory]] bitcoin client.

Transactions are signed offline, then transferred on a USB stick via [https://en.wikipedia.org/wiki/Sneakernet Sneakernet] to an online system for broadcasting.

[https://www.pi-wallet.com/ pi-wallet.com]

 

=== BitcoinCard Megion Technologies-Card based wallet ===
[[File:Bitcoincard-medley-large.jpg|400px|thumb|left|Bitcoin Card]]
[http://www.bitcoincard.org/ Bitcoincard Home Page]

[http://blog.bitinstant.com/blog/2012/6/19/our-discovery-in-vienna-the-bitcoin-card.html Excellent review by evoorhees]

Incorporates a e-paper display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred.

 

=== BitSafe - allten/someone42's hardware wallet ===
[[File:Bitsafe-wallet-sizecompare.jpg|200px|thumb|left|Bitsafe wallet]]
[https://bitcointalk.org/index.php?topic=152517.0 Final BitSafe announcement]

Signing transactions only, requires USB host software for transactions & USB power. Has a OLED display and Confirm/Cancel buttons. Evolved out of someone42's prototype below, and has significant contributions from someone42 as well.
 

=== Swiss Bank in Your Pocket - Hardware wallet ===
[[File:SBIYP.png|300px|thumb|left|Swiss Bank In Your Pocket]]

The Swiss Bank in Your Pocket is a Windows Desktop Application providing functionality for 5 Bitcoin Wallets and a Bitcoin Vault.

The Bitcoin Vault can only send Bitcoins to the Bitcoin Wallets with in the application. Each Bitcoin wallet can have up to 5 Receive addresses. The intuitive user interface is designed for ease of use. USB security key is required to make any type of transaction. frontend software is installed on windows. Package includes secure USB key, and an additional recovery USB key. So in case of an accident, customer will have an additional backup to access their wallets.

[https://swissbankinyourpocket.com/ swissbankinyourpocket.com]

 

=== someone42's original prototype ===
[[File:Someone42-wallet-prototype.jpg|300px|thumb|left|someone42's original prototype]]
[https://bitcointalk.org/index.php?topic=78614.0 Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices]

Signing transactions only, requires USB host software for transactions & USB power. All work is rolled into the above BitSafe wallet currently.
 
=== Other/Defunct but with good discussion: ===
* natman3400's BitClip Jun 2011 [https://bitcointalk.org/index.php?topic=24852.0 https://bitcointalk.org/index.php?topic=24852.0]
:Seems to have gone defunct around Dec 2011. Some good ideas though and seemed to have started on execution.
* jim618 hardware wallet proposal Apr 2012 [https://bitcointalk.org/index.php?topic=77553.0 Dedicated bitcoin devices - dealing with untrusted networks]
:Great discussion and good ideas from jim618. Also linked the following video:
* Prof. Clemens Cap's hardware wallet? (video:)[https://www.youtube.com/watch?v=IavQ-Wc8S1U Clemens Cap about electronic bitcoin wallet at EuroBit]
:Clemens Cap of Uni Rostock explains the Electronic Bitcoin wallet device he's working on. It's based on adafruit microtouch device.
* ripper234's discussion based on Yubikeys Aug 2012 [https://bitcointalk.org/index.php?topic=99492 Having a YUBIKEY as one of the parties for m-of-n signatures]
:The use of Yubikeys. They only support symmetric crypto, so you'd have to trust the host device.
* kalleguld's hardware wallet proposal Oct 2012 [https://bitcointalk.org/index.php?topic=115294.0 Proposal: Hardware wallet (Win 3 BTC)]
* Vaporware: Matthew N Wright's ellet [https://bitcointalk.org/index.php?topic=85931.0 ANN The world's first handheld Bitcoin device, the Ellet!] (Vaporware)

== Smart Card based wallets ==
This type of device requires complete trust in the host device, as there is no method for user input.
See [[Smart card wallet]]

== Related Resources ==
* [https://bitcoinnewsmagazine.com/best-bitcoin-hardware-wallet-2015/ Best Bitcoin Hardware Wallet 2015] - reviews of all bitcoin hardware wallets.
* [http://99bitcoins.com/trezor-vs-ledger-hands-hardware-wallets-review/ TREZOR vs. Ledger] - User reviews and Reddit feedback
* [https://bitcointalk.org/index.php?topic=125383.0 Hardware wallet wire protocol]: slush's Hardware wallet wire protocol discussion
* [https://bitcointalk.org/index.php?topic=19080.msg272348#msg272348 Re: Split private keys]: kjj's Todo List discussion for client protocol requirements
* [https://bitcointalk.org/index.php?topic=134277.0 Hardware Wallet Roundup]
* [https://www.buybitcoinworldwide.com/wallets/ Bitcoin Hardware Wallet Comparison] - information about using Bitcoin hardware wallets for cold storage.
* [https://www.weusecoins.com/bitcoin-ledger-wallet-review/ Ledger Wallet Review]

== See Also ==

* [[Storing bitcoins]]
* [[How to set up a secure offline savings wallet]]
* [[Cold storage]]

[[Category:Security]]
[[Category:Wallets| ]]
[[Category:Hardware]]

Multi-signature

2019-08-06T03:40:18Z

Fresheneesz: /* Multisignature Applications */ Adding distributed backup application

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]].

* 1 OR 3-of-4: Distributed Backup - The primary owner can use the wallet at will, but if that owner loses their private keys, they can recover with the help of 3 of the other 4 trusted friends/organizations. One key could be kept in a security deposit box at a bank, the other 3 could be distribute to friends. In the case of death of the owner, the security deposit box can be willed to one of the trusted friends or someone who can get the help of the trusted friends. More [https://bitcoin.stackexchange.com/questions/89589/is-it-possible-to-do-a-3-of-5-or-1-multi-sig-for-backup-purposes/89590?noredirect=1#comment102505_89590 complex] multisig wallets can be created if desired.

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]

BTC.com

2018-03-01T08:03:26Z

Fresheneesz: rm founders - bitmain is not the founder

{{infobox company|image=[[File:Logo-white-sq.png|250px|thumb|left]]|name=BTC.com
|foundation= 2015
|industry=[[Wallet]] [[Api]] [[Block Explorer]]
|website=https://www.btc.com
}}[https://www.btc.com BTC.com] is a [https://wallet.btc.com web wallet] originally created by Blocktrail and now owned by Bitmain Technologies. It also publishes an [https://play.google.com/store/apps/details?id=com.blocktrail.mywallet&hl=en Android wallet], an [https://itunes.apple.com/us/app/blocktrail-bitcoin-wallet/id1019614423/ iOS Wallet], a Bitcoin API, a [http://www.btc.com block explorer], and a [[mining pool]]. 

On July 19, 2016 [[Blocktrail]] was acquired by [[Bitmain]] and subsequently re-branded to BTC.com.<ref>http://www.coindesk.com/bitcoin-miner-bitmain-acquires-blockchain-data-startup/</ref>

==Wallet==

The wallets they offer allow you to buy bitcoin and bitcoin cash alongside basic wallet features and features like 2-factor-auth.

The wallets are open source software hosted at http://github.com/blocktrail/blocktrail-wallet.

== Mining Pool ==
On September 13, 2016, BTC.com launched a mining pool<ref>http://www.coindesk.com/bitmain-bitcoin-mining-launch-second-mining-pool/</ref> using a settlement mode called PPS (pay-per-share).<ref>https://blog.btc.com/btc-com-launches-new-open-source-mining-pool-with-zero-mining-fee-2f6e0a53ce2c#.33zivpv2w</ref>

==See Also==

* [[Block chain browser]]
* [[Api]]
* [[Wallet]]
* [[Mining Pool]]

==External Links==

==References==
<references />

[[Category:Services]]
[[Category:Wallets]]
[[Category:Mobile]]
[[Category:Block chain browsers]]
[[Category:Frontends]]
[[Category:Bitcoin]]
[[Category:Clients]]
[[Category:Pool Operators]]

BTC.com

2018-02-27T01:02:13Z

Fresheneesz: removing lots of marketing content - this page is not free advertising space

{{infobox company|image=[[File:Logo-white-sq.png|250px|thumb|left]]|name=BTC.com
|founder= [[Bitmain]]
|foundation= 2015
|industry=[[Wallet]] [[Api]] [[Block Explorer]]
|website=https://www.btc.com
}}[https://www.btc.com BTC.com] is a [https://wallet.btc.com web wallet] originally created by Blocktrail and now owned by Bitmain Technologies. It also publishes an [https://play.google.com/store/apps/details?id=com.blocktrail.mywallet&hl=en Android wallet], an [https://itunes.apple.com/us/app/blocktrail-bitcoin-wallet/id1019614423/ iOS Wallet], a Bitcoin API, a [http://www.btc.com block explorer], and a [[mining pool]]. 

On July 19, 2016 [[Blocktrail]] was acquired by [[Bitmain]] and subsequently re-branded to BTC.com.<ref>http://www.coindesk.com/bitcoin-miner-bitmain-acquires-blockchain-data-startup/</ref>

==Wallet==

The wallets they offer allow you to buy bitcoin and bitcoin cash alongside basic wallet features and features like 2-factor-auth.

The wallets are open source software hosted at http://github.com/blocktrail/blocktrail-wallet.

== Mining Pool ==
On September 13, 2016, BTC.com launched a mining pool<ref>http://www.coindesk.com/bitmain-bitcoin-mining-launch-second-mining-pool/</ref> using a settlement mode called PPS (pay-per-share).<ref>https://blog.btc.com/btc-com-launches-new-open-source-mining-pool-with-zero-mining-fee-2f6e0a53ce2c#.33zivpv2w</ref>

==See Also==

* [[Block chain browser]]
* [[Api]]
* [[Wallet]]
* [[Mining Pool]]

==External Links==

==References==
<references />

[[Category:Services]]
[[Category:Wallets]]
[[Category:Mobile]]
[[Category:Block chain browsers]]
[[Category:Frontends]]
[[Category:Bitcoin]]
[[Category:Clients]]
[[Category:Pool Operators]]