Topic: Future ("scheduled") transaction for inheritance (Read 273 times)

And here is the solution I tested:

Be careful, play on testnet first!

This only works with non segwit addresses and with one unspent output/transaction. You can modify it of course. Was good enough for me.

What you need:
1. Some Bitcoins to worry about (what happens if something happens with me...)
2. Bitcoin Core wallet

1. Create a new wallet for your loved ones and set it up on their machine(s). Get address(es) from this new wallet. You can close this new wallet, we will work on your own "source" wallet from now on.
 
2. Open your own Bitcoin Core wallet and go to Help/Debug window/Console (maximize it so you can see better)

3. Commands to run
getblockcount
Output:
520100
This will is the current block count. There are ~6 blocks per hour, so if you got back 520100 and want to create a transaction 365 days in the future 6*24*365=52560. 520100+52560=572660 (or add 5-10% to cover network growth) This is the not earlier than block number.

4. listunspent
This will show you all the Bitcons you have by TXID (incoming transaction ID with what you received with). You could have dozens! I advise you consolidate your coins first, so you will only have one/few.
Output:
{
    "txid": "aac0000000000000.000000000000017",
    "vout": 5,
    "address": "1XXXXXXXXXXXXXXXXXXXXXXXXXXXXX123",      
    "account": "NameWhatYouChooseForThisAddress",
    "scriptPubKey": "THISISTHESCRIPTPUBKEYPLACEHOLDERXXXXXXXXXXXXXXXXXX",          
    "amount": 1.12345678,           
    "confirmations": 4885,
    "spendable": true,
    "solvable": true,
    "safe": true
  },
TIP: You can copy to notepad and edit there, not typing manually

5. Print out the private key (X clears this window at the top right corner, be careful with this!)
dumpprivkey "1XXXXXXXXXXXXXXXXXXXXXXXXXXXXX123"
Output:
PRIXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

6. Create a RAW transaction
createrawtransaction '[{"txid":"txidFromStep4GoesHere","vout":0,"scriptPubKey":"scriptPubKeyGoesHereFromStep4"}]' '{"TargetAddressFromNewWalletGoesHere":1.11}' '572660'
- Amount (1.11 here) needs to be slightly less than what you have (remaining goes to the miners). BE CAREFULL because ALL REMAINING GOES TO THE MINERS!!!
'572660' is the not earlier than block number. Transaction will not be possible to broadcast (to be included in blocks) sooner than this.
Output:
AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXB

7.
signrawtransaction 'AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXB' '[{"txid":"txidFromStep4GoesHere","vout":0,"scriptPubKey":"scriptPubKeyGoesHereFromStep4"}]' '["PRIXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"]'
First parameter: Output string of createraw in Step 6
Second parameter: The whole section between the first {} in Step 6
Third parameter: Output private key from Step 5
Output:
{
  "hex": "AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB",     
  "complete": true
}
You got true back, you are good to go.
Tis is what you need to give to your loved ones is the string behind the hex.

You can check if its ok:
decoderawtransaction "AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB"

And this is what they will need to do after the give block number:
sendrawtransaction  "AXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXB"
They execute this and the coins will be transfered to the new address. But nothing can be done before that!

Advanteges IMHO:
If you are still ok you can just move the coins to a new address (or to the same address because the UTXOID what actually counts). Before the set blockcount and the saved raw transaction can never be used (as it will try to move coins which are not there).
You can split knowledge. Like giving the wallet to two of your kids and the rawtransaction text to your wife, etc. So they have to be both present.
It will work forever (until funds not moved and Bitcoin network is up of course)
It even works if you happen to forget your password or loose your original wallet.

Thanks, interesting read indeed. Multisig is a great feature I believe few Bitcoin users know about.

In my current case locking funds is not the goal, but allowing access to others in a future date without giving them control before.
(But keeping leaving open for current owner to spend at any time)

PS:
Anyone trying to use this don't forget. Future transaction only valid until you don't move the coins (or possibly any fraction of them)

just one short comment:
nowadays it is easier to use CLTV and CSV for time locked transactions.

I had these examples posted here: https://bitcointalksearch.org/topic/m.23664225

CHECKSEQUENCEVERIFY: lock some Satoshis until a specific number of block have passed, before I can use them, and if I really, really need the coins before, have a 2-3 multisig to release them immedeatly
CHECKLOCKTIMEVERIFY: lock some Satoshis until a specific number of block appears (aka my son is 18 years old...), but use a 2-3 multisig to release the funds in case funds are required earlier

The forum here provides many references (I remember having searched for this some time ago), as well as bitcoin.stackexchange. But best (as usual) seems to me the book from Andreas: "Mastering Bitcoin". In chapter 7 he describes the usage of the script mechanism. Warning though: it gets very detailed, and deep down into script layer 
But that's why we have these forums, to raise next questions! 

Understood Thank you both!

It works, just not the way you're thinking.
You're probably thinking you'd broadcast the transaction and it will sit in mempool of nodes until the nLockTime is reached, but like Achow explained above, it won't get related by nodes in the first place because if it was then it'd be trivial to spam mempool of nodes with lots of timelocked transactions.

The way it (currently) works is that you sign a transaction and store it but not broadcast it UNTIL nLockTime elapses.

Thanks for the detailed answer! So basically it would safe, but won't survive/get into in the mempool hence won't really work, especially not long term

I assume my idea would only work with a "side-chain"+new app which would hold these future locked transactions (and paid for it) than broadcast them on the Bitcoin chain when/if needed.

The transaction won't be in most node's mempools (note that there is no "the mempool"). Most nodes will not accept a transaction whose locktime has not yet passed.

No. Transactions that have been in a node's mempool are automatically evicted after a certain amount of time (default is 2 weeks). You could rebroadcast the transaction routinely, but in your case, that won't help.

Not a concern because it won't be accepted to the mempool in the first place.

Yes. If a block contains a transaction that has a lock time that has not yet passed, it will be invalid.

Yes. Your digital signature protects the locktime, just like all other parts of the transaction. Changing the locktime would make the signature invalid thus making the entire transaction invalid.

Yes, You can spend the same output in a different transaction thus invalidating the locktimed transaction.

Hi,

Problem:
One has BTC and want to be sure it won't be lost in the case of death (or any other events).

I am planning to do something like this:
- I would give a new, empty wallet to the loved ones
- Create a future transaction (like months/years in the future) sending all the coins from the live wallet to the inheritance wallet

Than there would be two outcome:
A) In the case the owner still around and has the keys to the original wallet he would simply transfer all the coins to a new address before the locktime allows the transaction to be included in a block.
B) If the BTC is still on the original address it will be transferred to the new address.

I think locktime could be used for this:
https://bitcoin.org/en/glossary/locktime

My questions:
This transaction would be in the mempool until could be included in a block. Can a "well paid" transaction hang around in the mempool for months/years?
How can it be checked if trown out of mempool?
Is the locktime strictly enforced?
Is the locktime value unmodifiable?
I assume the future timelocked mempool transaction shouldn't prevent spending the funds without current locktime?

Thanks