Date: Tue, 08 Nov 2022 12:01:11 +0000
To: Salvatore Ingala <salvatore.ingala@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Vbb1PZfBzm6JBddqNIfikVE2G1fDmObt0BBt2BqhmHV_Tx7KLGU5SSQPPp0OaLZHAKrkKobA2f60tX4TOl996aE9ds1tZWaGAHbSr9wu5r0=@protonmail.com>
In-Reply-To: <CAMhCMoH9uZPeAE_2tWH6rf0RndqV+ypjbNzazpFwFnLUpPsZ7g@mail.gmail.com>
References: <CAMhCMoH9uZPeAE_2tWH6rf0RndqV+ypjbNzazpFwFnLUpPsZ7g@mail.gmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Merkleize All The Things
Precedence: list

Good morning Salvatore,

Interesting idea.

The idea to embed the current state is similar to something I have been mus=
ing about recently.


> ### Game theory (or why the chain will not see any of this)
>=20
> With the right economic incentives, protocol designers can guarantee that=
 playing a losing game always loses money compared to cooperating. Therefor=
e, the challenge game is never expected to be played on-chain. The size of =
the bonds need to be appropriate to disincentivize griefing attacks.

Modulo bugs, operator error, misconfigurations, and other irrationalities o=
f humans.


> - OP_CHECKOUTPUTCOVENANTVERIFY: given a number out_i and three 32-byte ha=
sh elements x, d and taptree on top of the stack, verifies that the out_i-t=
h output is a P2TR output with internal key computed as above, and tweaked =
with taptree. This is the actual covenant opcode.

Rather than get taptree from the stack, just use the same taptree as in the=
 revelation of the P2TR.
This removes the need to include quining and similar techniques: just do th=
e quining in the SCRIPT interpreter.

The entire SCRIPT that controls the covenant can be defined as a taptree wi=
th various possible branches as tapleaves.
If the contract is intended to terminate at some point it can have one of t=
he tapleaves use `OP_CHECKINPUTCOVENANTVERIFY` and then determine what the =
output "should" be using e.g. `OP_CHECKTEMPLATEVERIFY`.


> - Is it worth adding other introspection opcodes, for example OP_INSPECTV=
ERSION, OP_INSPECTLOCKTIME? See Liquid's Tapscript Opcodes [6].

`OP_CHECKTEMPLATEVERIFY` and some kind of sha256 concatenated hashing shoul=
d be sufficient I think.

> - Is there any malleability issue? Can covenants =E2=80=9Crun=E2=80=9D wi=
thout signatures, or is a signature always to be expected when using spendi=
ng conditions with the covenant encumbrance? That might be useful in contra=
cts where no signature is required to proceed with the protocol (for exampl=
e, any party could feed valid data to the bisection protocol above).

Hmm protocol designer beware?

Regards,
ZmnSCPxj