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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BC20A86D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Jun 2019 20:25:16 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A486E2C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Jun 2019 20:25:15 +0000 (UTC)
Date: Sat, 29 Jun 2019 20:25:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1561839912;
bh=DtlBAwMc2eOcwMfYtIM/KOYP1wlwZnqsw0/n4vr1zOg=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=Qgij0NXeTwrU8aBOhYhVn3qi2oMs7LKO75axSsrNtXLD0G4e3Fht8MuT63xAJ4u2q
ZJn1C6CTEBVzZYJTUCgyu8a+od3woAZU9nl1BKpkeDunxPMmgdjhBrKemw8IrdaTyS
Wp3j8XkHPFgnz7tE+o35MKI+OVnINDQh1pwynapA=
To: Tamas Blummer <tamas.blummer@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com>
In-Reply-To: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com>
References: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW, URI_NOVOWEL autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 29 Jun 2019 21:07:15 +0000
Subject: Re: [bitcoin-dev] Generalized covenant to implement side chains
embedded into the bitcoin block chain
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sat, 29 Jun 2019 20:25:16 -0000
Good morning Tamas,
While I think covenants for some kind of debt tool is mildly interesting an=
d an appropriate solution, I wonder about this particular use-case.
It seems to me that, as either the `Transfer` signers or `Exit` signers are=
always involved, that the `Transfer` signers can be constrained so as to e=
nsure that the rules are followed correctly, without requiring that covenan=
ts be used on the Bitcoin layer.
After all, the outputs of each transaction signed by the `Transfer` signers=
are part of the transaction that is being signed; surely the `Transfer` si=
gners can validate that the output matches the contract expected, without r=
equiring that fullnodes also validate this?
In particular, it seems to me that covenants are only useful if there exist=
some alternative that does not involve some kind of fixed `Transfer` signe=
r set, but still requires a covenant.
Otherwise, the `Transfer` signer set could simply impose the rules by thems=
elves.
Another thing is that, if my understanding is correct, the "sidechain" here=
is not in fact a sidechain; the "sidechain" transaction graph is published=
on the Bitcoin blockchain.
Instead, the `Transfer` signers simply validate some smart contract, most l=
ikely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public key=
s, and ensure that the smart contract is correctly executed.
In that case, it may be useful to consider Smart Contracts Unchained instea=
d: https://zmnscpxj.github.io/bitcoin/unchained.html
It would be possible, under Smart Contracts Unchained, to keep the `Transfe=
r`-signed transactions offchain, until `Exit`-signing.
Then, when this chain of transaction spends is presented to the participant=
s, the participants can be convinced to sign a "cut-through" transaction th=
at cuts through the offchain transactions, with the resulting cut-through b=
eing the one confirmed onchain, and signed only the participants, without t=
he `Transfer` or `Exit` federation signatures appearing onchain.
This hides not only the smart contract being executed, but also the fact th=
at a Smart Contracts Unchained technique was at all used.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Saturday, June 29, 2019 1:53 PM, Tamas Blummer via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:
> I introduced you to gerneralized covenants[1] earlier, but in a domain sp=
ecific context that de-routed us from technical discussion. Let me demonstr=
ate the concept in a more generic use:
>
> A covenant=C2=A0
>
> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant dro=
p)=C2=A0
>
> would put a coin under the alternative control of a Transfer and Exit key=
s together with the script in control of the current owner.=C2=A0
> Additional transaction level validations of transactions spending input w=
ith covenants apply as in [1]
>
> Owner of such coins would be able to transfer them to others provided an =
addtional Transfer signature, in which case the coin remains encumbered wit=
h the same covenant.
> If Exit and owner signs the covenant is dropped on the output, it becomes=
a plain Bitcoin again.
>
> The Thransfer and Exit signatures could be threshold signatures of a fede=
ration, whereby member decide if the proposed transfer transaction complies=
with whatever unique rules they impose.=C2=A0
>
> The result is a federated side chain embedded into the Bitcoin block chai=
n.
>
> Bob could purchase some asset guarded by the federation with a transactio=
n:
>
> Inputs
> 100.0001 pk(Bob)
>
> Outputs
> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and=
(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)=C2=
=A0
> 99.9=C2=A0pk(Transfer)
>
> Transfer to Alice with consent of the transfer validators:
>
> Inputs
> 0.1 or(and(pk(Transfer), pk(Bob)), and(pk(Exit), pk(Bob)) covenant or(and=
(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)=C2=
=A0
> 100.001 pk(Alice)
>
> Outputs
> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or=
(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)=
=C2=A0
> 100 pk(Bob)
>
> Alice might be approved to exit with the exit signature of the federation=
:
>
> Inputs
> 0.1 or(and(pk(Transfer), pk(Alice)), and(pk(Exit), pk(Alice)) covenant or=
(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant drop)=
=C2=A0
> 99.9 pk(Transfer)
>
> Outputs
> 99.9999 pk(Alice)
>
> Tamas Blummer
> [1]=C2=A0https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Jun=
e/017059.html
|
