Quote from: ETFbitcoin on September 19, 2019, 06:53:23 PM

Your solution still falls on type 3 if you didn't mention wallet which automate the process. Even so, it requires both Alice and Bob use same wallet, unless there's standard (such as BIP) where other wallet might adopt the standard.

It still shouldn't fall on type 3 as there is no need to move bitcoins onchain to new CSV locked output when current one expires for heir. Owner watches if transaction was not broadcasted and organizes transaction and scripts delivery to heir, but never puts it onchain and pays fees. However, I agree that there is still a need to create this wallet functionality or the BIP, which may be even better.

Quote from: ETFbitcoin on September 19, 2019, 06:53:23 PM

This parts is similar with LN network where dishonest user attempt to broadcast earlier state of channel, which require honest user online 24/7 or use watchtower.
And AFAIK your idea suffer same problem.

Lightning network lock period is much smaller (no more that a few days, if I'm not mistaken) than that of which can be used in the schema. For example, 3 months locking on the output of broadcasted transaction should not bee too big period for heir to wait before getting full control over the bitcoins and, in the same time, this will not make owner to be online 24/7 or use watchtower. A manual check one time in a month should be enough in this case.

Quote from: Andriian on September 19, 2019, 12:28:50 PM

AFAIK there aren't any wallet which allow you make P2SH/P2WSH transaction.

Neither do I, if not take into account simple M-of-N multisigs which are technically P2SH/P2WSH.

Quote from: Andriian on September 19, 2019, 12:28:50 PM

Quote from: lightningmelo on September 19, 2019, 05:44:29 PM

I don't know of anything that exists with bitcoin script, but there's FinalMessage.io which is a custodial dead man switch, might want to check that one out

But then we're back to the older problem where higher degree of trust is required.

Yes a service type like FinalMessage.io has disadvantages as higher degree of trust. However it doesn't look to be custodial which can have full control of owner's funds. It keeps only 1 key in 2-of-3 multisig schema. So it may cause funds to be forever lost but not stolen.
Apart from that, such kind of service has other advantages comparing to the proposed schema:

Better privacy: A service will never know which are actual owner addresses and balances. This will not happen even in the case when one of three private keys is decrypted somehow by service. It will never know all three public keys to construct 2-of-3 multisig hash which is an owner address.
Better privacy again: A heir will not know which is actual owner address and balances up until receiving the private key from the service. Here we assume that heir already has 1 private and public key and other owner's public key, so missing only one public key (to be derived from service private key)

So that may be personal owner preferences what is more essential for her: privacy or no third-party dependency.

P.S. This brings up an interesting task of third-party decentralization with minimal overhead, to take the best of both approaches.