Bitcoin Wiki - User contributions [en]

List of address prefixes

2013-01-08T03:23:49Z

PC: Consistently use "pubkey", and "for (un)compressed pubkey" for testnet just like on mainnet

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Initial byte(s)
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|<tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Bitcoin Private key (for uncompressed pubkey)
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|128
|K or L
|Bitcoin Private key (for compressed pubkey)
|<tt>L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Testnet script hash
|
|-
|239
|9
|Testnet Private key (for uncompressed pubkey)
|<tt>91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6</tt>
|-
|239
|c
|Testnet Private key (for compressed pubkey)
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|
|-
|0x142, 0x143
|6P
|Encrypted private key ([[BIP 0038|BIP 38]])
|<tt> 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg </tt>
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

[[es:Lista de prefijos de direcciones]]

List of address prefixes

2012-12-10T21:27:31Z

PC: Clarifying that it's not the private key that's compressed, but the corresponding public key

Blockchain-based currencies use addresses, which are a [[Base58Check encoding]] of some hash, typically that of a public key. The encoding includes a version byte, which affects the first character in the address. The following is a list of some prefixes which are in use.

{| class="wikitable"
|-
!Initial byte(s)
!Leading symbol
!Use
!Example
|-
|0
|1
|Bitcoin pubkey hash
|<tt>12CPLrAUPvhVwjZqBgww3sLdEg4Z888R1j</tt>
|-
|5
|3
|Bitcoin script hash
|<tt>3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX</tt>
|-
|48
|L
|Litecoin pubkey hash
|<tt>LhK2kQwiaAvhjWY799cZvMyYwnQAcxkarr</tt>
|-
|52
|M or N
|Namecoin pubkey hash
|<tt>NATX6zEUNfxfvgVwz8qVnnw3hLhhYXhgQn</tt>
|-
|95
|f
|Fairbrix pubkey hash
|<tt>fF6o8LeDAfswEpMbCW8BqaqmzMWS7TGgew</tt>
|-
|97
|g
|GeistGeld pubkey hash
|<tt>gQ8YScyiMUTart6kUJpzhjPzAKfiYAwooc</tt>
|-
|105
|j
|i0coin pubkey hash
|<tt>jWmCr5cKeQjV4iyfUyipfLGwVML8MvXhF2</tt>
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|<tt>mkJ7Bf5chdfw61d1m7gnDVAQV3EQQAb8iz</tt>
|-
|125
|s
|Solidcoin pubkey hash
|<tt>sXNaMoYBocjcQJRLK53dkaQ5mWuKfvHB9f</tt>
|-
|127
|t
|Tenebrix pubkey hash
|<tt>tUK2EQTMF6cN6vuNEfJtVf1BMqarvEZJBL</tt>
|-
|128
|5
|Bitcoin Private key (for uncompressed public key)
|<tt>5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq</tt>
|-
|128
|K or L
|Bitcoin Private key (for compressed public key)
|<tt>L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ</tt>
|-
|138
|x
|ixcoin pubkey hash
|<tt>xoKDFH4uWpyzxUcCC5jCLFujRKayv3HHcV</tt>
|-
|196
|2
|Testnet script hash
|
|-
|239
|9
|Uncompressed Testnet Private key
|<tt>91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6</tt>
|-
|239
|c
|Compressed Testnet Private key
|<tt>cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm</tt>
|
|-
|0x142, 0x143
|6P
|Encrypted private key ([[BIP 0038|BIP 38]])
|<tt> 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg </tt>
|}

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

{| class="wikitable"
|-
!Decimal version
!Leading symbol
!Address length
|-
|0
|1
|up to 34
|-
|1
|Q-Z, a-k, m-o
|33
|-
|2
|o-z, 2
|33 or 34
|-
|3
|2
|34
|-
|4
|2 or 3
|34
|-
|5-6
|3
|34
|-
|7
|3 or 4
|34
|-
|8
|4
|34
|-
|9
|4 or 5
|34
|-
|10-11
|5
|34
|-
|12
|5 or 6
|34
|-
|13
|6
|34
|-
|14
|6 or 7
|34
|-
|15-16
|7
|34
|-
|17
|7 or 8
|34
|-
|18
|8
|34
|-
|19
|8 or 9
|34
|-
|20-21
|9
|34
|-
|22
|9 or A
|34
|-
|23
|A
|34
|-
|24
|A or B
|34
|-
|25-26
|B
|34
|-
|27
|B or C
|34
|-
|28
|C
|34
|-
|29
|C or D
|34
|-
|30-31
|D
|34
|-
|32
|D or E
|34
|-
|33
|E
|34
|-
|34
|E or F
|34
|-
|35-36
|F
|34
|-
|37
|F or G
|34
|-
|38
|G
|34
|-
|39
|G or H
|34
|-
|40-41
|H
|34
|-
|42
|H or J
|34
|-
|43
|J
|34
|-
|44
|J or K
|34
|-
|45-46
|K
|34
|-
|47
|K or L
|34
|-
|48
|L
|34
|-
|49
|L or M
|34
|-
|50-51
|M
|34
|-
|52
|M or N
|34
|-
|53
|N
|34
|-
|54
|N or P
|34
|-
|55-56
|P
|34
|-
|57
|P or Q
|34
|-
|58
|Q
|34
|-
|59
|Q or R
|34
|-
|60-61
|R
|34
|-
|62
|R or S
|34
|-
|63
|S
|34
|-
|64
|S or T
|34
|-
|65-66
|T
|34
|-
|67
|T or U
|34
|-
|68
|U
|34
|-
|69
|U or V
|34
|-
|70-71
|V
|34
|-
|72
|V or W
|34
|-
|73
|W
|34
|-
|74
|W or X
|34
|-
|75-76
|X
|34
|-
|77
|X or Y
|34
|-
|78
|Y
|34
|-
|79
|Y or Z
|34
|-
|80-81
|Z
|34
|-
|82
|Z or a
|34
|-
|83
|a
|34
|-
|84
|a or b
|34
|-
|85
|b
|34
|-
|86
|b or c
|34
|-
|87-88
|c
|34
|-
|89
|c or d
|34
|-
|90
|d
|34
|-
|91
|d or e
|34
|-
|92-93
|e
|34
|-
|94
|e or f
|34
|-
|95
|f
|34
|-
|96
|f or g
|34
|-
|97-98
|g
|34
|-
|99
|g or h
|34
|-
|100
|h
|34
|-
|101
|h or i
|34
|-
|102-103
|i
|34
|-
|104
|i or j
|34
|-
|105
|j
|34
|-
|106
|j or k
|34
|-
|107-108
|k
|34
|-
|109
|k or m
|34
|-
|110
|m
|34
|-
|111
|m or n
|34
|-
|112-113
|n
|34
|-
|114
|n or o
|34
|-
|115
|o
|34
|-
|116
|o or p
|34
|-
|117-118
|p
|34
|-
|119
|p or q
|34
|-
|120
|q
|34
|-
|121
|q or r
|34
|-
|122-123
|r
|34
|-
|124
|r or s
|34
|-
|125
|s
|34
|-
|126
|s or t
|34
|-
|127-128
|t
|34
|-
|129
|t or u
|34
|-
|130
|u
|34
|-
|131
|u or v
|34
|-
|132-133
|v
|34
|-
|134
|v or w
|34
|-
|135
|w
|34
|-
|136
|w or x
|34
|-
|137-138
|x
|34
|-
|139
|x or y
|34
|-
|140
|y
|34
|-
|141
|y or z
|34
|-
|142-143
|z
|34
|-
|144
|z or 2
|34 or 35
|-
|145-255
|2
|35
|}

Network

2012-06-08T20:17:16Z

PC: IPv6 is gaining support in Bitcoin

Bitcoin uses a simple broadcast network to propagate transactions and blocks. All communications are done over TCP. Bitcoin is fully able to use ports other than 8333 via the -port parameter. IPv6 is [https://bitcointalk.org/index.php?topic=81378.0 in the process of being supported].

== Messages ==
* ''version'' - Information about program version and block count. Exchanged when first connecting.
* ''verack'' - Sent in response to a version message to acknowledge that we are willing to connect.
* ''addr'' - List of one or more IP addresses and ports.
* ''inv'' - "I have these blocks/transactions: ..." Normally sent only when a ''new'' block or transaction is being relayed. This is only a list, not the actual data.
* ''getdata'' - Request a single block or transaction by hash.
* ''getblocks'' - Request an ''inv'' of all blocks in a range.
* ''getheaders'' - Request a ''headers'' message containing all block headers in a range.
* ''tx'' - Send a transaction. This is sent only in response to a ''getdata'' request.
* ''block'' - Send a block. This is sent only in response to a ''getdata'' request.
* ''headers'' - Send up to 2,000 block headers. Non-generators can download the headers of blocks instead of entire blocks.
* ''getaddr'' - Request an ''addr'' message containing a bunch of known-active peers (for bootstrapping).
* ''submitorder'', ''checkorder'', and ''reply'' - Used when performing an [[IP address|IP transaction]].
* ''alert'' - Send a network alert.
* ''ping'' - Does nothing. Used to check that the connection is still online. A TCP error will occur if the connection has died.

More information and in-depth technical information is in the [[Protocol Specification]].

== Connection ==

To connect to a peer, you send a ''version'' message containing your version number, block count, and current time. The remote peer will send back a ''verack'' message and his own ''version'' message if he is accepting connections from your version. You will respond with your own ''verack'' if you are accepting connections from his version.

The time data from all of your peers is collected, and the median is used by Bitcoin for all network tasks that use the time (except for other version messages).

You then exchange ''getaddr'' and ''addr'' messages, storing all addresses that you don't know about. ''addr'' messages often contain only one address, but sometimes contain up to 1000. This is most common at the beginning of an exchange.

== Standard relaying ==

When someone sends a transaction, they send an ''inv'' message containing it to all of their peers. Their peers will request the full transaction with ''getdata''. If they consider the transaction valid after receiving it, they will also broadcast the transaction to all of their peers with an ''inv'', and so on. Peers ask for or relay transactions only if they don't already have them. A peer will never rebroadcast a transaction that it already knows about, though transactions will eventually be forgotten if they don't get into a block after a while. The sender and receiver of the transaction will rebroadcast, however.

Anyone who is generating will collect valid received transactions and work on including them in a block. When someone does find a block, they send an ''inv'' containing it to all of their peers, as above. It works the same as transactions.

Everyone broadcasts an ''addr'' containing their own IP address every 24 hours. Nodes relay these messages to a couple of their peers and store the address if it's new to them. Through this system, everyone has a reasonably clear picture of which IPs are connected to the network at the moment. After connecting to the network, you get added to everyone's address database almost instantly because of your initial ''addr''.

Network alerts are broadcast with ''alert'' messages. No ''inv''-like system is used; these contain the entire alert. If a received alert is valid (signed by one of the people with the private key), it is relayed to all peers. For as long as an alert is still in effect, it is rebroadcast at the start of every new connection.

== Initial block download ==

At the start of a connection, you send a ''getblocks'' message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an ''inv'' that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with ''getdata'', and the peer will send them to you with ''block'' messages. After you have downloaded and processed all of these blocks, you will send another ''getblocks'', etc., until you have all of the blocks.

0.3.18 introduced new ''headers'' and ''getheaders'' messages. These are not currently used, but they will be used by non-generators to download block headers without the corresponding block bodies. Only the headers are necessary for verifying received transactions -- full blocks are needed only by generators. Instead of the ''getblocks/inv/getdata/block'' sequence, non-generators will send a ''getheaders'' message (very like ''getblocks''), and the peer will immediately respond with a ''headers'' message containing up to 2,000 of the next headers. This will make initial block download ''much'' faster.

== Bootstrapping ==

You choose which peers to connect to by sorting your address database by the time since you last saw the address and then adding a bit of randomization.

Bitcoin has three methods of finding peers.

=== Addr ===

The ''addr'' messages described above create an effect similar to the IRC bootstrapping method. You know reasonably quickly whenever a peer joins, though you won't know for a while when they leave.

Bitcoin comes with a list of addresses known as "seed nodes". If you are unable to connect to IRC and you've never connected to the network before, the client will update the address database by connecting to one of the nodes from this list.

The -addnode command line option can be used to manually add a node. The -connect option can force bitcoin to connect only to a specific node.

=== DNS ===

Bitcoin looks up the IP Addresses of several host names and adds those to the list of potential addresses. This is the dfault seeding mechanism, as of v0.6.x and later.

=== IRC ===

As-of version 0.6.x of the Bitcoin client, IRC bootstrapping is no longer enabled by default. The information below is accurate for most versions prior.

Bitcoin joins a random channel between #bitcoin00 and #bitcoin99 on irc.lfnet.org. Your nick is set to an encoded form of your IP address. By decoding all the nicks of all users on the channel, you get a list of all IP addresses currently connected to Bitcoin.

For hosts that cannot make outbound connections on port 6667, the lfnet servers are also [[FAQ#Do_I_need_to_configure_my_firewall_to_run_bitcoin?|listening on port 7777]].

== Heartbeat ==

If thirty minutes or more has passed since the client has transmitted any messages it will transmit a message to keep the connection to the peer node alive.

If ninety minutes has passed since a peer node has communicated any messages, then the client will assume that connection has closed.

== See Also ==

* [[Protocol Specification]]
* [[Satoshi Client Node Discovery]]
* [http://bitcoinstatus.rowit.co.uk/ Current Network Status]

[[Category:Technical]]

[[pl:Sieć]]

Private key

2012-04-02T13:22:13Z

PC: Added base58 wallet import info for compressed public keys; though it's based only on my experimentation.

A '''private key''' in the context of Bitcoin is a secret number that allows bitcoins to be spent. Every Bitcoin address has a matching private key, which is saved in the wallet file of the person who owns the balance. The private key is mathematically related to the Bitcoin address, and is designed so that the Bitcoin address can be calculated from the private key, but importantly, the same cannot be done in reverse.

Because the private key is the "ticket" that allows someone to spend bitcoins, it is important that these are kept secure. Private keys can be kept on computer files, but they are also short enough that they can be printed on paper. An example of a utility that allows extraction of private keys from your wallet file for printing purposes is [[pywallet]].

As of March 2012, the easiest way to redeem a private key is on [[MtGox]]'s Add Funds screen. Funds are deposited to the MtGox account after a six-confirmation wait (typically one hour). In addition to MtGox, the following services allow redemption of private keys:

* [[StrongCoin]]

==An example private key==
In Bitcoin, a private key is a 256-bit number, which can be represented one of several ways. Here is a private key in hexadecimal - 256 bits in hexadecimal is 32 bytes, or 64 characters in the range 0-9 or A-F.

E9 87 3D 79 C6 D8 7D C0 FB 6A 57 78 63 33 89 F4 45 32 13 30 3D A6 1F 20 BD 67 FC 23 3A A3 32 62

==Range of valid private keys==
Nearly every 256-bit number is a valid private key. Specifically, any 256-bit number between 0x1 and 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 is a valid private key.

The range of valid private keys is governed by the [[secp256k1]] ECDSA standard used by Bitcoin.

==Base 58 Wallet Import format==
When we represent private keys in Bitcoin, however, we use a shorter format known as [[wallet import format]], which offers a few advantages. The wallet import format is shorter, and includes built-in error checking codes so that typos can be automatically detected and/or corrected (which is impossible in hex format). Wallet import format is the most common way to represent private keys in Bitcoin. For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5. Private keys associated with compressed public keys are 52 characters and start with a capital L or K. This is the same private key in wallet import format.

5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

When a private key is imported, it always corresponds to exactly one [[Address|Bitcoin address]]. Any utility which performs the conversion can display the matching Bitcoin address. The mathematical conversion is somewhat complex and best left to a computer, but it's notable that each private key will always correspond to the same address no matter which program is used to convert it.

The Bitcoin address corresponding to the sample above is: 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj

==Mini private key format==
Some applications use the [[mini private key format]]. Not every private key or Bitcoin address has a corresponding mini private key - they have to be generated a certain way in order to ensure a mini private key exists for an address. The mini private key is used for applications where space is critical, such as in QR codes and in [[physical bitcoins]]. The above example has a mini key, which is:

SzavMBLoXU6kDrqtUVmffv

==Summary==
Any Bitcoins sent to the address 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj can be spent by anybody who knows the private key in ''any'' of the three formats. That includes bitcoins presently at the address, as well as any bitcoins that are ever sent to it in the future. The private key is only needed to spend the balance, not necessarily to see it. The Bitcoin balance of the address can be determined by anybody with the public [[Block Explorer]] at http://www.blockexplorer.com/address/1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj - even if they don't have the private key.

If a private key with a Bitcoin balance is compromised or stolen, the bitcoin balance can only be protected if it is immediately spent to a different address whose private key is not compromised. Because bitcoins can only be spent once, when they are spent away from a private key, the private key is worthless unless more coins are sent to the address.