📅 Original date posted:2023-03-13
🗒️ Summary of this message: Brandon suggests replacing the internal key with a hardcoded NUMS point to enable batching of multiple vault inputs with the same scriptpubkey.
📝 Original message: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
Brandon Black [ARCHIVE] /
npub1tx…grmss
2023-06-07 23:20:08
in reply to nevent1q…8vzz
Author Public Key
npub1txgfckk6qxy5yh6c7sag0m4sjycag8fn9xx7jj5efpf05s7ztt7s5grmssPublished at
2023-06-07 23:20:08Event JSON
{
"id": "6e7aa36efc0e4eef017d14f5f6fce3fe90ef4b6eae577b2a5999f9ffd391d607",
"pubkey": "59909c5ada0189425f58f43a87eeb09131d41d33298de94a994852fa43c25afd",
"created_at": 1686180008,
"kind": 1,
"tags": [
[
"e",
"647fc7db9ce6599535c0921f7a07494f1213a0b3b646951b297e97e004c8718e",
"",
"root"
],
[
"e",
"b659bf08396e444bca99dc9831a901249c02c569d3d11abea278960b44102210",
"",
"reply"
],
[
"p",
"745e2723e72d7ded3f0dd293d710b706cd302ab8476983c292d4bdb7f9c5d366"
]
],
"content": "📅 Original date posted:2023-03-13\n🗒️ Summary of this message: Brandon suggests replacing the internal key with a hardcoded NUMS point to enable batching of multiple vault inputs with the same scriptpubkey.\n📝 Original message:Hi Gents,\n\n\u003e \u003e I don't think replacing the internal-public-key makes sense -- if it\n\u003e was immediately spendable via the keypath before there's no reason for\n\u003e it not to be immediately spendable now.\n\u003e \n\u003e Slavishly following the current proposal was the idea to make sure all\n\u003e functionality was captured; I agree with this change.\n\nI think we do need to replace the internal key with a hardcoded NUMS\npoint to allow us to batch multiple vault inputs which might have\ndifferent internal keys but the same OP_FLU/OP_VAULT_TRIGGER script to\nthe same time+template-restricted output.\n\nI like that in James' current PR proposal we can explicitly batch via\nthe implied input/output summation rules while avoiding address reuse.\nIf we can retain some or all of that, I think it would be good for on\nchain efficiency and potentially privacy.\n\nMy thoughts on batching:\n\nMany inputs with different internal keys can be combined to satisfy the\ntotal output value for a single output, as long as their scriptpubkeys\nwith FLU and NUMS internal key are equal This enables avoiding address\nreuse within the vault.\n\nMany inputs with the same scriptpubkey can be combined to satisfy a\nsingle CTV output template. This allows a user to unfsck themselves if\nthey initiate a withdrawal that cannot be satisfied because they didn't\nsend enough sats to satisfy their template.\n\nBest,\n\n--Brandon",
"sig": "53f422ed7b9b4776d1ac07fb16fc152dfc87f4a67a46785547f72bf699bffe15977be1a4239d6d1d82233f3b6f052c819f1d50cdbcd5b8f0dc76c1243e51cb45"
}