For the fee, a one-input one output transaction isn't that expensive even with an overpay 50+ sat/B fee, average of 200B, that's 0.0001 per update.
Trice a year or Quarterly, it won't be too expensive (plus the fee rate could be lower than 50).
Good point. It may be not that expensive when there is re-sending of only one or a few outputs. But it can be more expensive if Alice needs keep her funds split to many outputs for privacy purpose. However, some additional analysis is needed here.
For the complexity, it will only became complex if Alice accidentally broadcasted the transaction prematurely,
that would require her to clear her node's mempool or wait for it to expire (
and -zapwallettxes) to re-spend the input(s) involved.
Otherwise, She can just create another tx to "
extend" the lock-time since Bob's or others' node
won't accept/relay that particular TX.
Sorry, I didn't get the point here.
type 3 is about this kind of locking script where Alice can spend anytime:
OP_IF
OP_CHECKSIG
OP_ELSE
OP_CSV DROP OP_CHECKSIG
OP_ENDIF
I guess, this statement should partially make sense for Bob but not Alice.
Basically, in terms of complexity I mean that:
1)
Leave bitcoins where they are. Alice does not even need to move funds to new locking script when she enables this kind of recovery. Just leave bitcoins in the same outputs where they are. That may be important for business needs with technical dependencies on existing set of addresses / UTXOs.
2)
May reduce error prone / inconvenient operations: Sign and transfer to Bob new incoming payments (not urgent) but no regular re-spends of each output (urgent before deadline). Especially if Alice herself represents multisig schema of M-of-N partners.
3)
Reverse watching. In
type 3 Bob may watch Alice via chain if she forgets to re-spend. Alice has no idea if he's watching. In new proposal that is vice versa. Alice is watching if Bob abuses her trust.