đ
Original date posted:2023-06-02
đď¸ Summary of this message: Greg Sanders is interested in using the annex data with LN-Symmetry, but there are concerns about the fact that BIP341/342 signature hashes do not cover other inputs' annex fields, which could lead to griefing. Possible solutions include limiting annex usage to opt-in inputs or having a field that limits the total transaction weight.
đ Original message:
Hello Joost, David,
Thanks for the link to my ln-symmetry draft David. I'd also be curious as
to the usage you have in
mind Joost.
It's probably helpful to cite the most recent discussions on the topic,
which is probably
https://github.com/bitcoin-inquisition/bitcoin/pull/22 , where
bitcoin-inquisition has included
the `annexcarrier` option. I have a particular use for APO-enabled payment
channel designs
that doesn't require consensus meaning, so some effort was put in to try
something out there.
Attempting to summarize the linked PR:
I think the biggest remaining issue to this kind of idea, which is why I
didn't propose it for mainnet,
is the fact that BIP341/342 signature hashes do not cover *other* inputs'
annex fields, which we
briefly discussed here
https://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r1143382264
.
This means that in a coinjoin like scenario, even if the other joining
parties prove they don't have any
crazy script paths, a malicious party can make the signed transaction into
a maximum sized transaction
package, causing griefing. The mitigation in the PR I linked was to limit
it to 126 bytes, basically punting
on the problem by making the grief vector small. Another solution could be
to make annex usage "opt-in"
by requiring all inputs to commit to an annex to be relay-standard. In this
case, you've opted into a possible
vector, but at least current usage patterns wouldn't be unduly affected.
For those who opt-in, perhaps the first
order of business would be to have a field that limits the total
transaction weight, by policy only?
Some logs related to that here:
https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb
Related discussion on possible BIP118 modifications to mitigate this in
tapscript-spending circumstances:
https://github.com/bitcoin-inquisition/bitcoin/issues/19
Anyways, curious to hear what people think and want to make sure everyone
is on the same page.
Best,
Greg
On Fri, Jun 2, 2023 at 9:08âŻPM David A. Harding via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:
> > the benefits of making the annex available in a
> > non-structured form are both evident and immediate. By allowing
> > developers to utilize the taproot annex without delay, we can take
> > advantage of its features today,
>
> Hi Joost,
>
> Out of curiosity, what features and benefits are available today? I
> know Greg Sanders wants to use annex data with LN-Symmetry[1], but
> that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you
> mention that it could allow putting arbitrary data into a witness
> without having to commit to that data beforehand, but that would only
> increase the efficiency of witness stuffing like ordinal inscriptions by
> only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be
> required to create an output in order to spend it.
>
> Is there some other way to use the annex today that would be beneficial
> to users of Bitcoin?
>
> -Dave
>
> [1]
>
> https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119
> _______________________________________________
> 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/20230602/7ff6b96e/attachment-0001.html>;
Greg Sanders [ARCHIVE] /
npub1jdâŚ3gh0m
2023-06-19 18:19:50
in reply to nevent1qâŚu8yq
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-19 18:19:50Event JSON
{
"id": "84a57a6cba2d06cded199fb4ec228da5652f48ba6763790277eed7de0da9fab5",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1687198790,
"kind": 1,
"tags": [
[
"e",
"68ea5a0105a7a492dce97362b0bd66bf00dac11bf2874dff55cd731b6f35e825",
"",
"root"
],
[
"e",
"a38cc5441e7cf3dfa3ab83f81e44af77066fd5180df45b1af716d3b6071a2fd3",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "đ
Original date posted:2023-06-02\nđď¸ Summary of this message: Greg Sanders is interested in using the annex data with LN-Symmetry, but there are concerns about the fact that BIP341/342 signature hashes do not cover other inputs' annex fields, which could lead to griefing. Possible solutions include limiting annex usage to opt-in inputs or having a field that limits the total transaction weight.\nđ Original message:\nHello Joost, David,\n\nThanks for the link to my ln-symmetry draft David. I'd also be curious as\nto the usage you have in\nmind Joost.\n\nIt's probably helpful to cite the most recent discussions on the topic,\nwhich is probably\nhttps://github.com/bitcoin-inquisition/bitcoin/pull/22 , where\nbitcoin-inquisition has included\nthe `annexcarrier` option. I have a particular use for APO-enabled payment\nchannel designs\nthat doesn't require consensus meaning, so some effort was put in to try\nsomething out there.\n\nAttempting to summarize the linked PR:\n\nI think the biggest remaining issue to this kind of idea, which is why I\ndidn't propose it for mainnet,\nis the fact that BIP341/342 signature hashes do not cover *other* inputs'\nannex fields, which we\nbriefly discussed here\nhttps://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r1143382264\n.\n\nThis means that in a coinjoin like scenario, even if the other joining\nparties prove they don't have any\ncrazy script paths, a malicious party can make the signed transaction into\na maximum sized transaction\npackage, causing griefing. The mitigation in the PR I linked was to limit\nit to 126 bytes, basically punting\non the problem by making the grief vector small. Another solution could be\nto make annex usage \"opt-in\"\nby requiring all inputs to commit to an annex to be relay-standard. In this\ncase, you've opted into a possible\nvector, but at least current usage patterns wouldn't be unduly affected.\nFor those who opt-in, perhaps the first\norder of business would be to have a field that limits the total\ntransaction weight, by policy only?\n\nSome logs related to that here:\nhttps://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb\n\nRelated discussion on possible BIP118 modifications to mitigate this in\ntapscript-spending circumstances:\nhttps://github.com/bitcoin-inquisition/bitcoin/issues/19\n\nAnyways, curious to hear what people think and want to make sure everyone\nis on the same page.\n\nBest,\nGreg\n\nOn Fri, Jun 2, 2023 at 9:08âŻPM David A. Harding via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On 2023-06-02 05:00, Joost Jager via bitcoin-dev wrote:\n\u003e \u003e the benefits of making the annex available in a\n\u003e \u003e non-structured form are both evident and immediate. By allowing\n\u003e \u003e developers to utilize the taproot annex without delay, we can take\n\u003e \u003e advantage of its features today,\n\u003e\n\u003e Hi Joost,\n\u003e\n\u003e Out of curiosity, what features and benefits are available today? I\n\u003e know Greg Sanders wants to use annex data with LN-Symmetry[1], but\n\u003e that's dependent on a soft fork of SIGHASH_ANYPREVOUT. I also heard you\n\u003e mention that it could allow putting arbitrary data into a witness\n\u003e without having to commit to that data beforehand, but that would only\n\u003e increase the efficiency of witness stuffing like ordinal inscriptions by\n\u003e only 0.4% (~2 bytes saved per 520 bytes pushed) and it'd still be\n\u003e required to create an output in order to spend it.\n\u003e\n\u003e Is there some other way to use the annex today that would be beneficial\n\u003e to users of Bitcoin?\n\u003e\n\u003e -Dave\n\u003e\n\u003e [1]\n\u003e\n\u003e https://github.com/lightning/bolts/compare/master...instagibbs:bolts:eltoo_draft#diff-156a655274046c49e6b1c2a22546ed66366d3b8d97b8e9b34b45fe5bd8800ae2R119\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230602/7ff6b96e/attachment-0001.html\u003e",
"sig": "11bf1499d965a5580875f4376113a59332e7a4a44bfb07dd1de44bf3ade9b48dc461faa78914c3969ce5f57870f60aae11795a4704075ecf007dbb764092943b"
}