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

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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