📅 Original date posted:2021-06-12
📝 Original message:On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud <billy.tetrud at gmail.com> wrote:
> > taproot annex
>
> From what I can tell, the annex is basically additional inputs to a script
> that might have additional constraints put on it. Is that right? I don't
> quite follow how moving the max height to the annex helps script caching
> here. I wasn't able to find much information on how the annex is envisioned
> to be used. Would you mind elaborating on how this would work?
>
> Also, I think the proposal as it stands already addresses script caching
> (in the Transaction Evaluation section
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-evaluation>;).
> The result of the script can be cached as long as the cache item also
> contains information requiring just the OP_BBV to be re-evaluated (for the
> relevant block).
>
The normal approach for this problem would be a design that adds an "annex
field" (where the details on how to delimit annex fields is not yet
standardized) for a maxheight value, and add a consensus rule that
transaction with one (or more?) maxheight fields are invalid in blocks
whose height exceeds this (or any) maxheight value. Then you could/would
add an OP code to push a copy of the (smallest) maxheight value from the
annex onto the stack or maybe an opcode to compare a stack item with this
(every) maxheight value from the annex. This indirection is how OP_CLTV
and OP_CSV work and this indirection makes script validity cacheable
because script remains a function of the transaction data only. Since
transaction data doesn't change, neither does the outcome of script
evaluation. The rule that invalidates late transactions looks only at the
annex and is independent of any script evaluation considerations.
> > this auto-double-spend wallet would send every payment with an annex value
> that limits the payment to being valid only up to the next block
>
> One possible solution to that would be to require that the input to OP_BBV
> to be in the script itself and not originate from the witness.
>
> Regardless, I think the ideal solution is to not have any of these such
> rules if we can simply change the definition for what counts as
> finalization to account for the fact that BBV transactions mined close to
> their expiration. Is there a reason this finalization-redefinition is not
> an adequate solution?
>
Generally speaking, you cannot solve security problems through optional and
completely voluntary transaction relay policy. I'll just send my
about-to-expire transactions directly to miners and they will probably mine
them because they are, in fact, valid, and pay fees. Why wouldn't they
mine it?
(Yes, I know this logic also applies to RBF flagged transactions. Indeed,
you cannot rely on an RBF flag to prevent double spending, Yes I think the
RBF flag ought to be removed from consideration and every transaction
should be considered RBFable. Maybe that even happens to be my own node's
relay policy.)
I apologize, but I don't think I have further time to engage in an idea
that I don't consider likely to achieve broad community support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210612/b68c365f/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 22:54:40
in reply to nevent1q…lh0j
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 22:54:40Event JSON
{
"id": "6e5d09d470578c4783ef6f91d54f39810d501e8f797b8bc63e67938076fea016",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686178480,
"kind": 1,
"tags": [
[
"e",
"19219b8a40816b3048ed7e7f7885f05c8d7b3e286139413a0db0ed635a83e06f",
"",
"root"
],
[
"e",
"bdabfeacf570a05862819b4cb9470ed9d22384539c66d605950a7ff702aac589",
"",
"reply"
],
[
"p",
"3030ec2d70259fdd55ba8e063740c139c3daaa618f86e3fae34cebcb73c742ba"
]
],
"content": "📅 Original date posted:2021-06-12\n📝 Original message:On Sat, Jun 12, 2021 at 3:59 AM Billy Tetrud \u003cbilly.tetrud at gmail.com\u003e wrote:\n\n\u003e \u003e taproot annex\n\u003e\n\u003e From what I can tell, the annex is basically additional inputs to a script\n\u003e that might have additional constraints put on it. Is that right? I don't\n\u003e quite follow how moving the max height to the annex helps script caching\n\u003e here. I wasn't able to find much information on how the annex is envisioned\n\u003e to be used. Would you mind elaborating on how this would work?\n\u003e\n\u003e Also, I think the proposal as it stands already addresses script caching\n\u003e (in the Transaction Evaluation section\n\u003e \u003chttps://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-evaluation\u003e).\n\u003e The result of the script can be cached as long as the cache item also\n\u003e contains information requiring just the OP_BBV to be re-evaluated (for the\n\u003e relevant block).\n\u003e\n\nThe normal approach for this problem would be a design that adds an \"annex\nfield\" (where the details on how to delimit annex fields is not yet\nstandardized) for a maxheight value, and add a consensus rule that\ntransaction with one (or more?) maxheight fields are invalid in blocks\nwhose height exceeds this (or any) maxheight value. Then you could/would\nadd an OP code to push a copy of the (smallest) maxheight value from the\nannex onto the stack or maybe an opcode to compare a stack item with this\n(every) maxheight value from the annex. This indirection is how OP_CLTV\nand OP_CSV work and this indirection makes script validity cacheable\nbecause script remains a function of the transaction data only. Since\ntransaction data doesn't change, neither does the outcome of script\nevaluation. The rule that invalidates late transactions looks only at the\nannex and is independent of any script evaluation considerations.\n\n\n\u003e \u003e this auto-double-spend wallet would send every payment with an annex value\n\u003e that limits the payment to being valid only up to the next block\n\u003e\n\u003e One possible solution to that would be to require that the input to OP_BBV\n\u003e to be in the script itself and not originate from the witness.\n\u003e\n\u003e Regardless, I think the ideal solution is to not have any of these such\n\u003e rules if we can simply change the definition for what counts as\n\u003e finalization to account for the fact that BBV transactions mined close to\n\u003e their expiration. Is there a reason this finalization-redefinition is not\n\u003e an adequate solution?\n\u003e\n\nGenerally speaking, you cannot solve security problems through optional and\ncompletely voluntary transaction relay policy. I'll just send my\nabout-to-expire transactions directly to miners and they will probably mine\nthem because they are, in fact, valid, and pay fees. Why wouldn't they\nmine it?\n\n(Yes, I know this logic also applies to RBF flagged transactions. Indeed,\nyou cannot rely on an RBF flag to prevent double spending, Yes I think the\nRBF flag ought to be removed from consideration and every transaction\nshould be considered RBFable. Maybe that even happens to be my own node's\nrelay policy.)\n\nI apologize, but I don't think I have further time to engage in an idea\nthat I don't consider likely to achieve broad community support.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210612/b68c365f/attachment.html\u003e",
"sig": "78ef07c80091d88b4b844be6a214098a619243bb5b66a5bc8e34b031a52d9061784d39bd99018f458547a790ea8e993a90c6a3873ba0d192fc75f2b11d8a8d17"
}