Topic: Using Locktime for inheritance planning, backups or gifts - page 2. (Read 2944 times)

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

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.

Is this a correct walk through?

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


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:


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)

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!

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.

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.

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.

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.

You could also use a script that looks something like

IF yourkey CHECKSIGVERIFY ELSE 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...)

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.

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.

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.

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


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.

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:


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.

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.

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.

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.

Can you explain this one-liner a bit?

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

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.)

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.

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: