From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C5C5FC016F for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <1z54XsScl3QReBGNtkf6I45p_IwHQMZ6EBVTM5qdZ9P6xv7a3SMxP2l3KahOoUvKRW9o6-saM36A0vxJtMS9pIRVTPGNlU3DMlUVwHZyZks=@protonmail.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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