Bitcoin Wiki - User contributions [en]

Mini private key format

2025-11-11T07:02:07Z

Object In Space: /* Creating mini private keys */ convert Casascius Bitcoin Utility red link to link to GH repo, and add link to my utility too.

[[Image:QR-privkeys-sidebyside.png|thumb|right|Comparison of QR codes of the same private key, encoded in mini private key format (left) and [[wallet import format]] (right). Both codes have the same dot density and error correction level, but the mini key is 57% of the full code's size.]]
[[Image:Redeemed Denarium physical bitcoin.jpg|thumb|right|A minikey in a small space on a physical bitcoin]]
{{sample}}
The '''mini private key format''' is a method of encoding a Bitcoin private key in as few as 30 characters for the purpose of being embedded in a small space. A private key encoded in this format is called a '''minikey'''. This private key format was designed for and first used in [[Casascius physical bitcoins]], and is also favorable for use in QR codes. The fewer characters encoded in a QR code, the lower dot density can be used, as well as more dots allocated to error correction in the same space, significantly improving readability and resistance to damage. The mini private key format offers its own built-in check code as a small margin of protection against typos.

Casascius Series 1 holograms use a 22-character variant of the minikey format, instead of 30 characters. Everything is the same other than the length. To properly implement minikey redemption, services and clients must support the 30-character format, but may optionally support the 22-character format as well to allow redemption of old Casascius coins. Use of the 22-character format for future applications is discouraged due to security considerations; the standard 30-character format should be used instead.

An example key using this encoding is '''S6c56bnXQiBjk9m{{taggant private key}}qSYE7ykVQ7NzrRy'''.

==Usage==
===Physical bitcoins===
{{multiple image|align=vertical|width=300
|image1=Miniprivkeys.jpg
|image2=Minipubkeys.jpg
|footer=Paper disc inserts for [[Casascius physical bitcoins|Casascius coins]] with minikeys on the obverse (top) and corresponding address prefixes on the reverse (bottom)
}}
Minikeys are used extensively on physical bitcoins, because their small size allows them to be printed and read easily even on tiny surfaces inside the coins. Typically, a small paper or plastic disc is placed behind a tamper-evident security hologram on the back of a metal coin or bar, with the minikey printed on the inside such that it can only be read if the security hologram is removed.

Some physical bitcoins include a window in the security hologram to view the back of this disc, which includes the prefix of the address corresponding to the hidden minikey.

===1D barcodes===
The mini private key is small enough to fit in a one-dimensional barcode while still remaining practical. Among the most popular one-dimensional barcode symbologies, the one known as "Code 128" is best suited for encoding a minikey due to its favorable data density and support for mixed case strings. The variant known as "Code 128-B" produces the shortest code for strings containing lowercase characters.

The sample private minikey encoded with Code 128-B looks like this:

[[Image:Private_minikey_in_1D_barcode.gif]]

===2D barcodes===
The mini private key is suitable for use in QR codes. The recommended settings for maximizing readability are: QR version 3, error correction level Q (near highest, 25% possible lost codeword recovery). This results in a 29x29 grid. A minikey QR code can also fit in a 25x25 grid with QR version 2, error correction level L (lowest, 7% possible lost codeword recovery).

The sample private minikey encoded as a QR code on a 29x29 grid looks like this:

[[Image:Private_minikey_in_2D_barcode.gif]]

==Import==
Mini private keys can be imported through the following clients/services:

===Applications===
* [[Armory]]
* [[Electrum]]

[[Bitcoin Core]] cannot currently be used to import minikeys directly, although it can be used in conjunction with the conversion tools listed below.

===Web===

* [[BlockChain.info]]
** Private keys can be imported into a Blockchain.info wallet and bitcoins can be sent to another address immediately upon import without needing to wait for any confirmations. Even after import, funds remain associated with the private key until they are actually spent to a different address.
* [[StrongCoin]]

===Conversion tools===

These tools can convert a minikey into its corresponding address, and private key in [[wallet import format]], where it can be used with any compatible software.

* [https://codeberg.org/objectinspace/minikey Minikey] is a simple 100-line open-source tool with no external dependencies other than the programming language.
* https://www.bitaddress.org/ can also convert minikeys - although be sure to run the software offline rather than entering the minikey directly into the website, where it could be intercepted.

==Decoding==
The private key encoding consists of 30 alphanumeric characters from the [[base58]] alphabet used in Bitcoin. The first of the characters is always the uppercase letter S.

To determine whether the minikey is valid:

# Add a question mark to the end of the mini private key string.
# Take the SHA256 hash of the entire string. However, we will only look at the first byte of the result.
# If the first byte is 00, the string is a well-formed minikey. If the first byte is not 00, the string should be rejected as a minikey.

===Example with SHA256===
Here is an example with the sample private key <tt>S6c56bnXQiBjk9mq{{taggant private key}}SYE7ykVQ7NzrRy</tt>.

The string "<tt>S6c56bnXQiBjk9{{taggant private key}}mqSYE7ykVQ7NzrRy?</tt>" has a SHA256 value that begins with 00, so it is well-formed.

To obtain the full 256-bit private key, simply take the SHA256 hash of the entire string. There is no encoding for line breaks in the string, even if the key is broken into multiple lines for printing. The SHA256 should be taken of exactly thirty bytes.

SHA256("S6c56bnXQiBjk9{{taggant private key}}mqSYE7ykVQ7NzrRy") = 4C7A9640C72DC2099F23715D0C8A0D8A35F8906E3CAB61DD3F78B67BF887C9AB

This sample key in [[wallet import format]] is <tt>5JPy8Zg7z4P7RSLsiqcqyeAF1{{taggant private key}}935zjNUdMxcDeVrtU1oarrgnB7</tt>, and the corresponding [[Bitcoin address]] is <tt>1CciesT23BNionJe{{taggant address}}Xrbxmjc7ywfiyM4oLW</tt>.

==== Command line verification ====
To calculate SHA256 from the command line on OSX or Linux devices:

echo -n "S6c56bnXQiBjk9{{taggant private key}}mqSYE7ykVQ7NzrRy?" | shasum -a 256

That should output a line of text like "<tt>000f2453798ad4f951eecced2242eaef3e1cbc8a7c813c203ac7ffe57060355d -</tt>". Since the first two characters are <tt>00</tt> the verification passes for the mini key <tt>S6c56bnXQiBjk9{{taggant private key}}mqSYE7ykVQ7NzrRy</tt>

==Check code==
The mini private key format offers a simple typo check code. Mini private keys must be generated in a "brute force" fashion, keeping only keys that conform to the format's rules. If a key is well-formed (30 Base58 characters starting with S), but fails the hash check, then it probably contains a typo.

If the SHA256 hash of the string followed by '?' doesn't result in something that begins with 0x00, the string is not a valid mini private key.

==Creating mini private keys==
Creating mini private keys is relatively simple. One program which can create such keys is [https://github.com/casascius/Bitcoin-Address-Utility Casascius Bitcoin Utility]. [https://codeberg.org/objectinspace/minikey Minikey] is also capable of generating minikeys.

Mini private keys must be created "from scratch", as the conversion from mini private key to full-size private key is one-way. In other words, there is no way to convert an existing full-size private key into a mini private key.

To create mini private keys, simply create random strings that satisfy the well-formedness requirement, and then eliminate the ones that do not pass the typo check. (This means eliminating more than 99% of the candidates.) Then use the appropriate algorithm to compute the corresponding private key, and in turn, the matching Bitcoin address. The Bitcoin address can always be computed from just the private key.

It is strongly advisable to avoid using the digit "1" in minikeys unless it is being printed in such a way where a user is unlikely to mistake it for the lowercase letter "l". Few clients and redemption tools are prepared to tell the user that their entry containing the letter "l" should actually be the number "1" - rather, they will simply reject the code and may leave the user confused.

In all cases, you '''must''' use a secure cryptographic random number generator to eliminate risks of predictability of the random strings.

==Python Code==
The following code produces sample 30-character SHA256-based mini private keys in Python. For real-world use, ''random'' must be replaced with a better source of entropy, as the Python documentation for ''random'' states the function ''"is completely unsuitable for cryptographic purposes"''.

<source lang="python">
import random
import hashlib

BASE58 = '23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

def Candidate():
"""
Generate a random, well-formed mini private key.
"""
return('%s%s' % ('S', ''.join(
[BASE58[ random.randrange(0,len(BASE58)) ] for i in range(29)])))

def GenerateKeys(numKeys = 10):
"""
Generate mini private keys and output the mini key as well as the full
private key. numKeys is The number of keys to generate, and
"""
keysGenerated = 0
totalCandidates = 0
while keysGenerated < numKeys:
try:
cand = Candidate()
# Do typo check
t = '%s?' % cand
# Take one round of SHA256
candHash = hashlib.sha256(t).digest()
# Check if the first eight bits of the hash are 0
if candHash[0] == '\x00':
privateKey = GetPrivateKey(cand)
print('\n%s\nSHA256( ): %s\nsha256(?): %s' %
(cand, privateKey, candHash.encode('hex_codec')))
if CheckShortKey(cand):
print('Validated.')
else:
print('Invalid!')
keysGenerated += 1
totalCandidates += 1
except KeyboardInterrupt:
break
print('\n%s: %i\n%s: %i\n%s: %.1f' %
('Keys Generated', keysGenerated,
'Total Candidates', totalCandidates,
'Reject Percentage',
100*(1.0-keysGenerated/float(totalCandidates))))

def GetPrivateKey(shortKey):
"""
Returns the hexadecimal representation of the private key corresponding
to the given short key.
"""
if CheckShortKey(shortKey):
return hashlib.sha256(shortKey).hexdigest()
else:
print('Typo detected in private key!')
return None

def CheckShortKey(shortKey):
"""
Checks for typos in the short key.
"""
if len(shortKey) != 30:
return False
t = '%s?' % shortKey
tHash = hashlib.sha256(t).digest()
# Check to see that first byte is \x00
if tHash[0] == '\x00':
return True
return False
</source>

Mini private key format

2025-11-11T06:57:25Z

Object In Space: /* Import */ Add Electrum, Bitaddress.org, and my Minikey tool to the Import section

[[Image:QR-privkeys-sidebyside.png|thumb|right|Comparison of QR codes of the same private key, encoded in mini private key format (left) and [[wallet import format]] (right). Both codes have the same dot density and error correction level, but the mini key is 57% of the full code's size.]]
[[Image:Redeemed Denarium physical bitcoin.jpg|thumb|right|A minikey in a small space on a physical bitcoin]]
{{sample}}
The '''mini private key format''' is a method of encoding a Bitcoin private key in as few as 30 characters for the purpose of being embedded in a small space. A private key encoded in this format is called a '''minikey'''. This private key format was designed for and first used in [[Casascius physical bitcoins]], and is also favorable for use in QR codes. The fewer characters encoded in a QR code, the lower dot density can be used, as well as more dots allocated to error correction in the same space, significantly improving readability and resistance to damage. The mini private key format offers its own built-in check code as a small margin of protection against typos.

Casascius Series 1 holograms use a 22-character variant of the minikey format, instead of 30 characters. Everything is the same other than the length. To properly implement minikey redemption, services and clients must support the 30-character format, but may optionally support the 22-character format as well to allow redemption of old Casascius coins. Use of the 22-character format for future applications is discouraged due to security considerations; the standard 30-character format should be used instead.

An example key using this encoding is '''S6c56bnXQiBjk9m{{taggant private key}}qSYE7ykVQ7NzrRy'''.

==Usage==
===Physical bitcoins===
{{multiple image|align=vertical|width=300
|image1=Miniprivkeys.jpg
|image2=Minipubkeys.jpg
|footer=Paper disc inserts for [[Casascius physical bitcoins|Casascius coins]] with minikeys on the obverse (top) and corresponding address prefixes on the reverse (bottom)
}}
Minikeys are used extensively on physical bitcoins, because their small size allows them to be printed and read easily even on tiny surfaces inside the coins. Typically, a small paper or plastic disc is placed behind a tamper-evident security hologram on the back of a metal coin or bar, with the minikey printed on the inside such that it can only be read if the security hologram is removed.

Some physical bitcoins include a window in the security hologram to view the back of this disc, which includes the prefix of the address corresponding to the hidden minikey.

===1D barcodes===
The mini private key is small enough to fit in a one-dimensional barcode while still remaining practical. Among the most popular one-dimensional barcode symbologies, the one known as "Code 128" is best suited for encoding a minikey due to its favorable data density and support for mixed case strings. The variant known as "Code 128-B" produces the shortest code for strings containing lowercase characters.

The sample private minikey encoded with Code 128-B looks like this:

[[Image:Private_minikey_in_1D_barcode.gif]]

===2D barcodes===
The mini private key is suitable for use in QR codes. The recommended settings for maximizing readability are: QR version 3, error correction level Q (near highest, 25% possible lost codeword recovery). This results in a 29x29 grid. A minikey QR code can also fit in a 25x25 grid with QR version 2, error correction level L (lowest, 7% possible lost codeword recovery).

The sample private minikey encoded as a QR code on a 29x29 grid looks like this:

[[Image:Private_minikey_in_2D_barcode.gif]]

==Import==
Mini private keys can be imported through the following clients/services:

===Applications===
* [[Armory]]
* [[Electrum]]

[[Bitcoin Core]] cannot currently be used to import minikeys directly, although it can be used in conjunction with the conversion tools listed below.

===Web===

* [[BlockChain.info]]
** Private keys can be imported into a Blockchain.info wallet and bitcoins can be sent to another address immediately upon import without needing to wait for any confirmations. Even after import, funds remain associated with the private key until they are actually spent to a different address.
* [[StrongCoin]]

===Conversion tools===

These tools can convert a minikey into its corresponding address, and private key in [[wallet import format]], where it can be used with any compatible software.

* [https://codeberg.org/objectinspace/minikey Minikey] is a simple 100-line open-source tool with no external dependencies other than the programming language.
* https://www.bitaddress.org/ can also convert minikeys - although be sure to run the software offline rather than entering the minikey directly into the website, where it could be intercepted.

==Decoding==
The private key encoding consists of 30 alphanumeric characters from the [[base58]] alphabet used in Bitcoin. The first of the characters is always the uppercase letter S.

To determine whether the minikey is valid:

# Add a question mark to the end of the mini private key string.
# Take the SHA256 hash of the entire string. However, we will only look at the first byte of the result.
# If the first byte is 00, the string is a well-formed minikey. If the first byte is not 00, the string should be rejected as a minikey.

===Example with SHA256===
Here is an example with the sample private key <tt>S6c56bnXQiBjk9mq{{taggant private key}}SYE7ykVQ7NzrRy</tt>.

The string "<tt>S6c56bnXQiBjk9{{taggant private key}}mqSYE7ykVQ7NzrRy?</tt>" has a SHA256 value that begins with 00, so it is well-formed.

To obtain the full 256-bit private key, simply take the SHA256 hash of the entire string. There is no encoding for line breaks in the string, even if the key is broken into multiple lines for printing. The SHA256 should be taken of exactly thirty bytes.

SHA256("S6c56bnXQiBjk9{{taggant private key}}mqSYE7ykVQ7NzrRy") = 4C7A9640C72DC2099F23715D0C8A0D8A35F8906E3CAB61DD3F78B67BF887C9AB

This sample key in [[wallet import format]] is <tt>5JPy8Zg7z4P7RSLsiqcqyeAF1{{taggant private key}}935zjNUdMxcDeVrtU1oarrgnB7</tt>, and the corresponding [[Bitcoin address]] is <tt>1CciesT23BNionJe{{taggant address}}Xrbxmjc7ywfiyM4oLW</tt>.

==== Command line verification ====
To calculate SHA256 from the command line on OSX or Linux devices:

echo -n "S6c56bnXQiBjk9{{taggant private key}}mqSYE7ykVQ7NzrRy?" | shasum -a 256

That should output a line of text like "<tt>000f2453798ad4f951eecced2242eaef3e1cbc8a7c813c203ac7ffe57060355d -</tt>". Since the first two characters are <tt>00</tt> the verification passes for the mini key <tt>S6c56bnXQiBjk9{{taggant private key}}mqSYE7ykVQ7NzrRy</tt>

==Check code==
The mini private key format offers a simple typo check code. Mini private keys must be generated in a "brute force" fashion, keeping only keys that conform to the format's rules. If a key is well-formed (30 Base58 characters starting with S), but fails the hash check, then it probably contains a typo.

If the SHA256 hash of the string followed by '?' doesn't result in something that begins with 0x00, the string is not a valid mini private key.

==Creating mini private keys==
Creating mini private keys is relatively simple. One program which can create such keys is [[Casascius Bitcoin Utility]].

Mini private keys must be created "from scratch", as the conversion from mini private key to full-size private key is one-way. In other words, there is no way to convert an existing full-size private key into a mini private key.

To create mini private keys, simply create random strings that satisfy the well-formedness requirement, and then eliminate the ones that do not pass the typo check. (This means eliminating more than 99% of the candidates.) Then use the appropriate algorithm to compute the corresponding private key, and in turn, the matching Bitcoin address. The Bitcoin address can always be computed from just the private key.

It is strongly advisable to avoid using the digit "1" in minikeys unless it is being printed in such a way where a user is unlikely to mistake it for the lowercase letter "l". Few clients and redemption tools are prepared to tell the user that their entry containing the letter "l" should actually be the number "1" - rather, they will simply reject the code and may leave the user confused.

In all cases, you '''must''' use a secure cryptographic random number generator to eliminate risks of predictability of the random strings.

==Python Code==
The following code produces sample 30-character SHA256-based mini private keys in Python. For real-world use, ''random'' must be replaced with a better source of entropy, as the Python documentation for ''random'' states the function ''"is completely unsuitable for cryptographic purposes"''.

<source lang="python">
import random
import hashlib

BASE58 = '23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

def Candidate():
"""
Generate a random, well-formed mini private key.
"""
return('%s%s' % ('S', ''.join(
[BASE58[ random.randrange(0,len(BASE58)) ] for i in range(29)])))

def GenerateKeys(numKeys = 10):
"""
Generate mini private keys and output the mini key as well as the full
private key. numKeys is The number of keys to generate, and
"""
keysGenerated = 0
totalCandidates = 0
while keysGenerated < numKeys:
try:
cand = Candidate()
# Do typo check
t = '%s?' % cand
# Take one round of SHA256
candHash = hashlib.sha256(t).digest()
# Check if the first eight bits of the hash are 0
if candHash[0] == '\x00':
privateKey = GetPrivateKey(cand)
print('\n%s\nSHA256( ): %s\nsha256(?): %s' %
(cand, privateKey, candHash.encode('hex_codec')))
if CheckShortKey(cand):
print('Validated.')
else:
print('Invalid!')
keysGenerated += 1
totalCandidates += 1
except KeyboardInterrupt:
break
print('\n%s: %i\n%s: %i\n%s: %.1f' %
('Keys Generated', keysGenerated,
'Total Candidates', totalCandidates,
'Reject Percentage',
100*(1.0-keysGenerated/float(totalCandidates))))

def GetPrivateKey(shortKey):
"""
Returns the hexadecimal representation of the private key corresponding
to the given short key.
"""
if CheckShortKey(shortKey):
return hashlib.sha256(shortKey).hexdigest()
else:
print('Typo detected in private key!')
return None

def CheckShortKey(shortKey):
"""
Checks for typos in the short key.
"""
if len(shortKey) != 30:
return False
t = '%s?' % shortKey
tHash = hashlib.sha256(t).digest()
# Check to see that first byte is \x00
if tHash[0] == '\x00':
return True
return False
</source>

Talk:List of address prefixes

2017-10-30T07:59:24Z

Object In Space: /* BIP 0173 */ new section

Shouldn't the line
128 5 Bitcoin Private key 5Htn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq
be
128 t Bitcoin Private key tHtn3FzuH3b1X5VF2zLTsAQzBcyzkZNJsa2egXN8ZFJTCqQm3Rq
according to
127-128 t 34
?
--[[User:ThePiachu|ThePiachu]] ([[User talk:ThePiachu|talk]]) 01:59, 27 June 2012 (GMT)

What is the policy regarding addresses which are not altcoins but which relate to protocols being built on top of bitcoin? I think there is value in some kind of registry for such protocols to prevent address clashes, and help users know the purpose of different addresses. But I don't want to overstep if that's not the purpose of this page.
--[[User:gidgreen|gidgreen]] 7 July 2014 (GMT)

* I'm not sure what you mean by that. Altcoins abusing bitcoin's blockchain are still altcoins. Also note that the version byte is for a version, not a namespace. CoinSpark seems to be inserting a "features" in the address. It makes sense to have this, I think, but it should be based on version 5 addresses (p2sh), not the obsolete version 0 (p2pkh)... Perhaps more importantly, this should be proposed on the development mailing list and made a BIP before appearing on this page. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 20:47, 7 July 2014 (UTC)
** CoinSpark is not an altcoin. It's a protocol for enriching bitcoin transactions via OP_RETURNs. Of the 5 features on the current roadmap, one is a variant on the idea of colored coins (I don't know if you would call that an altcoin or not) but the rest are all about making regular bitcoin transactions easier and more useful. I imagine it will be one of many such protocols which come out during the coming years, and I think there is sense in avoiding addressing clashes between these different protocols. As you say, [http://coinspark.org/developers/coinspark-addresses/ CoinSpark addresses] encode several types of information but this is not really appropriate for a BIP since it's not an enhancement to the bitcoin protocol itself. (Think TCP/IP and the Web.) So what mechanism would you suggest for avoiding addressing clashes? [[User:Gidgreen|Gidgreen]] ([[User talk:Gidgreen|talk]]) 06:28, 20 July 2014 (UTC)
*** If it's not Bitcoin, it doesn't belong on the Bitcoin Wiki or in the Bitcoin blockchain. If it is Bitcoin, then a BIP is appropriate. BIPs are for any Bitcoin Improvement Proposal, not just select parts of the system. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 17:58, 20 July 2014 (UTC)

It seems odd that keys (HD and WIF) are listed in a table of "address prefixes".
--[[User:evoskuil|evoskuil]] 28 September 2015

== [[BIP 0173]] ==

This page and [[Address]] need to be updated to account for [[BIP 0173]] and [[Segregated Witness]].

Talk:Invoice address

2017-10-30T07:58:49Z

Object In Space: /* BIP 0173 */ new section

{{WikiProject|Protocol|quality=QNR|importance=HIGH}}
During the described process of generating a bitcoin address, can it further be explained which parts are the private key or how they are computed too?

:Please see [[Technical background of Bitcoin addresses]] for that information --[[User:Atheros|Atheros]] 08:42, 9 December 2011 (GMT)

This wiki says a bitcoin address can have a length between 27 and 34 characters. But acc. to "https://bitcointalk.org/index.php?topic=278814.msg2978906#msg2978906" bitcoin addresses with only 26 (!) characters are also possible as well. What is written there appears plausible to me, so maybe someone skilled can verify, and if confirmed, correct the text in this wiki. --[[User:Michael_S|Michael_S]], 14:13, 7 December 2013 (CET)

== [[BIP 0173]] ==

This page and [[List of address prefixes]] need to be updated to account for [[BIP 0173]] and [[Segregated Witness]].