path: root/34/d5fab7f9626362eefd223925cd32caaa57c097

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C5C5FC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 09:19:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id A598324E00
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 09:19:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id roDuV1RUFU9U
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 09:19:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
 [185.70.40.132])
 by silver.osuosl.org (Postfix) with ESMTPS id F20D52045D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 09:19:27 +0000 (UTC)
Date: Tue, 21 Jul 2020 09:19:17 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1595323165;
 bh=NKPNfcqfHiZipUrHs+gXI3ndeo2PY9DDrJljuAPwdDY=;
 h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
 b=wZAfjh8m/dAYMinImV8F1auaBn19vr7l1vMdz+Af6AkT7VglnrrEPTN+7vPHLequR
 t5a/lcm3IzwGhZ4yKXezt72DWuUUzYXJ1xOhEzE0SeJVfRCHMQsb8TxSVoJ7+CMGSX
 RbM7PGdIQ7otB2E96uui8iZN0BqeDmPqsCHTOxT8=
To: Andy Schroder <info@AndySchroder.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <hgBfb7bz5aPN_58-7zBYWl6hDS0fZ28-dcIFy-YgRVm3_G1wKyxBZxr63Opwl-plJFdypycG_28Bag_sZmxn1xRQL67krUFpM-Cs98WTp1g=@protonmail.com>
In-Reply-To: <eb464fc9-38e1-541b-2465-dc3b95cf1bf7@AndySchroder.com>
References: <1z54XsScl3QReBGNtkf6I45p_IwHQMZ6EBVTM5qdZ9P6xv7a3SMxP2l3KahOoUvKRW9o6-saM36A0vxJtMS9pIRVTPGNlU3DMlUVwHZyZks=@protonmail.com>
 <eb464fc9-38e1-541b-2465-dc3b95cf1bf7@AndySchroder.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For
	Smart Transferable Hardware
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2020 09:19:30 -0000

Good morning Andy,

> > 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=3D
> >
> > Time stops for no one; it will not stop for thee.
> > Or, in more science-appropriate terms: the passage of time is the direc=
tion 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 heade=
r hash.
> > Now, we can observe that temperature is largely itself also an expressi=
on of entropy.
> > Higher-entropy areas are higher temperature, and lower-entropy areas ar=
e 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=3D1&0_ValueIndex=
=3DOptimal&HorizontalAxis=3D0&1_ValueIndex=3DOptimal&VerticalAxis=3D1&2_Val=
ueIndex=3DOptimal&3_ValueIndex=3DOptimal&4_ValueIndex=3DOptimal&5_ValueInde=
x=3D0&6_ValueIndex=3D0&7_ValueIndex=3D0&8_ValueIndex=3D0&9_ValueIndex=3D0&1=
0_ValueIndex=3D0&11_ValueIndex=3D0&12_ValueIndex=3D0&ContourValue=3Defficie=
ncy&LinePlotVerticalAxisValue=3Defficiency&CyclePlotVerticalAxis=3DTemperat=
ure&CyclePlotHorizontalAxis=3DPressure&CyclePlotContourLevel=3DEntropy

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 appr=
oaches 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 t=
he 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 th=
e 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) =3D 12.5% higher than the heat it remove=
s
> 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, th=
e 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 candi=
date blocks whose block header hashes are not "cold enough" (i.e. have entr=
opy
>
> production
>
> > greater than the difficulty target), and only allow "cold" block header=
s 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 (in=
creasing universal entropy).
> >
> > ...then we know that a longer proof-of-work header chain represents mor=
e 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 h=
eader chain.
> > Crucially, this is better than SPV security, since we are only measurin=
g the passage of time and do not particularly care about reorgs and the tra=
nsactions in the block.
> > The longest chain wins, so the "largest blockheight" can only grow mono=
tonically 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
> >
> > =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
> >
> > We can argue that the Cryptographic Relay is a device tr\*sted to actua=
lly do what we claim it does here.
> > In particular, its users tr\*st that its manufacturer does not have a s=
ecret backdoor, a special public key recognized by every Cryptographic Rela=
y by which the manufacturer can gain ownership of every piece of smart hard=
ware 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 device=
s.
> > That way, the source code that performs the ownership-assignment can be=
 openly audited, and independent observers can check that the asset-assignm=
ent 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 somewhe=
re 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 ca=
n still insert a secret backdoor that ignores the public asset-assignment b=
lockchain 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-assig=
nment of real-world things, are far more centralized due to their non-gener=
ic nature: very few entities are interested in those spaces.

A Cryptographic Relay demonstrates that we can do better, by making a gener=
ic 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 pr=
obability 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 Crypt=
ographic Relay and the controlling devices, but would also include details =
like voltage levels, current limits, normally-closed vs normally-open vs ma=
ke-before-break SPDT/DPDT vs break-before-make SPDT/DPDT, physical dimensio=
ns 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 flexibilit=
y.

I considered the "relay" interface to be better since a relay can be used a=
s a (very slow) transistor, but if you want to transport say a 220V AC main=
s 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 oper=
ation 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 mai=
ns 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 bett=
er mechanical longevity and lower continuous power use, which requires two =
relay driver interfaces and timing).

> > Practical Deployment
> >
> > =3D=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 prov=
ides us with a practical deployment for smart devices that can recognize th=
eir 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 Crypto=
graphic 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; poss=
ession 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