Bitcoin Wiki - User contributions [en]

Talk:Mini private key format

2011-11-27T20:03:04Z

T X:

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

: The original private key has 256bits of entropy, not 160, hasn't it? (I don't know why the current wiki page compares it with 160 bits) --[[User:T X|T X]] 20:03, 27 November 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

:The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.

:Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= Purpose of appending the '?' for determining algorithm? =

At first I was wondering why this should be appended, why not just checking the first byte of SHA256 of the minikey as is. The reason I now could think of is that you don't want someone to be able to tell whether a bitcoin private key was generated from a minikey. Is that a good or a bad thing? Is that the main reason? Are there any other reasons? Maybe such reasons should be explained on the wiki page? --[[User:T X|T X]] 16:32, 26 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?

:: But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be: Adding a Reserved Minikey Version Character?

:: --[[User:T X|T X]] 04:19, 25 November 2011 (GMT)

::: Hm, after some more thoughts, I think I might be able to partially answer this to myself: If I were receiving a minikey from an untrusted/unknown party, the minikey is pretty much worthless anyway due to not being able to verify that it is a valid minikey until getting access to a computer. As you said before, if it is a known, public party then I can usually get information probably somewhere online about the used algorithm at any time. If it is a trusted but non-public party I want to get a minikey from then the my trusting that the other party chose a good minikey algorithm is marginal compared to my already given trust in the other party that they have generated a valid minikey in general.

::: Now there's just one scenario left I can come up with: I might have obtained lots of minikeys from trusted, non-public parties which I had all put in my piggy bank at home. Now, five years later some issues came up with certain minikey algorithms which suggests anyone having such minikeys to redeem the value as soon as possible. If only about 5% of the minikeys in my piggy bank were using the broken minikey algorithm, I'd still have to copy and check all of them on my computer.

::: Maybe the conclusion could be that you shouldn't save 'anonymous' minikeys (if any due to the lower entropy). Don't know. --[[User:T X|T X]] 15:25, 26 November 2011 (GMT)

= Adding a Reserved Minikey Version Character? =

What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).

Advantages:
* Selected algorithm visibility / minikey 'strength' visibility
* Easy Extensibility

For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= PBKDF2 =

== HMAC-SHA1 or HMAC-SHA256? ==
Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

: I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of [http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html Ian Grigg's hypotheses]. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

== Use exponential rounds encoding ==

With the values from 0x0128 to 0x01FF being reserved about another 7.75 Bits (log2 (0xFF - 0x27)) of entropy would be lost. I don't think that for instance very similar number of rounds are needed. Instead the number of rounds could be encoded exponentially and reserved in less bits. For instance:

* (SHA256 & 0xFF03) == 0x0100 -> 4096 rounds
* (SHA256 & 0xFF03) == 0x0101 -> 8192
* (SHA256 & 0xFF03) == 0x0102 -> 16384
* (SHA256 & 0xFF03) == 0x0103 -> 32768

This would only remove about 2 instead of the 7.75Bits of entropy. --[[User:T X|T X]] 16:11, 26 November 2011 (GMT)

= Tagging Stable Versions =

Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= More specific applications for simple SHA256 minikeys =

"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"

Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?

If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.

I saw that you, [[User:Casascius|Casascius]], were playing with [[Casascius_Bitcoin_POS_system|POS systems]]: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

----

= (Probably) Finished Discussions =

== Python Code ==

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

== 717 round SHA256 ==

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: The 717 round bit was mostly a proposal, I am not aware of any use in the field. I did not use them in Casascius Coins. The PBKDF2 version would be preferred long term. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Oki doki, makes sense (as already said above) --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

Talk:Mini private key format

2011-11-26T16:32:02Z

T X:

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

:The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.

:Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= Purpose of appending the '?' for determining algorithm? =

At first I was wondering why this should be appended, why not just checking the first byte of SHA256 of the minikey as is. The reason I now could think of is that you don't want someone to be able to tell whether a bitcoin private key was generated from a minikey. Is that a good or a bad thing? Is that the main reason? Are there any other reasons? Maybe such reasons should be explained on the wiki page? --[[User:T X|T X]] 16:32, 26 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?

:: But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be: Adding a Reserved Minikey Version Character?

:: --[[User:T X|T X]] 04:19, 25 November 2011 (GMT)

::: Hm, after some more thoughts, I think I might be able to partially answer this to myself: If I were receiving a minikey from an untrusted/unknown party, the minikey is pretty much worthless anyway due to not being able to verify that it is a valid minikey until getting access to a computer. As you said before, if it is a known, public party then I can usually get information probably somewhere online about the used algorithm at any time. If it is a trusted but non-public party I want to get a minikey from then the my trusting that the other party chose a good minikey algorithm is marginal compared to my already given trust in the other party that they have generated a valid minikey in general.

::: Now there's just one scenario left I can come up with: I might have obtained lots of minikeys from trusted, non-public parties which I had all put in my piggy bank at home. Now, five years later some issues came up with certain minikey algorithms which suggests anyone having such minikeys to redeem the value as soon as possible. If only about 5% of the minikeys in my piggy bank were using the broken minikey algorithm, I'd still have to copy and check all of them on my computer.

::: Maybe the conclusion could be that you shouldn't save 'anonymous' minikeys (if any due to the lower entropy). Don't know. --[[User:T X|T X]] 15:25, 26 November 2011 (GMT)

= Adding a Reserved Minikey Version Character? =

What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).

Advantages:
* Selected algorithm visibility / minikey 'strength' visibility
* Easy Extensibility

For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= PBKDF2 =

== HMAC-SHA1 or HMAC-SHA256? ==
Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

: I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of [http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html Ian Grigg's hypotheses]. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

== Use exponential rounds encoding ==

With the values from 0x0128 to 0x01FF being reserved about another 7.75 Bits (log2 (0xFF - 0x27)) of entropy would be lost. I don't think that for instance very similar number of rounds are needed. Instead the number of rounds could be encoded exponentially and reserved in less bits. For instance:

* (SHA256 & 0xFF03) == 0x0100 -> 4096 rounds
* (SHA256 & 0xFF03) == 0x0101 -> 8192
* (SHA256 & 0xFF03) == 0x0102 -> 16384
* (SHA256 & 0xFF03) == 0x0103 -> 32768

This would only remove about 2 instead of the 7.75Bits of entropy. --[[User:T X|T X]] 16:11, 26 November 2011 (GMT)

= Tagging Stable Versions =

Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= More specific applications for simple SHA256 minikeys =

"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"

Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?

If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.

I saw that you, [[User:Casascius|Casascius]], were playing with [[Casascius_Bitcoin_POS_system|POS systems]]: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

----

= (Probably) Finished Discussions =

== Python Code ==

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

== 717 round SHA256 ==

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: The 717 round bit was mostly a proposal, I am not aware of any use in the field. I did not use them in Casascius Coins. The PBKDF2 version would be preferred long term. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Oki doki, makes sense (as already said above) --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

Talk:Mini private key format

2011-11-26T16:11:18Z

T X: /* PBKDF2 */ suggestion to only lose ~2 instead of ~7.75 bits for PBKDF2 compared to SHA256

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

:The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.

:Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?

:: But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be: Adding a Reserved Minikey Version Character?

:: --[[User:T X|T X]] 04:19, 25 November 2011 (GMT)

::: Hm, after some more thoughts, I think I might be able to partially answer this to myself: If I were receiving a minikey from an untrusted/unknown party, the minikey is pretty much worthless anyway due to not being able to verify that it is a valid minikey until getting access to a computer. As you said before, if it is a known, public party then I can usually get information probably somewhere online about the used algorithm at any time. If it is a trusted but non-public party I want to get a minikey from then the my trusting that the other party chose a good minikey algorithm is marginal compared to my already given trust in the other party that they have generated a valid minikey in general.

::: Now there's just one scenario left I can come up with: I might have obtained lots of minikeys from trusted, non-public parties which I had all put in my piggy bank at home. Now, five years later some issues came up with certain minikey algorithms which suggests anyone having such minikeys to redeem the value as soon as possible. If only about 5% of the minikeys in my piggy bank were using the broken minikey algorithm, I'd still have to copy and check all of them on my computer.

::: Maybe the conclusion could be that you shouldn't save 'anonymous' minikeys (if any due to the lower entropy). Don't know. --[[User:T X|T X]] 15:25, 26 November 2011 (GMT)

= Adding a Reserved Minikey Version Character? =

What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).

Advantages:
* Selected algorithm visibility / minikey 'strength' visibility
* Easy Extensibility

For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= PBKDF2 =

== HMAC-SHA1 or HMAC-SHA256? ==
Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

: I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of [http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html Ian Grigg's hypotheses]. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

== Use exponential rounds encoding ==

With the values from 0x0128 to 0x01FF being reserved about another 7.75 Bits (log2 (0xFF - 0x27)) of entropy would be lost. I don't think that for instance very similar number of rounds are needed. Instead the number of rounds could be encoded exponentially and reserved in less bits. For instance:

* (SHA256 & 0xFF03) == 0x0100 -> 4096 rounds
* (SHA256 & 0xFF03) == 0x0101 -> 8192
* (SHA256 & 0xFF03) == 0x0102 -> 16384
* (SHA256 & 0xFF03) == 0x0103 -> 32768

This would only remove about 2 instead of the 7.75Bits of entropy. --[[User:T X|T X]] 16:11, 26 November 2011 (GMT)

= Tagging Stable Versions =

Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= More specific applications for simple SHA256 minikeys =

"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"

Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?

If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.

I saw that you, [[User:Casascius|Casascius]], were playing with [[Casascius_Bitcoin_POS_system|POS systems]]: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

----

= (Probably) Finished Discussions =

== Python Code ==

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

== 717 round SHA256 ==

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: The 717 round bit was mostly a proposal, I am not aware of any use in the field. I did not use them in Casascius Coins. The PBKDF2 version would be preferred long term. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Oki doki, makes sense (as already said above) --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

Talk:Mini private key format

2011-11-26T15:25:10Z

T X: /* Terminology */

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

:The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.

:Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?

:: But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be: Adding a Reserved Minikey Version Character?

:: --[[User:T X|T X]] 04:19, 25 November 2011 (GMT)

::: Hm, after some more thoughts, I think I might be able to partially answer this to myself: If I were receiving a minikey from an untrusted/unknown party, the minikey is pretty much worthless anyway due to not being able to verify that it is a valid minikey until getting access to a computer. As you said before, if it is a known, public party then I can usually get information probably somewhere online about the used algorithm at any time. If it is a trusted but non-public party I want to get a minikey from then the my trusting that the other party chose a good minikey algorithm is marginal compared to my already given trust in the other party that they have generated a valid minikey in general.

::: Now there's just one scenario left I can come up with: I might have obtained lots of minikeys from trusted, non-public parties which I had all put in my piggy bank at home. Now, five years later some issues came up with certain minikey algorithms which suggests anyone having such minikeys to redeem the value as soon as possible. If only about 5% of the minikeys in my piggy bank were using the broken minikey algorithm, I'd still have to copy and check all of them on my computer.

::: Maybe the conclusion could be that you shouldn't save 'anonymous' minikeys (if any due to the lower entropy). Don't know. --[[User:T X|T X]] 15:25, 26 November 2011 (GMT)

= Adding a Reserved Minikey Version Character? =

What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).

Advantages:
* Selected algorithm visibility / minikey 'strength' visibility
* Easy Extensibility

For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= PBKDF2 =

Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

: I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of [http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html Ian Grigg's hypotheses]. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Tagging Stable Versions =

Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= More specific applications for simple SHA256 minikeys =

"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"

Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?

If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.

I saw that you, [[User:Casascius|Casascius]], were playing with [[Casascius_Bitcoin_POS_system|POS systems]]: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

----

= (Probably) Finished Discussions =

== Python Code ==

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

== 717 round SHA256 ==

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: The 717 round bit was mostly a proposal, I am not aware of any use in the field. I did not use them in Casascius Coins. The PBKDF2 version would be preferred long term. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Oki doki, makes sense (as already said above) --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

Talk:Mini private key format

2011-11-25T04:21:20Z

T X: /* Terminology */

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

:The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.

:Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?

:: But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be: Adding a Reserved Minikey Version Character?

:: --[[User:T X|T X]] 04:19, 25 November 2011 (GMT)

= Adding a Reserved Minikey Version Character? =

What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).

Advantages:
* Selected algorithm visibility / minikey 'strength' visibility
* Easy Extensibility

For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= PBKDF2 =

Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

: I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of [http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html Ian Grigg's hypotheses]. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Tagging Stable Versions =

Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= More specific applications for simple SHA256 minikeys =

"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"

Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?

If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.

I saw that you, [[User:Casascius|Casascius]], were playing with [[Casascius_Bitcoin_POS_system|POS systems]]: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

----

= (Probably) Finished Discussions =

== Python Code ==

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

== 717 round SHA256 ==

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: The 717 round bit was mostly a proposal, I am not aware of any use in the field. I did not use them in Casascius Coins. The PBKDF2 version would be preferred long term. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Oki doki, makes sense (as already said above) --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

Talk:Mini private key format

2011-11-25T04:19:19Z

T X: /* Terminology */ adding signature

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

:The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.

:Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?

:: But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be: --[[User:T X|T X]] 04:19, 25 November 2011 (GMT)

= Adding a Reserved Minikey Version Character? =

What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).

Advantages:
* Selected algorithm visibility / minikey 'strength' visibility
* Easy Extensibility

For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= PBKDF2 =

Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

: I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of [http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html Ian Grigg's hypotheses]. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Tagging Stable Versions =

Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= More specific applications for simple SHA256 minikeys =

"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"

Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?

If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.

I saw that you, [[User:Casascius|Casascius]], were playing with [[Casascius_Bitcoin_POS_system|POS systems]]: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

----

= (Probably) Finished Discussions =

== Python Code ==

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

== 717 round SHA256 ==

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: The 717 round bit was mostly a proposal, I am not aware of any use in the field. I did not use them in Casascius Coins. The PBKDF2 version would be preferred long term. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Oki doki, makes sense (as already said above) --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

Talk:Mini private key format

2011-11-25T04:18:39Z

T X: /* PBKDF2 */ adding signature

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

:The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.

:Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?

:: But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be:

= Adding a Reserved Minikey Version Character? =

What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).

Advantages:
* Selected algorithm visibility / minikey 'strength' visibility
* Easy Extensibility

For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= PBKDF2 =

Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

: I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of [http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html Ian Grigg's hypotheses]. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Tagging Stable Versions =

Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= More specific applications for simple SHA256 minikeys =

"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"

Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?

If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.

I saw that you, [[User:Casascius|Casascius]], were playing with [[Casascius_Bitcoin_POS_system|POS systems]]: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

----

= (Probably) Finished Discussions =

== Python Code ==

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

== 717 round SHA256 ==

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: The 717 round bit was mostly a proposal, I am not aware of any use in the field. I did not use them in Casascius Coins. The PBKDF2 version would be preferred long term. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Oki doki, makes sense (as already said above) --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

Talk:Mini private key format

2011-11-25T04:18:10Z

T X: adding some more thoughts/comments/replies/considerations

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

:The only concern would be the number of bitcoins stored in low-entropy keys. The concern expressed by the developers (in #bitcoin-dev at around the same time I made the PBKDF2 edits - you can review the logs) wasn't whether a few Casascius coins were at risk, but rather, whether a low-entropy format would become popular enough as time goes on to make the constantly increasing reward for a successful attack eventually intersect with the constantly decreasing resource cost to attack it.

:Also the developers noted that QR codes are much more efficient when they are made strictly from the set of uppercase alphanumerics, as it switches to a QR encoding that spends fewer bits per character. Mixed case QR codes require a full 8-bit character set (IIRC), which takes up significantly more space than the QR alphanumeric encoding which doesn't support lowercase. The developers expressed a willingness to entertain an alternate encoding of full Bitcoin private keys that used base36 (or perhaps base44, since that's how many printable characters in the QR alphanumeric set), which would result in a significantly reduced footprint in QR codes. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: I don't think it will be a major issue. If there's a lot of them out there, they could easily be described by the product. For example, one could name "all Casascius coins with the 'casacius' misspelling" and accurately describe the set of affected coins, if a fault in 22-char sha256 keys were to be found. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: True, that could easily be done through the thing that embeds the minikey if this embedding thing is a fixed product version (like the casacius coins). But what if only the minikey is available without a recognisable product(which could probably easily happen if this format were widely adopted)?

:: But on second thought, even if having two minikey names this problem would still exist. Someone could still just print either minikey version and the user will not know which one that is without doing the first two decoding steps on a computer. So another thought would be:

= Adding a Reserved Minikey Version Character? =

What do you think about sacrificing another character to visibly allow knowing the chosen algorithm of this minikey? E.g. the first 'S' will still show that it's a minikey, but the second letter could note the selected algorithm (for instance '0' for sha256, '1' for PBKDF2-SHA256).

Advantages:
* Selected algorithm visibility / minikey 'strength' visibility
* Easy Extensibility

For instance if sha256 were at some day considered broken or improvements for the algorithm were coming up, we wouldn't need to reserve a new letter instead of the 'S', due to the minikey reserved version character in the second character. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: Correct, if a Bitcoin address has 160 bits, then the extra bits in the private key will probably add little or no value. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

= PBKDF2 =

Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

: I implemented an HMAC-SHA1 on my fork on Github just because the code was readily available. The developers' response was along the lines of "why should we make use of a hashing algorithm on its way out the door when we don't have to, it makes us look less sophisticated". I tend to agree and would favor HMAC-SHA256, was just a matter of how much time I had to throw at it. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)

:: Oki doki, makes sense for quick prototyping reasons. However for making it a 'Standard' probably the best available one today should be chosen, shouldn't it? Also kind of in the spirit of [http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html Ian Grigg's hypotheses].

= Tagging Stable Versions =

Just as a note and thought: Before including a minikey format in the bitcoin source code and after all questions and considerations have been resolved a fixed version should be tagged so that other people could rely on certain properties of a certain minikey version. Until then the whole thing (including the simple sha256 version?) should be explicitly marked as a draft, stating that any adoption in for instance commercial products should be done on one's own risk. --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

= More specific applications for simple SHA256 minikeys =

"The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers"

Would you mind explaining a little further in which use cases it might be desireable to compute minikeys on for instance microcontrollers? Are they common? Do they justify the necessity of a weaker minikey version?

If you have a certain product like your 'casacius coins', one possible application area, I guess you probably don't do this on microcontrollers. You usually have enough space + money for machines with enough computational power generating minikeys in PBKFD2-SHA256 format.

I saw that you, [[User:Casascius|Casascius]], were playing with [[Casascius_Bitcoin_POS_system|POS systems]]: Is that the main application for the SHA256 minikey version you had in mind? Won't most embedded devices need an internet connection to be useful anyway, just like such a POS system, which will in most use cases allow the outsourcing of computational intensive tasks, like a PBKFD2-SHA256 generation? Is there really a need to be able to calculate minikeys directly on tiny embedded systems? --[[User:T X|T X]] 04:18, 25 November 2011 (GMT)

----

= (Probably) Finished Discussions =

== Python Code ==

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: It was to force all codes to only pass the 717th round checksum, which is computationally intensive in slow interpreted languages like Javascript. But I would favor scrapping the arbitrary 717th round thing in favor of PBKDF2. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Ok, agreed, also makes sense to me to remove the 717th round sha256 in favour for PBKDF2. I removed it from the python code. --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

== 717 round SHA256 ==

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

: The 717 round bit was mostly a proposal, I am not aware of any use in the field. I did not use them in Casascius Coins. The PBKDF2 version would be preferred long term. [[User:Casascius|Casascius]] 03:32, 10 November 2011 (GMT)
:: Oki doki, makes sense (as already said above) --[[User:T X|T X]] 22:31, 20 November 2011 (GMT)

Talk:Mini private key format

2011-11-20T22:31:58Z

T X: ticked the 717 round sha256 questions from the list

Mini private key format

2011-11-20T22:21:00Z

T X: removing 717 round sha256 version (see discussion page)

[[Image:QR-privkeys-sidebyside.png|thumb|right|QR codes of the same private key, in mini versus regular private key format. Both codes have the same dot density and error correction level, but the mini key is 57% of the full code's size.]]
The '''mini private key format''' is a method of encoding a Bitcoin private key in as few as 22 characters so that it can be embedded in a small space. This private key format was 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.

An example key using this encoding is '''S4b3N3oGqDqR5jNuxEvDwf'''.

==Usage on a physical bitcoin==
The way it might appear within a physical bitcoin is on a round card printed as follows:

<center>S4b3N<br/>3oGqDq<br/>R5jNux<br/>EvDwf</center>

==Import==
To import the minikey in a user-friendly way the browser-wallet [[StrongCoin]] can be used.

Source code for a version of the client that can be compiled to import mini private keys via [[importprivkey]] can be found at github as casascius/bitcoin.

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

There are two methods to obtain the full 256-bit private key. One involves SHA256, and the other involves PBKDF2. A simple test must be performed to determine which method shall be used:

# 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 looking at the first two bytes of the result.
# If the first byte is 00, then the private key must be computed as simply SHA256(minikey). The question mark is not part of this computation.
# If the first byte is 01, then the private key must be computed using PBKDF2. The second byte determines the iteration count that will be passed into the PBKDF2 function. The iteration count is determined as follows: 2 ^ (n/4) rounded to the nearest integer, where n is the second byte. For example, if the second byte is 0x28, then 4096 iterations will be used. The salt string is "Satoshi Nakamoto". The Bitcoin client imposes an upper limit on the value of n, which is currently 0x40, or 65536 iterations, and rejects the key as invalid beyond the limit.

===Example with SHA256===
Here is an example with the sample private key S4b3N3oGqDqR5jNuxEvDwf.

The string "S4b3N3oGqDqR5jNuxEvDwf?" has a SHA256 value that begins with 00, so it uses SHA256.

To obtain the full 256-bit private key, simply take the SHA256 hash of the entire string. There is no encoding for breaks in the string even if printed that way - the SHA256 should be taken of exactly twenty-two bytes.

SHA256("S4b3N3oGqDqR5jNuxEvDwf") = 0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D

This sample key in [[wallet export format]] is 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ, and the corresponding [[Bitcoin address]] is 1GAehh7TsJAHuUAeKZcXf5CnwuGuGgyX2S.

===Example with PBKDF2===
Here is an example with the sample private key SmbM4uRBu2mQymCsuMKkiW.

The string "SmbM4uRBu2mQymCsuMKkiW?" has a SHA256 value that begins with 01 30 (hex), so it will use PBKDF2 with 4096 iterations.

To obtain the full 256-bit private key, evaluate the PBKDF2 function as follows:

PBKDF2("SmbM4uRBu2mQymCsuMKkiW", "Satoshi Nakamoto", 4096, 32bytes) =
80366610e37e56c5125aee358ab51326a15f6586d658b90bb881a6116b06853c

This sample key in [[wallet export format]] is 5Jnkbccxr6hbCkL7d4sufAzrTxqWmeSHTY2tKQp4P1vogQ13g5g, and the corresponding [[Bitcoin address]] is 1ArzEMMcd4EHV3jbWKkpuGRhBG6iV4RCVA.

The PBKDF2 key derivation algorithm is shared by the WPA-PSK encryption method used on WiFi networks. It also happens to also use 4096 iterations and 32 bytes of key, so a standard WPA key calculator can be used to test and confirm this particular result, simply by entering "Satoshi Nakamoto" as the SSID and "SmbM4uRBu2mQymCsuMKkiW" as the password.

==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 (22, 26, or 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 or 0x01, the mini private key is not valid.

If it starts with 0x01, but the second byte is higher than the allowed maximum (0x30), the mini private key is invalid. Note that the maximum is likely to be increased as computing power advances.

==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 '''highly recommended''' to use the PBKDF2 function and select at least 4096 rounds. (This means selecting strings as keys whose SHA256(string+"?") begins with 0x0128). Mini private keys offer a minimum of entropy, so the more rounds you choose, the stronger your keys will resist advances in technology to do brute-force cracks.

The SHA256 function is provided for the convenience of hardware and software environments that offer very limited computational power, such as microcontrollers. It provides for the ability to generate a valid mini private key with, on average, 256 operations of SHA256. However, it also offers the lowest brute force attack resistance. Such keys are only suitable for situations where a "throwaway" Bitcoin address is needed, such as on a coupon or ticket where the amount will be spent soon, as opposed to an address where bitcoins will be kept long term. The strongest possible PBKDF2-based keys should always be preferred in any environment where generating them is possible.

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

==Entropy considerations==
The 22-character mini private key code appears to offer about 123 bits of entropy, determined as log2(58^21). (Because the first character is fixed, there are 21 symbols which can each have one of 58 values).

The 26-character version offers about 146 bits of entropy by the same calculation. The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address.

==Python Code==
The following code produces sample 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 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

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(21)])))

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: %r\n%s: %.1f' %
('Keys Generated', keysGenerated,
'Total Candidates', totalCandidates,
'Additional Security', additionalSecurity,
'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) != 22:
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:Mini private key format

2011-11-10T01:01:28Z

T X: /* PBKDF2 */

I'm not sure I like the idea of encouraging people to use less than the current 160bits of entropy in a private key. [[User:Willphase|Willphase]] 14:15, 25 September 2011 (GMT)

= Python Code =

What was the "additionalSecurity" flag supposed to do? It seems unused. --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

= Application =

When minikeys should or should not be used is not really obvious to me from reading this article. From reading the introduction I'm especially getting the impression that minikeys should always be prefered.

Any disadvantages of minikeys are not directly mentioned - only indirectly via the entropy section, but this might not be understandable to anyone not that familiar with cryptography.

In forum and github posts I however got the impression, that due to the reduced entropy minikeys should be used for smaller amounts only. Is this the case for the SHA256 or also the PBKDF2 computed version?

Are there any other disadvantages? Would it be problematic if 1M (2M/4M/10M/...) bitcoins were stored in 1 (0.1/0.01/...) BTC mini private keys (via for instance Casascius or Casascius alike coins)? Is it really the case that a minikey is always "favorable for use in QR codes", under all circumstances? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

= 717 round SHA256 =

[https://github.com/bitcoin/bitcoin/pull/220#issuecomment-2185128 "I also got rid of the 717-round stuff. I haven't used any such codes on physical bitcoins so it can be scrapped right now."]

Does that mean that the 717 round sha256 version mentioned on this wiki page is deprecated due to a superior PBKDF2 version? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

= Terminology =

For a non-developer it is not obvious whether a certain minikey is the SHA256 or stronger PBKDF2 version. So for instance if a user got a receipt saying "minikey: ...", the user does not know whether s/he should hurry to redeem it or not. Maybe two distinct names should be used for the SHA256 and PBKDF2 versions? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

= Entropy Considerations =

The entropy is much lower due to the thrown away candidates, isn't it? So log2(58^21/2^7)?

"The 30-character version offers over 169 bits, which exceeds the 160-bits found in a Bitcoin address." But practically this doesn't make 30-char-minikeys more secure than 160bit bitcoin addresses, as only the 160bit bitcoin addresses are being used within the network anyway, right? --[[User:T X|T X]] 00:44, 10 November 2011 (GMT)

= PBKDF2 =

Is HMAC−SHA1 or HMAC−SHA256 being used? --[[User:T X|T X]] 01:01, 10 November 2011 (GMT)

Talk:Mini private key format

2011-11-10T01:01:05Z

T X:

Talk:Mini private key format

2011-11-10T00:44:06Z

T X: