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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id E754EC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2020 01:27:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id DB44087AD5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2020 01:27:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id TnuqCcuTvIiH
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2020 01:27:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch
[185.70.40.137])
by whitealder.osuosl.org (Postfix) with ESMTPS id 75AB686477
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 Jul 2020 01:27:32 +0000 (UTC)
Date: Tue, 21 Jul 2020 01:27:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1595294849;
bh=pswOajnWDSQfLh/4QZ/DjvyDcZLXaoLxODe26B6wl9c=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=RHakAZF6kQCtc4KK7cr4xIbQehjr3dq9NAUCtHj77SZ36loUwRd26kYZU+2XXPRFW
wCDuCr3rLIfzdStlcPWacYw8zj+hDGky3Ca5vCkfL14n2r4j1VSrQdRe1ApE2fp+pf
mC44UWCqVdQ8eTJ095xVcbk212Sto5G+CFhyMi2I=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2-aGj1jHrINMEcLsv_fVxA-k5Ovw1gEYKmNm3RepkteM_D7Ys9P1Q0qiFp3-J801HEyP8_4xfVT_86xU6SJQH8Cyf5cuwQ0-CpRtEOUqdcA=@protonmail.com>
In-Reply-To: <1z54XsScl3QReBGNtkf6I45p_IwHQMZ6EBVTM5qdZ9P6xv7a3SMxP2l3KahOoUvKRW9o6-saM36A0vxJtMS9pIRVTPGNlU3DMlUVwHZyZks=@protonmail.com>
References: <1z54XsScl3QReBGNtkf6I45p_IwHQMZ6EBVTM5qdZ9P6xv7a3SMxP2l3KahOoUvKRW9o6-saM36A0vxJtMS9pIRVTPGNlU3DMlUVwHZyZks=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For
Smart Transferable Hardware
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, 21 Jul 2020 01:27:35 -0000
Good morning list,
Andy Schroder shared a mildly related link: http://andyschroder.com/Distrib=
utedCharge/
The above project does not use the Cryptographic Relay.
Briefly, it is a rentable charging station for electric cars.
I observed, however, that a rentable Cryptographic Relay device could be im=
plemented using Cryptographic Relay features:
* Support for MuSig (by use of Schnorr signatures).
* Timelocks (by use of block header chains).
* Delegated operators.
> Suppose you own a Cryptographic Relay controlling a charger for electrica=
l cars.
> And I wish to rent this charger for some time so I can charge my electric=
al car.
>
> This rental contract can be done by this ritual:
>
> * We generate two fresh keypairs.
> * Call the first keypair the "rent-transfer" keypair.
> * Call the second keypair the "rental-period" keypair.
> * You generate, but do not sign, a rent-transfer command to transfer owne=
rship from your unilateral ownership to the MuSig of our rent-transfer keys=
.
> * We generate an initial backout command to transfer ownership from the M=
uSig rent-transfer key back to your control, but with an `nLockTime` in the=
close future.
> We sign this command.
> * We generate a rental-start command to transfer ownership from the MuSig=
rent-transfer key to our MuSig rental-period key.
> I create a partial signature, missing only your share.
> * We generate a command to add me as a delegated operator of the device, =
authorized by the MuSig rental-period key.
> * We generate a rental-end command to transfer ownership from the MuSig r=
ental-period key, back to your unilateral control, with an `nLockTime` equa=
l to the end of the rental period.
> We sign this command.
> * Then, I create (but do not sign!) a rent-funding Bitcoin transaction fo=
r the rent, paying to the Musig rent-transfer key.
> * We generate a rent-reclaim Bitcoin transaction spending the above rent-=
funding Bitcoin transaction, sending the funds back to my unilateral contro=
l, but with an `nLockTime` in the future but less than the timeout of the i=
nitial backout command.
> We sign this transaction.
> * You sign the rent-transfer command and feed it to the device.
> * We generate a rent-claim Bitcoin transaction spending the above rent-fu=
nding Bitcoin transaction, sending the funds to your unilateral control.
> I demand an adaptor signature, such that I can learn your share of the =
signature of the rental-start command.
> Then I provide a partial signature to you.
> * You complete the rent-claim Bitcoin transaction signature, claiming the=
rental fee.
> * I get the completed rental-start command signature and send it to the d=
evice, transferring ownership of the device to our MuSig rental-period pubk=
ey.
> * I send the command to add me as an operator of the device, letting me u=
se the device as I see fit, but not transfer ownership to anyone else.
> * When the rental period ends, you send the rental-end command to the dev=
ice and turn it off so I can no longer use it.
>
> The above can probably also be done with the Bitcoin-side payments done v=
ia Lightning-with-PTLC.
> It requires Taproot, but does not require `SIGHASH_ANYPREVOUT`.
We can also consider the case where the renter of the device wishes to retu=
rn it early, for a partial refund of the total rent (or equivalently, for t=
he renter to rent in units of smaller time and just extending the rental pe=
riod as needed).
> As the ownership of the device is in a 2-of-2 between the renter and the =
"true owner", they can, after having a meeting of minds, arrange for an ear=
ly return command conditional on a partial refund of the original rent.
> Again, there is simply a need for pay-for-signature, with the renter part=
ial-signing a command to return the device ownership early, which if comple=
ted by the owner, completes the signature to refund the original rent.
>
> Alternately, the rent may pay for a short rental period, and to extend th=
e rental period, the 2-of-2 between the nenter and "true owner" on the devi=
ce is "reseated" (i.e. fresh keypairs to generate a fresh 2-of-2 are create=
d and ownership transferred to the new 2-of-2) which invalidates the previo=
us timeout, and moves to a later timeout.
> The "re-rental" command which moves the ownership from the previous 2-of-=
2 to the next 2-of-2 is partially signed by the renter, and to complete the=
signature, the renter pays for the signature share from the owner.
> (this is done after setting up the command to make the renter a delegated=
operator and the command to let the owner re-acquire unilateral ownership =
of the device, I elide those steps here.)
> The pay-for-signature can be done over Lightning as well.
Now, suppose the device being rented out is in fact a smart domicile, which=
can be locked/unlocked by the owner/operator of a Cryptographic Relay.
Typically, when renting out domiciles, a deposit is involved, where:
* The tenant pays out the rent plus the deposit.
* The landlady may keep the deposit in case of egregious damage to (or othe=
r abuse of) the domicile.
The construction of a rent-with-deposit contract is actually similar to the=
construction of the earlier given collateralized loan:
> * The "loan shark" position is taken up by the "renter".
> * The "loaner" position is taken up by the "landlady" of the device being=
rented out.
> * The "loan shark" also asks for a command to add them as a delegated ope=
rator of the device.
> * Instead of the payback amount being larger than what the loan shark/ren=
ter pays to the loaner/landlady, it is smaller, with the lower payback amou=
nt representing the deposit.
>
> In this particular case, the contractors need not use `SIGHASH_ANYPREVOUT=
`, instead the landlady can give a PTLC on the deposit with the deposit bei=
ng funded from the loan payout transaction (which would be a rent+deposit-p=
ayout transaction).
(note: missing in the above is the detail that at the end of the contract p=
eriod, ownership of the device goes back to the landlady/loaner position, a=
s opposed to the collateralized-loan case where it goes to the loan shark p=
osition.)
Perhaps smart contract languages should have PTLCs and partial signatures a=
s primitives and be written in a compositional/declarative style, rather th=
an some Turing-complete mess, because PTLCs are cool.
Regards,
ZmnSCPxj
|
