📅 Original date posted:2021-06-10
📝 Original message:This is a continuation of the thread at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html
on this topic.
I still remain unconvinced that we ought to give up on the "reorg safety"
property that is explicitly part of Bitcoin's design.
On Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Everyone,
>
> I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY
> (OP_BBV) which is similar to ones that have been discussed before (eg
> OP_BLOCKNUMBER). The opcode is very simple: the it takes as a parameter a
> number representing a block height, and marks the transaction invalid if
> the current block the transaction is being evaluated for is greater than or
> equal to that block height, the transaction is invalid. I wrote up a bip
> for OP_BBV here
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md>;
> .
>
> The motivation for this opcode is primarily to do switch-off kinds of
> transactions. Eg, an output that contains both a spend path that uses
> OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a
> particular block one person can spend, and after that block a different
> person can spend. This can allow doing things like expiring payments or
> reversible payments in a cheaper way. Currently, things like that require a
> sequence of multiple transactions, however OP_BBV can do it in a single
> transaction, making these applications a lot more economically feasible.
>
> The particular application I'm most interested in is more efficient wallet
> vaults. However, wallet vaults requires other new opcodes, and I've been
> given the (good, I think) advice to start off this discussion with
> something a bit more bite sized and manageable. So I want to keep this
> discussion to OP_BBV and steer away from the specifics of the wallet vaults
> I'm thinking of (which are more involved, requiring other new opcodes that
> I think makes more sense to discuss in a different thread).
>
> The main thing I'd like to discuss is the historical avoidance of and
> stigma toward opcodes that can cause a valid transaction to become invalid.
>
> It seems there are two concerns:
>
> 1. that an opcode like might create a DOS vector where a malicious actor
> might be able to spam the mempool with transactions containing this opcode.
> 2. that an opcode like this could cause "bad" reorg behavior, where in a
> reorg, transactions that were spent become not spend and not spendable
> because they were mined too near their expiry point.
>
> While I don't want to claim anything about opcodes that can cause spend
> paths to expire in general, I do want to claim that *some* opcodes like
> that are safe - in particular OP_BBV. In the context of OP_BBV
> specifically, it seems to me like item 1 (mempool handling) is a solvable
> problem and that point 2 (reorg issues) is not really a problem since
> people should generally be waiting for 6 confirmations and software can
> warn the user to wait for 6 confirmations in relevant scenarios where a
> 6-block reorg might reverse the transaction. I discuss this in detail in
> the Design Tradeoffs and Risks
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry>; section
> of the document I wrote for OP_BBV. I'd love to hear thoughts from others
> on here about these things and especially the discussion of these issues in
> the document I linked to.
>
> Thanks,
> BT
>
> _______________________________________________
> 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/20210610/8acbf1df/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 22:54:35
in reply to nevent1q…r8mv
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 22:54:35Event JSON
{
"id": "6dcee287f0ba46ce730777d316533734f6f725c750a1681f51d8e305276d2625",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686178475,
"kind": 1,
"tags": [
[
"e",
"19219b8a40816b3048ed7e7f7885f05c8d7b3e286139413a0db0ed635a83e06f",
"",
"root"
],
[
"e",
"88296f6218e22853673a7cda66a022ebbd240447dadad8a68ef08a82c9544bdb",
"",
"reply"
],
[
"p",
"3030ec2d70259fdd55ba8e063740c139c3daaa618f86e3fae34cebcb73c742ba"
]
],
"content": "📅 Original date posted:2021-06-10\n📝 Original message:This is a continuation of the thread at\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018760.html\non this topic.\n\nI still remain unconvinced that we ought to give up on the \"reorg safety\"\nproperty that is explicitly part of Bitcoin's design.\n\nOn Thu, Jun 10, 2021 at 1:56 PM Billy Tetrud via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Everyone,\n\u003e\n\u003e I'd like to open a discussion of an opcode I call OP_BEFOREBLOCKVERIFY\n\u003e (OP_BBV) which is similar to ones that have been discussed before (eg\n\u003e OP_BLOCKNUMBER). The opcode is very simple: the it takes as a parameter a\n\u003e number representing a block height, and marks the transaction invalid if\n\u003e the current block the transaction is being evaluated for is greater than or\n\u003e equal to that block height, the transaction is invalid. I wrote up a bip\n\u003e for OP_BBV here\n\u003e \u003chttps://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md\u003e\n\u003e .\n\u003e\n\u003e The motivation for this opcode is primarily to do switch-off kinds of\n\u003e transactions. Eg, an output that contains both a spend path that uses\n\u003e OP_BBV and a spend path that uses OP_CHECKSEQUENCEVERIFY so that before a\n\u003e particular block one person can spend, and after that block a different\n\u003e person can spend. This can allow doing things like expiring payments or\n\u003e reversible payments in a cheaper way. Currently, things like that require a\n\u003e sequence of multiple transactions, however OP_BBV can do it in a single\n\u003e transaction, making these applications a lot more economically feasible.\n\u003e\n\u003e The particular application I'm most interested in is more efficient wallet\n\u003e vaults. However, wallet vaults requires other new opcodes, and I've been\n\u003e given the (good, I think) advice to start off this discussion with\n\u003e something a bit more bite sized and manageable. So I want to keep this\n\u003e discussion to OP_BBV and steer away from the specifics of the wallet vaults\n\u003e I'm thinking of (which are more involved, requiring other new opcodes that\n\u003e I think makes more sense to discuss in a different thread).\n\u003e\n\u003e The main thing I'd like to discuss is the historical avoidance of and\n\u003e stigma toward opcodes that can cause a valid transaction to become invalid.\n\u003e\n\u003e It seems there are two concerns:\n\u003e\n\u003e 1. that an opcode like might create a DOS vector where a malicious actor\n\u003e might be able to spam the mempool with transactions containing this opcode.\n\u003e 2. that an opcode like this could cause \"bad\" reorg behavior, where in a\n\u003e reorg, transactions that were spent become not spend and not spendable\n\u003e because they were mined too near their expiry point.\n\u003e\n\u003e While I don't want to claim anything about opcodes that can cause spend\n\u003e paths to expire in general, I do want to claim that *some* opcodes like\n\u003e that are safe - in particular OP_BBV. In the context of OP_BBV\n\u003e specifically, it seems to me like item 1 (mempool handling) is a solvable\n\u003e problem and that point 2 (reorg issues) is not really a problem since\n\u003e people should generally be waiting for 6 confirmations and software can\n\u003e warn the user to wait for 6 confirmations in relevant scenarios where a\n\u003e 6-block reorg might reverse the transaction. I discuss this in detail in\n\u003e the Design Tradeoffs and Risks\n\u003e \u003chttps://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#transaction-expiry\u003e section\n\u003e of the document I wrote for OP_BBV. I'd love to hear thoughts from others\n\u003e on here about these things and especially the discussion of these issues in\n\u003e the document I linked to.\n\u003e\n\u003e Thanks,\n\u003e BT\n\u003e\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/20210610/8acbf1df/attachment.html\u003e",
"sig": "e9c41ef3d4cb6de0e1700824577ba5b5807954e2d6b6100ec4396b946b4cc798b604850a488fce13f1b66db7d0eb9368951ecd46485367ff543cbae635a6aac2"
}