ビットコインを贈り、販売を阻止する方法

もう誰もが知っているように、ビットコインの本当の価値は、少なくとも5年間という長期にわたって保有することで生まれます。受取人にその能力がある場合、ビットコインを贈ることは価値があるので、ここではビットコインを贈り、販売を思いとどまらせるための簡単なトリックをいくつか紹介します。

People who receive bitcoin as a gift may not appreciate the value of holding for the long term, especially if they are used to day trading or if they have a short time horizon. Here are some ways to gift bitcoin and discourage the recipient from selling it prematurely.

ビットコインをギフトとして受け取った人は、特にデイトレードに慣れている場合や期間が短い場合、長期保有の価値を理解していない可能性があります。ここでは、ビットコインを贈り、受取人が早まって売却するのを防ぐいくつかの方法を紹介します。

Keep The Key Yourself

鍵は自分で保管してください

The simplest solution is to gift the bitcoin but keep the private 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.

最も簡単な解決策は、ビットコインを贈呈しますが、秘密鍵は保持しておくことです。時間が来たら、受信者はあなたに鍵を要求することができ、あなたが望むならそれを提供することができます。あなたは鍵を持っているので、ビットコインを使う権限を与えていないので、ある意味ではビットコインをまったく贈っているわけではありません。しかし、誰が気にするでしょうか？ほとんどの人は、ビットコインを受け取り、新しいビットコイン アドレスとそこにロックされているビットコインについて聞くと喜んでいるでしょう。これの良い点は、将来キーを取得するために任意のインセンティブ スキームを課すことができることです。たとえば、子供にとっては、「中学校のチェストーナメントで優勝する」、「総代になる」、または「スタートアップで最初の 100 万ドルの収益を生み出す」などが考えられます。自分でビットコインを使わないよう規律を正す必要があるだけです。

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.

より所有感を高めるには、キーの半分を受信者に渡し、残りの半分を自分で保管することができます。たとえば、24 個のシード フレーズのうち 12 個を与えることができます。そうすることで、たとえ実際に所有権を持っていないとしても、彼らはより多くの所有権を持っているように感じます。

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!

これをさらに挑戦的にしたい場合は、24 のシード フレーズのうち 20 を彼らに与えて、秘密キーを解読できるかどうかを確認することができます。十分なシード フレーズを指定すると、これは総当たりによって計算的に実行可能になります。彼らはそれを行う方法を見つけ出す必要があるだけです。コードの学習を奨励するこれ以上の方法はあるでしょうか?仕事の証拠！

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.

彼らにビットコインをマルチシグアドレスに渡し、一方の鍵を彼らに与え、もう一方の鍵を保持することができます。これは、上記のシード フレーズを使用して分割するよりも簡単です。 1 つのキーを与えると彼らに所有権の感覚が与えられ、残りのキーを保持して上記のインセンティブ構造のいずれかを使用することができます。たとえば、お父さんとお母さんがそれぞれ 1 つの鍵を持っていて、もう一方の鍵を子供にいつ公開するかについてのしきい値を設定する場合、これは機能します。

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.

ビットコインには、トランザクションの時間を遅らせるネイティブな方法、つまりトランザクション内の nLockTime フィールドがあります。これにより、ブロック 100 万など、特定のブロックの高さをクリアするまでブロックに含まれないビットコイン トランザクションを作成できます。これはビットコインの優れた機能であり、最初から存在していました。タイムロックは、ハッシュ タイムロック コントラクト (HTLC) を介したライトニング ネットワークと、Taproot の劣化したマルチシグ スキームで使用されます。これらは、プログラム可能なお金の非常に優れた機能です。

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.

タイム ロックの欠点の 1 つは、トランザクションの作成者が希望に応じて、タイム ロックの前に常に入力を別のトランザクションに費やすことができることです。アリスがボブに、100 万ブロック後にのみ有効になるトランザクションで 1 ビットコインを与えたとします。アリスはこの取引をボブに渡します。ボブはそれをブロードキャストできますが、タイムロックのためにそれを検証するノードはなく、マイナーもそれをブロックに含めないため、この贈り物に資金を提供しているアリスのトランザクション出力は未使用のままになります。

Before block s1 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.

ブロック s100 万の前に、アリスはキャロルに同じ UTXO で資金を提供する 2 番目のトランザクションを書き込むことができます。そのトランザクションに以前のタイムロックがあるか、まったくタイムロックがない場合、キャロルはそれをネットワークにブロードキャストして、ボブに渡す予定だったビットコインを要求することができます。ボブがブロードキャストしようとしても、受信できるビットコインはありません。

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.

数年前、ビットコインには「チェックロック時間検証」（CTLV）と呼ばれるソフトフォークがあり、トランザクションだけでなく実際のトランザクション出力もロックすることでこの問題を解決しました。これはより複雑な解決策ですが、ここでは説明しません。

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.

タイムロックには別の問題があります。アリスがボブのためにタイムロックトランザクションを作成するとき、トランザクション手数料を指定する必要があります。これらの手数料を短期的に予測するのは簡単ですが、長期的には将来の取引手数料がどのようになるかを知るのは困難です。料金を過小評価すると、料金が低すぎるため、ボブはネットワーク上でトランザクションを確認できなくなる可能性があります。料金を過大評価すると、マイナーに過剰な料金を支払うことになりますが、おそらく問題は大きくなりません。数年先のタイムロックでは問題にならないように思えるかもしれませんが、50年後に孫にビットコインを送ることを想像してみてください。いずれにせよ、ビットコインのタイムロックを利用することは興味深い機会であり、これを行う企業が増えれば、お金の真のプログラマビリティの一部を解き放つことができると思います。

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

ここでの 1 つの回避策は、Alice が複数のタイムロックされたトランザクションを作成することです。各トランザクションは同じ UTXO から送信され、ボブのアドレスに送信されますが、それぞれのトランザクション手数料は異なります。