Author: Russell O'Connor 2021-06-12 15:58:29
Published on: 2021-06-12T15:58:29+00:00
The conversation between Billy Tetrud and another person revolves around the concept of a taproot annex, which refers to additional inputs to a script with additional constraints. The person explains that the normal approach for this would be to add an annex field for a maxheight value and add a consensus rule that invalidates transactions with a maxheight value in blocks whose height exceeds it. An OP code could then be added to push a copy of the smallest maxheight value from the annex onto the stack or compare a stack item with every maxheight value from the annex. This indirection makes script validity cacheable.Regarding an auto-double-spend wallet that would send every payment with an annex value limiting the payment's validity up to the next block, the person suggests requiring the input to OP_BBV to be in the script itself and not originate from the witness. However, they believe that the ideal solution is to change the definition for what counts as finalization to account for BBV transactions mined close to their expiration. Still, they argue that relying on voluntary transaction relay policy cannot solve security problems.The person concludes by stating that they do not have further time to engage in an idea that they do not consider likely to achieve broad community support.
Updated on: 2023-06-14T22:30:55.487102+00:00