Your bitcoins if you die: time locked transactions?

[WiW]

tl;dr below

I'm young but the world is full of surprises, for better and for worse. So I've been thinking, in the unpredictable yet inevitable event of my death, how would I make sure that my bitcoins were left behind for those I care for.

I figured the best way for me would be to sign and print a time locked transaction one year in advance, along with the private key to the receiving address. This can be placed anywhere I expect my family/friends to find. The idea being that if something unexpected happens, my loved ones would have to wait no longer than a year to broadcast the transaction and receive my bitcoins. I, of course, would update this transaction once a year (destroy the old, make a new) or move the coins to a new address and sign a new time locked transaction.

tl;dr
I understand this is technically possible. If I were to use http://brainwallet.org/#tx, the lock_time is simply the absolute block height from which I would like the transaction to be valid?

[1715024886]

1715024886

[1715024886]

1715024886

[1715024886]

1715024886

[franky1]

tl;dr below

I'm young but the world is full of surprises, for better and for worse. So I've been thinking, in the unpredictable yet inevitable event of my death, how would I make sure that my bitcoins were left behind for those I care for.

Last Will and Testiment

[BTC Books]

nLockTime doesn't really do the job, as I understand it.  Nothing does.  Yet.

For a transmission of bitcoin upon ones' demise, there are a couple of very important requirements.

Firstly - no bullshit with lawyers, escrow, second or third parties at all.  Just a simple transmission of bitcoins.  So, you want to be able to set it up on a Dead Man's Switch:  if you don't call the transaction back, it goes.

Which means that the only way to do this effectively (and it really needs to be done) is to put a time-delayed transaction into the blockchain that can be recalled at any time before the trigger time - but only by whoever initiated the transaction; nobody else.  So no - this is by no means an idea that has anything to do with chargebacks.

Secondly - it is extremely important that some way be devised to send a percentage of bitcoin in a wallet, rather than an amount.  This will allow you to continue to use a wallet without worrying about having enough in it to cover a delayed transaction.  It means there won't be any leftovers that will disappear forever.  So if you have 1,000 bitcoin in your wallet and two kids to send bitcoin to in the event of your death, you send 50% to each - not 500 to each.  That means that if you run across something you want to buy you just buy it - without having to constantly change your Dead Man's Switch transaction every time your wallet balance changes.

This is really something that's needed.  A simple way to disburse your wealth upon your death, with no possibility of interference by any third party.

[WiW]

You folks aren't following. The transaction will be signed by the current living owner. It will only be transmitted to the network in the event of death. I sign a transaction, put it in my home. When I die and my family goes through my belongings, they will find the signed transaction and the receiving address. They will have to wait until the transaction is valid and then transmit it to the network. If I don't die by the time the transaction is valid, I have two ways of preventing the transaction from happening: either destroy the signed transaction - will never reach a block; or move the bitcoins to a new wallet - even if the txn will reach a block it won't be valid since it would be a double spend.

nLockTime doesn't really do the job, as I understand it.

What does it do then?

it is extremely important that some way be devised to send a percentage of bitcoin in a wallet, rather than an amount.

Or, alternatively, you can give each child an M key of N, and they must agree together how to send it. Each will have to sign separately with their key, and neither can "screw" the other.

[WiW]

Here is a discussion about it.  if you back up a few minutes they discuss the scripting language in general, this is the part about the "dead man's switch" that you discuss:
http://www.youtube.com/watch?v=TzhYB1jt30A&feature=player_detailpage#t=1360s

Precisely. Isn't this possible with lock_time?

[edmundedgar]

You folks aren't following. The transaction will be signed by the current living owner. It will only be transmitted to the network in the event of death. I sign a transaction, put it in my home. When I die and my family goes through my belongings, they will find the signed transaction and the receiving address. They will have to wait until the transaction is valid and then transmit it to the network. If I don't die by the time the transaction is valid, I have two ways of preventing the transaction from happening: either destroy the signed transaction - will never reach a block; or move the bitcoins to a new wallet - even if the txn will reach a block it won't be valid since it would be a double spend.

Just to add to that (and someone will correct me if I'm getting this wrong, I've never tried it) if you want to you can send the signed transaction out-of-band to the recipient, and then _they_ can transmit it to the network once the time is up. That way you don't have to rely on the people rifling through your belongings. Obviously once you've done that the "destroy the signed transaction" method of preventing it from happening won't work since the recipient already has a copy of the transaction, so when you get close to the lock time and discover that you're still alive you'll have to choose the "move the bitcoins to a new wallet" option to prevent your impatient heir from spending their inheritance before they inherit it.

[Dabs]

Digital or Electronic method.

1. Private keys stored encrypted. You could use RAR, or AxCrypt or TrueCrypt. Spread this. Give a flash drive to everyone.
2. Instructions on how to use. Complete tutorial for newbies as needed.
3. Use one of those delayed email services, deadmansswitch, email-from-future, etc. It will send the email (with the 64 character alphanumeric password) when you don't contact the system in 60 / 90 / whatever number of days.
4. As long as you are alive and conscious, log in to your service to tell them you are alive.

Paper method.

1. Print your private keys on paper. Seal the envelope. Tape it. Wax it.
2. Store in vault. Mark with "in case of death / emergency / whatever".

[edmundedgar]

Here is a discussion about it.  if you back up a few minutes they discuss the scripting language in general, this is the part about the "dead man's switch" that you discuss:
http://www.youtube.com/watch?v=TzhYB1jt30A&feature=player_detailpage#t=1360s

Precisely. Isn't this possible with lock_time?

I believe that feature was removed for the time being.  From what I understand it can be done but it will be up to your family to get a miner to include the transaction in a block as I don't think it will be done automatically with the current release.  Someone else can probably answer this better than me.

Per this thread:
https://bitcointalk.org/index.php?topic=23501.0
...lock time is implemented, and can be used.

What can't be used is the ability to replace transactions once they've been broadcast, but if I've got this right you can do what you need here by sending the signed, locked transaction to the recipient by email or whatever instead of broadcasting it to the network. That way the network should only ever see the transaction once, unless your heir tries to broadcast it too soon, in which case it should ignore it (Can anybody confirm if I've got this right?).

[BTC Books]

Y'see?  This is what I was talking about:  bullshit.  Lawyers, escrows, second and third parties, math, code, having relatives agree...

People have been dying for quite awhile as I understand it - and all these layers of legal bullshit we've placed on top of those deaths over the centuries have thankfully reduced fraud, legal disputes, and outright theft to near-zero, haven't they?  Oh... wait...

And so, on top of our existing pretty pathetic infrastructure of wealth inheritance, everyone in this thread is layering yet one more pile of bullshit on top of what is already known to be marginally effective at best:  a layer of incredibly complex mathematics, programming and cryptography.

It doesn't have to be like that.

Bitcoin has made so many things so simple and so inexpensive and so contractually bulletproof... there's no reason it can't do the same for inheritance.

A future-dated transaction in the blockchain that can be recalled only by the originator, and only before its date.

And the ability to send a percentage of coins in a wallet, rather than only an amount.

Seems pretty straightforward.

[edmundedgar]

Which means that the only way to do this effectively (and it really needs to be done) is to put a time-delayed transaction into the blockchain that can be recalled at any time before the trigger time - but only by whoever initiated the transaction; nobody else.  So no - this is by no means an idea that has anything to do with chargebacks.

Why do you think the transaction has to go into the blockchain right away? Why is it no good to communicate it directly to the recipient and let their software put it into the blockchain when the time is up?

Secondly - it is extremely important that some way be devised to send a percentage of bitcoin in a wallet, rather than an amount.  This will allow you to continue to use a wallet without worrying about having enough in it to cover a delayed transaction.  It means there won't be any leftovers that will disappear forever.  So if you have 1,000 bitcoin in your wallet and two kids to send bitcoin to in the event of your death, you send 50% to each - not 500 to each.  That means that if you run across something you want to buy you just buy it - without having to constantly change your Dead Man's Switch transaction every time your wallet balance changes.

This doesn't seem to fit very well with putting everything into the blockchain from the start, because the blockchain doesn't know about wallets - it knows about the component parts that wallets manage, like key pairs and inputs and outputs. In practice if you want the amount that you leave to your heirs to be able to vary, you're going to need your client software to manage this for you by either making or amending new transactions when your balance changes. This also feels like a case where you'd be better off leaving it out of the blockchain and communicating the signed transactions to your heirs out-of-band, which should be possible even with the network as it is, IIUC.

Obviously we'd hope that you'd have client software to make all this stuff easy so that the user doesn't have to worry about broadcasting signed raw transactions and what-not, but we'd need that either way.

[BTC Books]

Which means that the only way to do this effectively (and it really needs to be done) is to put a time-delayed transaction into the blockchain that can be recalled at any time before the trigger time - but only by whoever initiated the transaction; nobody else.  So no - this is by no means an idea that has anything to do with chargebacks.

Why do you think the transaction has to go into the blockchain right away? Why is it no good to communicate it directly to the recipient and let their software put it into the blockchain when the time is up?

Secondly - it is extremely important that some way be devised to send a percentage of bitcoin in a wallet, rather than an amount.  This will allow you to continue to use a wallet without worrying about having enough in it to cover a delayed transaction.  It means there won't be any leftovers that will disappear forever.  So if you have 1,000 bitcoin in your wallet and two kids to send bitcoin to in the event of your death, you send 50% to each - not 500 to each.  That means that if you run across something you want to buy you just buy it - without having to constantly change your Dead Man's Switch transaction every time your wallet balance changes.

This doesn't seem to fit very well with putting everything into the blockchain from the start, because the blockchain doesn't know about wallets - it knows about the component parts that wallets manage, like key pairs and inputs and outputs. In practice if you want the amount that you leave to your heirs to be able to vary, you're going to need your client software to manage this for you by either making or amending new transactions when your balance changes. This also feels like a case where you'd be better off leaving it out of the blockchain and communicating the signed transactions to your heirs out-of-band, which should be possible even with the network as it is, IIUC.

Obviously we'd hope that you'd have client software to make all this stuff easy so that the user doesn't have to worry about broadcasting signed raw transactions and what-not, but we'd need that either way.

Why do you think the transaction has to go into the blockchain right away? Why is it no good to communicate it directly to the recipient and let their software put it into the blockchain when the time is up?

It has to go into the blockchain because if it doesn't you need lawyers and communication and a recipient technically savvy enough to put it into transaction format.  I can think of any number of cases where a transaction just showing up in an heir's wallet is the best option - and several where it is the only acceptable option.  For example:

While you're still alive you have your intended heirs install clean wallets, which are intended just for their inheritance.  Say you have two kids... and also say you want to leave 20% of your bitcoin to one, and 80% to the other.  What happens if someone brings a lawyer into that after you're dead and can't control your own money - or if you stipulate in a will that nobody can contest it, but they do...?  Uh-huh.  That'll work great.  But with a Dead Man's Switch bitcoin inheritance, properly set up, nobody knows how much anybody else got.  And no lawyers get a cut, either.

As for the percentage thing - you're right.  The blockchain doesn't know about wallets.  And maybe that's not as absolute a requirement as a transactional Dead Man's Switch.  But it sure would be handy if it could be worked out.  I'm sure the Martingale freaks would love it. 

[edmundedgar]

It has to go into the blockchain because if it doesn't you need lawyers and communication and a recipient technically savvy enough to put it into transaction format.  I can think of any number of cases where a transaction just showing up in an heir's wallet is the best option - and several where it is the only acceptable option.  For example:

While you're still alive you have your intended heirs install clean wallets, which are intended just for their inheritance.  Say you have two kids... and also say you want to leave 20% of your bitcoin to one, and 80% to the other.  What happens if someone brings a lawyer into that after you're dead and can't control your own money - or if you stipulate in a will that nobody can contest it, but they do...?  Uh-huh.  That'll work great.  But with a Dead Man's Switch bitcoin inheritance, properly set up, nobody knows how much anybody else got.  And no lawyers get a cut, either.

What I'm saying (hopefully someone will jump in if I'm wrong) is that the Bitcoin protocol already supports Dead Man's Switch bitcoin inheritance, and you don't need lawyers to do it. Make a locked transaction, send it to the recipient, double-spend it before the lock time if you're still alive.

The difference between what you want and what the network would currently support is that you want to broadcast a transaction over the network and get it into a block, then cancel it, whereas currently you need to send it to the recipient (or anyone you like, several people if you prefer, it doesn't matter) without it getting into a block and have them broadcast it once the lock time is up. It's true that the latter is fiddly with the current client software, but the client software isn't set up to deal with the former either, since it's currently impossible... I suppose there's a difference to the extent that there's an extra step for the recipient (or somebody, it doesn't matter who), but there's no reason why it needs to be a difficult step.

Even now, that step should basically consist of pasting some text that you emailed them into:
http://blockchain.info/pushtx
...and hitting "Submit transaction". I suppose someone might want to make it so you can put the transaction body into the URL and send it as an email link, so they just have to click the link...

[BTC Books]

What I'm saying (hopefully someone will jump in if I'm wrong) is that the Bitcoin protocol already supports Dead Man's Switch bitcoin inheritance, and you don't need lawyers to do it. Make a locked transaction, send it to the recipient, double-spend it before the lock time if you're still alive.

Mmmm.  I didn't think it worked that way.  Nice if it does.

But of course, one of my other reasons for wanting the transaction to show up only after you're dead is to avoid getting killed by one of your heirs...    A depressing thought, I know - and yet it happens relatively (no pun intended) often.  If you send a locked transaction, the recipient knows the amount of it, yes?

[edmundedgar]

What I'm saying (hopefully someone will jump in if I'm wrong) is that the Bitcoin protocol already supports Dead Man's Switch bitcoin inheritance, and you don't need lawyers to do it. Make a locked transaction, send it to the recipient, double-spend it before the lock time if you're still alive.

Mmmm.  I didn't think it worked that way.  Nice if it does.

But of course, one of my other reasons for wanting the transaction to show up only after you're dead is to avoid getting killed by one of your heirs...    A depressing thought, I know - and yet it happens relatively (no pun intended) often.  If you send a locked transaction, the recipient knows the amount of it, yes?

Yes, but they'd also know that if you transmitted the transaction on the block-chain in the way you've suggested, since the block-chain is public and they must know their own Bitcoin address or they couldn't have given it to you.

If you wanted to get the raw transaction to them without them knowing about it you'd need some third-party person or service to look after the signed raw transaction for you and forward it to them (or broadcast it directly to the network) if you died. But unlike sending them private keys, that third-party wouldn't be able to do anything useful with that signed raw transaction like steal your money, as it would only be payable to your heir. And you could make multiple copies of the transaction and entrust them with several different people to pass on, in case one of them posthumously let you down or got run over by the same bus as you.

[Realpra]

A similar mechanism could be used for pensions where it forces you to not spend the money until you are ~60.

It would be best to update the Bitcoin script system a bit, but otherwise you could program a smartcard to have the 50% tx behavior aswell as a timelock.
Of course if you died before expected the card would remain locked until the time you set.

[BTC Books]

What I'm saying (hopefully someone will jump in if I'm wrong) is that the Bitcoin protocol already supports Dead Man's Switch bitcoin inheritance, and you don't need lawyers to do it. Make a locked transaction, send it to the recipient, double-spend it before the lock time if you're still alive.

Mmmm.  I didn't think it worked that way.  Nice if it does.

But of course, one of my other reasons for wanting the transaction to show up only after you're dead is to avoid getting killed by one of your heirs...    A depressing thought, I know - and yet it happens relatively (no pun intended) often.  If you send a locked transaction, the recipient knows the amount of it, yes?

Yes, but they'd also know that if you transmitted the transaction on the block-chain in the way you've suggested, since the block-chain is public and they must know their own Bitcoin address or they couldn't have given it to you.

If you wanted to get the raw transaction to them without them knowing about it you'd need some third-party person or service to look after the signed raw transaction for you and forward it to them (or broadcast it directly to the network) if you died. But unlike sending them private keys, that third-party wouldn't be able to do anything useful with that signed raw transaction like steal your money, as it would only be payable to your heir. And you could make multiple copies of the transaction and entrust them with several different people to pass on, in case one of them posthumously let you down or got run over by the same bus as you.

Yes.  * sigh *  Not really ideal.  Well, maybe someday.  The devs will get old and start thinking about such things...

[BTC Books]

A similar mechanism could be used for pensions where it forces you to not spend the money until you are ~60.

It would be best to update the Bitcoin script system a bit, but otherwise you could program a smartcard to have the 50% tx behavior aswell as a timelock.
Of course if you died before expected the card would remain locked until the time you set.

That wouldn't matter.

How does this smartcard idea work?  Are there any that will do it now, or are we waiting on Mycellium?

[edmundedgar]

Yes.  * sigh *  Not really ideal.  Well, maybe someday.  The devs will get old and start thinking about such things...

You want them to come up with a way to publish a transaction on a public network, while keeping it secret from the recipient?

[BTC Books]

Yes.  * sigh *  Not really ideal.  Well, maybe someday.  The devs will get old and start thinking about such things...

You want them to come up with a way to publish a transaction on a public network, while keeping it secret from the recipient?

Yes, if at all possible.

Rather than 'publish', the word I would use is 'insert'.

* sigh *  Maybe the best option is to deliver the paper backup for an Armory wallet, with instructions.

I've really been hoping for something more elegant though.

[WiW]

Y'see?  This is what I was talking about:  bullshit.  Lawyers, escrows, second and third parties, math, code, having relatives agree...

People have been dying for quite awhile as I understand it - and all these layers of legal bullshit we've placed on top of those deaths over the centuries have thankfully reduced fraud, legal disputes, and outright theft to near-zero, haven't they?  Oh... wait...

You're missing the simplicity of this method.

I, the living subject, once a year, sign a transaction from my savings wallet(s) to a receiving wallet. This transaction is time locked to a year in the future. I take the signed transaction(s) along with the private key of the receiving address, and give them to my relatives (or put them in a place they will find), simple instructions included. I time locked the transaction, so they can't do anything with these until a year in the future. Before renewing the transaction next year, I will invalidate the one I made last year. How? I simply spend the coins by moving them to new addresses (making the signed transaction a double spend).

The relative either finds or knows about this inheritance plan, and will simply need to broadcast the transaction to the network once a certain block is reached. Viola! They got their inheritance, no lawyer or escrow needed.