Casascius 2-Factor Physical Bitcoin

[casascius]

One of the simplest ways I could bring practical 2-factor to the masses is to just start including public keys on paper QR codes with my coins.  

Then, someone could use a 1 BTC coin as the "second factor" for any number of paper wallets they print themselves.

Given a public key, I could also offer to provide (sell) a certificate that gives a bitcoin address and certifies that "your key" plus the key in "this coin" results in the private key for "this address".  (I'd charge for this mainly because I would have to hand-type a pre-printed private key into a computer in order to produce it, before making a coin with it)

I kept the public keys for my series 2 coins on a flash drive (though I'm not entirely sure where, so don't quote me on this yet).  I don't want to publish the public keys for the whole set into the wild, but would entertain requests for public keys for single coins for those who would like to use a coin for this purpose.

(I only have public keys for series 2 coins in my most recent batch where I thought to keep them for this very purpose - the ones that start with 1ca, 1cc, 1cs, 1ag, etc.)

[casascius]

Why is this better than me sending you a bitcoin address to send coins to? I still have to keep the privkey

It's better if you're someone who isn't a computer expert and you want to hold some bitcoins but you want to outsource all of the risk management to a neutral third party without leaving them in a position to scam you.

Imagine you're a hedge fund manager and you decide you want to acquire some bitcoins on behalf of your clients but are hesitant because you're not sure how or you're afraid you might lose your clients' funds due to a technical error.  Buying a $50 bitcoin wallet that comes with a warranty and solves all of those problems is a great solution to a person like that.  They would still have to generate a key, but the average person should have no problem visiting a web page, printing it out, stashing it securely, and faxing me the half I need to produce their piece.

[TTBit]

I don't understand the math:
Is there a way to prove that the funded address is correct, without having to actually put the two private keys together?

[casascius]

I don't understand the math:
Is there a way to prove that the funded address is correct, without having to actually put the two private keys together?

Yes, if I provide the public key corresponding to what's inside the coin, and you combine it with your private key.

Either Public Key + Other Private Key => Combined Public Key and Bitcoin Address

Private Key + Other Private Key => Combined Private Key, Public Key, and Bitcoin Address

[adamas]

Casascius' work is definitely a gain for the community.

[Steve]

I don't understand the math:
Is there a way to prove that the funded address is correct, without having to actually put the two private keys together?

Yes, if I provide the public key corresponding to what's inside the coin, and you combine it with your private key.

Either Public Key + Other Private Key => Combined Public Key and Bitcoin Address

Private Key + Other Private Key => Combined Private Key, Public Key, and Bitcoin Address

But that doesn't prove that the private address under the sticker is the correct one.  For that, you have to place trust in the manufacturing process. 

I would almost say that the codes on the coin should all be viewable such that the person buying them can verify that all of the codes are readable and correct before loading them with funds.  The objective of these coins is that you can secure the coin and the second private key separately (such that it would be worthless for someone possessing one without the other), so I don't think concealing the private key on the coin is important for this use case.  The possessor of the coins would presumably secure these coins themselves (concealing all the information on them) since they aren't really designed for commerce.

Can the second private key be one derived from a memorized password and the public key (or hash of it) on a coin?  You want to mix the password with something from the coin such that the second private key is unique for every coin.  That would make this a true two factor coin where you need a secret that you possess (the private key on the coin) and a secret that you know (the memorized password that can be used with codes on the coin to generate the second private key).

Lastly, I think you may want to consider making these in a different form factor…instead of a coin, use thick card stock where you can print instructions on it.  You could deliver the pre-printed cards with the address and private keys printed on them and easily readable and verifiable by the buyer.  Once verified, the buyer could fold the card, hiding the private key and affix some kind of tamper evident seal.  From that point forward, the buyer has confidence that the codes on the card are correct and that any funds sent to the address can be successfully redeemed.  People might even want to buy multiple copies of each card such that they can store them in multiple locations to mitigate the risk of theft or damage.

[casascius]

But that doesn't prove that the private address under the sticker is the correct one.  For that, you have to place trust in the manufacturing process.  

For the gold bar, I used a non-windowed sticker, mainly with the thought that I don't want someone accidentally thinking they should send BTC to the visible firstbits.  But then I thought of another idea: if I were to do another one like this, I'd black out the first three characters (so for example instead of seeing "1Cs55Txg" one might see just "55Txg").  This would be enough to identify, at the very least, that I have put the "correct" key circle under the sticker, removing one major human element out of the trust equation, and limiting it to whether the key circles were printed correctly (something I have a very high degree of confidence in, since I produced them with an overkill of caution every step of the way, and I don't lose any sleep over the thought of putting 1000 BTC on one).

If I sold a $50 gold plated brick, part of what is being bought and sold is my assertion and warranty that the private key I say I put under the sticker is really there and corresponds to the public key I say it does, which I could offer in writing.  If sold to an institutional buyer, their interest may not be so much in the ability to verify the bar as correctly produced, but the fact that they have a place to point a finger and an avenue for recourse if anything were to go wrong.

Can the second private key be one derived from a memorized password and the public key (or hash of it) on a coin?

Absolutely.  And it's probably a better way to go, as well as having a little bit looser requirements than a strict brainwallet, since I'm the only possible attacker they need protection from, rather than a whole world's worth of GPU crackers.

Lastly, I think you may want to consider making these in a different form factor…instead of a coin, use thick card stock where you can print instructions on it.  You could deliver the pre-printed cards with the address and private keys printed on them and easily readable and verifiable by the buyer.

In essence, I've just about already done this, with the right price tag to boot: free.  You have described the equivalent of my banknote printer program downloadable at https://casascius.com/btcaddress.zip.  It already supports producing password-protected banknotes.  Simply print on cardstock and add a tamper-evident sticker and you have it now.

[Steve]

If I sold a $50 gold plated brick, part of what is being bought and sold is my assertion and warranty that the private key I say I put under the sticker is really there and corresponds to the public key I say it does, which I could offer in writing.  If sold to an institutional buyer, their interest may not be so much in the ability to verify the bar as correctly produced, but the fact that they have a place to point a finger and an avenue for recourse if anything were to go wrong.

Yes, that's all true, but if it's not adding anything to the security or usability, then why introduce this additional bit of counter party risk?  A prudent user of your service would need to factor in the odds that you might screw up a coin as well as the likelihood of recovering the lost funds.  And you would need to place some caps on the liability (what if someone loaded $10 million worth of bitcoins onto a faulty coin?  would you cover that loss?).

[casascius]

If I sold a $50 gold plated brick, part of what is being bought and sold is my assertion and warranty that the private key I say I put under the sticker is really there and corresponds to the public key I say it does, which I could offer in writing.  If sold to an institutional buyer, their interest may not be so much in the ability to verify the bar as correctly produced, but the fact that they have a place to point a finger and an avenue for recourse if anything were to go wrong.

Yes, that's all true, but if it's not adding anything to the security or usability, then why introduce this additional bit of counter party risk?  A prudent user of your service would need to factor in the odds that you might screw up a coin as well as the likelihood of recovering the lost funds.  And you would need to place some caps on the liability (what if someone loaded $10 million worth of bitcoins onto a faulty coin?  would you cover that loss?).

Why introduce the risk?  Because it's the product the customer wants to buy, the reason they'd want to spend $50 on something they could print themselves for free with a web browser.  A rational user of my service will consider that given a strong incentive to make sure I produced a functioning piece and no incentive to not do so, the likelihood that I will do so is overwhelmingly high.

I am not worrying that someone loads $10 million on to a faulty bar, because if I'm going to offer a warranty like that, I can choose to be careful enough to make sure the item isn't faulty.  It's just a piece of paper with two numbers on it, one of which is partially visible and can be independently verified.  Unlike an electronic gadget or product that does something, it's not likely to fail in any manner that could be considered my fault.  The only thing I had to be absolutely sure of is that what is printed on the front matches what's printed on the back and that I haven't been sloppy with copies.  I can't warrant that the piece is uncrackable or that it isn't vulnerable to some sort of high-tech imaging or whatever, but I can warrant that I put in it what I said I did and that it was good at the time of delivery.

Of course, I'm more willing to offer that on the series 2 windowed items rather than the ones that are completely covered.  Granted, there's maybe a 1/1000 or 1/5000 chance that despite printing everything in sequential order to keep it as simple as possible, I simply put the wrong private key inside a series 1 coin.  This error could occur simply because the label and key has to be matched by sight and human error rate is never zero, a risk that is still mitigated in practice by the most likely error being a transposition and that the wrong key still has 1 BTC on it.  But on the series 2 coins, that risk doesn't exist, or at least is fully within my control.

Restaurant owners have it worse.  On any given day, some 16-year-old new-hire could decide to play a vicious prank without thinking through the consequences and put something in a taco that turns somebody into a vegetable and runs up $10 million in medical expenses, pain, suffering, attorney bills, negative PR, and lost business.  They are exposed to this risk again and again each day they do business (though naturally they buy insurance for the part of it that they can be billed for).  My exposure was limited to spending 1 day designing and printing less than 100 sheets of paper and hand-inspecting each one to make sure each sheet satisfied a list of criteria to assure me each key was safe to put money on before placing the sheets into a laser cutter and turning them into circles.  The next time I need to print more, I'll probably block off another whole day to do it, just to give myself the means to know I did it right.

EDIT: here is another way to put it, while still acknowledging that the error rate is nonzero (assuming, for example, a cosmic ray could flip a bit in my printer and make it print the wrong thing - or that I could make a mistake no matter how careful I was and how much thought I put into it):

if it's a $50 product, let's assume my profit is half, and the typical clearly-my-fault major error could be a $50,000 liability.  (that's not to discount that $10M is possible, but it's probably on the high end of the spectrum, and quite honestly, someone with a $10M budget for bitcoins will probably do more due diligence than just buying and loading my bar and will probably employ someone to manage them).  That means I would have to sell 2000 bars to absorb the losses of one bad bar.  If I think my risk of making a faulty bar is much less than 2000:1, then selling bars for $50 should be a great bet for me to make.

Meanwhile, I haven't drafted that kind of document that would constitute any such "warranty", but if I were to put a specific dollar amount on it, I'd be limiting my liability at the same time offering some sort of meaningful guarantee.  Bottom line is though, I believe I can produce those bars with enough accuracy that it would be like selling life insurance to the immortal: profitable no matter what price is charged.  It is a guarantee I believe I will never have to pay out on.

[molecular]

So the customer still has to secure a piece of paper (with priv1) somewhere.
What exactly is the benefit of the coin? You lose the printout, you lose it all. Just like before, when people may use a paperwallet.
The benefit of the original Casascius coin was, for me, to have the funds in a, well, coin? Which may or may not be more robust and easy to lose than a printout..

This hasn't been answered directly, I think: The benefit is that - as opposed to the situation with the normal coins - casascius has no incentive to keep the private key... in fact he doesn't have it. The only thing he could do to screw the customer over would be to omit the half of the key he generated from the coin (or put a wrong key-half into the coin). The incentive for this is negative: he wouldn't gain access to the funds (as he could with "traditional" coins).

So this coin is more secure against theft by Mike, but less secure against loss by loss of key.

;tldr: benefit of this coin is: casascius can't steal your money.

[casascius]

I have recently improved this by introducing BIP 38 and a working proof-of-concept implementation of it.

https://en.bitcoin.it/wiki/BIP_0038

Instead of keeping a whole private key (51+ characters), you can instead keep just the password/passphrase of your choice, which serves as the second factor.

This is a whole lot easier to keep around.  You can engrave it on a gold-plated bar, or include it on a small card inside the presentation box of a gold coin.  Best yet, it uses a very slow variant of "scrypt", so even an 8 character password will provide a decent amount of security.  It only has to be kept secret from the maker of the coin (me), and can be publicly displayed to everyone else...  A Bitcoin-related phrase could be used as a passphrase that displays well, such as "Money of the 21st century"

[stalker00075]

I have recently improved this by introducing BIP 38 and a working proof-of-concept implementation of it.

True. I forgot that random letters have a magnetic quality that pulls the two halves of the letter b (but not d) apart, making it confusing like this. And the research probably shows that 1 and l don’t have this problern, loecause they are all one piece. Good call

help me please
need get address of the private key

Code:

import random
import hashlib

BASE58 = '23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

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

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

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

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

now
SKhHHQLDkHsAniFW2MRyVw9jwDDkKx
SHA256( ): ae172028e80ef37d3e01906ccd05441946c3efa9e4532ab20f5a6e25ce293840
sha256(?): 0057497a02482464d757500773d3d2c26badbcd94d5081d1cff9ea7c16fd2175
Validated.

need
SKhHHQLDkHsAniFW2MRyVw9jwDDkKx
SHA256( ): ae172028e80ef37d3e01906ccd05441946c3efa9e4532ab20f5a6e25ce293840
sha256(?): 0057497a02482464d757500773d3d2c26badbcd94d5081d1cff9ea7c16fd2175
Address: 17bYqJpPz3huoXuz6Dx6iLejuAHA2k2q3H
Validated.