Date: Mon, 14 Aug 2023 14:07:19 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: symphonicbtc <symphonicbtc@proton.me>
Message-ID: <PfvRyT3qBOh4ap8M1a7E45pKofXHR7k0K_YxS8cPE83sPzSiKH9aiAqukMYBTH8svl4Ob3yYWarP9tjnyZS3vidfAmz7Rb9NEj98f9mVxD0=@proton.me>
In-Reply-To: <CALZpt+F251k7gSpogwFYHxFtGxc_tZjB4UU4SVEr=WvrsyMVMQ@mail.gmail.com>
References: <CAMhCMoFYF+9NL1sqKfn=ma3C_mfQv7mj2fqbqO5WXVwd6vyhLw@mail.gmail.com>
 <CALZpt+F251k7gSpogwFYHxFtGxc_tZjB4UU4SVEr=WvrsyMVMQ@mail.gmail.com>
Feedback-ID: 77757318:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concrete MATT opcodes
Precedence: list

> I think cross-input inspection (not cross-input signature aggregation whi=
ch 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 th=
e 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.
>=20
> 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 securit=
y model. The assumption of the existence of constructs such as oracles or a=
ltchains for =E2=80=9Ctrustless=E2=80=9D out-of-band payments opens the doo=
r for plenty of things that in reality are not possible without sacrificing=
 security. The assumption that these constructs =E2=80=9Cminimize=E2=80=
=9D miner / attacker trust is no better than assuming the existence of an o=
racle that can simply perform the entire attack.

Moreover, even the limited examples of attacks that do not use these constr=
ucts 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 th=
ey can all be fired by node-runners at any time, it is also not in miners i=
nterests to reorg the chain if say an anonymous miner mines some transactio=
ns that were being censored. Sustained, successful censorship in any capaci=
ty assumes that bitcoin is compromised, a 51% attack has occurred, and nece=
ssitates a change in PoW algorithm. A sufficient CSV in LN-like protocols i=
s 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 <bit=
coin-dev@lists.linuxfoundation.org> wrote:


> Hi Salvatore,
> > This also allows inspection of other inputs, that was not possible with=
 the original opcodes.
>=20
> I think cross-input inspection (not cross-input signature aggregation whi=
ch 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 th=
e 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.
>=20
> See https://blog.bitmex.com/txwithhold-smart-contracts/ and https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021395.html
>=20
> 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 s=
afe design practice to rule out those types of concerns thanks to smart bit=
coin contracting primitives.
>=20
> I think this is a common risk to all second-layers vaults, lightning chan=
nels and payment pools.
>=20
> > A flag can disable this behavior"
>=20
> More than a binary flag like a matrix could be introduced to encode subse=
t of introspected inputs /outputs to enable sighash_group-like semantic:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.=
html
>=20
> > There are two defined flags:
> > - CCV_FLAG_CHECK_INPUT =3D 1: if present, <index> refers to an input;
> > otherwise, it refers to an output.
> > - CCV_FLAG_IGNORE_OUTPUT_AMOUNT =3D 2: only defined when _CHECK_INPUT
> > is absent, it disables the deferred checks logic for amounts.
>=20
> Or even beyond a matrix, it could be a set of "tags". There could be a ge=
neralized tag for unstructured data, and another one for bitcoin transactio=
n / script data types (e.g scriptpubkey, amount, nsequence, merkle branch) =
that could be fetched from the taproot annex.
>=20
> > 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).
>=20
> 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 thi=
nk you would need more malleability here.
>=20
> > 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.
>=20
> I think this generic framework is interesting for joinpool / coinpool / p=
ayment pool, as you can check that any withdrawal output can be committed a=
s part of the input scriptpubkey, and spend it on blessed-with-one-particip=
ant-sig script. There is still a big open question if it's efficient in ter=
ms of witness space consumed.
>=20
> That said, I still think you would need at least ANYPREVOUT and more mall=
eability for the amount transfer validation as laid out above.
>=20
> Looking on the `DeferredCheck` framework commit, one obvious low-level co=
ncern is the DoS risk for full-nodes participating in transaction-relay, an=
d 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 netw=
ork today.
>=20
> Thanks for the proposal,
>=20
> Best,
> Antoine
>=20
>=20
>=20
> Le dim. 30 juil. 2023 =C3=A0 22:52, Salvatore Ingala via bitcoin-dev <bit=
coin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>=20
> > Hi all,
> >=20
> > 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.
> >=20
> > The code is implemented in the following fork of the
> > bitcoin-inquisition repo:
> >=20
> > https://github.com/Merkleize/bitcoin/tree/checkcontractverify
> >=20
> > Therefore, it also includes OP_CHECKTEMPLATEVERIFY, as in a
> > previous early demo for vaults [3].
> >=20
> > 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.
> >=20
> > ## Changes vs the previous draft
> >=20
> > 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).
> >=20
> > ## Semantics
> >=20
> > The new OP_CHECKCONTRACTVERIFY takes 5 parameters from the stack:
> >=20
> > <data>, <index>, <pk>, <taptree>, <flags>
> >=20
> > The core logic of the opcode is as follows:
> >=20
> > "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>".
> >=20
> > The following are special values of the parameters:
> >=20
> > - 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.
> >=20
> > There are two defined flags:
> > - CCV_FLAG_CHECK_INPUT =3D 1: if present, <index> refers to an input;
> > otherwise, it refers to an output.
> > - CCV_FLAG_IGNORE_OUTPUT_AMOUNT =3D 2: only defined when _CHECK_INPUT
> > is absent, it disables the deferred checks logic for amounts.
> >=20
> > 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.
> >=20
> > 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).
> >=20
> > ## Comment
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > I look forward to your comments, and to start drafting a BIP proposal.
> >=20
> > Best,
> > Salvatore Ingala
> >=20
> >=20
> > [*] - 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.
> >=20
> >=20
> > References:
> >=20
> > [1] - https://merkle.fun/
> > [2] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-Nove=
mber/021182.html
> > [3] - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Apri=
l/021588.html
> > [4] - https://github.com/bitcoin-inquisition/bitcoin/compare/24.0...Mer=
kleize:bitcoin:checkcontractverify
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev