Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-16 🗒️ Summary of this message: Greg suggests a ...
📅 Original date posted:2023-03-16
🗒️ Summary of this message: Greg suggests a single key hot wallet or MuSig2/FROST wallet with OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG for simple single key cases. This allows funds to be spent by a single key after a time delay, and rate-limiting can be added using OP_FORWARD_* opcodes. However, this does not extend to OP_CHECKSIGADD, and a recursive taproot or proper replacement for Bitcoin script may be needed for generalization.
📝 Original message:Hi Luke,
I think this works as with OP_FLU based construct, for the simplest single
key case.
e.g., single key hot wallet(or MuSig2/FROST wallet)
<hot_pubkey> 1 "<time-delay> OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG"
OP_FORWARD_LEAF_UPDATE
The <hot_pubkey> is appended at spending time.
This allows the utxo to go to $recover cold storage at any point like
before, otherwise the time matures and the funds can be spent by a single
key. Rate-limiting like usual can be bolted on as well using OP_FORWARD_*
opcodes, I'm pretty sure. This would as you note require wallet support,
where the hot wallet would have to be aware of the vault, or be scanning
inputs looking for this type of leaf.
Unfortunately this doesn't extend to things like OP_CHECKSIGADD, since the
pubkeys are all pushed first, then the opcodes run. OP_CHECKMULTISIG would
have worked probably.
To generalize I think you'd need recursive taproot, or a proper replacement
for Bitcoin script :)
Cheers,
Greg
On Mon, Mar 13, 2023 at 4:55 PM Luke Dashjr <luke at dashjr.org> wrote:
> 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
>>> (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 at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230316/89c8d041/attachment.html>;
🗒️ Summary of this message: Greg suggests a single key hot wallet or MuSig2/FROST wallet with OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG for simple single key cases. This allows funds to be spent by a single key after a time delay, and rate-limiting can be added using OP_FORWARD_* opcodes. However, this does not extend to OP_CHECKSIGADD, and a recursive taproot or proper replacement for Bitcoin script may be needed for generalization.
📝 Original message:Hi Luke,
I think this works as with OP_FLU based construct, for the simplest single
key case.
e.g., single key hot wallet(or MuSig2/FROST wallet)
<hot_pubkey> 1 "<time-delay> OP_CHECKSEQUENCEVERIFY OP_DROP OP_CHECKSIG"
OP_FORWARD_LEAF_UPDATE
The <hot_pubkey> is appended at spending time.
This allows the utxo to go to $recover cold storage at any point like
before, otherwise the time matures and the funds can be spent by a single
key. Rate-limiting like usual can be bolted on as well using OP_FORWARD_*
opcodes, I'm pretty sure. This would as you note require wallet support,
where the hot wallet would have to be aware of the vault, or be scanning
inputs looking for this type of leaf.
Unfortunately this doesn't extend to things like OP_CHECKSIGADD, since the
pubkeys are all pushed first, then the opcodes run. OP_CHECKMULTISIG would
have worked probably.
To generalize I think you'd need recursive taproot, or a proper replacement
for Bitcoin script :)
Cheers,
Greg
On Mon, Mar 13, 2023 at 4:55 PM Luke Dashjr <luke at dashjr.org> wrote:
> 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
>>> (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 at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230316/89c8d041/attachment.html>;