[bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

[bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

[ZmnSCPxj]

Introduction
============

An electrical relay is an electrically-controlled switch, often diagrammed as:

      +-------------o
      |
      |   \
      |    \
      +--o  o-------o

    o----  |
         ) |
         ) |
         ) |
    o----  |

The terminals at the left feed into a coil.
When electricity passes through the coil, it magnetizes a core, and the magnetism attracts a switch into a closed position, which would let electricity to pass through the terminals at the right.
This can be used to "turn on" or supply power to a different electrical device.

If no electricity is passing through the coil via the terminals on the left, then no electricity can pass through the terminals on the right, as the switch is an open position at default.

This is a fairly simple logic circuitry, upon which more complicated circuitry can be made.

Similarly, a Cryptographic Relay is a hardware electrical component that allows control of some electrical circuit.
It has two terminals which are the two terminals of a switch.
It can also be contacted, for example via Bluetooth, by an electronic computing device.
The Cryptographic Relay has a public key, which represents the current owner of the relay.
If the electronic device is able to provide a proof-of-knowledge of the private key (i.e. a signature) corresponding to the public key that the Cryptographic Relay knows, then it allows the switch to be controlled by that device.

Motivation
==========

Suppose I have a car I wish to sell to you, for Bitcoins.
This car, as it happens, has a Cryptographic Relay: it will only start its engine if it gets a signed message from me using a private key I have on my phone.
It knows my public key, and will only turn off and on at my command.

Now, you want to be able to know that by paying me Bitcoins, you get sole ownership of the car I am selling.

This is in fact, nothing more than a swap operation.
I have an asset, a car, and you have an asset, some Bitcoins.
We want to atomically swap one asset for the other asset, and those assets do not exist in a single asset-assignment system.

Paying Bitcoins For Cars Via Succinct Atomic Swaps
==================================================

Fortunately, there is an atomic swap operation, Succinct Atomic Swaps, which can be used to create an atomic swap between my car and your Bitcoins.

An important part of this Succinct Atomic Swap is that all timeouts are only in one asset-assignment system.
The original Succinct Atomic Swap discussion gives an example of swapping Bitcoins for Litecoins.
Each has its own distinct blockchain, which is a distinct distributed asset-assignment system.

A crucial part of the Succinct Atomic Swap is that all timelocks are only on one asset-assignment system.
The other asset-assignment system need not support anything other than assigning ownership of assets to (homomorphically additive) public keys.

This is important as a major simplification of the Cryptographic Relay:
The relay only needs to know its *current owner*, and does not need to know the current time!

Thus, in order for you to buy my car:

* You set up the Succinct Atomic Swap on the Bitcoin blockchain.
* We generate fresh private keys, then combine them via MuSig, and I transfer the ownership of the car to that MuSig public key.
* If I claim the funds, that atomically reveals my share of the private key to you, so you can claim the car using your private key plus my share and transfer the car to sole control of you.
* If I fail to claim the funds, then when you reclaim your funds at timeout, that atomically reveals your share of the private key to me, so that I can claim the car using my private key plus your share and transfer the car back to sole control of me.

This is in fact the same as the Succinct Atomic Swap example, except that instead of me swapping my Litecoins for your Bitcoins, I am swapping my Cryptographic Relay for your Bitcoins.

Cryptographic Relay Operations
==============================

Thus, a Cryptographic Relay needs to support only the following basic operations.
These operations are triggered by its owner sending a message, plus a signature verifiable by the public key, to the Cryptographic Relay.
(Cryptographer warning: if using Schnorr, the message hashed into the signature also has to include the public key that is signing it, since BIP32 nonhardened derivation allows a Schnorr signature created by one child private key to be trivially malleated into a signature for the same message by a sibling private key; this does not exist in ECDSA due to its nonlinearity.
message sends need not include the public key, it can be added by the cryptographic relay since it has to know the public key of the owner anyway.
Of note is that the bip-340 description of Schnorr includes the public key in the hash operation of signatures as well, and does not require this.)

The only operations necessary are:

1.  Turn on.
2.  Turn off.
3.  Transfer ownership to new pubkey ___.

Due to Succinct Atomic Swaps not requiring any kind of timelock on one asset-assignment system, the Cryptographic Relay need not have any concept of time, as mentioned above, and transfer of ownership can be done by a simple message signed by the current owner transferring ownership to a new public key.

(Cryptographer warning: turn-on/turn-off messages should be challenge-response: the Cryptographic Relay requests signing with a unique nonce included in the message, otherwise previous messages can be captured by third parties and replayed; ownership-transfer messages should probably also include a nonce, or otherwise we could require non-reuse of keys.
This can be implemented with a 64-bit incrementing nonce, which should work for the practical lifetime of any Cryptographic Relay.)

(Cryptographer warning: similarly, ownership-transfer messages should probably be indexed as well with an incrementing nonce, otherwise key reuse would allow signature replay; similarly again, each Cryptographic Relay should have a UUID that is included in message hashes, as otherwise key reuse would allow signature replay for commands to one device to be repeated for another device.)

Lightning
=========

Unfortunately, it seems not possible to transport Succinct Atomic Swap constructions over the Lightning Network.

Succinct Atomic Swaps have an asymmetric setup, unlike the traditional HTLC-based atomic swaps.
This asymmetry makes it difficult to reason about how a forwarding node on the Lightning Network would be able to accept a Succinct Atomic Swap and then send out another Succinct Atomic Swap.

An observation to make is that the Bitcoin-side construction in the Succinct Atomic Swap description has the following branches:

* B gets the money, and A learns a secret from B.
* After a timeout, A gets the money back, and B learns a secret from A.

Unfortunately, the above construction, while instantiatable in a single channel (any absolute-timelock contract enforceable on a blockchain can be instantiated in a channel anchored in that blockchain), cannot be safely *forwarded* over the Lightning Network in a sequence of channels forming a route.

This is because we need to have a different timeout at each forwarding hop, in order to allow a forwarding node enough time to discover an event and react accordingly.
This means that each forwarding node has to have a shorter timeout on its outgoing contract than its incoming contract.

But in the half-Succinct-Atomic-Swap contract, the forwarding node needs to provide a secret in order to reclaim the funds at the timeout.
And it can only discover that secret at the later timeout of the incoming contract.
Thus, it is not safe for the forwarding node to forward any half-Succinct-Atomic-Swap contract.

Thus, we either:

* Prevent old, low-value cryptographic cars from being bought using Lightning, reducing their economic veolocity and preventing moon and lambos.
* OR, we give the Cryptographic Relay a notion of time which makes it compatible with PTLCs that can be routed over Lightning.
  In essence, the PTLC "goes over one more hop", this time transferring ownership of the Cryptographic Relay.

A Cryptographic Notion of Time
==============================

Time stops for no one; it will not stop for thee.

Or, in more science-appropriate terms: the passage of time is the direction in which universal entropy increases.

Now, we can observe that block header hashes are, in fact, low-entropy.
This is because the higher bits of block header hashes are consistently 0; there are thus fewer bits of entropy you can extract from a block header hash.

Now, we can observe that temperature is largely itself also an expression of entropy.
Higher-entropy areas are higher temperature, and lower-entropy areas are lower temperature.
Overall, the temperature differential across the universe decreases in the direction of future time.

However, it is possible to implement a sort of Maxwell's Demon.
Maxwell's Demon is an entity that guards a hole between two containers containing air.
If a high-speed, high-tempreature molecule of air on the left side approaches the hole, Maxwell's Demon magically swats it away, but if a similar high-speed, high-temperature molecule of air on the right side approaches the hole, Maxwell's Demon lets it pass.
It has the reverse policy for low-temperature molecules of air, letting it go from the left container to the right container.

Over time, the temperature of the right container drops, because all the high-temperature molecules have been moved to the left container.

Of course, we already have implementations of Maxwell's Demon.
We call such implementations "refrigerators".

Refrigerators, to do their magic, must consume energy and emit heat.
Indeed, the total heat emitted by the refrigerator is much larger than the heat it removes in the cold part of the refrigerator.
We can verify that the refrigerator is working, trivially, by checking that the supposedly-cold part of the refrigerator is indeed cold.
But we know that refrigerators, to do their work, must consume energy and emit heat.

And we also know that, due to the heat emitted by the refrigerators, the universal level of entropy increases, and we know thereby a direction of time is equivalent to a refrigerator successfully freezing something.

Similarly, in order to create low-entropy ("cold") block header hashes, miners of Bitcoin must consume energy and emit heat.
Bitcoin miners then act similarly to Maxwell's Demon; they reject candidate blocks whose block header hashes are not "cold enough" (i.e. have entropy greater than the difficulty target), and only allow "cold" block headers to be broadcast over the blockchain.

And since we know that:

* The future is where the universal entropy is larger than the past.
* Miners producing blocks must consume energy and emit waste heat (increasing universal entropy).

...then we know that a longer proof-of-work header chain represents more actual physical time passing.

Proof-of-work is therefore also an unforgeable proof-of-time-passing.

Thus, all we need for a cryptographically-secure *measure of time* is a header chain.

Crucially, this is better than SPV security, since we are only measuring the passage of time and do not particularly care about reorgs and the transactions in the block.
The longest chain wins, so the "largest blockheight" can only grow monotonically even if a reorg happens.
Even if the transactions in a reorg are ultimately disconfirmed (double-spent), or turn out to be invalid, the Cryptographic Relay does not depend on their validity, it only cares about time passing in order to implement a timeout.

This is significantly better than having to implement a stable clock on the Cryptographic Relay to implement a timeout.
Clocks may drift, and the Cryptographic Relay might not want to tr\*st external sources to give it a true notion of time.
Loss of power supply may also cause the Cryptographic Relay to lose its clock as well.
Thus, it must use this cryptographic notion of time.

Giving Cryptographic Relays a Notion of Time
============================================

In order to implement timelocks, we can add an `nLockTime` field to ownership-transfer messages for the Cryptographic Relay.

On manufacturing a Cryptographic Relay, the manufacturer stores in unchangeable memory (e.g. burned diode non-erasable PROMs) the block header hash of a sufficiently-deep block (for example, one that has been buried for 6 or so difficulty adjustment periods), its blockheight, and the difficulty target for the adjustment period.

If the Cryptographic Relay receives an ownership-transfer message with `nLockTime` greater than this recorded block height, it demands a header chain rooted at the prerecorded block up to the specified `nLockTime`.
It then validates that the header chain has sufficient difficulty for each adjustment period covered, and also emulates the difficulty adjustment at appropriate blockheights.
This is sufficient proof to it that time has passed since its manufacture, as a header chain is a cryptographic proof of time passing.

This allows me to sell a cryptographic car to you, over Lightning, by this ritual:

* First, we generate fresh keypairs and their combined MuSig pubkey.
* We perform a MuSig signing operation, signing an ownership-transfer message with a future `nLockTime`, transferring ownership from the MuSig pubkey back to my unilateral pubkey.
* I transfer control of the car to the MuSig pubkey.
* We partially perform a second MuSig signing operation, signing an ownership-transfer message with a 0 `nLockTime`, transferring ownership from the MuSig pubkey back to you, but pausing after the `R` exchange.
  * Specifically, after the `R` exchange, you generate the point corresponding to my share of the signature `s`, which you can get from my `R`, your `R`, my public key, and your public key, and the message we agreed on.
* I generate an invoice for the above signature share point (i.e. pay for signature).
* You pay the invoice, making sure that the maximum cltv-delta for the outgoing payment does not exceed the pre-agreed timeout (minus some time margin you deem safe).

Then:

* If you successfully pay the invoice (i.e. I release my share of the signature) you can now complete the signature for the transfer to your unilateral control.
* If you are unable to pay the invoice, then once the future blockheight is reached, I download the Bitcoin block header chain and feed it and the backout ownership-transfer message to the car and regain control of my vehicle.

This provides Lightning-with-PTLCs compatibility (which we expect to be deployed on the network anyway), while still requiring relatively low resources on the Cryptographic Relay hardware (at the cost that timelocked backouts require much bandwidth; but since such backouts are expected to be rare, this may be an acceptable tradeoff).

A Cryptographic Relay accepting this notion of time can continue to be used with Succinct Atomic Swaps, by using ownership-transfer messages with a 0 `nLockTime`, with the advantage that backouts need not download a block header chain to the Cryptographic Relay.

A Case Against Blockchain Proliferation
=======================================

We can argue that the Cryptographic Relay is a device tr\*sted to actually do what we claim it does here.
In particular, its users tr\*st that its manufacturer does not have a secret backdoor, a special public key recognized by every Cryptographic Relay by which the manufacturer can gain ownership of every piece of smart hardware in the world.

This may lead some to propose that a publicly-auditable blockchain can be used to manage the assignment of ownership of Cryptographic Relay devices.
That way, the source code that performs the ownership-assignment can be openly audited, and independent observers can check that the asset-assignment blockchain indeed works using the published source code by compiling it themselves and running it, and checking that it remains in synchrony with the asset-assignment blockchain.

However, I should point out that merely because some blockchain somewhere considers asset X to be owned by pubkey Y, does not mean that the actual real-world asset X will have a control system that responds to pubkey Y.

Or in other words, the manufacturer of the actual real-world asset X can still insert a secret backdoor that ignores the public asset-assignment blockchain anyway.

And since blockchains are massive bandwidth hogs, we should avoid using them unless we gain some actual benefit.

On the other hand, the proposed Cryptographic Relay here is reasonably simple, requires no consensus system.

The best that can be done would be to standardize Cryptographic Relays and encourage multiple manufacturers to follow the same standard.
Such a standard would include communication protocols between the Cryptographic Relay and the controlling devices, but would also include details like voltage levels, current limits, normally-closed vs normally-open vs make-before-break SPDT/DPDT vs break-before-make SPDT/DPDT, physical dimensions of the package(s), etc.

Tr\*st in manufacturers can be acquired, at very high expense, by using cut-and-choose: get a number of Cryptographic Relays, randomly select some of them, then open those and analyze if there are any backdoors, then utilize the rest if the randomly-opened ones do not have any discovered backdoors or other security issues.

Delegated Operators
===================

Another useful capability to add to Cryptographic Relays would be to allow adding operators, which are additional public keys that can turn it on or off, but cannot authorize a transfer of ownership or the addition of new operators.

Only the owner of the Cryptographic Relay can add or delete operators.

For example, suppose you, the buyer of my cryptographic car, represent a typical family share-owned between you and all of your husbands.
Then when purchasing the car from me, you can transfer ownership of the car to a MuSig n-of-n between you and your husbands, rather than unilateral control of yourself.

Of course, practically speaking, only one of you or your husbands can operate the car at once.
Thus, while the ownership of the vehicle is an n-of-n MuSig, you can assign individual keys of yourself and each of your husbands, as operators of the car.

The Cryptographic Relay would need to allocate a fixed amount of space for the number of allowed operators, thus imposing a practical limit on the number of husbands you can have simultaneously.
Unfortunately, the Cryptographic Relay cannot store an arbitrary number of public keys, thus there are limits on the number of husbands a human can have.

Whenever an ownership transfer is performed, all operators are deleted, thus preventing one of the previous operators attempting to start the car and drive it off even though it is semantically owned by someone else.

A car purchased by an extended family, such as a company, might be owned by a k-of-n of the stakeholders of the company, and then employees of the company might be assigned as operators.

Practical Deployment
====================

By focusing on developing the most basic Cryptographic Relay, this provides us with a practical deployment for smart devices that can recognize their owner and be used only by the owner (and its delegated operators).

In particular, any existing non-smart electrical device can be modified post-warranty into a smart device that knows its owner, by adding a Cryptographic Relay hardware device somewhere along the path to its power supply.
For example, a Cryptographic Relay could replace a power switch, or be spliced onto the power cord.

Now, of course such a jury-rigging could be easily bypassed, by simply splicing a wire across its terminals.
Similarly, many existing cars can be started without keys by hot-wiring.
Ultimately, the same can be said of almost any end-user appliance; possession remains 9/10ths of the law.

A Cryptographic Relay is a simple device:

* The design of the device is simple, requiring support for only a few operations.
* The interface of the device is simple: it is only a switch, and easy to integrate into more complex applications.
  The switch may be used as the route for the power supply, or it may be used simply for an electrical connection that is detected by some control system of the appliance to know whether it should act as "on" or "off".
  This simplicity and generality allows simple interfacing with a variety of electrical devices.

The intent is that:

* It is easy to implement and subsequently manufacture the device, so that risks of backdoors being installed by centralized manufacturers is mitigated by having multiple Cryptographic Relay manufacturers competing and incentivized to discover backdoors and other security failures of their competitors.
* It is easy to integrate the device into the design of a more complex device intended for use by an end-user.
  It is also easy to integrate the device, post-design, to a more complex existing device that did not include it.

Collateralizing Cryptographic Relay Devices
===========================================

Giving Cryptographic Relays a notion of time allows them to be used in more complicated contracts.

Suppose after purchasing the cryptographic car from me, you and your husbands find yourselves in tight financial straits.
You and your husbands might then want to take a loan from some entity.

Obviously, that entity will not simply loan out precious Bitcoins unless you promise to pay it back with *more* Bitcoins than what it gave out.
And that entity might want to accept your cryptographic car as collateral for the loan, so that if you are unable to pay, the entity can partially recoup losses by reselling your cryptographic car.

With `SIGHASH_ANYPREVOUT` and Taproot, it becomes possible to trustlessly arrange a collateralized loan on the cryptographic car (to the extent the loan shark tr\*sts that none of you or any of your husbands have replaced the Cryptographic Relay with a backdoored device, at least).

The loan shark arranges a loan in a multi-step process involving multiple PTLC-like constructions:

* First, all of you (you and your husbands, and the loan shark) generate two fresh keypairs.
  * Call the first the "loan-out" keypair.
  * Call the second the "loan-payback" keypair.
* You generate (but do not sign!) a command to transfer control of the car from you to a MuSig(you, your husbands ..., loan shark) using the "loan-out" pubkeys.
* Generate the initial backout command, which transfers from the MuSig loan-out pubkey above, back to you and your husbands, but with an `nLockTime` in the future.
  Get a complete signature for this command with the loan shark and your husbands and you.
  * This backout timeout period should be short, and is needed only if the loan shark suddenly aborts before it hands over the loan to you.
* Sign the transfer of the car from you to the MuSig loan-out and feed it to the car.
* Generate (but do not sign!) the collateralization command, which transfers from the MuSig loan-out pubkey, to a new MusSig(you, your husbands ..., loan shark) using the "loan-payback" pubkeys.
* Generate the collateral-claim command, which transfers from the MuSig loan-payback pubkey to the loan shark, but with an `nLockTime` a little after the due date of your loan.
  Generate a complete signature for this command to the loan shark, which the loan shark will now hold and use in case you do not pay back the loan.
* Generate the collateral-reclaim command, which transfers from the MuSig loan-payback pubkey back to you and your husbands.
  Generate a partial signature for this command from you and your husbands, but with a missing share from the loan shark, and keep this partial signature.
* Generate a Taproot address (called the loan-payback Taproot address) with two SCRIPT branches, with an internal public key equal to the loan-payback pubkey.
  * One SCRIPT branch allows signing by the internal public key with `SIGHASH_ANYPREVOUT`.
  * The other SCRIPT branch imposes a short `OP_CHECKSEQUENCEVERIFY` timeout, and claiming by the MuSig of you and your husbands.
* Generate loan-payback Bitcoin transaction, which spends using a `SIGHASH_ANYPREVOUT` signature on the first branch of the above Taproot address, an amount equal to your loan plus interest, and sending unilateral control to the loan shark.
  Demand an adaptor signature for this transaction, which would reveal to you the loan shark signature share of the collateral-reclaim command.
  Then provide the signature shares for you and your husband to the loan shark.
  * If the loan shark completes this signature and reclaims the loan plus interest, you learn the share to complete the collateral-reclaim command and thereby reclaim your car after paying back the loan.
* Now the loan shark creates (but does not sign!) the loan-out transaction, which pays out the MuSig loan-out pubkey the amount being loaned.
* Generate the loan-out-revert transaction, which spends the loan-out transaction and pays it back to the loan shark, but with an `nLockTime` in the future, nearer than the `nLockTime` of the initial backout command.
  Sign this transaction with you and your husbands and the loan shark.
* The loan shark generates a partial signature for the collateralization command, missing the shares from you and your husbands.
* Generate the loan-out-claim transaction, which spends the loan-out transaction and pays it to you and your husbands.
  The loan shark will demand an adaptor signature for this transaction, which lets it learn the sum of the missing signatures shares for the collateralization command.
  Then the loan shark provides its share of the signature for the loan-out-claim transaction.
* The loan shark signs the loan-out transaction and broadcasts it.
* You now complete the signature for the loan-out-claim transaction and broadcast it.
  The loan shark learns the missing signature shares for the collateralization command and performs it, locking your car into collateralization (where it cannot be transferred unless you, your husbands, and the loan shark agree).
  With the loan-out-claim transaction valid, you can now take the loan.

Then, if you are able to pay back the loan before the due date:

* Send the loan amount plus interest, exactly, to the loan-payback Taproot address.
* If the loan shark accepts the payback of the loan, it reanchors the loan-payback Bitcoin transaction and completes the signature, then claims the paid back loan.
* With the loan-payback signature completed, you learn the partial signature needed to complete the signature for the collateral-reclaim command, and you can now feed it to the car and regain ownership over it.
* If the loan shark does not accept payback of the loan, you can at least recover the loan and interest by the second branch of the loan-payback Taproot address.

If you are unable to pay back the loan:

* The collateral-claim command becomes valid a little after the loan due date, and the loan shark takes unilateral possession of your car to recoup its losses.

The above uses onchain Bitcoins.
Similar setups may be possible over Lightning (there is no need for a `SIGHASH_ANYPREVOUT` in this case, as the loan shark may issue a long-lived invoice that lets you learn its signature share for the collateral-reclaim command signature).

Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

[ZmnSCPxj]

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

Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

[Andy Schroder]

See multiple places below


Andy Schroder

On 7/20/20 10:18 AM, ZmnSCPxj via bitcoin-dev wrote:
> Introduction
> ============
>
> An electrical relay is an electrically-controlled switch, often diagrammed as:
>
>        +-------------o
>        |
>        |   \
>        |    \
>        +--o  o-------o
>
>      o----  |
>           ) |
>           ) |
>           ) |
>      o----  |
>
> The terminals at the left feed into a coil.
> When electricity passes through the coil, it magnetizes a core, and the magnetism attracts a switch into a closed position, which would let electricity to pass through the terminals at the right.
> This can be used to "turn on" or supply power to a different electrical device.
>
> If no electricity is passing through the coil via the terminals on the left, then no electricity can pass through the terminals on the right, as the switch is an open position at default.
>
> This is a fairly simple logic circuitry, upon which more complicated circuitry can be made.
>
> Similarly, a Cryptographic Relay is a hardware electrical component that allows control of some electrical circuit.
> It has two terminals which are the two terminals of a switch.
> It can also be contacted, for example via Bluetooth, by an electronic computing device.
> The Cryptographic Relay has a public key, which represents the current owner of the relay.
> If the electronic device is able to provide a proof-of-knowledge of the private key (i.e. a signature) corresponding to the public key that the Cryptographic Relay knows, then it allows the switch to be controlled by that device.
>
> Motivation
> ==========
>
> Suppose I have a car I wish to sell to you, for Bitcoins.
> This car, as it happens, has a Cryptographic Relay: it will only start its engine if it gets a signed message from me using a private key I have on my phone.
> It knows my public key, and will only turn off and on at my command.
>
> Now, you want to be able to know that by paying me Bitcoins, you get sole ownership of the car I am selling.
>
> This is in fact, nothing more than a swap operation.
> I have an asset, a car, and you have an asset, some Bitcoins.
> We want to atomically swap one asset for the other asset, and those assets do not exist in a single asset-assignment system.
>
> Paying Bitcoins For Cars Via Succinct Atomic Swaps
> ==================================================
>
> Fortunately, there is an atomic swap operation, Succinct Atomic Swaps, which can be used to create an atomic swap between my car and your Bitcoins.
>
> An important part of this Succinct Atomic Swap is that all timeouts are only in one asset-assignment system.
> The original Succinct Atomic Swap discussion gives an example of swapping Bitcoins for Litecoins.
> Each has its own distinct blockchain, which is a distinct distributed asset-assignment system.
>
> A crucial part of the Succinct Atomic Swap is that all timelocks are only on one asset-assignment system.
> The other asset-assignment system need not support anything other than assigning ownership of assets to (homomorphically additive) public keys.
>
> This is important as a major simplification of the Cryptographic Relay:
> The relay only needs to know its *current owner*, and does not need to know the current time!
>
> Thus, in order for you to buy my car:
>
> * You set up the Succinct Atomic Swap on the Bitcoin blockchain.
> * We generate fresh private keys, then combine them via MuSig, and I transfer the ownership of the car to that MuSig public key.
> * If I claim the funds, that atomically reveals my share of the private key to you, so you can claim the car using your private key plus my share and transfer the car to sole control of you.
> * If I fail to claim the funds, then when you reclaim your funds at timeout, that atomically reveals your share of the private key to me, so that I can claim the car using my private key plus your share and transfer the car back to sole control of me.
>
> This is in fact the same as the Succinct Atomic Swap example, except that instead of me swapping my Litecoins for your Bitcoins, I am swapping my Cryptographic Relay for your Bitcoins.
>
> Cryptographic Relay Operations
> ==============================
>
> Thus, a Cryptographic Relay needs to support only the following basic operations.
> These operations are triggered by its owner sending a message, plus a signature verifiable by the public key, to the Cryptographic Relay.
> (Cryptographer warning: if using Schnorr, the message hashed into the signature also has to include the public key that is signing it, since BIP32 nonhardened derivation allows a Schnorr signature created by one child private key to be trivially malleated into a signature for the same message by a sibling private key; this does not exist in ECDSA due to its nonlinearity.
> message sends need not include the public key, it can be added by the cryptographic relay since it has to know the public key of the owner anyway.
> Of note is that the bip-340 description of Schnorr includes the public key in the hash operation of signatures as well, and does not require this.)
>
> The only operations necessary are:
>
> 1.  Turn on.
> 2.  Turn off.
> 3.  Transfer ownership to new pubkey ___.
>
> Due to Succinct Atomic Swaps not requiring any kind of timelock on one asset-assignment system, the Cryptographic Relay need not have any concept of time, as mentioned above, and transfer of ownership can be done by a simple message signed by the current owner transferring ownership to a new public key.
>
> (Cryptographer warning: turn-on/turn-off messages should be challenge-response: the Cryptographic Relay requests signing with a unique nonce included in the message, otherwise previous messages can be captured by third parties and replayed; ownership-transfer messages should probably also include a nonce, or otherwise we could require non-reuse of keys.
> This can be implemented with a 64-bit incrementing nonce, which should work for the practical lifetime of any Cryptographic Relay.)
>
> (Cryptographer warning: similarly, ownership-transfer messages should probably be indexed as well with an incrementing nonce, otherwise key reuse would allow signature replay; similarly again, each Cryptographic Relay should have a UUID that is included in message hashes, as otherwise key reuse would allow signature replay for commands to one device to be repeated for another device.)
>
> Lightning
> =========
>
> Unfortunately, it seems not possible to transport Succinct Atomic Swap constructions over the Lightning Network.
>
> Succinct Atomic Swaps have an asymmetric setup, unlike the traditional HTLC-based atomic swaps.
> This asymmetry makes it difficult to reason about how a forwarding node on the Lightning Network would be able to accept a Succinct Atomic Swap and then send out another Succinct Atomic Swap.
>
> An observation to make is that the Bitcoin-side construction in the Succinct Atomic Swap description has the following branches:
>
> * B gets the money, and A learns a secret from B.
> * After a timeout, A gets the money back, and B learns a secret from A.
>
> Unfortunately, the above construction, while instantiatable in a single channel (any absolute-timelock contract enforceable on a blockchain can be instantiated in a channel anchored in that blockchain), cannot be safely *forwarded* over the Lightning Network in a sequence of channels forming a route.
>
> This is because we need to have a different timeout at each forwarding hop, in order to allow a forwarding node enough time to discover an event and react accordingly.
> This means that each forwarding node has to have a shorter timeout on its outgoing contract than its incoming contract.
>
> But in the half-Succinct-Atomic-Swap contract, the forwarding node needs to provide a secret in order to reclaim the funds at the timeout.
> And it can only discover that secret at the later timeout of the incoming contract.
> Thus, it is not safe for the forwarding node to forward any half-Succinct-Atomic-Swap contract.
>
> Thus, we either:
>
> * Prevent old, low-value cryptographic cars from being bought using Lightning, reducing their economic veolocity and preventing moon and lambos.
> * OR, we give the Cryptographic Relay a notion of time which makes it compatible with PTLCs that can be routed over Lightning.
>    In essence, the PTLC "goes over one more hop", this time transferring ownership of the Cryptographic Relay.
>
> A Cryptographic Notion of Time
> ==============================
>
> Time stops for no one; it will not stop for thee.
>
> Or, in more science-appropriate terms: the passage of time is the direction in which universal entropy increases.
>
> Now, we can observe that block header hashes are, in fact, low-entropy.
> This is because the higher bits of block header hashes are consistently 0; there are thus fewer bits of entropy you can extract from a block header hash.
>
> Now, we can observe that temperature is largely itself also an expression of entropy.
> Higher-entropy areas are higher temperature, and lower-entropy areas are lower temperature

, at constant pressure

> .

Or, at constant temperature, higher entropy areas have lower pressure 
and lower entropy areas have higher pressure. See the background contour 
of the figure on the bottom left here for an example with carbon dioxide:

http://andyschroder.com/CO2Cycle/Explorer?DatasetNumber=1&0_ValueIndex=Optimal&HorizontalAxis=0&1_ValueIndex=Optimal&VerticalAxis=1&2_ValueIndex=Optimal&3_ValueIndex=Optimal&4_ValueIndex=Optimal&5_ValueIndex=0&6_ValueIndex=0&7_ValueIndex=0&8_ValueIndex=0&9_ValueIndex=0&10_ValueIndex=0&11_ValueIndex=0&12_ValueIndex=0&ContourValue=efficiency&LinePlotVerticalAxisValue=efficiency&CyclePlotVerticalAxis=Temperature&CyclePlotHorizontalAxis=Pressure&CyclePlotContourLevel=Entropy






> Overall, the temperature differential across the universe decreases in the direction of future time.
> However, it is possible to implement a sort of Maxwell's Demon.
> Maxwell's Demon is an entity that guards a hole between two containers containing air.
> If a high-speed, high-tempreature molecule of air on the left side approaches the hole, Maxwell's Demon magically swats it away, but if a similar high-speed, high-temperature molecule of air on the right side approaches the hole, Maxwell's Demon lets it pass.
> It has the reverse policy for low-temperature molecules of air, letting it go from the left container to the right container.
>
> Over time, the temperature of the right container drops, because all the high-temperature molecules have been moved to the left container.
>
> Of course, we already have implementations of Maxwell's Demon.
> We call such implementations "refrigerators".
Don't know why I never thought of it this way!


>
> Refrigerators, to do their magic, must consume energy and emit heat.
> Indeed, the total heat emitted by the refrigerator is much larger than the heat it removes in the cold part of the refrigerator.

Not necessarily "much larger". For example, a good geothermal heat pump 
has a COP greater than 8. That means 8 units of heat are removed for 1 
unit of work input. That means that the total heat emitted by the 
refrigerator is only (1-(8+1)/8) = 12.5% higher than the heat it removes 
from inside the refrigerator.





> We can verify that the refrigerator is working, trivially, by checking that the supposedly-cold part of the refrigerator is indeed cold
and it's temperature does not begin to rise over time.




> But we know that refrigerators, to do their work, must consume

mechanical

> energy and emit heat.
>
> And we also know that, due to the heat emitted by the refrigerators, the universal level of entropy increases, and we know thereby a direction of time is equivalent to a refrigerator successfully freezing something.

However, the entropy inside a chamber can still decrease if the pressure 
goes up and heat is allowed to conduct away as the temperature tries to 
go up. This however, also results in more work being input into the 
refrigerator, which means it still consumes energy. Also, if you are 
okay with the temperature inside a chamber going up (instead of down), 
you can consume energy and compress it adiabatically and the pressure 
will rise and so will the entropy rise.





> .
>
> Similarly, in order to create low-entropy ("cold") block header hashes, miners of Bitcoin must consume energy and emit heat.
> Bitcoin miners then act similarly to Maxwell's Demon; they reject candidate blocks whose block header hashes are not "cold enough" (i.e. have entropy

production


>   greater than the difficulty target), and only allow "cold" block headers to be broadcast over the blockchain.

Blocks freeze the transactions in place!

Or, blocks compress transactions in place.

>
> And since we know that:
>
> * The future is where the universal entropy is larger than the past.
> * Miners producing blocks must consume energy and emit waste heat (increasing universal entropy).
>
> ...then we know that a longer proof-of-work header chain represents more actual physical time passing.
>
> Proof-of-work is therefore also an unforgeable proof-of-time-passing.
>
> Thus, all we need for a cryptographically-secure *measure of time* is a header chain.
>
> Crucially, this is better than SPV security, since we are only measuring the passage of time and do not particularly care about reorgs and the transactions in the block.
> The longest chain wins, so the "largest blockheight" can only grow monotonically even if a reorg happens.
> Even if the transactions in a reorg are ultimately disconfirmed (double-spent), or turn out to be invalid, the Cryptographic Relay does not depend on their validity, it only cares about time passing in order to implement a timeout.
>
> This is significantly better than having to implement a stable clock on the Cryptographic Relay to implement a timeout.
> Clocks may drift, and the Cryptographic Relay might not want to tr\*st external sources to give it a true notion of time.
> Loss of power supply may also cause the Cryptographic Relay to lose its clock as well.
> Thus, it must use this cryptographic notion of time.

Very interesting thought!

>
> Giving Cryptographic Relays a Notion of Time
> ============================================
>
> In order to implement timelocks, we can add an `nLockTime` field to ownership-transfer messages for the Cryptographic Relay.
>
> On manufacturing a Cryptographic Relay, the manufacturer stores in unchangeable memory (e.g. burned diode non-erasable PROMs) the block header hash of a sufficiently-deep block (for example, one that has been buried for 6 or so difficulty adjustment periods), its blockheight, and the difficulty target for the adjustment period.
>
> If the Cryptographic Relay receives an ownership-transfer message with `nLockTime` greater than this recorded block height, it demands a header chain rooted at the prerecorded block up to the specified `nLockTime`.
> It then validates that the header chain has sufficient difficulty for each adjustment period covered, and also emulates the difficulty adjustment at appropriate blockheights.
> This is sufficient proof to it that time has passed since its manufacture, as a header chain is a cryptographic proof of time passing.
>
> This allows me to sell a cryptographic car to you, over Lightning, by this ritual:
>
> * First, we generate fresh keypairs and their combined MuSig pubkey.
> * We perform a MuSig signing operation, signing an ownership-transfer message with a future `nLockTime`, transferring ownership from the MuSig pubkey back to my unilateral pubkey.
> * I transfer control of the car to the MuSig pubkey.
> * We partially perform a second MuSig signing operation, signing an ownership-transfer message with a 0 `nLockTime`, transferring ownership from the MuSig pubkey back to you, but pausing after the `R` exchange.
>    * Specifically, after the `R` exchange, you generate the point corresponding to my share of the signature `s`, which you can get from my `R`, your `R`, my public key, and your public key, and the message we agreed on.
> * I generate an invoice for the above signature share point (i.e. pay for signature).
> * You pay the invoice, making sure that the maximum cltv-delta for the outgoing payment does not exceed the pre-agreed timeout (minus some time margin you deem safe).
>
> Then:
>
> * If you successfully pay the invoice (i.e. I release my share of the signature) you can now complete the signature for the transfer to your unilateral control.
> * If you are unable to pay the invoice, then once the future blockheight is reached, I download the Bitcoin block header chain and feed it and the backout ownership-transfer message to the car and regain control of my vehicle.
>
> This provides Lightning-with-PTLCs compatibility (which we expect to be deployed on the network anyway), while still requiring relatively low resources on the Cryptographic Relay hardware (at the cost that timelocked backouts require much bandwidth; but since such backouts are expected to be rare, this may be an acceptable tradeoff).
>
> A Cryptographic Relay accepting this notion of time can continue to be used with Succinct Atomic Swaps, by using ownership-transfer messages with a 0 `nLockTime`, with the advantage that backouts need not download a block header chain to the Cryptographic Relay.
>
> A Case Against Blockchain Proliferation
> =======================================
>
> We can argue that the Cryptographic Relay is a device tr\*sted to actually do what we claim it does here.
> In particular, its users tr\*st that its manufacturer does not have a secret backdoor, a special public key recognized by every Cryptographic Relay by which the manufacturer can gain ownership of every piece of smart hardware in the world.
>
> This may lead some to propose that a publicly-auditable blockchain can be used to manage the assignment of ownership of Cryptographic Relay devices.
> That way, the source code that performs the ownership-assignment can be openly audited, and independent observers can check that the asset-assignment blockchain indeed works using the published source code by compiling it themselves and running it, and checking that it remains in synchrony with the asset-assignment blockchain.
>
> However, I should point out that merely because some blockchain somewhere considers asset X to be owned by pubkey Y, does not mean that the actual real-world asset X will have a control system that responds to pubkey Y.
>
> Or in other words, the manufacturer of the actual real-world asset X can still insert a secret backdoor that ignores the public asset-assignment blockchain anyway.
And you are saying below that risk can be mitigated if manufactures 
working very hard to build up enough market share that there is enough 
auditing of their devices that appear to be honestly manufactured?



>
> And since blockchains are massive bandwidth hogs, we should avoid using them unless we gain some actual benefit.
>
> On the other hand, the proposed Cryptographic Relay here is reasonably simple, requires no consensus system.
>
> The best that can be done would be to standardize Cryptographic Relays and encourage multiple manufacturers to follow the same standard.
> Such a standard would include communication protocols between the Cryptographic Relay and the controlling devices, but would also include details like voltage levels, current limits, normally-closed vs normally-open vs make-before-break SPDT/DPDT vs break-before-make SPDT/DPDT, physical dimensions of the package(s), etc.

I would just keep it simple and stick with simple standards for 
transistors and then let the user choose many of the parameters their 
own by supplying their own electro mechanical relay. Most I/O devices 
have a transistor in them, then you need a booster transistor to add on 
it to it to get enough current in order to actually drive a relay coil. 
This is more complicated for the end user, but gives them more flexibility.


>
> Tr\*st in manufacturers can be acquired, at very high expense, by using cut-and-choose: get a number of Cryptographic Relays, randomly select some of them, then open those and analyze if there are any backdoors, then utilize the rest if the randomly-opened ones do not have any discovered backdoors or other security issues.
>
> Delegated Operators
> ===================
>
> Another useful capability to add to Cryptographic Relays would be to allow adding operators, which are additional public keys that can turn it on or off, but cannot authorize a transfer of ownership or the addition of new operators.
>
> Only the owner of the Cryptographic Relay can add or delete operators.
>
> For example, suppose you, the buyer of my cryptographic car, represent a typical family share-owned between you and all of your husbands.
> Then when purchasing the car from me, you can transfer ownership of the car to a MuSig n-of-n between you and your husbands, rather than unilateral control of yourself.
>
> Of course, practically speaking, only one of you or your husbands can operate the car at once.
> Thus, while the ownership of the vehicle is an n-of-n MuSig, you can assign individual keys of yourself and each of your husbands, as operators of the car.
>
> The Cryptographic Relay would need to allocate a fixed amount of space for the number of allowed operators, thus imposing a practical limit on the number of husbands you can have simultaneously.
> Unfortunately, the Cryptographic Relay cannot store an arbitrary number of public keys, thus there are limits on the number of husbands a human can have.
>
> Whenever an ownership transfer is performed, all operators are deleted, thus preventing one of the previous operators attempting to start the car and drive it off even though it is semantically owned by someone else.
>
> A car purchased by an extended family, such as a company, might be owned by a k-of-n of the stakeholders of the company, and then employees of the company might be assigned as operators.
>
> Practical Deployment
> ====================
>
> By focusing on developing the most basic Cryptographic Relay, this provides us with a practical deployment for smart devices that can recognize their owner and be used only by the owner (and its delegated operators).
>
> In particular, any existing non-smart electrical device can be modified post-warranty into a smart device that knows its owner, by adding a Cryptographic Relay hardware device somewhere along the path to its power supply.
> For example, a Cryptographic Relay could replace a power switch, or be spliced onto the power cord.
>
> Now, of course such a jury-rigging could be easily bypassed, by simply splicing a wire across its terminals.
> Similarly, many existing cars can be started without keys by hot-wiring.
> Ultimately, the same can be said of almost any end-user appliance; possession remains 9/10ths of the law.


This is true, but if the devices is complicated and interconnected 
enough, the cost to hot-wire may outweigh the gains of stealing the 
device. For example, in an electric car, the battery pack, inverter, 
motor, charge controller, media computer, autopilot computer, bluetooth 
radio, cellular radio, FM radio, A/C compressor controller, drivetrain 
coolant system controller, charge port controller, anti-lock brake 
controller, power window motors, door locks, ignition, etc. all were 
locked together, it could become prohibitively expensive to hot wire 
given all those components would need to be removed from the vehicle and 
a specific chip removed (which likely will be embedded). And, it's 
trivial to "bake in" the "cryptographic relays" into every component 
during the initial manufacturing process. So, the transfer of ownership 
could need to by performed on all components simultaneously in order to 
successfully sell/trade the vehicle in order for this transfer to be 
really effective.





>
> A Cryptographic Relay is a simple device:
>
> * The design of the device is simple, requiring support for only a few operations.
> * The interface of the device is simple: it is only a switch, and easy to integrate into more complex applications.
>    The switch may be used as the route for the power supply, or it may be used simply for an electrical connection that is detected by some control system of the appliance to know whether it should act as "on" or "off".
>    This simplicity and generality allows simple interfacing with a variety of electrical devices.
>
> The intent is that:
>
> * It is easy to implement and subsequently manufacture the device, so that risks of backdoors being installed by centralized manufacturers is mitigated by having multiple Cryptographic Relay manufacturers competing and incentivized to discover backdoors and other security failures of their competitors.
> * It is easy to integrate the device into the design of a more complex device intended for use by an end-user.
>    It is also easy to integrate the device, post-design, to a more complex existing device that did not include it.
>
> Collateralizing Cryptographic Relay Devices
> ===========================================
>
> Giving Cryptographic Relays a notion of time allows them to be used in more complicated contracts.
>
> Suppose after purchasing the cryptographic car from me, you and your husbands find yourselves in tight financial straits.
> You and your husbands might then want to take a loan from some entity.
>
> Obviously, that entity will not simply loan out precious Bitcoins unless you promise to pay it back with *more* Bitcoins than what it gave out.
> And that entity might want to accept your cryptographic car as collateral for the loan, so that if you are unable to pay, the entity can partially recoup losses by reselling your cryptographic car.
>
> With `SIGHASH_ANYPREVOUT` and Taproot, it becomes possible to trustlessly arrange a collateralized loan on the cryptographic car (to the extent the loan shark tr\*sts that none of you or any of your husbands have replaced the Cryptographic Relay with a backdoored device, at least).
>
> The loan shark arranges a loan in a multi-step process involving multiple PTLC-like constructions:
>
> * First, all of you (you and your husbands, and the loan shark) generate two fresh keypairs.
>    * Call the first the "loan-out" keypair.
>    * Call the second the "loan-payback" keypair.
> * You generate (but do not sign!) a command to transfer control of the car from you to a MuSig(you, your husbands ..., loan shark) using the "loan-out" pubkeys.
> * Generate the initial backout command, which transfers from the MuSig loan-out pubkey above, back to you and your husbands, but with an `nLockTime` in the future.
>    Get a complete signature for this command with the loan shark and your husbands and you.
>    * This backout timeout period should be short, and is needed only if the loan shark suddenly aborts before it hands over the loan to you.
> * Sign the transfer of the car from you to the MuSig loan-out and feed it to the car.
> * Generate (but do not sign!) the collateralization command, which transfers from the MuSig loan-out pubkey, to a new MusSig(you, your husbands ..., loan shark) using the "loan-payback" pubkeys.
> * Generate the collateral-claim command, which transfers from the MuSig loan-payback pubkey to the loan shark, but with an `nLockTime` a little after the due date of your loan.
>    Generate a complete signature for this command to the loan shark, which the loan shark will now hold and use in case you do not pay back the loan.
> * Generate the collateral-reclaim command, which transfers from the MuSig loan-payback pubkey back to you and your husbands.
>    Generate a partial signature for this command from you and your husbands, but with a missing share from the loan shark, and keep this partial signature.
> * Generate a Taproot address (called the loan-payback Taproot address) with two SCRIPT branches, with an internal public key equal to the loan-payback pubkey.
>    * One SCRIPT branch allows signing by the internal public key with `SIGHASH_ANYPREVOUT`.
>    * The other SCRIPT branch imposes a short `OP_CHECKSEQUENCEVERIFY` timeout, and claiming by the MuSig of you and your husbands.
> * Generate loan-payback Bitcoin transaction, which spends using a `SIGHASH_ANYPREVOUT` signature on the first branch of the above Taproot address, an amount equal to your loan plus interest, and sending unilateral control to the loan shark.
>    Demand an adaptor signature for this transaction, which would reveal to you the loan shark signature share of the collateral-reclaim command.
>    Then provide the signature shares for you and your husband to the loan shark.
>    * If the loan shark completes this signature and reclaims the loan plus interest, you learn the share to complete the collateral-reclaim command and thereby reclaim your car after paying back the loan.
> * Now the loan shark creates (but does not sign!) the loan-out transaction, which pays out the MuSig loan-out pubkey the amount being loaned.
> * Generate the loan-out-revert transaction, which spends the loan-out transaction and pays it back to the loan shark, but with an `nLockTime` in the future, nearer than the `nLockTime` of the initial backout command.
>    Sign this transaction with you and your husbands and the loan shark.
> * The loan shark generates a partial signature for the collateralization command, missing the shares from you and your husbands.
> * Generate the loan-out-claim transaction, which spends the loan-out transaction and pays it to you and your husbands.
>    The loan shark will demand an adaptor signature for this transaction, which lets it learn the sum of the missing signatures shares for the collateralization command.
>    Then the loan shark provides its share of the signature for the loan-out-claim transaction.
> * The loan shark signs the loan-out transaction and broadcasts it.
> * You now complete the signature for the loan-out-claim transaction and broadcast it.
>    The loan shark learns the missing signature shares for the collateralization command and performs it, locking your car into collateralization (where it cannot be transferred unless you, your husbands, and the loan shark agree).
>    With the loan-out-claim transaction valid, you can now take the loan.
>
> Then, if you are able to pay back the loan before the due date:
>
> * Send the loan amount plus interest, exactly, to the loan-payback Taproot address.
> * If the loan shark accepts the payback of the loan, it reanchors the loan-payback Bitcoin transaction and completes the signature, then claims the paid back loan.
> * With the loan-payback signature completed, you learn the partial signature needed to complete the signature for the collateral-reclaim command, and you can now feed it to the car and regain ownership over it.
> * If the loan shark does not accept payback of the loan, you can at least recover the loan and interest by the second branch of the loan-payback Taproot address.
>
> If you are unable to pay back the loan:
>
> * The collateral-claim command becomes valid a little after the loan due date, and the loan shark takes unilateral possession of your car to recoup its losses.
>
> The above uses onchain Bitcoins.
> Similar setups may be possible over Lightning (there is no need for a `SIGHASH_ANYPREVOUT` in this case, as the loan shark may issue a long-lived invoice that lets you learn its signature share for the collateral-reclaim command signature).
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

[ZmnSCPxj]

Good morning Andy,

> > A Cryptographic Notion of Time
> >
> > ===============================
> >
> > Time stops for no one; it will not stop for thee.
> > Or, in more science-appropriate terms: the passage of time is the direction in which universal entropy increases.
> > Now, we can observe that block header hashes are, in fact, low-entropy.
> > This is because the higher bits of block header hashes are consistently 0; there are thus fewer bits of entropy you can extract from a block header hash.
> > Now, we can observe that temperature is largely itself also an expression of entropy.
> > Higher-entropy areas are higher temperature, and lower-entropy areas are lower temperature
>
> , at constant pressure

True.

> > .
>
> Or, at constant temperature, higher entropy areas have lower pressure
> and lower entropy areas have higher pressure. See the background contour
> of the figure on the bottom left here for an example with carbon dioxide:
>
> http://andyschroder.com/CO2Cycle/Explorer?DatasetNumber=1&0_ValueIndex=Optimal&HorizontalAxis=0&1_ValueIndex=Optimal&VerticalAxis=1&2_ValueIndex=Optimal&3_ValueIndex=Optimal&4_ValueIndex=Optimal&5_ValueIndex=0&6_ValueIndex=0&7_ValueIndex=0&8_ValueIndex=0&9_ValueIndex=0&10_ValueIndex=0&11_ValueIndex=0&12_ValueIndex=0&ContourValue=efficiency&LinePlotVerticalAxisValue=efficiency&CyclePlotVerticalAxis=Temperature&CyclePlotHorizontalAxis=Pressure&CyclePlotContourLevel=Entropy

Yes, PVT relation.

> > Overall, the temperature differential across the universe decreases in the direction of future time.
> > However, it is possible to implement a sort of Maxwell's Demon.
> > Maxwell's Demon is an entity that guards a hole between two containers containing air.
> > If a high-speed, high-tempreature molecule of air on the left side approaches the hole, Maxwell's Demon magically swats it away, but if a similar high-speed, high-temperature molecule of air on the right side approaches the hole, Maxwell's Demon lets it pass.
> > It has the reverse policy for low-temperature molecules of air, letting it go from the left container to the right container.
> > Over time, the temperature of the right container drops, because all the high-temperature molecules have been moved to the left container.
> > Of course, we already have implementations of Maxwell's Demon.
> > We call such implementations "refrigerators".
>
> Don't know why I never thought of it this way!
>

Yes.

> > Refrigerators, to do their magic, must consume energy and emit heat.
> > Indeed, the total heat emitted by the refrigerator is much larger than the heat it removes in the cold part of the refrigerator.
>
> Not necessarily "much larger". For example, a good geothermal heat pump
> has a COP greater than 8. That means 8 units of heat are removed for 1
> unit of work input. That means that the total heat emitted by the
> refrigerator is only (1-(8+1)/8) = 12.5% higher than the heat it removes
> from inside the refrigerator.
>

Granted.
I am now investigating geothermal heat pumps in the context of taking over the world, thank you for your information.

> > We can verify that the refrigerator is working, trivially, by checking that the supposedly-cold part of the refrigerator is indeed cold
>
> and it's temperature does not begin to rise over time.
>
> > But we know that refrigerators, to do their work, must consume
>
> mechanical
>
> > energy and emit heat.
> > And we also know that, due to the heat emitted by the refrigerators, the universal level of entropy increases, and we know thereby a direction of time is equivalent to a refrigerator successfully freezing something.
>
> However, the entropy inside a chamber can still decrease if the pressure
> goes up and heat is allowed to conduct away as the temperature tries to
> go up. This however, also results in more work being input into the
> refrigerator, which means it still consumes energy. Also, if you are
> okay with the temperature inside a chamber going up (instead of down),
> you can consume energy and compress it adiabatically and the pressure
> will rise and so will the entropy rise.
>
> > .
> > Similarly, in order to create low-entropy ("cold") block header hashes, miners of Bitcoin must consume energy and emit heat.
> > Bitcoin miners then act similarly to Maxwell's Demon; they reject candidate blocks whose block header hashes are not "cold enough" (i.e. have entropy
>
> production
>
> > greater than the difficulty target), and only allow "cold" block headers to be broadcast over the blockchain.
>
> Blocks freeze the transactions in place!

Certainly an interesting thought!

>
> Or, blocks compress transactions in place.
>
> > And since we know that:
> >
> > -   The future is where the universal entropy is larger than the past.
> > -   Miners producing blocks must consume energy and emit waste heat (increasing universal entropy).
> >
> > ...then we know that a longer proof-of-work header chain represents more actual physical time passing.
> > Proof-of-work is therefore also an unforgeable proof-of-time-passing.
> > Thus, all we need for a cryptographically-secure measure of time is a header chain.
> > Crucially, this is better than SPV security, since we are only measuring the passage of time and do not particularly care about reorgs and the transactions in the block.
> > The longest chain wins, so the "largest blockheight" can only grow monotonically even if a reorg happens.
> > Even if the transactions in a reorg are ultimately disconfirmed (double-spent), or turn out to be invalid, the Cryptographic Relay does not depend on their validity, it only cares about time passing in order to implement a timeout.
> > This is significantly better than having to implement a stable clock on the Cryptographic Relay to implement a timeout.
> > Clocks may drift, and the Cryptographic Relay might not want to tr\*st external sources to give it a true notion of time.
> > Loss of power supply may also cause the Cryptographic Relay to lose its clock as well.
> > Thus, it must use this cryptographic notion of time.
>
> Very interesting thought!

Thank you very much.


> > A Case Against Blockchain Proliferation
> >
> > ========================================
> >
> > We can argue that the Cryptographic Relay is a device tr\*sted to actually do what we claim it does here.
> > In particular, its users tr\*st that its manufacturer does not have a secret backdoor, a special public key recognized by every Cryptographic Relay by which the manufacturer can gain ownership of every piece of smart hardware in the world.
> > This may lead some to propose that a publicly-auditable blockchain can be used to manage the assignment of ownership of Cryptographic Relay devices.
> > That way, the source code that performs the ownership-assignment can be openly audited, and independent observers can check that the asset-assignment blockchain indeed works using the published source code by compiling it themselves and running it, and checking that it remains in synchrony with the asset-assignment blockchain.
> > However, I should point out that merely because some blockchain somewhere considers asset X to be owned by pubkey Y, does not mean that the actual real-world asset X will have a control system that responds to pubkey Y.
> > Or in other words, the manufacturer of the actual real-world asset X can still insert a secret backdoor that ignores the public asset-assignment blockchain anyway.
>
> And you are saying below that risk can be mitigated if manufactures
> working very hard to build up enough market share that there is enough
> auditing of their devices that appear to be honestly manufactured?
>

Potentially.
A lot of alternative blockchains that are designed for handling asset-assignment of real-world things, are far more centralized due to their non-generic nature: very few entities are interested in those spaces.

A Cryptographic Relay demonstrates that we can do better, by making a generic component, and disposing of the blockchain, and shows that even in the "blockchain for things!" case, you *still have to trust manufacturers anyway*.

After all, CPUs are commoditized enough that we hardly ever wonder if e.g. Intel or AMD or ARM have secreted backdoors into their CPUs.
Hopefully, Cryptographic Relays are commoditized enough as well that the probability of a manufacturer adding secret backdoors is low.

> > And since blockchains are massive bandwidth hogs, we should avoid using them unless we gain some actual benefit.
> > On the other hand, the proposed Cryptographic Relay here is reasonably simple, requires no consensus system.
> > The best that can be done would be to standardize Cryptographic Relays and encourage multiple manufacturers to follow the same standard.
> > Such a standard would include communication protocols between the Cryptographic Relay and the controlling devices, but would also include details like voltage levels, current limits, normally-closed vs normally-open vs make-before-break SPDT/DPDT vs break-before-make SPDT/DPDT, physical dimensions of the package(s), etc.
>
> I would just keep it simple and stick with simple standards for
> transistors and then let the user choose many of the parameters their
> own by supplying their own electro mechanical relay. Most I/O devices
> have a transistor in them, then you need a booster transistor to add on
> it to it to get enough current in order to actually drive a relay coil.
> This is more complicated for the end user, but gives them more flexibility.

I considered the "relay" interface to be better since a relay can be used as a (very slow) transistor, but if you want to transport say a 220V AC mains supply, you cannot use a transistor.
The slowness of relays (due to their mechanical nature) is acceptable since power-on and power-off events are expected to be rare compared to the operation of the device.

For example, a pre-existing non-cryptographic Smart TV can be upgraded into a cryptographic Smart TV by splicing a DPST Cryptographic Relay in its mains supply cord.
(This voids warranty, but if warranty is already ended, might as well.)

That said, it is possible to start with a relay driver interface instead of a relay interface (though I prefer the latch-type relays due to their better mechanical longevity and lower continuous power use, which requires two relay driver interfaces and timing).

> > Practical Deployment
> >
> > =====================
> >
> > By focusing on developing the most basic Cryptographic Relay, this provides us with a practical deployment for smart devices that can recognize their owner and be used only by the owner (and its delegated operators).
> > In particular, any existing non-smart electrical device can be modified post-warranty into a smart device that knows its owner, by adding a Cryptographic Relay hardware device somewhere along the path to its power supply.
> > For example, a Cryptographic Relay could replace a power switch, or be spliced onto the power cord.
> > Now, of course such a jury-rigging could be easily bypassed, by simply splicing a wire across its terminals.
> > Similarly, many existing cars can be started without keys by hot-wiring.
> > Ultimately, the same can be said of almost any end-user appliance; possession remains 9/10ths of the law.
>
> This is true, but if the devices is complicated and interconnected
> enough, the cost to hot-wire may outweigh the gains of stealing the
> device. For example, in an electric car, the battery pack, inverter,
> motor, charge controller, media computer, autopilot computer, bluetooth
> radio, cellular radio, FM radio, A/C compressor controller, drivetrain
> coolant system controller, charge port controller, anti-lock brake
> controller, power window motors, door locks, ignition, etc. all were
> locked together, it could become prohibitively expensive to hot wire
> given all those components would need to be removed from the vehicle and
> a specific chip removed (which likely will be embedded). And, it's
> trivial to "bake in" the "cryptographic relays" into every component
> during the initial manufacturing process. So, the transfer of ownership
> could need to by performed on all components simultaneously in order to
> successfully sell/trade the vehicle in order for this transfer to be
> really effective.

Indeed, that would be possible.

Though note that if I am trying to abscond with an electric car, all I need to *hot*wire would be the battery pack, inverter, motor, and ignition.
After absconding the electric car and placing it in a location I control, I can crack (i.e. splice wires across) the Cryptographic Relays of the other components at my leisure.

Thus, this post is simply a prelude to me becoming the next protagonist of Fast and Furious.


Regards,
ZmnSCPxj