Bitcoin Digital Investment
As we all know by now, the real value of bitcoin comes from holding for a long period and time horizon, at least five years. Gifting bitcoin can be valuable if your recipient has that ability, so here are some simple tricks to gift bitcoin and discourage selling.
Keep the key yourself
The easiest solution is to gift the bitcoin but keep the key. When the time comes, the recipient can request the key from you, which you can furnish if you want. Since you have the key, in a sense you’re not gifting the bitcoin at all since you’re not granting the ability to spend the bitcoin. But who cares? Most people will be happy to receive the bitcoin and hear about their new bitcoin address and about the bitcoin that is locked in there. The nice thing about this is you can impose whatever incentive scheme you like to get the key in the future. For example, for kids, it could be “win the middle school chess tournament,” “become valedictorian,” or “generate your first $1 million in revenue in your startup.” You just need to be disciplined not to spend the bitcoin yourself.
Keep part of the key
To give more of a sense of ownership, you could give half of the key to your recipient and keep the other half yourself. For example, you could give them 12 of the 24 seed phrases. This way they feel like they have more ownership, even though they don’t.
If you wanted to make this more of a challenge, you could give them 20 out of the 24 seed phrases and then see if they can crack the private key. When you give enough seed phrases, this is computationally feasible by brute force. They would just need to figure out how to do it. What better way to incentivize learning to code? Proof of work!
Lock the Bitcoin in a Multisig
You could give them bitcoin into a multisig address and give them one key while you keep the other. This is easier than using and splitting the seed phrase above. Giving them one key gives them a sense of ownership, and you could keep the remaining keys and use any of the incentive structures above. For example, this would work if mom and dad each had one key, and they each got to set their thresholds for when to reveal the other key to the kid.
Write a time-locked transaction
Bitcoin has a native way to time delay a transaction, the nLockTime field in the transaction. This allows you to create a bitcoin transaction that will not get included in a block until it clears a certain block height, like block 1 million. This is a cool feature of Bitcoin that was there from the beginning. Time locks are used in the lightning network through hash time-locked contracts (HTLCs) and in degraded multisig schemes in Taproot. They are a really cool feature of programmable money.
One wrinkle with time locks is that the person creating the transaction can always spend the inputs in another transaction before the time lock if he or she wants. Suppose Alice gives Bob one bitcoin in a transaction that will activate only after block 1 million. Alice gives this transaction to Bob. Bob can broadcast it, but no node would verify it and no miner would include it in a block because of the time lock, so Alice’s transaction output that is funding this gift remains unspent.
Before block 1 million, Alice could write a second transaction to Carol funding it with the same UTXO. If that transaction has an earlier time lock or none at all, then Carol could broadcast it to the network and claim the bitcoin that was meant for Bob. When Bob tries to broadcast, there would be no bitcoin to receive.
There was a soft fork in Bitcoin a few years ago called “check lock time verify,” CTLV, that fixed this problem by locking not just the transaction but the actual transaction output. That’s a more complex solution that I won’t get into here.
There is another issue with time locks. When Alice creates the time-locked transaction for Bob, she needs to specify the transaction fees. It’s easy to forecast these fees in the short term, but in the long term, it’s hard to know what future transaction fees will be. If you underestimate the fees, then Bob may never be able to confirm his transaction on the network because the fees are too low. If you overestimate the fees, then you’re overpaying the miners, which is probably a lesser problem. This may not seem like a problem for time locks a few years in advance, but imagine sending bitcoin to your grandkids in 50 years. Regardless, I think making use of time locks in bitcoin is an interesting opportunity, and more businesses that do this can unlock some of the true programmability of money.
One workaround here is for Alice to create multiple time-locked transactions. Each transaction is sourced from the same UTXO and sent to Bob’s address, but each has different transaction fees, ranging from low to high. Alice can give them all to Bob, knowing that only one will confirm, since nodes check for double-spending. The transaction that confirms will automatically invalidate all the others, similar to what happens in Lightning with older transactions reflecting outdated channel balances.
