There are many ways if he rely on trusted people or 3rd party which already mentioned by others.
Otherwise, the closest things that i could think is using P2SH transaction/bitcoin script where the receiver only can claim the Bitcoin after n days/blocks. To prevent claim abuse while he's still alive, he could remake the script with different timelock before current timelock is "expired".
The rough code should look like this (i'm still learning bitcoin script, so most likely it's inaccurate) :
With above modification (DROP opcode is mandatory here and added by me), this is the ultimate solution.Otherwise, the closest things that i could think is using P2SH transaction/bitcoin script where the receiver only can claim the Bitcoin after n days/blocks. To prevent claim abuse while he's still alive, he could remake the script with different timelock before current timelock is "expired".
The rough code should look like this (i'm still learning bitcoin script, so most likely it's inaccurate) :
Code:
OP_IF
OP_CHECKSIG
OP_ELSE
<90 days> OP_CSV DROP OP_CHECKSIG
OP_ENDIF
OP_CHECKSIG
OP_ELSE
<90 days> OP_CSV DROP OP_CHECKSIG
OP_ENDIF
I keep forgetting add
That said, besides including its hash in the output script of her P2SH transaction, Alice has to give above redeem script to Bob somehow and she should keep updating Bob regularly about the latest redeem script version. One solution may be to treat the whole process like part a formal will. In 90 days after Alice has passed, Bob would be able to claim the balance using the latest redeem script he has received.
The code shows the beauty of CHECKSEQUENCEVERIFY opcode and its wide range of applications. unlike legacy nLockTime alternative which is transaction level and prevents the whole transaction from getting into blockchain and being effective, OP_CSV provides locking mechanism for tx outputs which makes such applications possible.
The code shows the beauty of CHECKSEQUENCEVERIFY opcode and its wide range of applications. unlike legacy nLockTime alternative which is transaction level and prevents the whole transaction from getting into blockchain and being effective, OP_CSV provides locking mechanism for tx outputs which makes such applications possible.
Aside from process where Bob give his public key to Alice for first time, Alice could write a script which :
1. Make exactly same script, expect timestamp/block height modified for next 90 days
2. Spend Bitcoin from older P2SH transaction and send it to same address with new script
3. Send newer script to Bob (through email perhaps)
Additionally, Alice could send the script only one time to Bob and said she always add value for OP_CSV time with +12960 (block) or +7776000 (timestamp) every transaction "refresh", so continues communication or 3rd party dependency can be removed as Bob simply need to know how many "refresh" happens.
P.S.
I just don't get it by the way, why should we continue arguing once the solution has been presented?. The post I quoted from @ETFbitcoin was submitted few hours after op, I suppose.
I just don't get it by the way, why should we continue arguing once the solution has been presented?. The post I quoted from @ETFbitcoin was submitted few hours after op, I suppose.
No idea, HeRetiK and me already give the solutions through different method.