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
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
|
Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3508FC3A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Jun 2019 16:57:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com
[209.85.128.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2E508A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Jun 2019 16:57:11 +0000 (UTC)
Received: by mail-wm1-f49.google.com with SMTP id x15so13513593wmj.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Jun 2019 09:57:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
:references; bh=Q5erL7tVwL+qczBk3g324dNfiWmJOTRCJkC/uGRlFZw=;
b=Jmxj76io31A4vNA2pzaym/4bA9pUK03CwfTUCmalR0Fw1mlwHoXr5whD1tDlj7C0V9
9S6Yu96rl3AgaLReq1aZ947uwl/al4rJ5LYdqKBobCM+fIK589uAa6yeLKwJeRRFYaef
XrkLczyMTVt591mzmmi7ie2HK8BqIhpXgJqj4qusGA8beXkZB/iqWDskWKm9aqZnTEWo
4AGYa705tP0oDBr2ZxbjNV5mvd90UEw4eOlcF54d6z3XCDpsS/IzLtuCfE6mADCPSqom
I7xPTOp6C3hc0ahaDbxVWhEPLzsZJLzDIfloKak/fdswz6dUW6+v2OKqbLqFNR8XoBSg
cw7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:message-id:mime-version:subject:date
:in-reply-to:cc:to:references;
bh=Q5erL7tVwL+qczBk3g324dNfiWmJOTRCJkC/uGRlFZw=;
b=iHVFNVhxPthp6GvCQwoc3JALWo6P27KW+yc0dA1bIfF7QHAfZ33C5gkfaSartimgvM
lqW6a2k2+4hsoFL8835bTugomkmvBeGO5T42eF+zaaiVpWFa+XmudjB3cueyEXdaDcSB
Y9onVHSkErGvP2ZrKFDN+XLTm0AKSFImWc68D2f73MpDifaX8jfOC5oZvMBDqhAgJcJL
mDgk0fI5q/5gBf4WCvYASlDTWdlu0mUyGPAZqSKnwmuqJzSKjeu4YDlgiackuIs8rRmx
TpWy7L5/+Ch+WsGgXmYEXv98bOfDbdNGZfmIa/XlUH6UXoV2+y+epaJr2YcN81GKADGj
y/Lg==
X-Gm-Message-State: APjAAAVv8fexJ4i2+J1zUm4FBI9rafaDPLYpmxZDZxbADUJHMCvktpgl
SuUkAXB/6vhBdCoFML2WnbA=
X-Google-Smtp-Source: APXvYqw3ciB1x9stpP29sl+w9ipecoSguL/GqvtHqLpxkL0dHP8Fh77Fm1KpmOx9qDXvuvb8JBxE9Q==
X-Received: by 2002:a7b:c202:: with SMTP id x2mr13376177wmi.49.1561913829691;
Sun, 30 Jun 2019 09:57:09 -0700 (PDT)
Received: from p200300dd6712641801d2360ece635895.dip0.t-ipconnect.de
(p200300DD6712641801D2360ECE635895.dip0.t-ipconnect.de.
[2003:dd:6712:6418:1d2:360e:ce63:5895])
by smtp.gmail.com with ESMTPSA id s10sm9519636wmf.8.2019.06.30.09.57.08
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 30 Jun 2019 09:57:08 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <A048BAB4-9166-40BD-BC70-7FCE47F00D72@gmail.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_2C5E3A2E-B13A-49FF-9845-7129C8F59250";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 30 Jun 2019 18:57:06 +0200
In-Reply-To: <_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <7856AC5A-D2AD-4C94-99BC-AA0F948E2B40@gmail.com>
<_H2l-XejXP1xbWnnuxmn6V6YlA6KYbN-7f_nYF32W609BvQANEiJYVq9z0DWvQVAFTmKHlzwVPiHiRBT0XETT7UJi0syxXMxXN4HskUDHW4=@protonmail.com>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: Sun, 30 Jun 2019 17:08:59 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 30 Jun 2019 16:57:12 -0000
--Apple-Mail=_2C5E3A2E-B13A-49FF-9845-7129C8F59250
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Hello ZmnSCPxj,
Yes, representation of debt is more interesting here as it requires the =
covenant, wheras this example, as you point out, was less convincing =
given alternatives.
I created this example to avoid discussion of topics not approriate on =
this list.
Thank you for the suggestion of unchained execution of transfers with =
cut-through exit transaction as this made the example much stronger:
The most important question for someone who trusts his coins to some =
unchained platform is probably the question of how exit is guaranteed if =
one is unhappy with what one gets.
With the exit covenant exit conditions are set in stone, since validated =
on-chain. If the exit key is owned by a trusted arbiter other than the =
federation governing the unchained platform
then one at least have the option to cut losses at some point by =
presenting the arbiter a chain of valid transactions and asking to sign =
the exit.
Participants in the unchained platform would also be interested to =
regularly snapshot the economic effect of offchain transactions with =
cut-through transactions as such cut-through shortens the chain of =
transactions
they would need to get on chain if chosing the exit without consent of =
the federation governing the transfers.
So the convenant needed is: 'covenant or(_ covenant transitive, =
and(pkExit, _) covenant drop)' which gives unrestricted flexibility to =
the unchained platform with the exception that it has to maintain the =
exit option.
Tamas Blummer
> On Jun 29, 2019, at 22:25, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Tamas,
>=20
> While I think covenants for some kind of debt tool is mildly =
interesting and an appropriate solution, I wonder about this particular =
use-case.
>=20
> 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 ensure that the rules are followed correctly, =
without requiring that covenants 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` signers can validate that the output matches the contract =
expected, without requiring that fullnodes also validate this?
>=20
> 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` signer set, but still requires a covenant.
> Otherwise, the `Transfer` signer set could simply impose the rules by =
themselves.
>=20
>=20
> 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 likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` =
public keys, and ensure that the smart contract is correctly executed.
> In that case, it may be useful to consider Smart Contracts Unchained =
instead: https://zmnscpxj.github.io/bitcoin/unchained.html
>=20
> It would be possible, under Smart Contracts Unchained, to keep the =
`Transfer`-signed transactions offchain, until `Exit`-signing.
> Then, when this chain of transaction spends is presented to the =
participants, the participants can be convinced to sign a "cut-through" =
transaction that cuts through the offchain transactions, with the =
resulting cut-through being the one confirmed onchain, and signed only =
the participants, without the `Transfer` or `Exit` federation signatures =
appearing onchain.
> This hides not only the smart contract being executed, but also the =
fact that a Smart Contracts Unchained technique was at all used.
>=20
> Regards,
> ZmnSCPxj
>=20
>=20
> Sent with ProtonMail Secure Email.
>=20
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 =
Original Message =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:
>=20
>> I introduced you to gerneralized covenants[1] earlier, but in a =
domain specific context that de-routed us from technical discussion. Let =
me demonstrate the concept in a more generic use:
>>=20
>> A covenant
>>=20
>> or(and(pk(Transfer), _) covenant transitive, and(pk(Exit),_) covenant =
drop)
>>=20
>> would put a coin under the alternative control of a Transfer and Exit =
keys together with the script in control of the current owner.
>> Additional transaction level validations of transactions spending =
input with covenants apply as in [1]
>>=20
>> Owner of such coins would be able to transfer them to others provided =
an addtional Transfer signature, in which case the coin remains =
encumbered with the same covenant.
>> If Exit and owner signs the covenant is dropped on the output, it =
becomes a plain Bitcoin again.
>>=20
>> The Thransfer and Exit signatures could be threshold signatures of a =
federation, whereby member decide if the proposed transfer transaction =
complies with whatever unique rules they impose.
>>=20
>> The result is a federated side chain embedded into the Bitcoin block =
chain.
>>=20
>> Bob could purchase some asset guarded by the federation with a =
transaction:
>>=20
>> Inputs
>> 100.0001 pk(Bob)
>>=20
>> 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)
>> 99.9 pk(Transfer)
>>=20
>> Transfer to Alice with consent of the transfer validators:
>>=20
>> 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)
>> 100.001 pk(Alice)
>>=20
>> 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)
>> 100 pk(Bob)
>>=20
>> Alice might be approved to exit with the exit signature of the =
federation:
>>=20
>> 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)
>> 99.9 pk(Transfer)
>>=20
>> Outputs
>> 99.9999 pk(Alice)
>>=20
>> Tamas Blummer
>> [1] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.h=
tml
>=20
>=20
--Apple-Mail=_2C5E3A2E-B13A-49FF-9845-7129C8F59250
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0Y6eIACgkQ9nKRxRdx
ORwqsgf+OXnIOUlhsuiM3+/oNE4oNPMku5GybhHaTzOYlMYhe0jm9ZySGC3W1qEU
igmwWlLBLBBXPIS5eCsqtPaEP0yJg2HooOMjVoiCvJ37qVyq/X+LnWKbt2FzI8Rc
ecVd5rA3+9h3dSDOUwJkTYPziKwww3/hVTkOLx7tYVv2PzMxl2wEUsswaciwW4Jv
MTLQvs94i3p4jzIDoTen+F/RTdCBRG4JBYcCMXLdqlC7+EbLPpTYqKBSOURXeXuJ
qBgTJHUwThiXTdFhP3VZ7UuI7vsoPzO3Cy/RcmlxtF1fEhJuvNuqD264jOfYu9X2
Lft73ink04d0iOxxjRn7k2t0YgYzhQ==
=GaXW
-----END PGP SIGNATURE-----
--Apple-Mail=_2C5E3A2E-B13A-49FF-9845-7129C8F59250--
|