diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-07-21 09:19:17 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-07-21 09:19:30 +0000 |
| commit | 2eb5e7016f0da6de3e8e5a9bad56b5ea400ef329 (patch) | |
| tree | 274614244901ea330ad9a9a12194f1b2debc3f29 | |
| parent | 3187122ce0f425e6167d6063ea6ce8f2681c26cd (diff) | |
| download | pi-bitcoindev-2eb5e7016f0da6de3e8e5a9bad56b5ea400ef329.tar.gz pi-bitcoindev-2eb5e7016f0da6de3e8e5a9bad56b5ea400ef329.zip | |
Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware
| -rw-r--r-- | 34/d5fab7f9626362eefd223925cd32caaa57c097 | 338 |
1 files changed, 338 insertions, 0 deletions
diff --git a/34/d5fab7f9626362eefd223925cd32caaa57c097 b/34/d5fab7f9626362eefd223925cd32caaa57c097 new file mode 100644 index 000000000..15181007d --- /dev/null +++ b/34/d5fab7f9626362eefd223925cd32caaa57c097 @@ -0,0 +1,338 @@ +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 + |