Giving Bitcoin as a Gift, Initial Thoughts

 'Tis the season and I'm thinking about how to give bitcoin as a gift, to non-technical people, without requiring them to do anything like create an account or download software in order to accept it.

Paper Wallet

Bitcoin paper wallets have been around a long time.  The concept is simple.  Generate a send/receive address pair (private/public key pair) and print them on a piece of paper.  Basic operations:

  • To add bitcoin to the wallet, send some bitcoin to the receive address
  • To check your balance, type or scan the public key into any blockchain explorer 
  • To gift that bitcoin, just hand over the piece of paper
  • To send the bitcoin on the blockchain, type or scan the private key into the bitcoin wallet software of your choice

Pros:

  • simple, no fancy hardware or software required for them to receive the bitcoin
Cons:
  • No guarantee that the giver didn't keep a copy of the private key
  • Private key could be easy for someone else to see/copy
  • Private key could be easily lost
  • If you want to add more funds, you have to reuse the same receive address, which is bad for privacy

Hardware "paper" Wallet

There is a hardware solution to the first problem, the Opendime. It's essentially the same thing as the paper wallet, except it generates the key pair and keeps the private key hidden until you mechanically alter the device.  If someone gives you an Opendime, it's easy to see that they have not altered the device and seen the private key.  It has the same address re-use downside of the paper wallet.  It's also pretty expensive if you just want to give a kid $5 worth of bitcoin.  Even more so if you want to give a bunch of nieces and nephews bitcoin!

I thought more about keeping the private key private and realized that some niece or nephew is likely to lose either a piece of paper or an Opendime and then come to me and ask what they can do to recover their bitcoin.  I think that in this scenario of mine, it would be best if I did keep a copy of the private key someplace safe.  That turns the first con into a pro!

Full Hardware Wallet

For my own private keys, I use a Trezor hardware wallet.  It generates the private key on the device and never lets anyone see it, except once at setup time in the form of a backup seed phrase.  It uses the Hierarchical Deterministic Wallet (HD Wallet) structure, which is really cool.  You can generate a sequence of private keys and corresponding public keys from the main private key that comes from the seed phrase.  You can also generate a sequence of keys under each of those keys, making them parent keys of a bunch of other keys (thus, hierarchical).  But the really cool part is you can generate just the sequence of public keys from a given public key, no private keys have to be involved in that calculation.

A practical example of why this is great.  I use Swan Bitcoin (affiliate link, we each get $10 if you sign up with it) to buy my bitcoin.  Swan automatically transfers the bitcoin from their account to mine on a regular basis.  I could give them a single public-key (address) that they always use for those transfers, or, I can give them a public-key from my hierarchical wallet and they can generate a series of public keys to send the bitcoin to, using a new key each time.  This eliminates address reuse and I don't have to manually give them a new key for each transaction.  If I keep that public key private between me and them, then nobody knows that each of those transactions from Swan are going to me.

Back to giving bitcoin as a gift.  I could give each person a parent public key from my Trezor.  There is a nice bitcoin wallet app called BlueWallet that also knows how to do the HD Wallet thing that they can use to manage the public keys.  That would keep the private keys totally safe.  I could still print the master public key onto a piece of paper.  The basic operations become:

  • To add bitcoin to the wallet, type or scan the main public key into BlueWallet, get the next public key (receive address), send some bitcoin to the receive address
  • To check your balance, type or scan the public key into BlueWallet
  • If you want to gift that bitcoin, just hand over the piece of paper
  • To send the bitcoin on the blockchain, they have to call me up and I have to use the Trezor to send it

Pros:

  • Simple, no fancy hardware or software required for them to receive the bitcoin
  • No address reuse
  • Private key is safely backed up with me

The downsides to this are:

  • They have no control over the private key

That is a pretty big downside, they really don't own the bitcoin.

HD Paper Wallet

Once I figured out this whole seed phrase and HD wallet thing, I came up with another idea.  I could generate a seed phrase and the corresponding master public and private key pairs and give them those.  I'd keep a copy of the seed phrase myself just in case they lose it.  Now the operations become:
  • To add bitcoin to the wallet, type or scan the main public key into BlueWallet, get the next public key (receive address), send some bitcoin to the receive address
  • To check your balance, type or scan the public key into BlueWallet
  • If you want to gift that bitcoin, just hand over the piece of paper
  • To send the bitcoin on the blockchain, type or scan the main private key into BlueWallet

Pros:

  • Simple, no fancy hardware or software required for them to receive the bitcoin
  • No address reuse
  • Private key is backed up with me

The downsides to this are:

  • Private key could be easy for someone else to see/copy
  • Private key could be easily lost

I feel like this is the best compromise.  There is one more downside.  No websites or tools exist to make a pretty paper wallet out of HD wallet master public and private keys.  I'm going to have to make that on my own.

Any thoughts?  Please let me know in the comments.  I sometimes think I'm over complicating this with the HD wallet.  Who cares that much about a little address reuse?  I like the tech (math, really) of the HD wallet though.  Or maybe the Trezor is the best way?  That keeps the private keys safest.  They can check their balance with their public keys and feel like they own it.  Is that good enough?

Comments

Post a Comment

Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either. I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor. OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this: module top; task do_stuff ( int wait_time); #wait_time $display ( "waited %0d, then did stuff" , wa...
Read more

'git revert' Is Not Equivalent To 'svn revert'

I just learned that if you have some changes in your working tree that you want to get rid of, you don't type 'git revert' like you might guess. No, that's what cvs, subversion, mercurial, and bazaar (to name a few) use revert to mean, but not git. With git, revert is used to undo actual commits. Thankfully, you can undo your revert with another 'git revert', I just learned. So let me repeat to be clear, if you have changes to your working files that you want to abandon, DO NOT do this: git revert HEAD That will undo your last commit. Do this instead: git reset --hard HEAD I'm glad I have that straightened out now. I'm wondering if /etc was really a good place for me to start out playing with git. UPDATE: Nearly two years later and I'm still getting comments on this. I'm glad I've been able to help people out this way. The discussion in the comments is good, and one thing I'd like to point out is that I now always use...
Read more

SystemVerilog Streaming Operator: Knowing Right from Left

SystemVerilog has this cool feature that is very handy for converting one type of collection of bits into another type of collection of bits.  It's the streaming operator.  Or the streaming concatenation operator.  Or maybe it's the concatenation of streaming expressions (it's also called pack/unpack parenthetically).  Whatever you want to call it, it's nice.  If you have an array of bytes and you want to turn it into an int, or an array of ints that you want to turn into an array of bytes, or if you have a class instance that you want to turn into a stream of bits, then streaming is amazing.  What used to require a mess of nested for-loops can now be done with a concise single line of code. As nice as it is, getting the hang of the streaming operator is tough.  The SystemVerilog 1800-2012 LRM isn't totally clear (at least to me) on the details of how they work.  The statement from the LRM that really got me was this, "The stream_operator <...
Read more