public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Concrete MATT opcodes
@ 2023-07-30 21:37 Salvatore Ingala
  2023-08-06 20:13 ` David A. Harding
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Salvatore Ingala @ 2023-07-30 21:37 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4110 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5082 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

• * Re: [bitcoin-dev] Concrete MATT opcodes
    2023-07-30 21:37 [bitcoin-dev] Concrete MATT opcodes Salvatore Ingala
  @ 2023-08-06 20:13 ` David A. Harding
    2023-08-07  8:31   ` Salvatore Ingala
    2023-08-07 11:37 ` Johan Torås Halseth
    2023-08-14  3:00 ` Antoine Riard
    2 siblings, 1 reply; 12+ messages in thread
  From: David A. Harding @ 2023-08-06 20:13 UTC (permalink / raw)
    To: Salvatore Ingala, Bitcoin Protocol Discussion
  
  
  
  On July 30, 2023 11:37:49 AM HST, Salvatore Ingala via bitcoin-dev
  >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.
  > [...]
  >[1] - https://merkle.fun/
  >[2] -
  >https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html
  
  Hi Salvatore,
  
  Where exactly is the proposal?  Merkle.fun links to a "WIP" comment that seems to specify OP_CHECKCONTRACTVERIFY but your text above says "core opcodes" (plural) so I feel like I'm missing something.  Also, it being "WIP" makes me wonder if that actually is the "complete proposal" I should be looking for.
  
  When I read "complete proposal", I was expecting a draft BIP.
  
  -Dave
  
  
  ^ permalink raw reply	[flat|nested] 12+ messages in thread

• • * Re: [bitcoin-dev] Concrete MATT opcodes
      2023-08-06 20:13 ` David A. Harding
    @ 2023-08-07  8:31   ` Salvatore Ingala
      0 siblings, 0 replies; 12+ messages in thread
    From: Salvatore Ingala @ 2023-08-07  8:31 UTC (permalink / raw)
      To: David A. Harding; +Cc: Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
    
    Hi Dave,
    
    I apologize for the confusion and the inconsistent use of plurals.
    The reason I called it a "complete proposal" is that the opcode is
    now functionally complete, unlike the previous attempt where the
    approach for the output amount introspection was not yet specified.
    
    The semantics are informally defined in the previous e-mail, and
    implemented in the code [1], which is the only formal specification
    at this time. I believe the code is now fairly stable and ready to
    experiment with.
    My own and (hopefully) others' experimentation will help in writing
    a more informed BIP proposal in the next few months.
    
    About the plurals: OP_CHECKCONTRACTVERIFY is indeed now a single
    opcode that is useful on its own, but I will also be maintaining a
    separate branch [2] that contains both OP_CHECKCONTRACTVERIFY and
    OP_CAT, which enables the full generality of the MATT proposal.
    
    Best,
    Salvatore
    
    [1] -
    https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Merkleize:bitcoin:checkcontractverify
    [2] - https://github.com/Merkleize/bitcoin/tree/matt
    
    [-- Attachment #2: Type: text/html, Size: 1406 bytes --]
    
    ^ permalink raw reply	[flat|nested] 12+ messages in thread

• * Re: [bitcoin-dev] Concrete MATT opcodes
    2023-07-30 21:37 [bitcoin-dev] Concrete MATT opcodes Salvatore Ingala
    2023-08-06 20:13 ` David A. Harding
  @ 2023-08-07 11:37 ` Johan Torås Halseth
    2023-08-09  8:38   ` Salvatore Ingala
    2023-08-14  3:00 ` Antoine Riard
    2 siblings, 1 reply; 12+ messages in thread
  From: Johan Torås Halseth @ 2023-08-07 11:37 UTC (permalink / raw)
    To: Salvatore Ingala, Bitcoin Protocol Discussion
  
  Hi, Salvatore.
  
  Thanks for the update! I like the fact that taptree verification now
  can be done on both input and outputs, and having them be symmetrical
  also makes the learning curve a bit easier.
  
  I have implemented the updated opcodes in btcd (very rough
  implementation)]1] as well as updated the example scripts for
  simulating CTV[2] and Coinpools[3].
  
  From doing this I would again like to offer some suggestions on the proposal.
  
  - For the opcode parameter ordering, it feels unnatural for the two
  tweaks (data, taptree) to be separated by the internal key. A more
  natural ordering of parameters IMO would be (of course this is all
  subjective):
  <data> <taptree> <internalkey> <index> <flags> OP_CCV.
  
  If you disagree, I would love some rationale for the ordering you
  chose! (looks like you also changed it again after your last post?).
  
  - The deferred amount check seems a bit out of place, and insufficient
  at least for the use cases I had in mind. They work well in a vault
  setting, where you want to consolidate many outputs into a single new
  one, and in 1-input-1-output settings where you want to preserve the
  amount exactly. However, for coinpools, CTV with more than one output
  and other interesting contracts where you want to split or combine
  amounts it won't be powerful enough.
  
  I'm wondering what other use cases you had in mind for the deferred
  output amount check? Maybe I have missed something, but if not it
  would perhaps be better to leave out the amount preservation check, or
  go the extra mile and propose a more powerful amount introspection
  machinery.
  
  Cheers,
  Johan
  
  [1] - https://github.com/halseth/btcd/pull/1
  [2] - https://github.com/halseth/tapsim/blob/8f4ac4d914fde0847c72cd22bdd45a1b7247cadf/examples/matt/ctv2/README.md
  [3] - https://github.com/halseth/tapsim/blob/8f4ac4d914fde0847c72cd22bdd45a1b7247cadf/examples/matt/coinpool/README.md
  
  
  On Sun, Jul 30, 2023 at 11:51 PM Salvatore Ingala via bitcoin-dev
  <bitcoin-dev@lists•linuxfoundation.org> wrote:
  >
  > 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@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  
  
  ^ permalink raw reply	[flat|nested] 12+ messages in thread

• • * Re: [bitcoin-dev] Concrete MATT opcodes
      2023-08-07 11:37 ` Johan Torås Halseth
    @ 2023-08-09  8:38   ` Salvatore Ingala
      0 siblings, 0 replies; 12+ messages in thread
    From: Salvatore Ingala @ 2023-08-09  8:38 UTC (permalink / raw)
      To: Johan Torås Halseth; +Cc: Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 2131 bytes --]
    
    Hi Johan,
    
    Thanks a lot for the comments, and the independent implementation!
    
    > - For the opcode parameter ordering, it feels unnatural for the two
    > tweaks (data, taptree) to be separated by the internal key. A more
    > natural ordering of parameters IMO would be (of course this is all
    > subjective):
    > <data> <taptree> <internalkey> <index> <flags> OP_CCV.
    >
    > If you disagree, I would love some rationale for the ordering you
    > chose! (looks like you also changed it again after your last post?).
    
    The main concern for the reordering was to put <data> at the bottom,
    as that's typically passed via the witness stack.
    
    I put the <index> right next, as I suspect there are use cases for
    specifying via the witness what is the input index where a certain
    (CCV-encumbered) UTXO is to be found, or which output should funds
    be sent to, instead of hard-coding this in the script. This might
    help in designing contracts that are more flexible in the way they
    are spent, for example by allowing batching their transactions.
    
    Instead, I expect the other parameters to almost always be hardcoded,
    or propagated from the current input with the <-1> special values.
    
    I agree that your ordering is more aesthetically pleasing, though.
    
    > I'm wondering what other use cases you had in mind for the deferred
    > output amount check? Maybe I have missed something, but if not it
    > would perhaps be better to leave out the amount preservation check, or
    > go the extra mile and propose a more powerful amount introspection
    > machinery.
    
    Yes, the deferred output amount check is not enough for coinpools;
    however, it comes at no cost if we have a <flags> parameter anyway,
    as OP_2 (value for CCV_IGNORE_OUTPUT_AMOUNT) is a single byte opcode.
    
    The intent of preserving amounts for many-to-one contracts (vaults),
    or the one-to-one cases (channels, any 2-party contract, etc.) seems
    common enough to deserve 1 bit in the flags, IMHO.
    Efforts to define and add explicit introspection to cover your
    (exciting!) use cases can proceed independently, but I don't think
    they would nullify the advantages of this (optional) feature of CCV.
    
    Best,
    Salvatore
    
    [-- Attachment #2: Type: text/html, Size: 2435 bytes --]
    
    ^ permalink raw reply	[flat|nested] 12+ messages in thread

• * Re: [bitcoin-dev] Concrete MATT opcodes
    2023-07-30 21:37 [bitcoin-dev] Concrete MATT opcodes Salvatore Ingala
    2023-08-06 20:13 ` David A. Harding
    2023-08-07 11:37 ` Johan Torås Halseth
  @ 2023-08-14  3:00 ` Antoine Riard
    2023-08-14 14:07   ` symphonicbtc
    2023-08-18 15:08   ` Salvatore Ingala
    2 siblings, 2 replies; 12+ messages in thread
  From: Antoine Riard @ 2023-08-14  3:00 UTC (permalink / raw)
    To: Salvatore Ingala, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 8042 bytes --]
  
  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@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@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  >
  
  [-- Attachment #2: Type: text/html, Size: 10160 bytes --]
  
  ^ permalink raw reply	[flat|nested] 12+ messages in thread

• • * Re: [bitcoin-dev] Concrete MATT opcodes
      2023-08-14  3:00 ` Antoine Riard
    @ 2023-08-14 14:07   ` symphonicbtc
      2023-08-18 20:12     ` Antoine Riard
      2023-09-13 20:25     ` Antoine Riard
      2023-08-18 15:08   ` Salvatore Ingala
      1 sibling, 2 replies; 12+ messages in thread
    From: symphonicbtc @ 2023-08-14 14:07 UTC (permalink / raw)
      To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
    
    > 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
    
    Hi Antoine,
    
    These two papers make a lot of incorrect assumptions about bitcoins security model. The assumption of the existence of constructs such as oracles or altchains for “trustless” out-of-band payments opens the door for plenty of things that in reality are not possible without sacrificing security. The assumption that these constructs “minimize” miner / attacker trust is no better than assuming the existence of an oracle that can simply perform the entire attack.
    
    Moreover, even the limited examples of attacks that do not use these constructs completely overlook the fact that bitcoins security model is dependent on the preservation of the nash equilibrium between miners. Not only is it disincentivized for miners to engage in any form of censorship, because they can all be fired by node-runners at any time, it is also not in miners interests to reorg the chain if say an anonymous miner mines some transactions that were being censored. Sustained, successful censorship in any capacity assumes that bitcoin is compromised, a 51% attack has occurred, and necessitates a change in PoW algorithm. A sufficient CSV in LN-like protocols is always sufficient to avoid being attacked in this way.
    
    The addition of most forms of covenant does not assist any of these attacks afaict because they already make assumptions rendering them invalid.
    
    
    Symphonic
    
    ------- Original Message -------
    On Monday, August 14th, 2023 at 3:00 AM, Antoine Riard via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    
    > 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@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@lists•linuxfoundation.org
    > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    
    
    ^ permalink raw reply	[flat|nested] 12+ messages in thread

  • • * Re: [bitcoin-dev] Concrete MATT opcodes
        2023-08-14 14:07   ` symphonicbtc
      @ 2023-08-18 20:12     ` Antoine Riard
        2023-08-19 23:11       ` symphonicbtc
        2023-09-13 20:25     ` Antoine Riard
        1 sibling, 1 reply; 12+ messages in thread
      From: Antoine Riard @ 2023-08-18 20:12 UTC (permalink / raw)
        To: symphonicbtc; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 12896 bytes --]
      
      Hi Symphonic,
      
      From a game-theory viewpoint where we define among other players utility
      functions, set of moves, rules of the games and pattern of information, I
      don't think oracles can be mathematically reduced to miners.
      
      Miners are competing to generate a proof-of-work on a set of transactions.
      This proof-of-work requires hashrate capabilities investment and censoring
      LN time-sensitive transactions impacting their marginal gains in the mining
      competitions to sustain the investment renewment in their mining chips.
      
      On the other hand, anyone can show as a proof-of-real-world-state oracle,
      without mining investment. They will take a while to build a reputation as
      a UTXO state oracle and even in case of wrongdoing, laziness is hard to
      prove [0].
      
      To the best of my knowledge, there is no complete and practical security
      model for "DLC-like" oracles, as such it's hard to have the epistemological
      discussion on which assumptions should be regarded as valid or excluded
      from the formalization.
      
      As a note the CLTV-timelock matter for LN-like protocol, beyond CSV and
      here you start to have interactions with timewarp inflation attacks, which
      is still not fixed as a consensus-level vulnerability [1].
      
      I think my previous statement that the addition of cross-UTXO covenant
      inspection raises risks in the lack of further R&D on the security model
      and the game-theory of Bitcoin is still correct. While a risk zero is not
      an intellectual mirage, at the very least when we're talking about the
      consensus rules of a $500 B ecosystem, we should bind to world-class
      standards of software engineering R&D. And as the ecosystem grows, I think
      we should aim to match best practices in aircraft software design or
      nuclear reactors.
      
      Best,
      Antoine
      
      [0] https://github.com/discreetlogcontracts/dlcspecs/pull/152
      [1]
      https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki
      
      Le lun. 14 août 2023 à 15:07, symphonicbtc <symphonicbtc@proton•me> a
      écrit :
      
      > > 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
      >
      > Hi Antoine,
      >
      > These two papers make a lot of incorrect assumptions about bitcoins
      > security model. The assumption of the existence of constructs such as
      > oracles or altchains for “trustless” out-of-band payments opens the door
      > for plenty of things that in reality are not possible without sacrificing
      > security. The assumption that these constructs “minimize” miner / attacker
      > trust is no better than assuming the existence of an oracle that can simply
      > perform the entire attack.
      >
      > Moreover, even the limited examples of attacks that do not use these
      > constructs completely overlook the fact that bitcoins security model is
      > dependent on the preservation of the nash equilibrium between miners. Not
      > only is it disincentivized for miners to engage in any form of censorship,
      > because they can all be fired by node-runners at any time, it is also not
      > in miners interests to reorg the chain if say an anonymous miner mines some
      > transactions that were being censored. Sustained, successful censorship in
      > any capacity assumes that bitcoin is compromised, a 51% attack has
      > occurred, and necessitates a change in PoW algorithm. A sufficient CSV in
      > LN-like protocols is always sufficient to avoid being attacked in this way.
      >
      > The addition of most forms of covenant does not assist any of these
      > attacks afaict because they already make assumptions rendering them invalid.
      >
      >
      > Symphonic
      >
      > ------- Original Message -------
      > On Monday, August 14th, 2023 at 3:00 AM, Antoine Riard via bitcoin-dev <
      > bitcoin-dev@lists•linuxfoundation.org> wrote:
      >
      >
      > > 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@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@lists•linuxfoundation.org
      > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      
      [-- Attachment #2: Type: text/html, Size: 16385 bytes --]
      
      ^ permalink raw reply	[flat|nested] 12+ messages in thread

    • • * Re: [bitcoin-dev] Concrete MATT opcodes
          2023-08-18 20:12     ` Antoine Riard
        @ 2023-08-19 23:11       ` symphonicbtc
          0 siblings, 0 replies; 12+ messages in thread
        From: symphonicbtc @ 2023-08-19 23:11 UTC (permalink / raw)
          To: Antoine Riard; +Cc: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 14447 bytes --]
        
        Hi Antoine,
        
        It is important to consider that miners are not always incentivized by what brings them the most profit in the moment, but also their long-term prospects. If they begin participating in transaction censorship, they open the possibility of reducing the value of the coins they mine and also of being "fired" (change of PoW algorithm or etc) by participants in bitcoin.
        
        As far as I know, miners are currently not incentivized to engage in more than a surface-level of performative censorship, such as miners who do not include OFAC sanctioned txs in their blocks. This is economical for them purely because they run a low risk of causing real disruptions to these transactions, and thus the ecosystem itself, and thus their source of profit, but they benefit greatly from the legal impacts doing so may have for them.
        
        Should miners begin to more actively censor transactions, like purposely orphaning blocks, this will be considered as a 51% attack and bitcoin will respond appropriately. These attacks can currently be done (with cooperation between attackers and miners); I fail to see how additional constructs and smart contracts would incentivize it any further.
        
        The disincentives for executing a timewarp attack are similar.
        
        I wholeheartedly agree that due diligence should be taken with these kinds of consensus upgrades, but it is necessary to choose an appropriate security model to do so. Bitcoin does not need built-in mechanisms to defend against miner attacks; proper models of miner incentives as well as the guarantee that node-runners will appropriately respond to attacks is more then sufficient to cover this angle when considering covenant upgrades. The disincentives for miners are the same as any standard 51% attack.
        
        Regards,
        
        Symphonic
        
        ------- Original Message -------
        On Friday, August 18th, 2023 at 8:12 PM, Antoine Riard <antoine.riard@gmail•com> wrote:
        
        > Hi Symphonic,
        >
        > From a game-theory viewpoint where we define among other players utility functions, set of moves, rules of the games and pattern of information, I don't think oracles can be mathematically reduced to miners.
        >
        > Miners are competing to generate a proof-of-work on a set of transactions. This proof-of-work requires hashrate capabilities investment and censoring LN time-sensitive transactions impacting their marginal gains in the mining competitions to sustain the investment renewment in their mining chips.
        >
        > On the other hand, anyone can show as a proof-of-real-world-state oracle, without mining investment. They will take a while to build a reputation as a UTXO state oracle and even in case of wrongdoing, laziness is hard to prove [0].
        >
        > To the best of my knowledge, there is no complete and practical security model for "DLC-like" oracles, as such it's hard to have the epistemological discussion on which assumptions should be regarded as valid or excluded from the formalization.
        >
        > As a note the CLTV-timelock matter for LN-like protocol, beyond CSV and here you start to have interactions with timewarp inflation attacks, which is still not fixed as a consensus-level vulnerability [1].
        >
        > I think my previous statement that the addition of cross-UTXO covenant inspection raises risks in the lack of further R&D on the security model and the game-theory of Bitcoin is still correct. While a risk zero is not an intellectual mirage, at the very least when we're talking about the consensus rules of a $500 B ecosystem, we should bind to world-class standards of software engineering R&D. And as the ecosystem grows, I think we should aim to match best practices in aircraft software design or nuclear reactors.
        >
        > Best,
        > Antoine
        >
        > [0] https://github.com/discreetlogcontracts/dlcspecs/pull/152
        > [1] https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki
        >
        > Le lun. 14 août 2023 à 15:07, symphonicbtc <symphonicbtc@proton•me> a écrit :
        >
        >>> 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
        >>
        >> Hi Antoine,
        >>
        >> These two papers make a lot of incorrect assumptions about bitcoins security model. The assumption of the existence of constructs such as oracles or altchains for “trustless” out-of-band payments opens the door for plenty of things that in reality are not possible without sacrificing security. The assumption that these constructs “minimize” miner / attacker trust is no better than assuming the existence of an oracle that can simply perform the entire attack.
        >>
        >> Moreover, even the limited examples of attacks that do not use these constructs completely overlook the fact that bitcoins security model is dependent on the preservation of the nash equilibrium between miners. Not only is it disincentivized for miners to engage in any form of censorship, because they can all be fired by node-runners at any time, it is also not in miners interests to reorg the chain if say an anonymous miner mines some transactions that were being censored. Sustained, successful censorship in any capacity assumes that bitcoin is compromised, a 51% attack has occurred, and necessitates a change in PoW algorithm. A sufficient CSV in LN-like protocols is always sufficient to avoid being attacked in this way.
        >>
        >> The addition of most forms of covenant does not assist any of these attacks afaict because they already make assumptions rendering them invalid.
        >>
        >> Symphonic
        >>
        >> ------- Original Message -------
        >> On Monday, August 14th, 2023 at 3:00 AM, Antoine Riard via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
        >>
        >>> 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@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@lists•linuxfoundation.org
        >>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        
        [-- Attachment #2: Type: text/html, Size: 19340 bytes --]
        
        ^ permalink raw reply	[flat|nested] 12+ messages in thread

    • * Re: [bitcoin-dev] Concrete MATT opcodes
        2023-08-14 14:07   ` symphonicbtc
        2023-08-18 20:12     ` Antoine Riard
      @ 2023-09-13 20:25     ` Antoine Riard
        1 sibling, 0 replies; 12+ messages in thread
      From: Antoine Riard @ 2023-09-13 20:25 UTC (permalink / raw)
        To: symphonicbtc; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 13824 bytes --]
      
      Hi Symphonic,
      
      I'm not aware of any theory of the "mining firm" (in the coasian sense)
      that would give the lineaments of the cost / income structure of a lambda
      mining operation, and from which to predict how a change in the withhold
      mined coins impact the long-term sustainability of their business,
      especially incorporating relationships with electricity providers and
      mining chips makers.
      
      On the impact of disregarding OFAC sanctioned txs, this sounds correct that
      as long as this is a minority of economic transactions that a mining
      operation can censor, they can afford to stay in business and not lose
      long-term blockspace issuance. If the regulation enforcement cost starts to
      be too high, they can move to a jurisdiction where regulation costs are
      lower [0].
      
      This is indeed a good remark that is unclear if additional constructs and
      smart contracts would incentive block-reorgs or transactions censoring
      attitudes, or even if we would see "lightning-bounty" transactions
      constructs happening generating an economic equilibrium between censorship
      and confirmation. I think this is an area deserving more research for sure.
      
      This is unclear if reduction of the timewarp attack too could modify the
      miners incentives equilibrium [1].
      
      In the end I can only agree that miners and full-nodes operators incentives
      should be a built-in protection in case of consensus upgrades substantially
      altering the Bitcoin deep security model. The thing is this model is very
      unclear to the best of my knowledge and I don't think anyone has taken time
      to formalize it from the years of blocksize wars from then to analyze
      carefully proposed covenant upgrades.
      
      Best,
      Antoine
      
      [0] Side-note and IANA disclaimer. On the application to US OFAC by Bitcoin
      economic entities operators, there is a huge uncertainty if naive
      application of OFAC is respecting the EU GDPR, the article 8 of the CEDH
      and what is left of Roe vs Wade in the US in terms of constitutional
      protections. If you're a human right activist, you have time to dedicate
      yourself on years-long issues and you have the dual-level of legal and
      technical expertise, I would invite you to open litigations against mining
      pools and chainanalysis companies in this space. While European and US
      jurisdictions have clear traditional constitutional protections and legal
      remedies to protect the end-users zone of data autonomy, I'm incredibly
      worried w.r.t to non-Western based jurisdictions less concerned with human
      rights, where chainanalysis companies might do ethically concerning things.
      
      [1] Putting back
      https://bitcoinops.org/en/topics/consensus-cleanup-soft-fork/ on the
      consensus upgrade table I think it would be great to address Bitcoin
      consensus "technical debt" and simplify the design and analysis of
      covenants and second-layers protocols.
      
      
      Le lun. 14 août 2023 à 15:07, symphonicbtc <symphonicbtc@proton•me> a
      écrit :
      
      > > 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
      >
      > Hi Antoine,
      >
      > These two papers make a lot of incorrect assumptions about bitcoins
      > security model. The assumption of the existence of constructs such as
      > oracles or altchains for “trustless” out-of-band payments opens the door
      > for plenty of things that in reality are not possible without sacrificing
      > security. The assumption that these constructs “minimize” miner / attacker
      > trust is no better than assuming the existence of an oracle that can simply
      > perform the entire attack.
      >
      > Moreover, even the limited examples of attacks that do not use these
      > constructs completely overlook the fact that bitcoins security model is
      > dependent on the preservation of the nash equilibrium between miners. Not
      > only is it disincentivized for miners to engage in any form of censorship,
      > because they can all be fired by node-runners at any time, it is also not
      > in miners interests to reorg the chain if say an anonymous miner mines some
      > transactions that were being censored. Sustained, successful censorship in
      > any capacity assumes that bitcoin is compromised, a 51% attack has
      > occurred, and necessitates a change in PoW algorithm. A sufficient CSV in
      > LN-like protocols is always sufficient to avoid being attacked in this way.
      >
      > The addition of most forms of covenant does not assist any of these
      > attacks afaict because they already make assumptions rendering them invalid.
      >
      >
      > Symphonic
      >
      > ------- Original Message -------
      > On Monday, August 14th, 2023 at 3:00 AM, Antoine Riard via bitcoin-dev <
      > bitcoin-dev@lists•linuxfoundation.org> wrote:
      >
      >
      > > 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@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@lists•linuxfoundation.org
      > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      
      [-- Attachment #2: Type: text/html, Size: 17230 bytes --]
      
      ^ permalink raw reply	[flat|nested] 12+ messages in thread

  • * Re: [bitcoin-dev] Concrete MATT opcodes
      2023-08-14  3:00 ` Antoine Riard
      2023-08-14 14:07   ` symphonicbtc
    @ 2023-08-18 15:08   ` Salvatore Ingala
      2023-09-15  0:23     ` Antoine Riard
      1 sibling, 1 reply; 12+ messages in thread
    From: Salvatore Ingala @ 2023-08-18 15:08 UTC (permalink / raw)
      To: Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 3964 bytes --]
    
    Hi Antoine,
    
    Thanks for your comments and insights.
    
    On Mon, 14 Aug 2023 at 05:01, Antoine Riard <antoine.riard@gmail•com> wrote:
    
    > 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.
    >
    
    At this time, my goal is to facilitate maximum experimentation; it's safe
    to open Pandora's box in a sandbox, as that's the only way to know if it's
    empty.
    Concerns will of course need to be answered when a soft-fork proposal is
    made, and restrictions can be added if necessary.
    
    Cross-input introspection seems very likely to have use cases; for example,
    I drafted some notes on how it could be used to implement eltoo-style
    replacement for lightning (or arbitrary state channels) when combined with
    ANYONECANPAY:
     https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63
    <https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63>.
    Although, it would be much easier with CCV+CHECKSIGFROMSTACK, and in that
    case cross-input introspection is not needed.
    
    Similarly, some people raised concerns with recursivity of covenant
    opcodes; that also could be artificially limited in CCV if desired, but it
    would prevent some use cases.
    
    I have some thoughts on why the fear of covenants might generally be
    unjustified, which I hope to write in long form at some point.
    
    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
    >
    
    The flags alter the semantic behavior of the opcode; perhaps you rather
    refer to generalizing the index parameter so that it can refer to a group
    of inputs/outputs, instead?
    I'm not aware of the use cases at this time, feel free to expand further.
    
    
    > 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.
    >
    
    How would these "tags" interact with CHECKCONTRACTVERIFY? I don't quite
    understand the use case.
    
    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.
    >
    
    More generic introspection might not fit well within the semantics of CCV,
    but it could (and probably should) be added with separate opcodes.
    
    That said, I still think you would need at least ANYPREVOUT and more
    > malleability for the amount transfer validation as laid out above.
    >
    
    I personally find OP_CHECKSIGFROMSTACK more natural when thinking about
    constructions with CCV; but most likely either would work here.
    
    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.
    >
    
    Of course, care needs to be taken in general when designing new deferred
    checks, to avoid any sort of quadratic validation cost.
    The DeferredChecks added specifically for CCV has negligible cost, as it's
    just O(n_outputs + n_ccv_out) where n_ccv_out is the number of executed
    OP_CHECKCONTRACTVERIFY opcodes (transaction-wide) that check the output
    amount.
    
    Best,
    Salvatore
    
    [-- Attachment #2: Type: text/html, Size: 5526 bytes --]
    
    ^ permalink raw reply	[flat|nested] 12+ messages in thread

  • • * Re: [bitcoin-dev] Concrete MATT opcodes
        2023-08-18 15:08   ` Salvatore Ingala
      @ 2023-09-15  0:23     ` Antoine Riard
        0 siblings, 0 replies; 12+ messages in thread
      From: Antoine Riard @ 2023-09-15  0:23 UTC (permalink / raw)
        To: Salvatore Ingala; +Cc: Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 8418 bytes --]
      
      Hi Salvatore,
      
      Thanks for the additional insights.
      
      > At this time, my goal is to facilitate maximum experimentation; it's safe
      to open Pandora's box in a sandbox, as that's the only way to know if it's
      empty.
      > Concerns will of course need to be answered when a soft-fork proposal is
      made, and restrictions can be added if necessary.
      
      Thinking more, I wonder if the following conjecture could be sketched out
      e.g "any utxo-inspecting based miners bribing contracts know a
      `counter-bribing` contract that can be offered by a honest Lightning
      channel counterparty".
      
      UTXO-inspection can be leveraged to offer "fee bounties" if a Lightning
      funding UTXO is unspent after X and there is some ongoing anomaly suspected
      (e.g miner-censorship)
      
      > Cross-input introspection seems very likely to have use cases; for
      example, I drafted some notes on how it could be used to implement
      eltoo-style replacement for lightning
      > (or arbitrary state channels) when combined with ANYONECANPAY:
       https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63
      <https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63>.
      Although, it would be much ?
      > easier with CCV+CHECKSIGFROMSTACK, and in that case cross-input
      introspection is not needed.
      
      I looked at the gist and the sequence of transactions is still a bit
      unclear to me. From my understanding:
      - Alice and Bob both creates virtual UTXOs
      - the asymmetric update transactions are valid at the condition of spending
      a lower-state number virtual UTXO
      - any new update transaction is committing to an on-chain virtual UTXO of a
      higher state number
      
      If I'm correct the construction sounds work to me, however I think it
      sounds slightly less economically efficient than OG Eltoo (as presented in
      2018 paper).
      
      > Similarly, some people raised concerns with recursivity of covenant
      opcodes; that also could be artificially limited in CCV if desired, but it
      would prevent some use cases.
      
      I think this is still a good design question if we could prevent recursive
      covenants that could be hijacked by censorship adversaries. Maybe
      recursivity-enablement could be safeguarded on a timelock allowing escape
      out of the recursivity after X blocks.
      
      > The flags alter the semantic behavior of the opcode; perhaps you rather
      refer to generalizing the index parameter so that it can refer to a group
      of inputs/outputs, instead?
      
      Yes, the link about sighash_group-like talk about the use-case of
      (non-interactive) aggregation of pre-signed LN commitment transactions with
      a single pair of input / output iirc. Witness space efficiency benefit for
      LSP and Lightning nodes with hundreds of channels to be closed.
      
      > How would these "tags" interact with CHECKCONTRACTVERIFY? I don't quite
      understand the use case.
      
      https://github.com/bitcoin/bips/pull/1381 and let's say you have
      `OP_PUSH_ANNEX_TAG(t)` where `t` is the type of tag queried. I wonder if
      you could re-build a more powerful CHECKSIGFROMSTACK combined with
      CHECKCONTRACTVERIFY.
      
      > More generic introspection might not fit well within the semantics of
      CCV, but it could (and probably should) be added with separate opcodes.
      
      I think more witness space efficiency could be obtained by casting the CCV
      hash as a merkle tree and traverse it a la g'root
      https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016249.html
      
      > I personally find OP_CHECKSIGFROMSTACK more natural when thinking about
      constructions with CCV; but most likely either would work here.
      
      I agree it's more natural to leverage OP_CHECKSIGFROMSTACK to enable amount
      transfer validation, however far less efficient in terms of witness space.
      
      > The DeferredChecks added specifically for CCV has negligible cost, as
      it's just O(n_outputs + n_ccv_out) where n_ccv_out is the number of executed
      > OP_CHECKCONTRACTVERIFY opcodes (transaction-wide) that check the output
      amount.
      
      At first sight, n_outputs + n_ccv_out sounds indeed cheap. Though I think
      this is yet to see how it interferes with spending script max opcode limits
      and max transaction size.
      
      Best,
      Antoine
      
      Le ven. 18 août 2023 à 16:08, Salvatore Ingala <salvatore.ingala@gmail•com>
      a écrit :
      
      > Hi Antoine,
      >
      > Thanks for your comments and insights.
      >
      > On Mon, 14 Aug 2023 at 05:01, Antoine Riard <antoine.riard@gmail•com>
      > wrote:
      >
      >> 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.
      >>
      >
      > At this time, my goal is to facilitate maximum experimentation; it's safe
      > to open Pandora's box in a sandbox, as that's the only way to know if it's
      > empty.
      > Concerns will of course need to be answered when a soft-fork proposal is
      > made, and restrictions can be added if necessary.
      >
      > Cross-input introspection seems very likely to have use cases; for
      > example, I drafted some notes on how it could be used to implement
      > eltoo-style replacement for lightning (or arbitrary state channels) when
      > combined with ANYONECANPAY:
      >  https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63
      > <https://gist.github.com/bigspider/041ebd0842c0dcc74d8af087c1783b63>.
      > Although, it would be much easier with CCV+CHECKSIGFROMSTACK, and in that
      > case cross-input introspection is not needed.
      >
      > Similarly, some people raised concerns with recursivity of covenant
      > opcodes; that also could be artificially limited in CCV if desired, but it
      > would prevent some use cases.
      >
      > I have some thoughts on why the fear of covenants might generally be
      > unjustified, which I hope to write in long form at some point.
      >
      > 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
      >>
      >
      > The flags alter the semantic behavior of the opcode; perhaps you rather
      > refer to generalizing the index parameter so that it can refer to a group
      > of inputs/outputs, instead?
      > I'm not aware of the use cases at this time, feel free to expand further.
      >
      >
      >> 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.
      >>
      >
      > How would these "tags" interact with CHECKCONTRACTVERIFY? I don't quite
      > understand the use case.
      >
      > 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.
      >>
      >
      > More generic introspection might not fit well within the semantics of CCV,
      > but it could (and probably should) be added with separate opcodes.
      >
      > That said, I still think you would need at least ANYPREVOUT and more
      >> malleability for the amount transfer validation as laid out above.
      >>
      >
      > I personally find OP_CHECKSIGFROMSTACK more natural when thinking about
      > constructions with CCV; but most likely either would work here.
      >
      > 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.
      >>
      >
      > Of course, care needs to be taken in general when designing new deferred
      > checks, to avoid any sort of quadratic validation cost.
      > The DeferredChecks added specifically for CCV has negligible cost, as it's
      > just O(n_outputs + n_ccv_out) where n_ccv_out is the number of executed
      > OP_CHECKCONTRACTVERIFY opcodes (transaction-wide) that check the output
      > amount.
      >
      > Best,
      > Salvatore
      >
      >
      
      [-- Attachment #2: Type: text/html, Size: 11131 bytes --]
      
      ^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2023-09-15  0:23 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-30 21:37 [bitcoin-dev] Concrete MATT opcodes Salvatore Ingala
2023-08-06 20:13 ` David A. Harding
2023-08-07  8:31   ` Salvatore Ingala
2023-08-07 11:37 ` Johan Torås Halseth
2023-08-09  8:38   ` Salvatore Ingala
2023-08-14  3:00 ` Antoine Riard
2023-08-14 14:07   ` symphonicbtc
2023-08-18 20:12     ` Antoine Riard
2023-08-19 23:11       ` symphonicbtc
2023-09-13 20:25     ` Antoine Riard
2023-08-18 15:08   ` Salvatore Ingala
2023-09-15  0:23     ` Antoine Riard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox