Quote from: n0nce on January 11, 2022, 11:47:38 PM

To me this sounds a bit like Lightning Network, where you send back and forth transactions representing the current channel state that can be published at any time and include a lock time so cheating attempts can be detected and mitigated if checking in often enough.

If it's implemented the same way as in LN commitments, it should work fine. By resending a new transaction from time to time, it can also account for mining fee fluctuations and with long enough lock time it won't require a watchtower or checking in manually way too often.

Yes it works the same way as Lightning Network in terms of cheating attempts detection. And that is true that mining fee is something that should be taken care of. However, not necessarily you need to monitor fee fluctuations and resend new transaction to Heir from time to time. It should be possible to construct such a transaction that you solve it once and forever. The ways to do it I can think off:

You can construct not one transaction but many of them with different fees so Heir is to choose which one is the best when it is time to broadcast
You can sign the transaction by not covering all inputs and outputs. e.g. SIGHASH_SINGLE|SIGHASH_ANYONECANPAY signing rules can help you with that. So Heir is able to add some inputs and outputs to increase fee.
Child Pays For Parent technique

Quote from: n0nce on January 11, 2022, 11:47:38 PM

I don't think the 'escrow address' is really needed; the commitments can send money directly to the kid's address (with lock time on the utxo though), just as in LN.

But if you send money directly to the kid's address with lock time on the utxo then you need to "move" bitcoins to new locked utxo each time when the time is close enough. In the approach proposed you don't need to move anything but just monitor from time to time. The latter is 1) more convenient: faster than signing and broadcasting, can be automated via watchtower services 2) more secure: you don't need to deal with you private keys.
Note that there is no "lock time" (nLockTime + CheckLockTimeVerify) in this protocol. What is used is "relative locktime" (nSequence + CheckSequenceVerify) according to the Bitcoin spec https://en.bitcoin.it/wiki/Timelock

Quote from: n0nce on January 11, 2022, 11:47:38 PM

What I think would make more sense implementation-wise (as also suggested in the other thread); would be simplifying to e.g. a shellscript that creates those transactions which can then be submitted with any client you want. The commitments can be transferred however secure way one prefers, which can be PGP encrypted e-mails, encrypted messengers or whatever. If this is really for the sake of inheritance, it can't be based on a phone app that itself (and / or its servers) might not be around by the time someone using it actually dies and wants to inherit their coins.

Not sure I understand about the shellscript and in which cases it may be more convenient (for non-technical user) than UI app. Can you please share me the thread by the way.
That is true that you can't rely on your phone as a Heir. Mobile app customisation is just the best way we found to implement the concept and let everyone try and feel how it works. For real production ready implementation there should be some software support to backup not only Heir's private keys but the transactions as well, hardware wallet support for better security, dealing with changing UTXO set on Owner's side, etc. All that we can figure out looks implementation-feasible unless someone can point if we missed something here.

Quote from: n0nce on January 11, 2022, 11:47:38 PM

Off-topic, but not sure if you need to cryptographically secure your BTC from someone you want to inherit it to. Like, this whole mechanism (over e.g. leaving behind an instruction on how to just get access to your wallet(s)) is to make sure they don't try to steal your coins before you die. Not sure I'd want to inherit my holdings to a person that I feel could try stealing my possessions.

Fair enough. However, even if someone fully trusts heirs, there is still a risk of compromise Heir's private key and inheritance info so an attacker can steal money. Yes, this approach still does not guarantee that 100% but at least makes it much harder for the attacker IMHO.
As other argument, I think there should be some subset of Owners that can't fully trust Heirs. For example, people sometimes change in worse way some day or just hide their nature. Don't believe this happen too often but, still, this may be a subject to market research to have more precise data about customer needs.
And finally, a Heir is not obligatory a physical person. It can be a some company or charity fund. I such a case, I think, there are even less guarantees that the Heir entity behaves honestly all the time in the future because you may deal with more than one specific person belonging to the organisation. An Owner may not be sure about all of them but it is still better for him to allow the company inherit when the time comes than BTC to be lost forever for everyone.