summaryrefslogtreecommitdiff
path: root/e6/0d310be9b208396c98916786fc2ae60af0613f
blob: 1dc61704aafa34ec70312c003e89a0c05b003f05 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3A7B9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Nov 2022 12:01:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 0800C402DC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Nov 2022 12:01:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 0800C402DC
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=F/AEznat
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id IIOfTjsH2OL7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Nov 2022 12:01:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9A48640104
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 9A48640104
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Nov 2022 12:01:28 +0000 (UTC)
Date: Tue, 08 Nov 2022 12:01:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1667908886; x=1668168086;
 bh=10vyl1VaZuxaKaJ6kQk4Q+Fa5V36zv6mTuYSKDSbdSg=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=F/AEznattWwZS3gVx6FY2FpXv3soeLy9wrF5yVv1MW2Al8zLC2i68ZLIFufM6+y+D
 9lVcGLRWw2Zj6aqL82vu7ZSk7//wGN2xFJmbvu3ODPPijmofeDbVBmSUgNpvy3aonB
 jFG3SMorn6dUglM1duwkFu79gsKZvLoWzg/rhwdwZskZhcgGAFbOlTF5U3Q3X86roF
 B/U8+OEyPF6u58uiYrQbVvr8+VjevBlEO4It9dvbT1k2ucS67j1D2tx0LAHNp2aa/Q
 RxDlXfWiG37O6gwzeiHu7ed1Ng2L4SpS/fSF2Iy4+g2XDWjOHhRzUoVtHoBwJds4WQ
 Etue47QODwQhA==
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2022 12:01:30 -0000

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