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 >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
