pull down to refresh

Bitcoin is programmable money and there are fascinating Bitcoin script mechanics that I am exploring. The idea of a "dead man's switch" in Bitcoin intrigues me. Let's say for sake of example that your heirs include your spouse and child. And you want them to receive your Bitcoin upon your passing. One can set up a multi-sig wallet where 3 of 5 seeds are required to sign a transaction. These 5 seeds can be distributed, 1 seed to your spouse, 1 seed to your child and you have your remaining 3 seeds properly secured. You can spend money at any time with 3 of 5. Your heirs cannot, they only have 2. You keep your 3 seeds hidden from them, but if when you die, that is, you do not sign a transaction for 52596 blocks ~1 year, then you can program the multi-sig to revert to 2 of 5. You have trained them and instructed them to sign a transaction once a year. However, once again, if both do not sign, then after another 52596 blocks, the multi-sig reverts to 1 of 5. Now any of the 5 seeds can sign, so either one of your heirs can sign. There is nothing preventing you from clocking another year and then further transferring the funds to the charity wallet of your choice, among an infinity of other options.
This reduces the possibility of lost seeds and lost funds. The Bitcoin script mechanics may look like this:
IF <52596> OP_CHECKSEQUENCEVERIFY OP_DROP // First timelock, approx 1 year 3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG ELSE <52596> OP_CHECKSEQUENCEVERIFY OP_DROP // Second timelock, another approx 1 year IF 2 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG ELSE 1 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG ENDIF ENDIF
I recognize that this transaction is not "standard" and may require custom wallet development to support automatic renewal of conditions.
The time frame is a parameter that can be set according to your will (pun intended). Obviously this would need to be tested extensively on testnet prior to blindly exposing your wealth to this script. I think that the idea holds theoretically, and this would serve as a template for a "dead mans switch". We can get much more sophisticated than this, such as after a given period of time, DCA so that funds are not available as a lump sum but distributed over time, but the Bitcoin script mechanics support such things and I think it is a really interesting area of research that removes lawyers from your estate planning and wealth distribution objectives.
Another aspect of this is that no force in the world can change or alter the rules you set. And once you set that script, not even you, the author, can revert it. No lawyer, court, judge, army, military, or the combined compute power of google, amazon, microsoft & the NSA can do a damn thing to change these rules.
You could distribute a diminishing amount of Bitcoin every month for a century if you so choose creating an absolutely unbreakable legacy.
@supertestnet - would greatly appreciate your feedback on the script mechanics.
Reviewing your script, I think it has two problems:
(1) it appears like the 3 of 5 option has to wait a year. Based on your description, I don't think that's what you want. You said, "You can spend money at any time with 3 of 5." But the script for the 3 of 5 has a 1 year timelock just like the one for the non-3-of-5.
(2) It appears like the 2-of-5 script and the 1-of-5 script are currently encumbered by an identical timelock. Which means the 1-of-5 person can take the money after waiting only 1 year. Based on your description, I don't think that's what you want. You said, "after another 52596 blocks, the multi-sig reverts to 1 of 5," and I think by "another 52596 blocks" you mean "an additional 52596 blocks."
To fix these issues, you could rewrite the script like this:
IF //this branch requires no timelock at all, so the 3 of 5 can spend at any time 3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG ELSE //the following branches are encumbered by different timelocks IF //if you only have 2 keys out of 5, you have to wait 1 year //but the 3 of 5 can renew the 1 year wait time by spending the money //before the year is up using the branch above this one <52596> OP_CHECKSEQUENCEVERIFY OP_DROP 2 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG ELSE //if you only have 1 key out of 5, you have to wait 2 years //but the 3 of 5 can renew the 2 year wait time by spending the money //before the 2 years are up using the first branch //and the 2 of 5 can also renew the 2 year wait time by spending the money //before the 2 years are up using the branch above this one //though only after themselves waiting at least 1 year <105192> OP_CHECKSEQUENCEVERIFY OP_DROP 1 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5 OP_CHECKMULTISIG ENDIF ENDIF
reply
This is very helpful! I really enjoy these OP code puzzles that solve established use cases. Cheers!
reply
50 sats \ 1 reply \ @nym 14 Jan
Anchor Watch is doing some work in this space
reply
Thanks for the reference. WIll take a look.
reply