📅 Original date posted:2023-06-16
🗒️ Summary of this message: Greg suggests using the TLV format for annex-vaults, which can be relaxed in the future, and limiting the maximum size to 256 bytes.
📝 Original message:
Hi Joost,
I haven't thought a ton about the specific TLV format, but that seems like
a reasonable place to start as it shouldn't unduly
impact current users, and is pretty simple from an accounting perspective.
It also can be further relaxed in the future if we so decide by using max
tx size policy "hints" in an annex field.
I'll let others chime in at this point!
Cheers,
Greg
On Fri, Jun 16, 2023 at 7:27 AM Joost Jager <joost.jager at gmail.com> wrote:
> Hi Greg,
>
> On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders <gsanders87 at gmail.com>
> wrote:
>
>> > Would it then still be necessary to restrict the annex to a maximum
>> size?
>>
>> I think it's worth thinking about to protect the opt-in users, and can
>> also be used for other anti-pinning efforts(though clearly not sufficient
>> by itself for the many many pinning vectors we have :) )
>>
>
> Thinking about the most restrictive policy that would still enable
> annex-vaults (which I believe has great potential for improving bitcoin
> custody) and is in line with work already done, I get to:
>
> * Opt-in annex (every input must commit to an annex even if its is empty)
> -> make sure existing multi-party protocols remain unaffected
> * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 ->
> future extensibility
> * Only allow tlv record 0 - unstructured data -> future extensibility
> * Limit maximum size of the value to 256 bytes -> protect opt-in users
>
> Unfortunately the limit of 126 bytes in
> https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient
> for these types of vaults. If there are two presigned txes (unvault and
> emergency), those signatures would already take up 2*64=128 bytes. Then you
> also want to store 32 bytes for the ephemeral key itself as the key can't
> be reconstructed from the schnorr signature. The remaining bytes could be
> used for a third presigned tx and/or additional vault parameters.
>
> Can you think of remaining practical objections to making the annex
> standard under the conditions listed above?
>
> Joost
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230616/e427c0b7/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-06-19 18:19:59
in reply to nevent1q…s72s
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-19 18:19:59Event JSON
{
"id": "891f61272c6b5625ac0f48e656f992e292dd78182de39d47ef48542a5eb44f6d",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1687198799,
"kind": 1,
"tags": [
[
"e",
"68ea5a0105a7a492dce97362b0bd66bf00dac11bf2874dff55cd731b6f35e825",
"",
"root"
],
[
"e",
"3375aba4a65d03454e09cac7af118758f01a3c689954680bc9f983d8563aeb74",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2023-06-16\n🗒️ Summary of this message: Greg suggests using the TLV format for annex-vaults, which can be relaxed in the future, and limiting the maximum size to 256 bytes.\n📝 Original message:\nHi Joost,\n\nI haven't thought a ton about the specific TLV format, but that seems like\na reasonable place to start as it shouldn't unduly\nimpact current users, and is pretty simple from an accounting perspective.\nIt also can be further relaxed in the future if we so decide by using max\ntx size policy \"hints\" in an annex field.\n\nI'll let others chime in at this point!\n\nCheers,\nGreg\n\nOn Fri, Jun 16, 2023 at 7:27 AM Joost Jager \u003cjoost.jager at gmail.com\u003e wrote:\n\n\u003e Hi Greg,\n\u003e\n\u003e On Thu, Jun 15, 2023 at 12:39 PM Greg Sanders \u003cgsanders87 at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e \u003e Would it then still be necessary to restrict the annex to a maximum\n\u003e\u003e size?\n\u003e\u003e\n\u003e\u003e I think it's worth thinking about to protect the opt-in users, and can\n\u003e\u003e also be used for other anti-pinning efforts(though clearly not sufficient\n\u003e\u003e by itself for the many many pinning vectors we have :) )\n\u003e\u003e\n\u003e\n\u003e Thinking about the most restrictive policy that would still enable\n\u003e annex-vaults (which I believe has great potential for improving bitcoin\n\u003e custody) and is in line with work already done, I get to:\n\u003e\n\u003e * Opt-in annex (every input must commit to an annex even if its is empty)\n\u003e -\u003e make sure existing multi-party protocols remain unaffected\n\u003e * Tlv format as defined in https://github.com/bitcoin/bips/pull/1381 -\u003e\n\u003e future extensibility\n\u003e * Only allow tlv record 0 - unstructured data -\u003e future extensibility\n\u003e * Limit maximum size of the value to 256 bytes -\u003e protect opt-in users\n\u003e\n\u003e Unfortunately the limit of 126 bytes in\n\u003e https://github.com/bitcoin-inquisition/bitcoin/pull/22 isn't sufficient\n\u003e for these types of vaults. If there are two presigned txes (unvault and\n\u003e emergency), those signatures would already take up 2*64=128 bytes. Then you\n\u003e also want to store 32 bytes for the ephemeral key itself as the key can't\n\u003e be reconstructed from the schnorr signature. The remaining bytes could be\n\u003e used for a third presigned tx and/or additional vault parameters.\n\u003e\n\u003e Can you think of remaining practical objections to making the annex\n\u003e standard under the conditions listed above?\n\u003e\n\u003e Joost\n\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230616/e427c0b7/attachment.html\u003e",
"sig": "9bb21feef6b01700587cec350c98986dd2fea292d481ff07d3ed6b6e7c27550de712690c52770a5eec2a68c1f608f891e8198d12dd802686232e9bda0d946002"
}