Antoine Riard [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-18 🗒️ Summary of this message: The proposed ...
📅 Original date posted:2023-06-18
🗒️ Summary of this message: The proposed Taproot upgrade may require Lightning nodes to add an annex and commit to it in the BIP341 signature digest, which could break propagations of their `option_taproot` channel transactions. Additionally, a limit of 256 bytes may be introduced to protect opt-in users. A TLV format and only allowing tlv record 0 may also be implemented for future extensibility.
📝 Original message:
Hi all,
> * Opt-in annex (every input must commit to an annex even if its is empty)
-> make sure existing multi-party protocols remain unaffected
By requiring every input to commit to an annex even if it is empty, do you
mean rejecting a transaction where the minimal annex with its 0x50 tag is
absent ?
If I understand correctly, this would require modifying current Taproot
support on the Lightning-side, where all P2TR spends must add an annex and
commit to it in the BIP341 signature digest. This would be quite a
mandatory upgrade for Lightning nodes, as failure to do so would break
propagations of their `option_taproot` channel transactions.
> * Limit maximum size of the value to 256 bytes -> protect opt-in users
There is another approach where the maximum size/weight of the
witness/transaction is introduced as a TLV record itself:
https://github.com/bitcoin-inquisition/bitcoin/pull/28
Note this branch also implements the "only allow tlv record 0" with the TLV
format from bips #1381.
Best,
Antoine
Le ven. 16 juin 2023 à 14:31, Greg Sanders via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> 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
>>
>>> _______________________________________________
> 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/20230618/e80a7213/attachment-0001.html>;
🗒️ Summary of this message: The proposed Taproot upgrade may require Lightning nodes to add an annex and commit to it in the BIP341 signature digest, which could break propagations of their `option_taproot` channel transactions. Additionally, a limit of 256 bytes may be introduced to protect opt-in users. A TLV format and only allowing tlv record 0 may also be implemented for future extensibility.
📝 Original message:
Hi all,
> * Opt-in annex (every input must commit to an annex even if its is empty)
-> make sure existing multi-party protocols remain unaffected
By requiring every input to commit to an annex even if it is empty, do you
mean rejecting a transaction where the minimal annex with its 0x50 tag is
absent ?
If I understand correctly, this would require modifying current Taproot
support on the Lightning-side, where all P2TR spends must add an annex and
commit to it in the BIP341 signature digest. This would be quite a
mandatory upgrade for Lightning nodes, as failure to do so would break
propagations of their `option_taproot` channel transactions.
> * Limit maximum size of the value to 256 bytes -> protect opt-in users
There is another approach where the maximum size/weight of the
witness/transaction is introduced as a TLV record itself:
https://github.com/bitcoin-inquisition/bitcoin/pull/28
Note this branch also implements the "only allow tlv record 0" with the TLV
format from bips #1381.
Best,
Antoine
Le ven. 16 juin 2023 à 14:31, Greg Sanders via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> 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
>>
>>> _______________________________________________
> 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/20230618/e80a7213/attachment-0001.html>;