📅 Original date posted:2023-08-14
🗒️ Summary of this message: The author discusses the potential risks of cross-input inspection in Bitcoin contracts, such as miners bribing contracts to censor transactions. They propose using flags or tags to enable selective introspection of inputs/outputs. The author also mentions the need for more malleability and efficient witness space consumption.
📝 Original message:
Hi Salvatore,
> This also allows inspection of other inputs, that was not possible with
the original opcodes.
I think cross-input inspection (not cross-input signature aggregation which
is different) is opening a pandora box in terms of "malicious" off-chain
contracts than one could design. E.g miners bribing contracts to censor the
confirmation of time-sensitive lightning channel transactions, where the
bribes are paid on the hashrate distribution of miners during the previous
difficulty period, thanks to the coinbase pubkey.
See https://blog.bitmex.com/txwithhold-smart-contracts/ and
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.html
I wonder if we might face the dilemma of miners censorship attacks, if we
wish to have more advanced bitcoin contracts, though I think it would be
safe design practice to rule out those types of concerns thanks to smart
bitcoin contracting primitives.
I think this is a common risk to all second-layers vaults, lightning
channels and payment pools.
> A flag can disable this behavior"
More than a binary flag like a matrix could be introduced to encode subset
of introspected inputs /outputs to enable sighash_group-like semantic:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> There are two defined flags:
> - CCV_FLAG_CHECK_INPUT = 1: if present, <index> refers to an input;
> otherwise, it refers to an output.
> - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT
> is absent, it disables the deferred checks logic for amounts.
Or even beyond a matrix, it could be a set of "tags". There could be a
generalized tag for unstructured data, and another one for bitcoin
transaction / script data types (e.g scriptpubkey, amount, nsequence,
merkle branch) that could be fetched from the taproot annex.
> After the evaluation of all inputs, it is verified that each output's
> amount is greater than or equal to the total amount in the bucket
> if that output (validation of the deferred checks).
At the very least, I think for the payment pool, where you're fanning-out
satoshis value from a subset of inputs to another subset of outputs, I
think you would need more malleability here.
> It is unclear if all the special values above will be useful in
> applications; however, as each special case requires very little added
> code, I tried to make the specs as flexible as possible at this time.
I think this generic framework is interesting for joinpool / coinpool /
payment pool, as you can check that any withdrawal output can be committed
as part of the input scriptpubkey, and spend it on
blessed-with-one-participant-sig script. There is still a big open question
if it's efficient in terms of witness space consumed.
That said, I still think you would need at least ANYPREVOUT and more
malleability for the amount transfer validation as laid out above.
Looking on the `DeferredCheck` framework commit, one obvious low-level
concern is the DoS risk for full-nodes participating in transaction-relay,
and that maybe policy rules should be introduced to keep the worst-CPU
input in the ranges of current transaction spend allowed to propagate on
the network today.
Thanks for the proposal,
Best,
Antoine
Le dim. 30 juil. 2023 à 22:52, Salvatore Ingala via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> Hi all,
>
> I have put together a first complete proposal for the core opcodes of
> MATT [1][2].
> The changes make the opcode functionally complete, and the
> implementation is revised and improved.
>
> The code is implemented in the following fork of the
> bitcoin-inquisition repo:
>
> https://github.com/Merkleize/bitcoin/tree/checkcontractverify
>
> Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a
> previous early demo for vaults [3].
>
> Please check out the diff [4] if you are interested in the
> implementation details. It includes some basic functional tests for
> the main cases of the opcode.
>
> ## Changes vs the previous draft
>
> These are the changes compared to the initial incomplete proposal:
> - OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by a single opcode
> OP_CHECKCONTRACTVERIFY (CCV). An additional `flags` parameter allows
> to specify if the opcode operates on an input or an output.
> This also allows inspection of other inputs, that was not possible
> with the original opcodes.
> - For outputs, the default behavior is to have the following deferred
> checks mechanism for amounts: all the inputs that have a CCV towards
> the same output, have their input amounts summed, and that act as a
> lower bound for that output's amount.
> A flag can disable this behavior. [*]
> - A number of special values of the parameters were defined in order
> to optimize for common cases, and add some implicit introspection.
> - The order of parameters is modified (particularly, <data> is at the
> bottom of the arguments, as so is more natural when writing Scripts).
>
> ## Semantics
>
> The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack:
>
> <data>, <index>, <pk>, <taptree>, <flags>
>
> The core logic of the opcode is as follows:
>
> "Check if the <index>-th input/output's scriptPubKey is a P2TR
> whose public key is obtained from <pk>, (optionally) tweaked with
> <data>, (optionally) tap-tweaked with <taptree>".
>
> The following are special values of the parameters:
>
> - if <pk> is empty, it is replaced with a fixed NUMS point. [**]
> - if <pk> is -1, it is replaced with the current input's taproot
> internal key.
> - if <index> is -1, it is replaced with the current input's index.
> - if <data> is empty, the data tweak is skipped.
> - if <taptree> is empty, the taptweak is skipped.
> - if <taptree> is -1, it is replaced with the current input's root
> of the taproot merkle tree.
>
> There are two defined flags:
> - CCV_FLAG_CHECK_INPUT = 1: if present, <index> refers to an input;
> otherwise, it refers to an output.
> - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT
> is absent, it disables the deferred checks logic for amounts.
>
> Finally, if both the flags CCV_FLAG_CHECK_INPUT and
> CCV_FLAG_IGNORE_OUTPUT_AMOUNT are absent:
> - Add the current input's amount to the <index>-th output's bucket.
>
> After the evaluation of all inputs, it is verified that each output's
> amount is greater than or equal to the total amount in the bucket
> if that output (validation of the deferred checks).
>
> ## Comment
>
> It is unclear if all the special values above will be useful in
> applications; however, as each special case requires very little added
> code, I tried to make the specs as flexible as possible at this time.
>
> With this new opcode, the full generality of MATT (including the fraud
> proofs) can be obtained with just two opcodes: OP_CHECKCONTRACTVERIFY
> and OP_CAT.
> However, additional opcodes (and additional introspection) would
> surely benefit some applications.
>
> I look forward to your comments, and to start drafting a BIP proposal.
>
> Best,
> Salvatore Ingala
>
>
> [*] - Credits go to James O'Beirne for this approach, taken from his
> OP_VAULT proposal. I cherry-picked the commit containing the
> Deferred Checks framework.
> [**] - The same NUMS point suggested in BIP-0341 was used.
>
>
> References:
>
> [1] - https://merkle.fun/
> [2] -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html
> [3] -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html
> [4] -
> https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify
> _______________________________________________
> 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/20230814/cef35006/attachment-0001.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-08-16 00:45:52
in reply to nevent1q…47rh
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-08-16 00:45:52Event JSON
{
"id": "92107c7d6029e02e343cb31ba676272e7747f0d1099c690264bee6b45121ac85",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1692146752,
"kind": 1,
"tags": [
[
"e",
"86649676ae3ff05a6e718ccf3b301e4e0e000c38b8f97ecfab084b85db23c5a3",
"",
"root"
],
[
"e",
"74222f9a3e673a987e2905d4e80a8ffd7b650c41fe129c7f06047c578308e3c9",
"",
"reply"
],
[
"p",
"f86db307ea15ecf745ec5b45e86abbf9755adbc7a6508dca12443cedf6718084"
]
],
"content": "📅 Original date posted:2023-08-14\n🗒️ Summary of this message: The author discusses the potential risks of cross-input inspection in Bitcoin contracts, such as miners bribing contracts to censor transactions. They propose using flags or tags to enable selective introspection of inputs/outputs. The author also mentions the need for more malleability and efficient witness space consumption.\n📝 Original message:\nHi Salvatore,\n\n\u003e This also allows inspection of other inputs, that was not possible with\nthe original opcodes.\n\nI think cross-input inspection (not cross-input signature aggregation which\nis different) is opening a pandora box in terms of \"malicious\" off-chain\ncontracts than one could design. E.g miners bribing contracts to censor the\nconfirmation of time-sensitive lightning channel transactions, where the\nbribes are paid on the hashrate distribution of miners during the previous\ndifficulty period, thanks to the coinbase pubkey.\n\nSee https://blog.bitmex.com/txwithhold-smart-contracts/ and\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.html\n\nI wonder if we might face the dilemma of miners censorship attacks, if we\nwish to have more advanced bitcoin contracts, though I think it would be\nsafe design practice to rule out those types of concerns thanks to smart\nbitcoin contracting primitives.\n\nI think this is a common risk to all second-layers vaults, lightning\nchannels and payment pools.\n\n\u003e A flag can disable this behavior\"\n\nMore than a binary flag like a matrix could be introduced to encode subset\nof introspected inputs /outputs to enable sighash_group-like semantic:\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html\n\n\u003e There are two defined flags:\n\u003e - CCV_FLAG_CHECK_INPUT = 1: if present, \u003cindex\u003e refers to an input;\n\u003e otherwise, it refers to an output.\n\u003e - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT\n\u003e is absent, it disables the deferred checks logic for amounts.\n\nOr even beyond a matrix, it could be a set of \"tags\". There could be a\ngeneralized tag for unstructured data, and another one for bitcoin\ntransaction / script data types (e.g scriptpubkey, amount, nsequence,\nmerkle branch) that could be fetched from the taproot annex.\n\n\u003e After the evaluation of all inputs, it is verified that each output's\n\u003e amount is greater than or equal to the total amount in the bucket\n\u003e if that output (validation of the deferred checks).\n\nAt the very least, I think for the payment pool, where you're fanning-out\nsatoshis value from a subset of inputs to another subset of outputs, I\nthink you would need more malleability here.\n\n\u003e It is unclear if all the special values above will be useful in\n\u003e applications; however, as each special case requires very little added\n\u003e code, I tried to make the specs as flexible as possible at this time.\n\nI think this generic framework is interesting for joinpool / coinpool /\npayment pool, as you can check that any withdrawal output can be committed\nas part of the input scriptpubkey, and spend it on\nblessed-with-one-participant-sig script. There is still a big open question\nif it's efficient in terms of witness space consumed.\n\nThat said, I still think you would need at least ANYPREVOUT and more\nmalleability for the amount transfer validation as laid out above.\n\nLooking on the `DeferredCheck` framework commit, one obvious low-level\nconcern is the DoS risk for full-nodes participating in transaction-relay,\nand that maybe policy rules should be introduced to keep the worst-CPU\ninput in the ranges of current transaction spend allowed to propagate on\nthe network today.\n\nThanks for the proposal,\n\nBest,\nAntoine\n\n\n\nLe dim. 30 juil. 2023 à 22:52, Salvatore Ingala via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e Hi all,\n\u003e\n\u003e I have put together a first complete proposal for the core opcodes of\n\u003e MATT [1][2].\n\u003e The changes make the opcode functionally complete, and the\n\u003e implementation is revised and improved.\n\u003e\n\u003e The code is implemented in the following fork of the\n\u003e bitcoin-inquisition repo:\n\u003e\n\u003e https://github.com/Merkleize/bitcoin/tree/checkcontractverify\n\u003e\n\u003e Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a\n\u003e previous early demo for vaults [3].\n\u003e\n\u003e Please check out the diff [4] if you are interested in the\n\u003e implementation details. It includes some basic functional tests for\n\u003e the main cases of the opcode.\n\u003e\n\u003e ## Changes vs the previous draft\n\u003e\n\u003e These are the changes compared to the initial incomplete proposal:\n\u003e - OP_CHECK{IN,OUT}CONTRACTVERIFY are replaced by a single opcode\n\u003e OP_CHECKCONTRACTVERIFY (CCV). An additional `flags` parameter allows\n\u003e to specify if the opcode operates on an input or an output.\n\u003e This also allows inspection of other inputs, that was not possible\n\u003e with the original opcodes.\n\u003e - For outputs, the default behavior is to have the following deferred\n\u003e checks mechanism for amounts: all the inputs that have a CCV towards\n\u003e the same output, have their input amounts summed, and that act as a\n\u003e lower bound for that output's amount.\n\u003e A flag can disable this behavior. [*]\n\u003e - A number of special values of the parameters were defined in order\n\u003e to optimize for common cases, and add some implicit introspection.\n\u003e - The order of parameters is modified (particularly, \u003cdata\u003e is at the\n\u003e bottom of the arguments, as so is more natural when writing Scripts).\n\u003e\n\u003e ## Semantics\n\u003e\n\u003e The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack:\n\u003e\n\u003e \u003cdata\u003e, \u003cindex\u003e, \u003cpk\u003e, \u003ctaptree\u003e, \u003cflags\u003e\n\u003e\n\u003e The core logic of the opcode is as follows:\n\u003e\n\u003e \"Check if the \u003cindex\u003e-th input/output's scriptPubKey is a P2TR\n\u003e whose public key is obtained from \u003cpk\u003e, (optionally) tweaked with\n\u003e \u003cdata\u003e, (optionally) tap-tweaked with \u003ctaptree\u003e\".\n\u003e\n\u003e The following are special values of the parameters:\n\u003e\n\u003e - if \u003cpk\u003e is empty, it is replaced with a fixed NUMS point. [**]\n\u003e - if \u003cpk\u003e is -1, it is replaced with the current input's taproot\n\u003e internal key.\n\u003e - if \u003cindex\u003e is -1, it is replaced with the current input's index.\n\u003e - if \u003cdata\u003e is empty, the data tweak is skipped.\n\u003e - if \u003ctaptree\u003e is empty, the taptweak is skipped.\n\u003e - if \u003ctaptree\u003e is -1, it is replaced with the current input's root\n\u003e of the taproot merkle tree.\n\u003e\n\u003e There are two defined flags:\n\u003e - CCV_FLAG_CHECK_INPUT = 1: if present, \u003cindex\u003e refers to an input;\n\u003e otherwise, it refers to an output.\n\u003e - CCV_FLAG_IGNORE_OUTPUT_AMOUNT = 2: only defined when _CHECK_INPUT\n\u003e is absent, it disables the deferred checks logic for amounts.\n\u003e\n\u003e Finally, if both the flags CCV_FLAG_CHECK_INPUT and\n\u003e CCV_FLAG_IGNORE_OUTPUT_AMOUNT are absent:\n\u003e - Add the current input's amount to the \u003cindex\u003e-th output's bucket.\n\u003e\n\u003e After the evaluation of all inputs, it is verified that each output's\n\u003e amount is greater than or equal to the total amount in the bucket\n\u003e if that output (validation of the deferred checks).\n\u003e\n\u003e ## Comment\n\u003e\n\u003e It is unclear if all the special values above will be useful in\n\u003e applications; however, as each special case requires very little added\n\u003e code, I tried to make the specs as flexible as possible at this time.\n\u003e\n\u003e With this new opcode, the full generality of MATT (including the fraud\n\u003e proofs) can be obtained with just two opcodes: OP_CHECKCONTRACTVERIFY\n\u003e and OP_CAT.\n\u003e However, additional opcodes (and additional introspection) would\n\u003e surely benefit some applications.\n\u003e\n\u003e I look forward to your comments, and to start drafting a BIP proposal.\n\u003e\n\u003e Best,\n\u003e Salvatore Ingala\n\u003e\n\u003e\n\u003e [*] - Credits go to James O'Beirne for this approach, taken from his\n\u003e OP_VAULT proposal. I cherry-picked the commit containing the\n\u003e Deferred Checks framework.\n\u003e [**] - The same NUMS point suggested in BIP-0341 was used.\n\u003e\n\u003e\n\u003e References:\n\u003e\n\u003e [1] - https://merkle.fun/\n\u003e [2] -\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html\n\u003e [3] -\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021588.html\n\u003e [4] -\n\u003e https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify\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/20230814/cef35006/attachment-0001.html\u003e",
"sig": "0d4eeb9396ec50bbd56fd8a6597443b9c2347ad599cc0abf4ee9567687655359c99977d5a4b904b5a30aa08f609d4f2e5912f0ed029a39fc8ae739b9c2b29bb6"
}