Date: Mon, 20 Jul 2020 14:18:10 +0000
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <1z54XsScl3QReBGNtkf6I45p_IwHQMZ6EBVTM5qdZ9P6xv7a3SMxP2l3KahOoUvKRW9o6-saM36A0vxJtMS9pIRVTPGNlU3DMlUVwHZyZks=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For
	Smart Transferable Hardware
Precedence: list

Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 mag=
netism attracts a switch into a closed position, which would let electricit=
y to pass through the terminals at the right.
This can be used to "turn on" or supply power to a different electrical dev=
ice.

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 s=
witch is an open position at default.

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

Similarly, a Cryptographic Relay is a hardware electrical component that al=
lows 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 compu=
ting device.
The Cryptographic Relay has a public key, which represents the current owne=
r of the relay.
If the electronic device is able to provide a proof-of-knowledge of the pri=
vate key (i.e. a signature) corresponding to the public key that the Crypto=
graphic Relay knows, then it allows the switch to be controlled by that dev=
ice.

Motivation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 o=
wnership 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Fortunately, there is an atomic swap operation, Succinct Atomic Swaps, whic=
h 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 onl=
y in one asset-assignment system.
The original Succinct Atomic Swap discussion gives an example of swapping B=
itcoins 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 o=
n one asset-assignment system.
The other asset-assignment system need not support anything other than assi=
gning 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 transf=
er 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 ca=
n claim the car using my private key plus your share and transfer the car b=
ack to sole control of me.

This is in fact the same as the Succinct Atomic Swap example, except that i=
nstead of me swapping my Litecoins for your Bitcoins, I am swapping my Cryp=
tographic Relay for your Bitcoins.

Cryptographic Relay Operations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

Thus, a Cryptographic Relay needs to support only the following basic opera=
tions.
These operations are triggered by its owner sending a message, plus a signa=
ture verifiable by the public key, to the Cryptographic Relay.
(Cryptographer warning: if using Schnorr, the message hashed into the signa=
ture also has to include the public key that is signing it, since BIP32 non=
hardened derivation allows a Schnorr signature created by one child private=
 key to be trivially malleated into a signature for the same message by a s=
ibling 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 crypt=
ographic 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 asse=
t-assignment system, the Cryptographic Relay need not have any concept of t=
ime, 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-respo=
nse: the Cryptographic Relay requests signing with a unique nonce included =
in the message, otherwise previous messages can be captured by third partie=
s 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 proba=
bly be indexed as well with an incrementing nonce, otherwise key reuse woul=
d allow signature replay; similarly again, each Cryptographic Relay should =
have a UUID that is included in message hashes, as otherwise key reuse woul=
d allow signature replay for commands to one device to be repeated for anot=
her device.)

Lightning
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Unfortunately, it seems not possible to transport Succinct Atomic Swap cons=
tructions 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 th=
en send out another Succinct Atomic Swap.

An observation to make is that the Bitcoin-side construction in the Succinc=
t 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 cha=
nnel (any absolute-timelock contract enforceable on a blockchain can be ins=
tantiated in a channel anchored in that blockchain), cannot be safely *forw=
arded* 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 r=
eact accordingly.
This means that each forwarding node has to have a shorter timeout on its o=
utgoing 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 c=
ontract.
Thus, it is not safe for the forwarding node to forward any half-Succinct-A=
tomic-Swap contract.

Thus, we either:

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

A Cryptographic Notion of Time
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D

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 ha=
sh.

Now, we can observe that temperature is largely itself also an expression o=
f entropy.
Higher-entropy areas are higher temperature, and lower-entropy areas are lo=
wer 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 cont=
aining air.
If a high-speed, high-tempreature molecule of air on the left side approach=
es 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 h=
ole, 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 hi=
gh-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 e=
mit heat.

And we also know that, due to the heat emitted by the refrigerators, the un=
iversal 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, min=
ers 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 (increasi=
ng universal entropy).

...then we know that a longer proof-of-work header chain represents more ac=
tual 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 hea=
der chain.

Crucially, this is better than SPV security, since we are only measuring th=
e passage of time and do not particularly care about reorgs and the transac=
tions in the block.
The longest chain wins, so the "largest blockheight" can only grow monotoni=
cally even if a reorg happens.
Even if the transactions in a reorg are ultimately disconfirmed (double-spe=
nt), 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 ti=
meout.

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 exte=
rnal sources to give it a true notion of time.
Loss of power supply may also cause the Cryptographic Relay to lose its clo=
ck as well.
Thus, it must use this cryptographic notion of time.

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

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

On manufacturing a Cryptographic Relay, the manufacturer stores in unchange=
able 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 targ=
et for the adjustment period.

If the Cryptographic Relay receives an ownership-transfer message with `nLo=
ckTime` 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 a=
ppropriate 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 messa=
ge 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 ownersh=
ip-transfer message with a 0 `nLockTime`, transferring ownership from the M=
uSig pubkey back to you, but pausing after the `R` exchange.
  * Specifically, after the `R` exchange, you generate the point correspond=
ing 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 s=
ignature).
* You pay the invoice, making sure that the maximum cltv-delta for the outg=
oing 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 signa=
ture) you can now complete the signature for the transfer to your unilatera=
l 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 bac=
kout ownership-transfer message to the car and regain control of my vehicle=
.

This provides Lightning-with-PTLCs compatibility (which we expect to be dep=
loyed on the network anyway), while still requiring relatively low resource=
s on the Cryptographic Relay hardware (at the cost that timelocked backouts=
 require much bandwidth; but since such backouts are expected to be rare, t=
his 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 hea=
der chain to the Cryptographic Relay.

A Case Against Blockchain Proliferation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 secre=
t 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 u=
sed to manage the assignment of ownership of Cryptographic Relay devices.
That way, the source code that performs the ownership-assignment can be ope=
nly audited, and independent observers can check that the asset-assignment =
blockchain indeed works using the published source code by compiling it the=
mselves 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 c=
onsiders asset X to be owned by pubkey Y, does not mean that the actual rea=
l-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 st=
ill insert a secret backdoor that ignores the public asset-assignment block=
chain anyway.

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

On the other hand, the proposed Cryptographic Relay here is reasonably simp=
le, 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 Cryptogra=
phic Relay and the controlling devices, but would also include details like=
 voltage levels, current limits, normally-closed vs normally-open vs make-b=
efore-break SPDT/DPDT vs break-before-make SPDT/DPDT, physical dimensions o=
f 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 o=
r other security issues.

Delegated Operators
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 o=
ff, but cannot authorize a transfer of ownership or the addition of new ope=
rators.

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

For example, suppose you, the buyer of my cryptographic car, represent a ty=
pical 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 co=
ntrol of yourself.

Of course, practically speaking, only one of you or your husbands can opera=
te 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 num=
ber 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 ha=
ve.

Whenever an ownership transfer is performed, all operators are deleted, thu=
s 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 com=
pany might be assigned as operators.

Practical Deployment
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 pos=
t-warranty into a smart device that knows its owner, by adding a Cryptograp=
hic Relay hardware device somewhere along the path to its power supply.
For example, a Cryptographic Relay could replace a power switch, or be spli=
ced onto the power cord.

Now, of course such a jury-rigging could be easily bypassed, by simply spli=
cing 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; possessi=
on 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 oper=
ations.
* The interface of the device is simple: it is only a switch, and easy to i=
ntegrate into more complex applications.
  The switch may be used as the route for the power supply, or it may be us=
ed simply for an electrical connection that is detected by some control sys=
tem of the appliance to know whether it should act as "on" or "off".
  This simplicity and generality allows simple interfacing with a variety o=
f 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 mitigate=
d by having multiple Cryptographic Relay manufacturers competing and incent=
ivized to discover backdoors and other security failures of their competito=
rs.
* It is easy to integrate the device into the design of a more complex devi=
ce intended for use by an end-user.
  It is also easy to integrate the device, post-design, to a more complex e=
xisting device that did not include it.

Collateralizing Cryptographic Relay Devices
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 husban=
ds 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 yo=
u 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 f=
or the loan, so that if you are unable to pay, the entity can partially rec=
oup losses by reselling your cryptographic car.

With `SIGHASH_ANYPREVOUT` and Taproot, it becomes possible to trustlessly a=
rrange a collateralized loan on the cryptographic car (to the extent the lo=
an 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 P=
TLC-like constructions:

* First, all of you (you and your husbands, and the loan shark) generate tw=
o 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` i=
n the future.
  Get a complete signature for this command with the loan shark and your hu=
sbands 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 t=
o the car.
* Generate (but do not sign!) the collateralization command, which transfer=
s from the MuSig loan-out pubkey, to a new MusSig(you, your husbands ..., l=
oan shark) using the "loan-payback" pubkeys.
* Generate the collateral-claim command, which transfers from the MuSig loa=
n-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 t=
he 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 l=
oan-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 signat=
ure.
* 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 `SIGHA=
SH_ANYPREVOUT`.
  * The other SCRIPT branch imposes a short `OP_CHECKSEQUENCEVERIFY` timeou=
t, 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 y=
ou the loan shark signature share of the collateral-reclaim command.
  Then provide the signature shares for you and your husband to the loan sh=
ark.
  * If the loan shark completes this signature and reclaims the loan plus i=
nterest, 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 trans=
action and pays it back to the loan shark, but with an `nLockTime` in the f=
uture, 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 co=
mmand, missing the shares from you and your husbands.
* Generate the loan-out-claim transaction, which spends the loan-out transa=
ction and pays it to you and your husbands.
  The loan shark will demand an adaptor signature for this transaction, whi=
ch lets it learn the sum of the missing signatures shares for the collatera=
lization 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 bro=
adcast it.
  The loan shark learns the missing signature shares for the collateralizat=
ion command and performs it, locking your car into collateralization (where=
 it cannot be transferred unless you, your husbands, and the loan shark agr=
ee).
  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 pa=
id back loan.
* With the loan-payback signature completed, you learn the partial signatur=
e 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 r=
ecover the loan and interest by the second branch of the loan-payback Tapro=
ot address.

If you are unable to pay back the loan:

* The collateral-claim command becomes valid a little after the loan due da=
te, and the loan shark takes unilateral possession of your car to recoup it=
s losses.

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