📅 Original date posted:2023-03-13 🗒️ Summary of this message: A proposed BIP for a deposit -> withdrawal -> resolve(claim/clawback) wallet paradigm is deemed too complicated for everyday use and may harm privacy. A new approach is suggested. 📝 Original message: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 at 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 at 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 > (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: > > > > > github.com/jamesob/bips/blob/jamesob-23-02-opvault/bip-vaults.mediawiki > > > > The corresponding PR is here: > > > > 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]: > > > lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021318.html > > [1]: github.com/bitcoin/bitcoin/pull/26857 > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev at lists.linuxfoundation.org > > lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230313/1ee9a035/attachment.html>