Using Locktime for inheritance planning, backups or gifts

[LoyceV]

TL;DR
As a bad-case-scenario backup, you can create a signed transaction that's only valid several years in the future, and sends your funds to an unencrypted wallet under your control.
If you ever need it, all you have to do is wait until you can broadcast the transaction.

Long version
I'll start by quoting myself:

~why would you give your family access to your Bitcoins? If it's meant for the "hit by a bus scenario", there might be another option. I've been thinking about this for a while now, but haven't actually used it:
1. Print a normal paper wallet.
2. Sign a transaction to send funds from your cold storage to the normal paper wallet, but add a Locktime so it's only valid from a block far far in the future. Say 1 million block count or even more (but not so far none of your family members will still be alive). Or while you're at it: create a few versions (1 million blocks, 1.5 million, 2 million) and print them on different sheets of paper.
3. Print the transaction and store it with the paper wallet.
4. If you're still alive a couple of months before the first transaction becomes valid: burn it, the next one becomes your new fail safe.
If your family ever needs it, all they have to do is wait a few years, broadcast the transaction, and the paper wallet becomes valuable.

I brought this up in another topic, and received more support than I expected. Hence the dedicated thread

Note: I haven't used this yet for a real application, it's only meant as a proof of concept.

Example
Address: 1GiL5Chm7qM9aV7xXWiAVKp7VnKPps13x8 (Balance: ) (HODL storage)
Private key: KxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxHw
This is the address in super secret private storage that only I can access.

Locktime Recovery Sheet
The following information including images is printed on the Locktime Recovery Sheet, together with it's private key and QR-codes. Whoever gets access to this paper after the Locktime expired, gets access to the funds. So keep it safe!

** start locktime recovery sheet **
Address: 1Kx5kYqStfhPQntRv185pTuyafLoaYLrV7 (Balance: ) (Recovery)
Private key: L3YR5E2NrGVXViKNBUGeBjmHxEFgEHkg5QJ9XS67YZJ6f1EyZFny



Signed Recovery Transaction

Code:

010000000126063a71fecd0c76fa7d31a561cbe95bf2c7e5da01ae04fed6a6e9dfbc80953e010000006a47304402201a16d89264518baca8f4959b446372c6ce91e8d1fbc0b7b48618aeb76113df33022040eb804bf7cd6519d01709066658251cef1822ff49fd07707e058a07b27b42f9012103f78766b4346bcec0f2ae92d7e132e6b321c47627f14356a704b3ce57169dcb4e000000000116260000000000001976a914cfdd1b997472bd0b668e7472d9708305f116994d88acc0270900

This transaction is valid from Block 600,000 (slightly less than 50 days from now).
** end locktime recovery sheet **

(to create this example, I ignored all proper security measures and used Bitaddress.org and Coinb.in online. That's why I only used 0.0001BTC for this example. This is very bad practice to do for anything with value. Take precautions!)

Precautions
Create this on an offline system that won't go online again afterwards. Use for example Ubuntu or Knoppix from a LIVE DVD without ethernet/Wi-Fi, and use a dumb printer that doesn't store anything.
Don't use an online website to generate QR-codes.
It's probably wise to leave some instructions for whoever is going to use your Locktime Recovery Sheet in the future. He or she should understand the importance, so it's not just dismissed by someone who doesn't know anything about Bitcoin.
Verify the signed transaction (offline!) to ensure it does what you want it to do.

Different versions
Since you don't know how long it will be before anyone needs this, you can quite easily create a few different versions with different Locktimes. A couple of months before each one of them would become valid, you can simply burn the paper and the next one takes it's place.

Risks
You should only do this if you know what you're doing! It's meant for long-term HODL funds, and you should know the pre-signed transaction becomes invalid the moment you move any of the input funds. You should also know any newly added funds won't automatically be added to your Locktime Recovery Sheet. You have to keep track of this by yourself.
We can't predict transaction fees in the future, so you'll have to take a guess there. There's no need to make it very high, because the receiver can always use CPFP if needed. It shouldn't be under the minimum though.
Don't accidentally set a Locktime many centuries ahead!
You may miss out on possible Forkcoins that use proper replay protection.

Giveaway
Another use I could think of, is when you give away some amount of Bitcoin for some occasion. Let's say a family member gets a baby, and you want to give the kid $100 in Bitcoin, but you don't want to risk it never being used. You can fund a good looking paper wallet, and give the parents the instruction to give it to the kid when he/she turns 18.
You keep a Locktime Recovery Sheet with Locktime 25 years in the future, and if the kid doesn't use the funds (by then hopefully worth a small fortune), you'll take it back after 25 years.
If you don't trust the parents not to touch it, you can give them a Locktime Recovery Sheet with a Locktime 18 years in the future, and keep one with a Locktime 25 years in the future for yourself. That way (when properly generated), nobody can access the funds earlier.

No spam
Please
On-topic posts are welcome!

[1715323342]

1715323342

[1715323342]

1715323342

[1715323342]

1715323342

[1715323342]

1715323342

[hatshepsut93]

What if I don't have a printer, don't want to buy a printer and don't trust any third-party printers ever? Mnemonic seeds allow me to make paper wallets with pen and paper, is there anything like that for raw transactions? I guess I could just send them the signed transaction via the Internet, and give them the seed of the wallet that has the receiving address on paper. Or I could give them everything on a flash drive. Anyone has some other ideas?

[pooya87]

you should really know what you are doing though, otherwise you may lock up your funds for eternity or sign a transaction that is not valid until hundreds of years. i did something like that recently on testnet because i didn't know about BIP68 and relative locktime, which is for version 2  transactions and the Sequence starts having a more complicated meaning (still haven't read about it though).

(to create this example, I ignored all proper security measures and used Bitaddress.org and Coinb.in online. That's why I only used 0.0001BTC for this example. This is very bad practice to do for anything with value. Take precautions!)

you could've used TestNet to save on precious bitcoins and fees and also don't create unnecessary transaction on the main blockchain. run bitaddress.org html or open the website by adding "?testnet=true" to the end. and go to https://coinb.in/#settings and set the network to Bitcoin(testnet)

We can't predict transaction fees in the future, so you'll have to take a guess there.

you could also sign with ALL | AnyoneCanPay flags so that in the future they could add an input to your signed transaction to cover the fee.

[Kakmakr]

OP, in your title, you mention doing this for inheritance, but most people do not know when they are going to die. In what type of scenario would you apply this for inheritance planning? I know some people become terminally ill <cancer> and they would welcome something like this, but how do you notify people that does not know a thing about Crypto currencies, to manage this?

I would like to see a time-locked paper wallet service that would automate a process that sends bitcoins to a wallet that I have given to people in advance <while I am still here to explain things> and when I pass on, the bitcoins will be transferred to that Bitcoin address.

Obviously this must be linked to some Smart contract and not a third party service that might steal those coins. Do you think that might work?

[LoyceV]

What if I don't have a printer, don't want to buy a printer and don't trust any third-party printers ever? Mnemonic seeds allow me to make paper wallets with pen and paper, is there anything like that for raw transactions?

You could write it down, but it's extremely unlikely not to make any mistakes (hence the QR-code).
Without a printer, this isn't for you

you should really know what you are doing though, otherwise you may lock up your funds for eternity or sign a transaction that is not valid until hundreds of years.

You'll still have your original storage, and this doesn't have to be the only system you use.

you could've used TestNet to save on precious bitcoins and fees and also don't create unnecessary transaction on the main blockchain. run bitaddress.org html or open the website by adding "?testnet=true" to the end. and go to https://coinb.in/#settings and set the network to Bitcoin(testnet)

You're right It's just that I'm so used to using real Bitcoin.

you could also sign with ALL | AnyoneCanPay flags so that in the future they could add an input to your signed transaction to cover the fee.

I didn't even know SIGHASH_ANYONECANPAY exists. But it makes it more complicated.

OP, in your title, you mention doing this for inheritance, but most people do not know when they are going to die. In what type of scenario would you apply this for inheritance planning?

I can think of a few scenarios: If you have young kids, set the first Locktime around 15 years in the future. You'll need someone trusted to ensure your kids get it when they're older.
Or just make 10 copies: 10, 20, ..., 100 years in the future. Chances are you'll die eventually, so if you never use your funds, someone can use it.

I know some people become terminally ill <cancer> and they would welcome something like this, but how do you notify people that does not know a thing about Crypto currencies, to manage this?

It can be as simple as a letter in a safe in your home.

I would like to see a time-locked paper wallet service that would automate a process that sends bitcoins to a wallet that I have given to people in advance

The reason I choose to include the paper wallet with the signed message, is so you don't have to trust they still have it after 10/20/40/60 years.

Obviously this must be linked to some Smart contract and not a third party service that might steal those coins. Do you think that might work?

As far as I know, that's not possible in Bitcoin.

[pooya87]

I didn't even know SIGHASH_ANYONECANPAY exists. But it makes it more complicated.

it actually is a very easy thing to use. it's just that no wallet implements it, even bitcoin-core only supports it if you use its debug window (command line). it basically is creating a transaction that may or may not have more inputs added later. using it with Sighash_All you ensure that your outputs remain the same. or you could add Sighash_Single so that you sign one output and make sure that remains the same but still leave room open for cases if the other inputs added had a higher value so the "change" could be sent to a new output.

[Indamuck]

Just share the private key of your funds while you are alive and avoid this complicated mess.  If you can't trust that person enough then you shouldn't be leaving your money to them in the first place.

It is sheer stupidity to ever have something locked for years with no way to get out.  What if bitcoin has another inflation bug that causes a catasrophic decline in price and you need to liquidate immediately.

[TheBeardedBaby]

TL;DR
~
Giveaway
Another use I could think of, is when you give away some amount of Bitcoin for some occasion. Let's say a family member gets a baby, and you want to give the kid $100 in Bitcoin, but you don't want to risk it never being used. You can fund a good looking paper wallet, and give the parents the instruction to give it to the kid when he/she turns 18.
You keep a Locktime Recovery Sheet with Locktime 25 years in the future, and if the kid doesn't use the funds (by then hopefully worth a small fortune), you'll take it back after 25 years.
If you don't trust the parents not to touch it, you can give them a Locktime Recovery Sheet with a Locktime 18 years in the future, and keep one with a Locktime 25 years in the future for yourself. That way (when properly generated), nobody can access the funds earlier.

No spam
Please
On-topic posts are welcome!

Holy Cow!! This is one of the best ways to give a gift to a newborn. I definitely will follow this method to give some babies a better chance for a easy future, I don't need to look for some stupid gifts they gonna trow in a year or two. Great work man, as always!! Just love reading your posts and ideas. Let's spread love and bitcoin

Edit: just shared it on my twitter

[javadsalehi]

I am new to locktime and it is this the first time I've heard about it.
Assume that I have 10 bitcoins and I sign a transaction which will be valid after 5 years from now. If I need money and I want to spend 1 bitcoin, what will happen?
Am I able to make this transaction? If yes, what will happen to that 10 bitcoins transaction?

[LoyceV]

Just share the private key of your funds while you are alive and avoid this complicated mess.

Lol, how about no

If you can't trust that person enough then you shouldn't be leaving your money to them in the first place.

Even if you trust that person completely, you're still introducing another risk factor to lose your funds due to mistakes or theft.

It is sheer stupidity to ever have something locked for years with no way to get out.

That's not what I'm proposing.

What if bitcoin has another inflation bug that causes a catasrophic decline in price and you need to liquidate immediately.

HODL!

Holy Cow!! This is one of the best ways to give a gift to a newborn. I definitely will follow this method to give some babies a better chance for a easy future, I don't need to look for some stupid gifts they gonna trow in a year or two. Great work man, as always!! Just love reading your posts and ideas. Let's spread love and bitcoin

Which one are you going to use? The paper wallet with 25 year Locktime for yourself, or the 18 year Locktime with 25 year Locktime for yourself? The second option makes me feel slightly uncomfortable as I've never actually tested it. Another thing is that the receiving party has to trust you didn't keep a copy of the private key, and they'll only know for sure after at least 18 years! So you should probably only use this for people who trust you.
I'll wait for block 600,000 to happen to test it with the 0.1 mBTC (or see if someone else takes the funds before I do).

Edit: just shared it on my twitter

Aren't you supposed to spam a list of links if you do that?

Assume that I have 10 bitcoins and I sign a transaction which will be valid after 5 years from now. If I need money and I want to spend 1 bitcoin, what will happen?
Am I able to make this transaction? If yes, what will happen to that 10 bitcoins transaction?

As long as you have the private key, you can make any transaction you want. But that will instantly invalidate your Locktime Recovery Sheet, because the inputs don't exist anymore.

[Kakmakr]

OP, I just gave you 2 merit points for this post, because it opened my eyes on the "hidden" potential of some features that I have never experimented before. < Use OP_CHECKLOCKTIMEVERIFY >  I am not a software developer and I always thought some of these features were too difficult for the average Joe to implement, but you made the task very simple with the way you presented it.    

I also never played around with https://coinb.in/ before, because I thought it was just a duplication of other web based wallet services that I used before. I will add this gem to my Crypto favorites.  

Thank you for the feedback on my previous post, it all makes more sense now, after I started experimenting with it in the way you presented it.  

[pooya87]

~ on the "hidden" potential of some features that I have never experimented before. < Use OP_CHECKLOCKTIMEVERIFY >  ~

i think you might have confused what this is. OP's proposal has nothing to do with OP_CHECKLOCKTIMEVERIFY, the output he is spending and the new one he is creating are both simple P2PKH outputs (check the raw transactions yourself).
he is simply using "locktime" (the last 4 bytes of every transaction) alongside non-max sequences to make the new transaction spendable only at a certain block height specified by that locktime.
in this tx:
01000000012<-snipped the middle part->8acc0270900
0270900 is the locktime and is equal to 600000 which is interpreted as the block height.

[TheBeardedBaby]

Holy Cow!! This is one of the best ways to give a gift to a newborn. I definitely will follow this method to give some babies a better chance for a easy future, I don't need to look for some stupid gifts they gonna trow in a year or two. Great work man, as always!! Just love reading your posts and ideas. Let's spread love and bitcoin

Which one are you going to use? The paper wallet with 25 year Locktime for yourself, or the 18 year Locktime with 25 year Locktime for yourself? The second option makes me feel slightly uncomfortable as I've never actually tested it. Another thing is that the receiving party has to trust you didn't keep a copy of the private key, and they'll only know for sure after at least 18 years! So you should probably only use this for people who trust you.
I'll wait for block 600,000 to happen to test it with the 0.1 mBTC (or see if someone else takes the funds before I do).

I'll go for the first option now because I know the parents well. Of course it really depends of the case. I like the idea and probably I'm going to use it more than once, so for sure the second solution with 18 years of locktime for the parents and 25 years for me will be used as well.
I can probably use the locking options for my kids too, so if something happens to me, the mother won't spend the money until the kids are 18 Well, I know the mother well so she won't spend them for sure.

Edit: just shared it on my twitter

Aren't you supposed to spam a list of links if you do that?

Oh,blimey!

[Robot1982]

Just as a note, you don't have to use block height in the locktime. You can actually use UNIX timestamps which is more precise than using block height (you can't know for sure how many blocks will be mined in 18 years). A value over 500000000 for nLockTime will be a UNIX timestamp: https://en.bitcoin.it/wiki/Protocol_documentation#tx I already tested this and it works as expected.

[vapourminer]

i like this.

but how "baked in" to the protocol is locktime? ie it will forever be compatible with whatever official client is in use in 15 or 20 years time? a tx created with locktime today will always work in the future?

sorry for noob question i just know btc slowly mutates as needed, and 15-20 years is a long time. as long as the locktime behavior is set in stone..

@Robot1982 i like that unix timestamp bit more than using block height, thanks.

[squatter]

i like this.

but how "baked in" to the protocol is locktime? ie it will forever be compatible with whatever official client is in use in 15 or 20 years time? a tx created with locktime today will always work in the future?

I don't think you have to worry about that too much. Height-based nLockTime was included in the original Bitcoin implementation and time-based nLockTime was implemented in version 0.1.6.

Time-locked bitcoins are one consideration in any fork that limits transaction size -- like the sigops limit Gavin Andresen wanted to introduce. Time-locked transactions that are too large would be invalidated. I doubt such a fork would gain wide consensus, though.

[pooya87]

ie it will forever be compatible with whatever official client is in use in 15 or 20 years time? a tx created with locktime today will always work in the future?

since bitcoin is not centralized, there is no centralized entity to release "official" anything. all we have is consensus that the entire network has to agree no matter what client they run. and since things like LockTime are enforced by the protocol to change them we have to create a fork and that is not going to happen and even if it does you will see it if you follow bitcoin (as in checking every couple of months).

[LoyceV]

but how "baked in" to the protocol is locktime? ie it will forever be compatible with whatever official client is in use in 15 or 20 years time? a tx created with locktime today will always work in the future?

In 20 years a lot can happen, so this could indeed be a risk. Or, maybe even more likely: a potential protocol change could invalidate the transaction too, for instance if quantum computing becomes a threat to the current encryption.
Unfortunately, we can't know for sure, so don't put your life savings at risk

And there's this:

Risks
You may miss out on possible Forkcoins that use proper replay protection.

[LoyceV]

We're closing in on block 600,000. If it wasn't obvious yet: it's okay to take the 0.0001BTC, please post here if you did.

[Dabs]

Do you have a tool to create the transaction? *edit* (oh, coinb.in, you have a step by step instruction for this?)

Also, as Robot1982 has said, and I found this:

https://bitcoin.org/en/transactions-guide#locktime-and-sequence-number

If greater than or equal to 500 million, locktime is parsed using the Unix epoch time format (the number of seconds elapsed since 1970-01-01T00:00 UTC—currently over 1.395 billion). The transaction can be added to any block whose block time is greater than the locktime.

So maybe something that gives you a date would be great. People are probably going to wait a few hours after that date or even a day after that date before broadcasting the future transaction.

For multiple versions, you'd maybe space it out every 2 weeks or every month, and create a sequence going into the future. All you'd have to do is burn one page at a time (or shred it, "burning" is bad for the environment.)

[LoyceV]

So maybe something that gives you a date would be great.

You can use the Epoch Unix Time Stamp Converter, but considering the importance of the result, it doesn't hurt to verify it with an offline method (basic math can get you a pretty accurate result).

The reason I didn't mention the possibility of using a date, is because I'm not sure how "hardcoded" that is. As far as I know, there's no time synchronization in the Bitcoin protocol, while the block count doesn't leave any doubt.

It seems to me that the use of Locktime is not as necessary as you say

Can you explain this one-liner a bit?

[Dabs]

The blocks do store the time. It can be off by up to about 2 hours and still be a valid block.

In general, miners have full nodes that have the correct time, or at least most computers online somehow sync to a reference time server. It's just something that is taken for granted because they just don't bother making sure the time on their computers are always correct.

Might be a good idea to test them, someone already did, maybe do a few more tests.

Block height can be estimated within the next so many years, and if you're off, that just means its a little earlier. Usually earlier, simply because miners mine faster over time, difficulty goes higher, but miners keep mining. It's rare that miners slow down.

Notice how halving date estimates keep coming closer.

Every block that's added to the blockchain is within 2 hours of the previous block's time, but in general it goes up about 10 minutes.


As for how "hardcoded" that is, the documentation just says anything above 500 million... We're not going to see 500 million blocks in a few centuries, (what's that equivalent to anyway, ... )

So 10 years is about 500,000 blocks ... 1 million blocks is 20 years... so 500 million blocks would have been ten thousand years.

We'll have another hard fork by then. LOL.

[LoyceV]

As for how "hardcoded" that is, the documentation just says anything above 500 million... We're not going to see 500 million blocks in a few centuries, (what's that equivalent to anyway, ... )

So 10 years is about 500,000 blocks ... 1 million blocks is 20 years... so 500 million blocks would have been ten thousand years.

That's my point: using a block number will work for a very long time, but using a UNIX timestamp I'm not so sure about: it's a 32 bit counter, and it has a Year 2038 problem.

If you want to set a Locktime 25 years in the future, it's already not possible and you'll have to rely on future fixes (and assume the implementation will still work for you). That can be a very expensive mistake if it fails.

[Dabs]

Oooooh .... right right ...  2038 problem with 32 bits. That far away, use a block height to date estimator. Write down that this is the estimate, and to check a week AFTER that estimate just to make sure.

So, use unix timestamps up until BEFORE January 2038. But then again, it's close enough to just stick to block heights, as if nothing changes in the protocol, we still have ten thousand years.

Probably don't use the time, there is a slightly related year 2036 problem, with the Network Time Protocol.

I thought this was fixed in some other linux and even windows versions to 64 bits already (which means, its a year 2 billion problem, something we don't need to think about.) Or as some put it:

The 64 bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64 bit second value is enough to provide unambiguous time representation until the universe goes dim.

I think current versions of OS now use 64 bit time. Windows doesn't have this problem as it uses a 4 digit year now (so its a year 10k problem), but since the protocol is the Unix timestamp, that might be irrelevant.

In either case, someone has to test this, make a bunch of versions, include a few that are in the year 2040, 2050, and 2100.. (include 2019 too, in case you want to spend it now, as this is just for testing, hehe.)


For anyone interested, 64 bit time = 292 million years in the past to 292 million years into the future from epoch. Just a little bit over a quarter of a billion years, so I'm quite sure the universe is still churning by then. It's about the time it takes for a lizard to grow into a dinosaur or for something else to migrate from the sea to land.

[Dabs]

Hey, do you have some block height to date converter estimator thingie? (or the other way around, date to block height)

I think for most people (probably everyone) who just uses block height, they wouldn't mind knowing just the day, it does not have to be the exact hour (and there is no way to reasonably predict this even a few years from now.)

I then looked up something and found this:
https://en.bitcoin.it/wiki/Block_timestamp

As a result block timestamps are not exactly accurate, and they do not need to be. Block times are accurate only to within an hour or two.

Bitcoin uses an unsigned integer for the timestamp, so the year 2038 problem is delayed for another 68 years.

So, the first one means, we can probably guess what block at what day in the future and it could be off by a couple of days, because of mining hashpower increases and difficulty adjustments. Usually the date gets closer as we have seen with these halving date websites.

The second one, means there will be an update to the time stored in the protocol (before the year 2106) and that implies a fork when it switches to a 64 bit integer. Then we have 200 million years. I don't know if that's a hard fork or a soft fork. I know it's just time, but from a 32 bit integer to a 64 bit integer ... and some code to ignore all earlier blocks, and some more code in a future block when it gets activated.

They should probably make it optional now, and then mandatory several updates later, maybe at least a year or two later. Still decades away.

[BrewMaster]

Hey, do you have some block height to date converter estimator thingie? (or the other way around, date to block height)

the only way to do that is by using an estimation and you won't need a tool for that you can use a simple calculator and assume there are fixed 144 blocks per day (1 block/10 min * 6 * 24) and then multiply that by number of days you want.

[LoyceV]

Since nobody took the small balance for about 200 blocks, I moved it myself. I could broadcast the transaction without any problems, after which I used the QR-code to sweep the private key.

This was my first test, and it all worked as expected.

[Dabs]

I was going to try and do it, but I forgot. Make another one and make the balance bigger, I'm sure someone will beat us to it (or set up a bot to do it a block after it can be transacted.)

This looks like something I can use either for myself or for some potential clients. I'll have to study the procedure a bit more. The transaction can also be made to pay out to more than 1 address.

[gmaxwell]

You could also use a script that looks something like

IF yourkey CHECKSIGVERIFY ELSE <duration> CSV OP_DROP theirkey CHECKSIGVERIFY ENDIF.

Then any output of yours that hasn't been moved by the CSV time can also be spent using theirkey.

Then ideally you'd make your wallet smart enough to preferentially spend coins where are getting close to their expiration.

This is essentially the kind of script used for the blockstream green 2fa-- you can spend with your sig and blockstream's sig, or after a timeout with just your sig.

W/ future taproot, this additional spending branch wouldn't make your outputs look any different from anyone elses.


This scheme has the advantage that you can create your backup once (by precomputing the addresses you'll use in the future, or using public derivation), rather than having to continually update a set of nlocktimed transactions every time you get a new payment or move coins (e.g. due to making a new payment).

It has a disadvantage that CSVs can't be set that far in the future, though I suppose you could use a CLTV instead but the disadvantage there is that you must set it pretty far in the future because you can't keep updating it.

Another possibility is to use a two phase release:   You hand someone a presigned transaction with no locktime that moves your coins to an output you can spend instantly, or which they can spend after a CSV.    If they broadcast that transaction while you're still alive, you use your key to claw the funds back and the exclude them from your will in the future.  Otherwise they can collect them after the CSV.

This approach could have a much shorter timeout-- less delay in getting to your coins.

Downside is ... more incentive to cause you to have an unfortunate accident.

The proposed checktemplateverify could be used to make this last form also a one shot enrolment.

The incentive to cause you to kick the bucket is one of the reasons that non-interactive/one-shot schemes are better.  You can just not tell people that might get dumb ideas about their inheritance and have all the info in a safe deposit box they only get access to after you die.


All this said-- it can be advantageous to give away funds that you'd otherwise bequeath while you're still alive:  You get the enjoyment of seeing people use your gifts... and if you're in the US you can gift $15k per person per year without it counting against your estate taxes.   (You never know what bitcoin might be worth in the future-- perhaps your holdings might become valuable enough to trigger estate taxes even if they aren't now... and, of course, tax policy might change...)

[jeremyrubin]

This is actually one of the prime use cases for OP_CTV.

As Greg points out, it can be useful to have an automatic clawback period mechanism if an inheritor tries to claim inheritance and you are not dead yet.

But you can go a bit further. Let's say you have 100 BTC that you want to bequeath your children. CTV makes it easy to set it up such that your progeny could get time release bitcoin (e.g., an annuity of 1 BTC a month).

You could also do this by directly creating 100 HTLC outputs with 1 BTC each revocable to you, and different locktimes, but there are some critical drawbacks with such an approach.

One such drawback is knowing when the tax obligation is due. You can't prove to the government that you didn't also receive a private key allowing you to spend at will as a part of the estate. However, with CTV you can prove that the annuity is set up correctly, and defer your tax obligation until the annuity payment is received.

If you have multiple inheritors and want to instead do some multisig scheme, there are similar drawbacks, but now added concerns that some of the inheritors will conspire against the others.


Ready for the galaxy brain....


CTV also would enable the spender to set up sub-inheritence schemes, to cover the case where one of the inheritors also "dies in the same car crash". You can specify a different redemption path if they don't claim their payment. At some point, you might want a will executor of last resort, like a law firm.

[Dabs]

And then those law firms would hire one of these trusted third party escrows to directly handle the coins, assuming they have access to the private keys or the the locktime transaction sends it to them, multisig of course, but for simplicity maybe just the backing of law would do. If it were a 2-of-3 multisig and only 1 survives, no one gets the coins.

[jeremyrubin]

And then those law firms would hire one of these trusted third party escrows to directly handle the coins, assuming they have access to the private keys or the the locktime transaction sends it to them, multisig of course, but for simplicity maybe just the backing of law would do. If it were a 2-of-3 multisig and only 1 survives, no one gets the coins.

Yeah the law firm case is sort of "everyone is dead" so it doesn't really matter what happens to your money in this event anyways

But yeah you can have the law firm be multisig'd with a key known to all inheritors so they can't simply steal the funds.

[Dabs]

Ideally you'd have only a primary and secondary, and maybe even a 3rd place beneficiary. You shouldn't run out of family that way, unless your entire clan is on the same plane (unlikely) you'd probably have some extended relatives, or at the very least make it go to some charity.

I've got term life insurance and if I remember correctly, I set it up so 100% goes to the spouse as primary. Secondary includes two named children. But yeah, I've got no one else set up if we're all dead.

[Docnaster]

TL;DR
~snip~

Excellent thread.

I was looking for more information on how to lock up Bitcoin for the long-term.

I have the unfortunately habit of selling at the very bottom, only to regret it several months (or even years) later.

Time to forcefully put an end to my misery!

[Timelord2067]

Is this a correct walk through?

I went to http://coinb.in/#newSegWit and generated this:

Code:

SegWit Address (Share)
bc1q6pqkrcgr52x5xsm5anpnkvs6vrx03xdrcf3zht

RedeemScript
d04161e103a28d434374ecc33b321a60ccf899a3

Public key
02614dc59a3f561b47337e192c439850e7b6d36e357e1c883756168ef11ba3f960

Private key (WIF key)
L1LbmSTnmdbguRLTRgyaZzj3dw2L6rnJhGv9EkYGkaC9pgsMM4oF

I then went to http://coinb.in/#newTimeLocked armed with the Public Key ( 02614dc59a3f561b47337e192c439850e7b6d36e357e1c883756168ef11ba3f960 ) entered the date 11/05/2020 00:00 and was given:

Code:

Address
36aGPF8dhu9Wg8RDtSRUpuiNzLA9UaNXSZ

Redeem Script
04e0b3a25fb1752102614dc59a3f561b47337e192c439850e7b6d36e357e1c883756168ef11ba3f960ac

Shareable URL
http://coinb.in/?verify=04e0b3a25fb1752102614dc59a3f561b47337e192c439850e7b6d36e357e1c883756168ef11ba3f960ac#verify

Do I then send funds to 36aGPF8dhu9Wg8RDtSRUpuiNzLA9UaNXSZ until the 5^th of November this year and then go to the URL and click "verify"?

Is it just that simple, or, am I missing something? (Thanks for this titbit of information)

[pooya87]

Do I then send funds to 36aGPF8dhu9Wg8RDtSRUpuiNzLA9UaNXSZ until the 5^th of November this year and then go to the URL and click "verify"?

Is it just that simple, or, am I missing something? (Thanks for this titbit of information)

the "verify" button is simply translating the script into human readable form which is what you can do on your own too. the first 5 bytes (04+e0b3a25f) is your epoch time in little endian for which is Wednesday, November 4, 2020 2:00:00 PM GMT (yes that is a bug in coinb.in that uses your local time instead of converting it). the next two are OP_CLV and OP_DROP and the next 34 bytes are your public key and finally the OP_CHECKSIG.

the problem you may face is for spending this since there is no easy way of doing it as far as i can tell.

[Timelord2067]

So what I wrote won't enable me to have a set-and-forget wallet transfer?

[pooya87]

So what I wrote won't enable me to have a set-and-forget wallet transfer?

you can create the address which is valid and you can send coins to it. but spending coins from that address is going to be hard because there is no easy way of doing it (at least i don't know any) even though signing the transaction with this script is trivially easy since the script doesn't have anything crazy in it like OP_CODESEPARATOR!

[Devawnm367]

I am really glad to see this. I brought this up with a relative a couple years ago! Lets say I lock 25 BTC for 10 years. When the 10 years is up it releases the keys to those in your will. Each person would have their very own locked wallet. Use their own private keys.  But you could realease like 5 BTC every 5 years so they did no blow their inheritance all at once! But with the Original private key you could release the funds as you wish!


Tommy gets 1
Jenifer gets 2
Tammy getts 2
_______________
Every 5 years for 25 years

Or release new keys using old keys each time!

[Timelord2067]

...
Every 5 years for 25 years

Or release new keys using old keys each time!

I think you may have to set up a separate set of funds for each time-frame as I have a feeling that wallets are swept clean when this process is done.

[LoyceV]

I think you may have to set up a separate set of funds for each time-frame as I have a feeling that wallets are swept clean when this process is done.

You can use the same wallet, as long as it has multiple inputs and you use only one at a time.
You can't create a Locktime transaction for funds that haven't arrived in a change address yet.

[SatsLife]

TL;DR
~snip~

Excellent thread.

I was looking for more information on how to lock up Bitcoin for the long-term.

I have the unfortunately habit of selling at the very bottom, only to regret it several months (or even years) later.

Time to forcefully put an end to my misery!

you will find this interesting then... https://bitcointalk.org/index.php?topic=5228739.0

[Timelord2067]

Can anyone help?

Do I then send funds to 36aGPF8dhu9Wg8RDtSRUpuiNzLA9UaNXSZ until the 5^th of November this year and then go to the URL and click "verify"?

Is it just that simple, or, am I missing something? (Thanks for this titbit of information)

the "verify" button is simply translating the script into human readable form which is what you can do on your own too. the first 5 bytes (04+e0b3a25f) is your epoch time in little endian for which is Wednesday, November 4, 2020 2:00:00 PM GMT (yes that is a bug in coinb.in that uses your local time instead of converting it). the next two are OP_CLV and OP_DROP and the next 34 bytes are your public key and finally the OP_CHECKSIG.

the problem you may face is for spending this since there is no easy way of doing it as far as i can tell.

Am I doing something wrong?

http://coinb.in/?verify=04e0b3a25fb1752102614dc59a3f561b47337e192c439850e7b6d36e357e1c883756168ef11ba3f960ac#verify

Code:

04e0b3a25f - b1 - 752102614dc59a3f561b47337e192c4398 - 50e7b6d36e357e1c883756168ef11ba3f960ac

the next two are OP_CLV and OP_DROP

I'm guessing "the next two" aren't one character long each?

The submit button also doesn't work.  (I've tried it with a date that's already come and gone)


I can broadcast a Raw transaction, that's ok, I'm just stuck working out which part is the actual transaction.

Thanks.

[pooya87]

Code:

04e0b3a25f - b1 - 752102614dc59a3f561b47337e192c4398 - 50e7b6d36e357e1c883756168ef11ba3f960ac

the next two are OP_CLV and OP_DROP

I'm guessing "the next two" aren't one character long each?

the text inside the code tags is written in hexadecimal encoding (aka base-16) and in this encoding each 2 characters represent 1 byte. for example 1 = 0x01, 255=0xff
in bitcoin scripts each OP code is 1 byte, so each one of those two (OP_CLV and OP_DROP) that are also 1 byte take up two characters: 0xb1 and 0x75 respectively.

[Jet Cash]

Surely if the lock down was any use, then you wouldn't need to bother with inheritance planning.

[Timelord2067]

Surely if the lock down was any use, then you wouldn't need to bother with inheritance planning.

You can use the time to plan your getaway, your diversion and a place to stash your funds while in lock-down.  There are plenty of movies where the criminals plan their next heist while in lock-up, come out then go back into lock-up.

[LoyceV]

@Jet Cash: I created this topic long before any lockdown. With or without lockdown, roughly 150,000 people per day die.

[erikoy]

Wow, this is a sort of a good way in making bitcoin as a wealth pass it to the next generation until such time that they will be allow to use or spend it.

Bitcoin is one good digital currency and I do believe that it will be adapted to the community over a period of time. This may not going to happen fast but at least it is already making their way for community adaptation. Bitcoin will be useful than any other currencies in the world.

Transferring money outside the country will be easy in a decentralized manner same as making payments and using it to buy products and services. This is an all in one digital cryptocurrency.

[Gotumoot]

I never knew that we could create a transaction right now and would take place in the future.
I think I really need to try it out to save money since I always end up spending the extra money that I have maybe this could be the answer for me to finally be able to save money.

[BlackHatCoiner]

I had heard about locktime before, but never took a look into it. This is actually a pretty nice solution to the inheritance of bitcoins. Still though, the receiving addresses of the signed transaction must remain on a safe place all that time. Thus, the people that will inherit the bitcoins must be fully informed of what it is.

Once again, bitcoin proved that you don't need a third party for another financial procedure!

[DYING_S0UL]

One month bump

One month bump

Bump into 2022.

Bump into 2023!

Bump into 2024 (almost)

Isn't there a simple version? I could just divide the seeds or private keys into three or four different parts. Then assume I have 2–3 children. They all get a piece of my private keys. And I keep one or two parts in my will. I could make multiple wills; when a specific will is valid, the other will is valid after some days.

Of course, there is a risk if they expose the private keys before my death. I never had or used any will. So I don't know if they are secure or not. Whether they can be manipulated or not. So I don't know if this method is practical or not.

I hope you will shine some light on it. Disadvantage & disadvantage of using a will.

[LoyceV]

Isn't there a simple version?
~
Of course, there is a risk if they expose the private keys before my death.

You said it That's the risk you should avoid.

I never had or used any will. So I don't know if they are secure or not.

Here, you'd have to use a notary. They're supposed to be trusted, but they're also human. And it would be impossible to prove if they used your private key, so I wouldn't risk it.

[apogio]

This is one of the best topics in the forum.

I am wondering if I could use it for emergency reasons.

I am thinking of following the steps below:

1. I have a wallet (let's call it "CLAIRE"), in which I have some UTXOs and I want to send them all in case something happened to me.
2. I will create a wallet using Electrum on Tails on a permanently airgapped pc. Let's call this wallet "STEVE".
    a. I will keep dual backup of the seed phrase.
    b. I will take the first address from the first (default) account of this wallet.
3. I will create and sign a transaction from CLAIRE to STEVE's address (from step 2b). I will add a locktime (let's say 10 years from now - or more).
4. I will export and save the transaction both on paper and digitally.

Now, is the tricky part.

I need to let someone know where to find the seed phrase backup & the transaction.

Thoughts - Questions:
1. I will save the backups in 2 separate places, but in each place I am thinking of leaving both the transaction and the seed phrase, since STEVE is empty and it can't be funded for 10 years.
2. How would I notify the people I want on how to find the backups without exposing the backups to danger?
3. Would you also leave instructions on how to find CLAIRE's seed phrase? It is kind of dangerous, considering that this wallet is already funded.

[LoyceV]

I need to let someone know where to find the seed phrase backup & the transaction.

Thoughts - Questions:
1. I will save the backups in 2 separate places, but in each place I am thinking of leaving both the transaction and the seed phrase, since STEVE is empty and it can't be funded for 10 years.
2. How would I notify the people I want on how to find the backups without exposing the backups to danger?
3. Would you also leave instructions on how to find CLAIRE's seed phrase? It is kind of dangerous, considering that this wallet is already funded.

To be clear: in this scenario you're assuming you're dead, right?

1. That should work, but if the location is compromised and someone gains access, he can patiently wait for the transaction to become valid and take your funds. So if you're still alive, it's best if you move your funds before the locktime expires.
2. This is more of an IRL problem than a Bitcoin problem. How do you usually get notified when someone dies? Someone else will have to take care of it for you.
3. That really depends on your personal situation. A spouse? Yes. A friend? No.

[apogio]

To be clear: in this scenario you're assuming you're dead, right?

Yes! that's the assumption.

1. That should work, but if the location is compromised and someone gains access, he can patiently wait for the transaction to become valid and take your funds. So if you're still alive, it's best if you move your funds before the locktime expires.
2. This is more of an IRL problem than a Bitcoin problem. How do you usually get notified when someone dies? Someone else will have to take care of it for you.
3. That really depends on your personal situation. A spouse? Yes. A friend? No.

If I die, then step (2) will happen.

In step (2), a person I trust will get notified with the necessary instructions and will try to gain access to the backups from step (1). So, they will be able to realise if the keys are compromised.

If they are not compromised, we are good. They can wait and get the money when needed.

If they are compromised, then, I need step (3) in which another (or the same person) will be able to recover my Original seed phrase and just spend the UTXOs, rendering the Locktime transaction invalid.

So again, the problem is:
1. How I would notify my beneficiary about the key and the timelocked transaction.
2. How can I trust someone (and who) with information regarding my original wallet that signed the timelocked transaction.

I sound paranoid, I know, but if I solve those two issues, then I will be very confident and I will beta-test ( ) my inheritance plan.

[LoyceV]

So again, the problem is:
1. How I would notify my beneficiary about the key and the timelocked transaction.

That's what I meant with "an IRL problem". You could setup a death man switch that sends an email if you don't reset the timer, but chances are you're going to forget it somewhere over the next 10 years. Or your system breaks at some point. It's not perfect.
A notary might work, but I wouldn't trust them either. They're great for legal paper work, but with Bitcoin there's no paper trail if they would commit fraud.

2. How can I trust someone (and who) with information regarding my original wallet that signed the timelocked transaction.

That's for you to figure out Who would you trust with $10k in small unmarked bills? Or, if it's $10M we're talking about: who do you trust not to kill you to stop you from resetting the locktime?

I sound paranoid, I know, but if I solve those two issues, then I will be very confident and I will beta-test ( ) my inheritance plan.

I'd start by discussing this with your beneficiary. I assume that's someone you trust, right?

[apogio]

That's what I meant with "an IRL problem". You could setup a death man switch that sends an email if you don't reset the timer, but chances are you're going to forget it somewhere over the next 10 years. Or your system breaks at some point. It's not perfect.
A notary might work, but I wouldn't trust them either. They're great for legal paper work, but with Bitcoin there's no paper trail if they would commit fraud.

Nope, I don't like any of these options for the reasons you have mentionned.

That's for you to figure out Who would you trust with $10k in small unmarked bills? Or, if it's $10M we're talking about: who do you trust not to kill you to stop you from resetting the locktime?

Nobody!

I'd start by discussing this with your beneficiary. I assume that's someone you trust, right?

Well yeah, it's the only reasonable option anyway.


Well it has nothing to do with Bitcoin. It's indeed a IRL problem...