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