In ordinary use cases, you wouldn't clawback; that would only be in the 
extreme case of the wallet being compromised. So typical usage would 
just be receive -> send, like wallets currently do.

Luke


On 3/13/23 10:56, Greg Sanders wrote:
> Didn't finish sentence: but in practice would end up with pretty 
> similar usage flows imho, and as noted in PR, would take a different 
> wallet paradigm,
> among other technical challenges.
>
> On Mon, Mar 13, 2023 at 10:55 AM Greg Sanders <gsanders87@gmail.com> 
> wrote:
>
>     Hi Luke,
>
>     Can you elaborate why the current idealized functionality of
>     deposit -> trigger -> withdrawal is too complicated for
>     everyday use but the above deposit -> withdrawal ->
>     resolve(claim/clawback)  wouldn't be? I admit at a high level
>     it's a fine paradigm, but in practice would end
>
>     Let's ignore implementation for the discussion, since that's in flux.
>
>     Cheers,
>     Greg
>
>     On Sat, Mar 11, 2023 at 3:53 PM Luke Dashjr via bitcoin-dev
>     <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>         I started reviewing the BIP, but stopped part way through, as
>         it seems
>         to have a number of conceptual issues.
>
>         I left several comments on the PR
>         (https://github.com/bitcoin/bips/pull/1421#pullrequestreview-1335925575),
>
>         but ultimately I think it isn't simplified enough for
>         day-to-day use,
>         and would harm privacy quite a bit.
>
>         Instead, I would suggest a new approach where:
>
>         1) Joe receives funds with a taproot output like normal.
>         2) Joe sends funds to Fred, but Fred cannot spend them until N
>         blocks
>         later (covenant-enforced relative locktime). Ideally, this should
>         use/support a taproot keypath spend somehow. It would be nice
>         to blind
>         the particular relative locktime somehow too, but that may be
>         too expensive.
>         2b) If Joe's funds were stolen, Joe can spend Fred's UTXO
>         within the N
>         block window to a recovery output.
>
>         Unfortunately, the implementation details for this kind of
>         setup are
>         non-obvious and will likely require yet another address format
>         (or at
>         least recipient-wallet changes), but certainly seems within
>         the scope of
>         possibility.
>
>         Thoughts?
>
>         Luke
>
>
>         On 2/13/23 16:09, James O'Beirne via bitcoin-dev wrote:
>         > Since the last related correspondence on this list [0], a
>         number of
>         > improvements have been made to the OP_VAULT draft [1]:
>         >
>         > * There is no longer a hard dependence on package
>         relay/ephemeral
>         >   anchors for fee management. When using "authorized
>         recovery," all
>         >   vault-related transactions can be bundled with unrelated
>         inputs and
>         >   outputs, facilitating fee management that is self
>         contained to the
>         >   transaction. Consequently, the contents of this proposal
>         are in theory
>         >   usable today.
>         >
>         > * Specific output locations are no longer hardcoded in any
>         of the
>         >   transaction validation algorithms. This means that the
>         proposal is now
>         >   compatible with future changes like SIGHASH_GROUP, and
>         >   transaction shapes for vault operations are more flexible.
>         >
>         > ---
>         >
>         > I've written a BIP that fully describes the proposal here:
>         >
>         >
>         https://github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki
>         >
>         > The corresponding PR is here:
>         >
>         > https://github.com/bitcoin/bips/pull/1421
>         >
>         > My next steps will be to try for a merge to the inquisition
>         repo.
>         >
>         > Thanks to everyone who has participated so far, but
>         especially to AJ and
>         > Greg for all the advice.
>         >
>         > James
>         >
>         > [0]:
>         >
>         https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html
>         > [1]: https://github.com/bitcoin/bitcoin/pull/26857
>         >
>         > _______________________________________________
>         > bitcoin-dev mailing list
>         > bitcoin-dev@lists.linuxfoundation.org
>         > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>         _______________________________________________
>         bitcoin-dev mailing list
>         bitcoin-dev@lists.linuxfoundation.org
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>