Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2023-03-14 🗒️ Summary of this message: Discussion on ...
📅 Original date posted:2023-03-14
🗒️ Summary of this message: Discussion on privacy and efficiency in Bitcoin vaults, including rotating trigger authorization keys and batching multiple inputs with different internal keys.
📝 Original message:Hi Brandon,
Thank you for chiming in, causing me to think a bit more deeply on the
privacy issues
and what seems possible.
> I like that in James' current PR proposal we can explicitly batch via
the implied input/output summation rules while avoiding address reuse.
If we can retain some or all of that, I think it would be good for on
chain efficiency and potentially privacy.
Rotating trigger authorization keys maintains batchability and stops
address reuse.
Remember that anytime you share any path, like recovery path, for batching,
it becomes
obvious at spend-time. Rotating inner pubkeys only doesn't seem to help
much.
Coinjoins being the other batching scenario which could benefit perhaps are
quite a heavy
lift. You'd need the recovery policy(every other branch) to be agreed upon,
have everyone unvault
to this new joint vault, then mix, and withdrawal back to the original
vault. If someone is going through
all that effort, I suspect they'll just use a NUMS to reduce fingerprinting.
> Many inputs with different internal keys can be combined to satisfy the
total output value for a single output, as long as their scriptpubkeys
with FLU and NUMS internal key are equal This enables avoiding address
reuse within the vault.
To reiterate, we can just cycle any key in the $trigger branch with OP_FLU,
which accomplishes the same thing.
Or in authorization-less $trigger, add a random number which is dropped.
> Many inputs with the same scriptpubkey can be combined to satisfy a
single CTV output template. This allows a user to unfsck themselves if
they initiate a withdrawal that cannot be satisfied because they didn't
send enough sats to satisfy their template.
I think that would fit the deprecated OP_FORWARD_OUTPUTS, but OP_CTV
commits to total
number of inputs to remove txid malleability. I think the real solution to
this mistake would be to hit
the big red RECOVERY button that you're relying on for vault security
anyways.
Cheers,
Greg
On Mon, Mar 13, 2023 at 3:04 PM Brandon Black <freedom at reardencode.com>
wrote:
> Hi Gents,
>
> > > I don't think replacing the internal-public-key makes sense -- if it
> > was immediately spendable via the keypath before there's no reason for
> > it not to be immediately spendable now.
> >
> > Slavishly following the current proposal was the idea to make sure all
> > functionality was captured; I agree with this change.
>
> I think we do need to replace the internal key with a hardcoded NUMS
> point to allow us to batch multiple vault inputs which might have
> different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to
> the same time+template-restricted output.
>
> I like that in James' current PR proposal we can explicitly batch via
> the implied input/output summation rules while avoiding address reuse.
> If we can retain some or all of that, I think it would be good for on
> chain efficiency and potentially privacy.
>
> My thoughts on batching:
>
> Many inputs with different internal keys can be combined to satisfy the
> total output value for a single output, as long as their scriptpubkeys
> with FLU and NUMS internal key are equal This enables avoiding address
> reuse within the vault.
>
> Many inputs with the same scriptpubkey can be combined to satisfy a
> single CTV output template. This allows a user to unfsck themselves if
> they initiate a withdrawal that cannot be satisfied because they didn't
> send enough sats to satisfy their template.
>
> Best,
>
> --Brandon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230314/b2e848e8/attachment.html>;
🗒️ Summary of this message: Discussion on privacy and efficiency in Bitcoin vaults, including rotating trigger authorization keys and batching multiple inputs with different internal keys.
📝 Original message:Hi Brandon,
Thank you for chiming in, causing me to think a bit more deeply on the
privacy issues
and what seems possible.
> I like that in James' current PR proposal we can explicitly batch via
the implied input/output summation rules while avoiding address reuse.
If we can retain some or all of that, I think it would be good for on
chain efficiency and potentially privacy.
Rotating trigger authorization keys maintains batchability and stops
address reuse.
Remember that anytime you share any path, like recovery path, for batching,
it becomes
obvious at spend-time. Rotating inner pubkeys only doesn't seem to help
much.
Coinjoins being the other batching scenario which could benefit perhaps are
quite a heavy
lift. You'd need the recovery policy(every other branch) to be agreed upon,
have everyone unvault
to this new joint vault, then mix, and withdrawal back to the original
vault. If someone is going through
all that effort, I suspect they'll just use a NUMS to reduce fingerprinting.
> Many inputs with different internal keys can be combined to satisfy the
total output value for a single output, as long as their scriptpubkeys
with FLU and NUMS internal key are equal This enables avoiding address
reuse within the vault.
To reiterate, we can just cycle any key in the $trigger branch with OP_FLU,
which accomplishes the same thing.
Or in authorization-less $trigger, add a random number which is dropped.
> Many inputs with the same scriptpubkey can be combined to satisfy a
single CTV output template. This allows a user to unfsck themselves if
they initiate a withdrawal that cannot be satisfied because they didn't
send enough sats to satisfy their template.
I think that would fit the deprecated OP_FORWARD_OUTPUTS, but OP_CTV
commits to total
number of inputs to remove txid malleability. I think the real solution to
this mistake would be to hit
the big red RECOVERY button that you're relying on for vault security
anyways.
Cheers,
Greg
On Mon, Mar 13, 2023 at 3:04 PM Brandon Black <freedom at reardencode.com>
wrote:
> Hi Gents,
>
> > > I don't think replacing the internal-public-key makes sense -- if it
> > was immediately spendable via the keypath before there's no reason for
> > it not to be immediately spendable now.
> >
> > Slavishly following the current proposal was the idea to make sure all
> > functionality was captured; I agree with this change.
>
> I think we do need to replace the internal key with a hardcoded NUMS
> point to allow us to batch multiple vault inputs which might have
> different internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to
> the same time+template-restricted output.
>
> I like that in James' current PR proposal we can explicitly batch via
> the implied input/output summation rules while avoiding address reuse.
> If we can retain some or all of that, I think it would be good for on
> chain efficiency and potentially privacy.
>
> My thoughts on batching:
>
> Many inputs with different internal keys can be combined to satisfy the
> total output value for a single output, as long as their scriptpubkeys
> with FLU and NUMS internal key are equal This enables avoiding address
> reuse within the vault.
>
> Many inputs with the same scriptpubkey can be combined to satisfy a
> single CTV output template. This allows a user to unfsck themselves if
> they initiate a withdrawal that cannot be satisfied because they didn't
> send enough sats to satisfy their template.
>
> Best,
>
> --Brandon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230314/b2e848e8/attachment.html>;