public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware
Date: Tue, 21 Jul 2020 01:27:27 +0000	[thread overview]
Message-ID: <2-aGj1jHrINMEcLsv_fVxA-k5Ovw1gEYKmNm3RepkteM_D7Ys9P1Q0qiFp3-J801HEyP8_4xfVT_86xU6SJQH8Cyf5cuwQ0-CpRtEOUqdcA=@protonmail.com> (raw)
In-Reply-To: <1z54XsScl3QReBGNtkf6I45p_IwHQMZ6EBVTM5qdZ9P6xv7a3SMxP2l3KahOoUvKRW9o6-saM36A0vxJtMS9pIRVTPGNlU3DMlUVwHZyZks=@protonmail.com>

Good morning list,

Andy Schroder shared a mildly related link: http://andyschroder.com/DistributedCharge/

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 implemented 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 electrical cars.
> And I wish to rent this charger for some time so I can charge my electrical 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 ownership from your unilateral ownership to the MuSig of our rent-transfer keys.
> * We generate an initial backout command to transfer ownership from the MuSig 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 rental-period key, back to your unilateral control, with an `nLockTime` equal to the end of the rental period.
>   We sign this command.
> * Then, I create (but do not sign!) a rent-funding Bitcoin transaction for 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 control, but with an `nLockTime` in the future but less than the timeout of the initial 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-funding 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 device, transferring ownership of the device to our MuSig rental-period pubkey.
> * I send the command to add me as an operator of the device, letting me use 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 device and turn it off so I can no longer use it.
>
> The above can probably also be done with the Bitcoin-side payments done via 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 return it early, for a partial refund of the total rent (or equivalently, for the renter to rent in units of smaller time and just extending the rental period 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 early return command conditional on a partial refund of the original rent.
> Again, there is simply a need for pay-for-signature, with the renter partial-signing a command to return the device ownership early, which if completed by the owner, completes the signature to refund the original rent.
>
> Alternately, the rent may pay for a short rental period, and to extend the rental period, the 2-of-2 between the nenter and "true owner" on the device is "reseated" (i.e. fresh keypairs to generate a fresh 2-of-2 are created and ownership transferred to the new 2-of-2) which invalidates the previous 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 other 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 operator of the device.
> * Instead of the payback amount being larger than what the loan shark/renter pays to the loaner/landlady, it is smaller, with the lower payback amount 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 being funded from the loan payout transaction (which would be a rent+deposit-payout transaction).

(note: missing in the above is the detail that at the end of the contract period, ownership of the device goes back to the landlady/loaner position, as opposed to the collateralized-loan case where it goes to the loan shark position.)

Perhaps smart contract languages should have PTLCs and partial signatures as primitives and be written in a compositional/declarative style, rather than some Turing-complete mess, because PTLCs are cool.

Regards,
ZmnSCPxj



  reply	other threads:[~2020-07-21  1:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20 14:18 [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware ZmnSCPxj
2020-07-21  1:27 ` ZmnSCPxj [this message]
2020-07-21  5:25 ` Andy Schroder
2020-07-21  9:19   ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='2-aGj1jHrINMEcLsv_fVxA-k5Ovw1gEYKmNm3RepkteM_D7Ys9P1Q0qiFp3-J801HEyP8_4xfVT_86xU6SJQH8Cyf5cuwQ0-CpRtEOUqdcA=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox