Bitcoin Forum

I have a wish.
I wish that in the future, I can not only choose the amount and address to where the transaction goes, but also the time of execution.
And that I am able to cancel that transaction.
Maybe on the Bitcoin Blockchain.
If not possible, then maybe on the Lightning Blockchain.
This would make the act of heritage so much easier.
I can keep my private keys private.
Forever.
Without that my Bitcoin are lost.

My wish:
I make a transaction of 1 BTC on 1st of July 2024 to the address of my daughter.
And one transaction of 1 BTC on 1st of July 2025.
And one transaction of 1 BTC on 1st of July 2026.
And one transaction of 1 BTC on 1st of July 2027.
And one transaction of 1 BTC on 1st of July 2028.
And so on.
Maybe starting from 2030 only 0.5 BTC. Because the value goes higher and higher with the time.

If I am still alive end of June 2024, I just cancel the transaction of July 2024 and make a new one for 1st of July 2029 or another date.

Like that I make sure that:
1. as long as I am alive I never have to share my private keys.
2. if I die, my BTC are not lost and will go to the person(s) I want.
3. my daughter will never lose all of the BTC because someone scammed her.

If her lover/friend/unknown scammer scams her, she can only lose the BTC for 1 year.
But she will never lose them all.
Just have to wait until next July, when a new transaction arrives.
Maybe I will send every year to a new address.
To avoid that if the seed phrase of the wallet of the year 2024 is exposed, the scammers have no access to the wallet of the year 2025.

That is my wish.
Please devs, do something.  ;D

It's already possible through transaction locktime. Well, locktime isn't something you exactly looking for but it should serve your purpose. Locktime defines a transaction to be broadcasted in a future date, time or after a certain block is mined.
You can learn more about it here- https://trezor.io/learn/a/locktime-in-trezor-suite-app

I had seen a thread here in the forum if I can remember correctly, let me find it.

Edit- I had created the thread. This thread has the similar purpose like you- https://bitcointalk.org/index.php?topic=5287093.0

I do not think I can give any additional explanation because Little Mouse explained it perfectly, the problem is that many people are using wallets that are not recommended, the wallets that you do not have such features. There are many wallets like that. I check wallet like Electrum last year and I noticed it supports using unix time as the lock time, also using normal time for it, and also possible you use block height. If you can do that on some wallets for now, I think it is more than enough.

wow crazy. read a bit, looks promising.
will need more time to go through it all.
thx very much  :)

so it looks like trezor and electrum can do it already.
crazy.
talked to ian c rogers from ledger exactly one year ago and he didn't mentioned anything like this...

@jackg mentioned it should be safe until 2050. my daughter would be 40 then.
have to read more...

Have your daughter generate 20 (for example) key pairs. She keeps the 20 private keys secret and gives you a list of 20 addresses.

Create a timelocked transaction sending 1 BTC to the first address, which cannot be broadcast for 1 year. Give her a copy of the transaction for safe keeping.
Create another timelocked transaction sending 1 BTC to the second address, which cannot be broadcast for 2 years. Again, give her a copy of the transaction.
Another transaction, timelocked for 3 years, to the third address. Give her a copy.
Etc.

If you die, then she can broadcast one transaction a year until she has broadcast them all.

If you are still alive in a year, then all you have to do is move the coins in the first transaction to a new address, and the timelocked transaction she is holding will be invalid and useless. So every year you are still alive, move the coins which she could redeem next to another address you own, and then create a new timelocked transaction for some other time in the future.

yeah, sounds like a good plan  :)
surprised that it is possible with trezor and electrum, but not with ledger? have to check next time.
atm too lazy to get out the stick...

what about this?

bugs in 10% of timelocked transactions?


https://www.coindesk.com/tech/2020/06/01/bug-in-timelocked-bitcoin-contracts-could-spur-miners-to-steal-from-each-other/

As it was mentioned you can use OP_CLV for #3 but the other three are not possible in the existing protocol. However you can use workarounds to do something similar by using a more complicated smart contract through OP_IF + OP_CHECK(MULT)ISIG.
Basically you combine your own key with the receiver's key in different branches of the OP_IF that way you can use the other branch to "cancel" the transaction (#4) by spending the outputs to your own address while at the same other the other party can use the other branch to spend the same output to their own address (#2).

LN is a network and has no blockchain.


This would be your redeem script. You hash this and use it to encode an address. Then send the coins to that address. At any time (before or after July 1, 2024) you can spend these coins and send them to a new address. After July 1, 2024 your daughter will also be able to spend these coins assuming they haven't been spent by you first.


That is about fee sniping which you shouldn't be concerned about. It is a theoretical attack which is basically like miners competing over transactions with very high fee. It is also unrelated to OP_CLV.
You can read more about it here: https://en.bitcoin.it/wiki/Fee_sniping

Hello! The purpose of this feature is to provide inheritance to someone? If so, why not give someone (your daughter) your seed phrase instead?


Is this option available using timelock? Because if you can cancel it, then I understand that this is different from sharing your seed phrase.

It can be done with a Ledger device via Electrum, rather than via Ledger Live.

It's an off-by-one-error which is irrelevant to your use case here.

Because then they could clear out your accounts before you die, and you also have the added risk of them storing a copy of your seed phrase and it being vulnerable to theft. Timelocked transactions avoid all of that.

Yes. You simply spend any one of the inputs before the timelock expires and the timelocked transaction become invalid and therefore useless.

I have heard many people in my life, claiming that Bitcoin inheritance is extremely difficult.

Using this feature, however, it seems INCREDIBLY EASY.

The only argument that I can accept from now on, regarding inheritance, is that the person who will inherit the money need to already have a wallet (and know some stuff already).

-- EDIT --

I really needed to test it, so:

I am using Sparrow upon my bitcoin node. I have just signed a transaction using my signing device.

I have set it to be able to be broadcasted after block height 786243. The current block height is 786238.

So the transaction was not broadcasting until we reached block 786243. Then I broadcasted it successfully.

However, who was going to broadcast the transaction in case I died before the block height 786243 was reached?

The person receiving the coins.

This is why I said above that after you have created the timelocked transaction, you should give a copy to your heir for safe keeping. This is so they can broadcast it after the timelock has expired. You can also keep a copy yourself, such as in a safe at home or a safe deposit box at a bank or somewhere else your heir will gain access to after you die.

If you are still alive, then before the timelock expires you move one of the inputs in the timelocked transaction to a new address, therefore rendering the timelocked transaction invalid and unable to be used. You then create a new timelocked transaction and give this to your heir. Rinse and repeat.

So is there an automatic broadcast option? It doesn't really make sense to be able to set it up automatically, considering the technical aspects behind it.

I will try to manually cancel a timelocked transaction following the process you mentioned.

No, I don't think he meant that. You can broadcast the signed transaction individually. You make it, set a certain block height as the requirement, sign it, and once the height is such, it can be broadcasted and mined. All this time, the signed transaction can be kept somewhere safely.

Don't test with real money. That's why we have the testnet (https://en.bitcoin.it/wiki/Testnet). Also, read this if you haven't already: https://bitcointalk.org/index.php?topic=5180850.0

Yeah most probably he/she meant what you said. Do you think there may be a way to broadcast a transaction automatically though? Generally speaking.


Obviously! I did it both in testnet and with real money however ;) Great post btw, I will check it.

There may be, but it's not worth the time and the potential drawbacks. You should rely on your daughter to do this individually, and not to some third party or local computer.

Also, I'd teach her some security basics before handing over anything. Unless she practices software engineering and knows from malicious factors, I'd tell her how to setup an air-gapped computer (or give her hardware wallet instructions for the sake of simplicity), tell her a few obvious things about Bitcoin wallets etc. It'd really be a pity to lose much money, and I'd be responsible for that.

Yes I agree! I don't have a daughter actually. I was simply inspired by the OP's thread and it got me very interested, that's why I asked.

original bitcoin version had fully working smart contract protocol that allowed transaction execution programming 
although it was not included in newer release, to make network faster
anyways some of the early bitcoin clones and hard forks still have it in place, text me for code examples

That's not true.
The code for the initial release can be found on github[1] and the script part of the code is almost identical to what we have today. OP codes such as OP_CAT that were removed weren't providing any kind of "transaction execution programming" that you claim. Their removal also had nothing to do with "making network faster" they were removed because they made no sense and were buggy.

[1] https://github.com/Maguines/Bitcoin-v0.1

You can make transaction offline anytime and broadcast it later, you can always cancel this transaction until you broadcast them. If you don't have internet connection by the time you want to spend 1 BTC to your daughter, it won't be possible for her to receive it.

You shouldn't share your private keys as long as you are alive. And if you die, your bitcoins will be lost because you haven't shared your keys with someone else. Another option to prevent this is, for example, 2/3 multisig wallet but you have to trust these two people. In 2/3 multisig wallet case, if you die but these two persons are alive, they will be able to make a transaction and get funds. In 2/3 multisig wallet, at least two sign is necessary to make a transaction, so, you can always prevent damage from one scammer.

What did I just read?
Wow in bitcoin everything is possible, but one concern is that most of these things are technical such that an average man that is not a computer geek may not be able to understand and implement these things.
This will be a problem in the future when bitcoin hits global adoption because people will have to pay people (it could be centralized platforms) to help them handle these things and which is not the right thing.

I don't understand what you mean a computer geek may be capable to do but everything written above doesn't require technical knowledge at all, it's easy. If you talk about implementations that you wish to happen, I think non computer geek will be able to do some of them because of the nature of technologies at the moment.

By the way, bitcoin was not designed for massive global usage. 2017 year made it necessary for bitcoin to come up with a new solution in the form of Lighting Network to handle increased number of transactions. It's block size is very small, 4MB. I think if time comes when bitcoin becomes massive, we will have a need of Fork and some other solutions.

When bitcoin was first launched, if you wanted to use it you had to run your own node, which was interacted with via the command line. Far too technical for the average user. Now you can simply download an app on your phone and you are good to go.

Using various scripts manually is perhaps too technical for the average use, but that doesn't mean there is no solution to that problem. In fact, the average user can create timelocked transactions right now using Electrum and by simply typing in a block number they don't want the transaction to be spent before in the relevant box in the GUI.

It's actually 4MB.

My bad, my bad, it was a typo, it has been changed since 2017.

I understand that there are sincere efforts to made bitcoin user friendly and also scalable. And many things have actually changed, but there is this feeling of technicalities in people's head while approaching bitcoin from higher angle other than send and recieve bitcoin. I am not an exception to this . But now I appreciate my decision to learn and my presence in this forum.
I am going to try this transaction timelock out, maybe for few weeks and I'll be glad to get bisq, SegWit and Timelock

LN was not introduced to handle increased number of transactions. The idea is to create an off chain channel that supports frequent and small amount of bitcoin transactions as coffee and tea transactions and at the end, the channel closed and collapse back to blockchain. The emphasis is rather on transaction fees.

I think there is a problem with this approach. You would need SIGHASH_ANYPREVOUT (BIP 118) (https://bips.xyz/118) for this, and it's currently still not included in the code.

Otherwise, any time you move your coins because you're still alive, you will invalidate all of the transactions to your daughter. Because when you move the coins, you'll spend the UTXO which is included in all timelocked transactions.

You could hold the coins for each transaction on a different address, then it would work. I think however it's an over-complicated approach, because you will have to move coins each year anyway. (It may make sense in some very special cases, for example, if you want to order coins by priority, "which ones could I need still in my lifetime and which ones not", etc.)

The simplest approach is instead what you (o_e_l_e_o) wrote here (https://bitcointalk.org/index.php?topic=5449391.msg62121150#msg62121150):

1) send a timelocked transaction to your daughter with all coins you want your daughter to receive, 1 year in the future. (You can send it even per (encrypted) email or messenger, if you're sure that she's storing it safely, or give her the transaction code on paper, etc.)
2) every 6 months, and every time you move your coins or even part of them, you send a new timelocked transaction, again 1 year in the future, and again with all coins.

And yes @OP, you can cancel even this simple plan any time: simply moving all coins to another address.

pooya87's method (https://bitcointalk.org/index.php?topic=5449391.msg62119756#msg62119756) also works and has the advantage that your daughter will not have to store the transaction as she's able to move the coins with her key. But you pay fees one time more.

There was a more advanced method I'd read and which has already been implemented in a mobile test wallet, but I currently don't remember where it was.

Not at all. I was simply assuming that OP was using coins in his own cold storage which will rarely, if ever, be moved. The coins for each transaction should already be separate UTXOs, so if he needs to spend one of the UTXOs it will only invalidate a single timelocked transaction, and not all of them.

I think it would be a reasonable approach to exclude some of OP's coins from this inheritance plan for the sake of ease. If he had, say, 10 BTC in these timelocked transactions, he could have 0.5 BTC in a different wallet for his own personal use. This could simply be passed on to his daughter by the way of a seed phrase which she will inherit after his death.

He actually only needs to move a single UTXO and it will invalidate the entire transaction. So if he has a timelocked transaction sending 100 UTXOs to his daughter, he can just move a single one of those UTXOs and the whole transaction is invalid.

@o_e_l_e_o: Yep, with the coins on different utxos it works, but that wasn't that clear in your post; I think as the OP is not very experienced with contracts it's good if this detail is clarified. You're actually right that the method with various transactions, as the OP wrote, has also advantages.

---

I've found the "advanced approach" I wrote about in the last post, it was developed by user Andriian (https://bitcointalk.org/index.php?topic=5185907.msg52497274#msg52497274) in 2019.
It was created for the case of a person who wants to ensure that after his death a family member has access to the funds, but can also be adapted to the use case "give the coins to my daughter at a certain day, regardless if I'm alive or dead." In this case CSV has to be replaced with CLTV.

The script would look exactly the same like in pooya87's approach in #8 (https://bitcointalk.org/index.php?topic=5449391.msg62119756#msg62119756), but it has one difference: the transaction with the timelock is not broadcast, but given to the beneficiary (daughter, heir etc.).

The differences to the method storing it on the blockchain are minimal, but you save fees (the beneficiary/heir has to pay them), and there are privacy advantages (nobody sees that the daughter has access to the coins). In the original use case, however, when you want to transfer the coins only when you're already dead, Andriian's method has the big advantage that you don't have to renew this transaction regularly.

If I'm sure I want the coins for my daughter, and the probability I need them myself or change my mind is very low, I would perhaps prefer pooya87's method, because it's simpler to spend for the daughter/heir/beneficiary when the coins are already accessible for her public key "on the blockchain".

Ahh, I do remember reading that now that you've linked it (and actually merited it at the time, heh).

I think the biggest drawback to this is the same as the drawback we are discussing above: As soon as Alice spends any of her bitcoin, then the transactions she has given to Bob are invalid and she has to generate new ones and give them to him. This method also requires Alice to keep a constant watch for the transactions she has given Bob showing up in a block. By using timelock as I suggested above, Alice can know for sure that there is zero chance the coins can be spent before the timelock expires. Using this method, Alice has to constantly check to see if Bob is trying to steal from her so she can sweep the coins before he can.

Thanks @littlemouse for your reference.

Actually that thread clearly mentions how difficult it would be to set up the timelock feature with the less to no knowledge about codes.

Checkout the solution from @Coin_trader. You can set up the same in Electrum wallet itself and have that “inheritance” bitcoin machine set up for your daughter.

Good to see that whatever we imagine in the crypto thee days is already thought by someone and surprisingly some solution pre exists.  ;D

If someone has already tried, then share the thoughts.

This could also become the best way to “HODL” the coins as long term investment for specific period of time through above system.

Yep. I think currently this problem is not solvable with on chain transactions, we would need SIGHASH_ANYPREVOUT for that, and even then there are some possible complications, for example the amount you chose could actually not be available anymore.

As a side note, in some altcoins the method may be already possible if they're not using UTXOs but an "account model", and thus working very similar to SIGHASH_ANYPREVOUT already now. So in the case this opcode never makes it into the code, in a sidechain such a flexible mechanism would be actually possible.

This is true for the original method which uses CSV but not for the adapted method where the timelock is set with CLTV to a fixed block height or time in the future, which would fit the OP's use case better. It would work almost exactly like in pooya87's example.