From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id E754EC016F for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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