U.S. patent application number 15/345424 was filed with the patent office on 2017-05-11 for systems and methods for autonomous device transacting.
This patent application is currently assigned to SWFL, Inc., d/b/a "Filament", SWFL, Inc., d/b/a "Filament". The applicant listed for this patent is SWFL, Inc., d/b/a "Filament", SWFL, Inc., d/b/a "Filament". Invention is credited to Allison Cliff-Jennings, Jeremie Miller, Thomas Muldowney.
Application Number | 20170132620 15/345424 |
Document ID | / |
Family ID | 58663460 |
Filed Date | 2017-05-11 |
United States Patent
Application |
20170132620 |
Kind Code |
A1 |
Miller; Jeremie ; et
al. |
May 11, 2017 |
SYSTEMS AND METHODS FOR AUTONOMOUS DEVICE TRANSACTING
Abstract
A system and method for facilitating microtransaction involving
an autonomous transacting device includes generating a plurality of
key pairs and sharing a key of each of the plurality of key pairs
with the transacting entity; establishing an escrow at the
blockchain and providing the plurality of key pairs to the
blockchain; exchanging one or more of the key pairs using a
sidechain; requesting a release or a refund of funds from the
escrow; and presenting one or more exchange key pairs to the
blockchain thereby establishing a percent completion of the
sidechain.
Inventors: |
Miller; Jeremie; (Reno,
NV) ; Muldowney; Thomas; (Reno, NV) ;
Cliff-Jennings; Allison; (Reno, NV) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
SWFL, Inc., d/b/a "Filament" |
Reno |
NV |
US |
|
|
Assignee: |
SWFL, Inc., d/b/a
"Filament"
Reno
NV
|
Family ID: |
58663460 |
Appl. No.: |
15/345424 |
Filed: |
November 7, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62252306 |
Nov 6, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 9/30 20130101; H04L
63/0428 20130101; H04W 12/02 20130101; G06Q 20/065 20130101; H04L
2209/38 20130101; H04L 63/083 20130101; G06Q 2220/00 20130101; H04L
9/14 20130101; H04L 9/3236 20130101; G06Q 20/06 20130101; H04L
9/0637 20130101; H04L 63/061 20130101; H04W 12/06 20130101; H04L
9/0861 20130101; H04L 9/3297 20130101; H04L 67/12 20130101; H04L
2209/80 20130101; H04L 2209/56 20130101; H04W 12/04 20130101; G06Q
20/3829 20130101; H04L 2209/805 20130101 |
International
Class: |
G06Q 20/38 20060101
G06Q020/38; H04L 9/08 20060101 H04L009/08 |
Claims
1. A system for facilitating microtransactions involving an
autonomous transacting device, the system comprising: a blockchain;
a transacting entity; an autonomous transacting device comprising:
(i) a cryptographic processor; (ii) a cryptographic storage medium
having cryptographic code stored thereon, that when executed by the
cryptographic processor performs: generating a plurality of key
pairs and sharing a key of each of the plurality of key pairs with
the transacting entity; establishing an escrow at the blockchain
and providing the plurality of key pairs to the blockchain;
exchanging one or more of the key pairs using a sidechain;
requesting a release or a refund of funds from the escrow; and
presenting one or more exchange key pairs to the blockchain thereby
establishing a percent completion of the sidechain.
2. A method for facilitating microtransaction involving an
autonomous transacting device, the method comprising: at a
cryptographic processor operably in communication a cryptographic
storage medium having stored thereon computer-executable code
stored thereon, that when executed by the cryptographic processor
performs: generating a plurality of key pairs and sharing a key of
each of the plurality of key pairs with a transacting entity;
establishing an escrow at the blockchain and providing the
plurality of key pairs to a blockchain; exchanging one or more of
the key pairs using a sidechain; requesting a release or a refund
of funds from the escrow; and presenting one or more exchange key
pairs to the blockchain thereby establishing a percent completion
of the sidechain.
3. A non-transitory computer-readable medium having stored thereon
computer-executable code that when executed by one or more of a
processor and a cryptographic processor performs: generating a
plurality of key pairs and sharing a key of each of the plurality
of key pairs with the transacting entity; establishing an escrow at
a blockchain and providing the plurality of key pairs to the
blockchain; exchanging one or more of the key pairs using a
sidechain; requesting a release or a refund of funds from the
escrow; and presenting one or more exchange key pairs to the
blockchain thereby establishing a percent completion of the
sidechain.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Application No. 62/252,306, filed 6 Nov. 2015, which is
incorporated in its entirety by this reference.
TECHNICAL FIELD
[0002] The inventions of the present application relate generally
to the electronic connectivity and communications fields, and more
specifically to improved systems and methods for implementing
secure and private communications between devices.
BACKGROUND
[0003] In many centralized systems, many devices across great and
small distances can achieve heightened levels of connectivity and
interaction without being physically connected to each other and
thus, are able to connect and communicate with one another
wirelessly. These centralized systems for connecting these devices,
however, are accompanied with several disadvantages that limit
connectivity in remote locations, limit the autonomy of the devices
operating in the centralized systems, and therefore, do not allow
for optimal connectivity, autonomous transacting, and
communications between and through the devices.
[0004] Additionally, due to the inherent lure of abuse and
exploitation by centralized systems, all of these economic
elements, digital and physical, with existing systems or new
products, must be fundamentally autonomous and distributed in
nature in order to maximize their potential. It is only in
autonomous and distributed environment that markets can naturally
emerge, balanced and maximizing benefit for all those involved.
[0005] The commonly referred to proposal to evolve the Internet to
optimize for the "Internet of Things" has become synonymous with
connected thermostats, pet collars, and toothbrushes. While the
ability to build connectivity between devices like these is novel,
there is a possibility that it may not realize the full potential
of digitally connecting the physical world of things together. When
a device can only connect with similarly-manufactured devices, and
each of them can only connect with their manufacturer-approved
cloud service, and thus, the vast majority of value that the device
could have provided over its lifetime is severely hindered since it
is strictly tied to a cloud-based interaction platform.
[0006] These new economic actors--e.g., the devices
themselves--must be principally independent actors from centralized
authority (e.g., manufacturers and connectivity servers) to unlock
the vast majority of value associated therewith. Including--and
especially--from the manufacturers of the devices themselves. It
can be a very risky proposition to continue to give central
authority, whether a nation state or a corporation, the reach and
control capable of this new type of connected device. These
autonomous and fully interconnected devices should retain full
control and complete privacy at the device providing the coupling
and creating the economic value.
[0007] But in order to realize such prospective technical
environments where devices are independent actors; the technical
functions involved in connectivity including discovery,
interacting, and even transacting value between devices and with
people, the entire protocol stack, systems, and methods governing
these technical functions must be re-evaluated from the ground up.
Thus, there is a need in the device connectivity and communication
field to create new and useful systems and methods for implementing
an environment for interactivity of autonomous devices without or
independent of a central authority for governing interaction there
between and consequently, enhancing the levels and quality of
connectivity achievable with such networks and devices.
BRIEF DESCRIPTION OF THE FIGURES
[0008] FIG. 1 is a schematic representation of a system of a
preferred embodiment of the present application;
[0009] FIG. 2 is a schematic representation of a component of
system of a preferred embodiment of the present application;
[0010] FIG. 3 is an example process flow of a method of a preferred
embodiment of the present application;
[0011] FIG. 4 is an example process flow of a method of a preferred
embodiment of the present application;
[0012] FIG. 5 is an example process flow of a method of a preferred
embodiment of the present application; and
[0013] FIG. 6 is an example process flow of a method of a preferred
embodiment of the present application.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0014] The following description of the preferred embodiments of
the inventions are not intended to limit the inventions to these
preferred embodiments, but rather to enable any person skilled in
the art to make and use these inventions.
[0015] DIST Protocols
[0016] In the present application, a set of protocols called
Distributed Sentient Transactions (DIST), are implemented in the
systems and methods described herein to provide a minimum set of
requirements necessary to realize autonomous, decentralized
devices.
[0017] In addition to the capabilities described of DIST and other
novel protocols described herein, there are two fundamental
requirements that are cornerstone for implementing a truly
decentralized connected device environment. The baseline of these
requirements revolve around security and privacy.
[0018] Security and privacy as two concepts that are sometimes used
interchangeably, and while these concepts are related, they are not
the same thing. For instance, in the realm of connectivity devices,
security entails guaranteeing that the identity given to a device
and the information transmitted by and between devices are what the
device(s) states it is, without tampering, interference, and
modification within transit, at the time of transmission, and/or at
the time of receipt. Security sometimes also includes enciphering
information so that the information is not readable by any other
entity but the sender and receiver. Privacy, on the other hand,
entails preventing others outside of the intended recipient to gain
information related to or about the transaction or transmission
between two devices or parties. Exploiting privacy could be as
simple as eavesdropping, or as sophisticated as deep-packet
inspection or timing attacks to determine additional information
about the transaction or transmission. Thus, in order for devices
to be truly autonomous, they must also have enough basic
capabilities, at the device level, in both privacy and security to
mitigate their vulnerabilities to security and privacy attacks that
would otherwise render the devices disabled or ineffective for
their intended purposes with the simplest effort (e.g.,
hacking).
[0019] Accordingly, DIST weaves security and privacy throughout the
entire collection of protocols that make up the composition for
DIST. While DIST protocols, in some embodiments, reduce
efficiencies in some processes, the benefit obtained by enhanced
security and privacy far outweigh the drawbacks in efficiencies. A
fundamental assumption, in many embodiments described herein, is
that any hardware the DIST stack of protocols runs on will have
access to a hardware cryptographic co-processor to securely
generate, manage, and store cryptographic keys--and when necessary,
to accelerate computation-intensive encipher and decipher
processing and to ensure tamper-resistant cryptographic code.
Security must be trusted at the lowest level of the hardware of the
device, or it is possible that all higher-level promises of
security and privacy become indefensible.
[0020] Privacy must also be adhered to at the very lowest levels.
Telehash protocol is a primary communication protocol in the DIST
protocol stack, and along with a sub-protocol of Telehash called
TMesh, Telehash protocols provide maximized communication privacy
between any two endpoints. Therefore, under such protocols,
encrypted communication is enforced, no metadata is ever leaked in
communications and the operations of devices, and perfect forward
secrecy is required.
[0021] The DIST protocol has been designed to run on a myriad of
hardware platforms, from laptops and embedded computers all the way
down to microcontroller-based systems such as wearables and
wireless sensors. Thus, it shall be understood that DIST protocol
can be run and/or applied to any type of device or element with
sufficient computational and/or processing abilities to execute
DIST protocols.
[0022] Blockname: Discovery Operation
[0023] Before any decentralized interaction between parties (e.g.,
devices) can happen, there must first be a means or method to
ensure both the identity and the discoverability of a party.
Identity of a party (e.g., an endpoint or node) focuses
specifically on the verifiability that a party is who they say they
are. Discovery focuses on the ability to find the network location
of the party, given a known identifier of that party. Blockname
primarily works to solve the discovery problem. But it also solves
the identity verifiability problem in concert with Telehash--the
secure communication protocol.
[0024] Blockname works on a novel premise, which is: leverage
almost all of the existing Domain Name System (DNS) infrastructure
that is currently used for Internet name resolution for domain
names to Internet protocol (IP) addresses. Except, instead of
relying on ICANN and its 13 root name server delegates to be the
final source-of-truth, replace the 13 root name server delegates
with the Bitcoin blockchain or other digital ledger technologies
operating without a central administrator. Blockname uses the
blockchain as a replacement start of authority (SOA) for normal DNS
resolution, as well as to resolve alternative domains and custom
top-level domains (TLDs). Blockname provides identity and discovery
in a completely distributed manner--no registrars, root servers, or
central authorities required further enabling the autonomy of the
devices operating thereunder.
[0025] Blockname solves an underlying issue with existing name
resolution and decentralization. DNS is not fundamentally
decentralized in that at its root, there is a federation of 13
servers run by a loose conglomerate of organizations, under the
singular ICANN DNS Root Server System Advisory Committee. However,
this root zone is actually controlled by governmental entities. The
government entities approve all changes to the root zone file as
requested by 1.
[0026] In order to replace the role of ICANN in Blockname, there
exists a notion of notaries. Notaries are a collection of
individuals or organizations who vouch for the authenticity of
names posted within a Blockname-based system. Notaries can use
several means or methods to guarantee authenticity, from
traditional ways such as confirming business licenses or personal
identities to using already-established means to confirm identity,
such as SSL certificate authorities (CAs). To prevent land-grabs
and squatting, it is expected that the earliest notaries will
leverage existing efforts from SSL certificate authorities in order
to bootstrap Blockname. As the Blockname protocol matures and sees
greater use, notaries will likely expand to use additional means to
validate identities.
[0027] On the software side, a Blockname Resolver is provided which
acts like a traditional DNS cache and recursive resolver. Blockname
Resolver will resolve all queries via regular DNS first, and only
when those queries fail will Blockname Resolver use any names that
come from the blockchain-based hints. In this mode, Blockname
always acts as a backup for any existing valid DNS names and only
provides additional resolution for unregistered domains or
unsupported Top-Level Domains (TLDs).
[0028] In the background, Blockname Resolver continuously indexes
all newly broadcast blockchain transactions that have a valid
hint--any OP_RETURN starting with a *--storing only the unique
hints that have the largest values associated with them. The value
of the hint's own output--what could be considered the "burned"
value in Satoshis--must be larger for the new hint to replace a
previous one of the same name. In this way, an old host name or IP
address can be updated by simply creating a new blockchain
transaction with a higher value assigned to it. Since a Satoshi is
1/100,000,000 of a Bitcoin, it is extremely low cost to update
Blockname records.
[0029] The other software component, the Blockname Notary, verifies
that the newly broadcast Blockname transactions are from an
authorized agent of that name. It shall be noted that the Blockname
Resolver will have a list of valid notaries in it--much like web
browsers have a list of valid certificate authorities that are used
to confirm authenticity for web site SSL certificates. Each
Blockname Resolver instance can modify the list of valid notaries,
but a default list is also provided.
[0030] While individual device names and subdomains can both use
Blockname, they may not scale well depending on how the combination
is utilized. Inefficiencies arise if it is attempted to store every
device identity inside the blockchain directly. Larger namespaces,
such as a custom TLDs, are formed by designated public Blockname
resolvers advertising their existence to each other and building a
distributed hash table (DHT) index for a TLD from those
advertisements. The DHT index is then used to dynamically resolve
any names with that TLD, allowing for ephemeral and alternative
uses on a custom TLD that do not require a transaction per name or
traditional DNS registration.
[0031] Telehash: Secure Communication Protocol
[0032] Once verifiable identity and lookup capabilities are
available through Blockname, Telehash allows devices to establish
secure communication directly with each other. Telehash, simply
put, is a lightweight network protocol with strong encryption to
enable communication across multiple transports and platforms. A
lightweight interoperable protocol with strong encryption to enable
mesh networking across multiple transports and platforms. Each
endpoint generates its own unique public-key based address (e.g., a
hashname) to send and receive small encrypted packets of JSON (with
optional binary payloads) to other trusted endpoints. An endpoint
may also provide routing assistance to others for bridging across
different transports and to help negotiate direct peer-to-peer
links.
[0033] Encryption is end-to-end, and is required one hundred
percent (100%) of the time. It is impossible to disable encryption
in Telehash. There is strict privacy, where no content, metadata or
identity is ever revealed to third-parties. Telehash runs well on
embedded, mobile, and desktop computing classes of hardware.
Several underlying transport protocols are supported, so Telehash
can run cleanly on top of very common networking protocols
currently in use today. Lastly, there are many native
implementations of Telehash supporting a large number of
programming languages.
[0034] Telehash could be considered a next generation iteration of
the best parts of the XMPP protocol. XMPP is a protocol created by
Jabber to facilitate instant messaging between entities in a
federated manner. Federation is similar to decentralization, except
that in XMPP's case, federation means that anyone could run their
own instant messaging server, and servers could communicate with
each other. Instant messaging clients would connect to servers to
send messages to each other on their clients' behalf. This was a
much better model than the silos of the day--most notably AOL
Instant Messenger (AIM). At the height of XMPP's popularity, over 1
billion people used it daily to communicate. Both Google Chat and
Facebook Messenger used it as their messaging protocol. However,
federation led to consolidation over time. Early on, there were
thousands of XMPP servers, and as time went on, the number of
servers decreased to just a dozen or so.
[0035] Telehash takes the best parts of XMPP, and addresses the
deficiencies found by having XMPP deployed at such a large scale.
The most important changes Telehash brings are in the areas of
protocol verbosity, privacy, and addressing the drawbacks of a
federated model.
[0036] As computing has become increasingly powerful and efficient,
protocol verbosity is not so much a problem as it used to be. The
size of the protocol packets, the amount of processing required to
encode and decode the packets, and the overall compute overhead
required to run that protocol are all less of a problem for today's
devices than they used to be. However, in this new era of connected
devices (e.g., nodes)--many of which are extremely low power and
compute (e.g., low computer processing capabilities) capability, a
lightweight protocol is actually more important now than it used to
be. Telehash can run on devices as small as ARM Cortex Mo+ class: a
32-bit microcontroller running at 48 MHz with 32 kB of SRAM. No
floating point processor and no memory controller is necessary.
Because of the proliferation of low-power connected devices,
Telehash must be able to run across all devices natively in order
to allow true end-to-end communication. It is important to note
that, in device classes as small as these, it is often beneficial
to leverage a hardware-based crypto-accelerator chip, not only to
increase cryptography performance, but for secure key storage as
well. A crypto-accelerator chip can be integrated or otherwise,
included in a number of different manners of a circuit board. A
significant purpose of the crypto-accelerator chip, as alluded to
above, is to load off very computing intensive tasks of
encryption/decryption and compression/decompression. In such cases,
the acceleration is often achieved by doing particular arithmetic
calculations in the hardware. Accordingly, by including a
crypto-accelerator chip in addition to a microcontroller and/or
cryptographic coprocessor on a device, significant computing
efficiencies can be achieved without necessarily having to increase
the size of a small device having the processors and chips
thereon.
[0037] In terms of privacy, XMPP originally did not handle privacy
considerations at all. Only at a later time was work done with
integrating Off-The-Record2 (OTR) functionality into XMPP. OTR
brought strong encryption, authentication, deniability, and perfect
forward secrecy to XMPP. Telehash handles these capabilities
natively within its protocol, without the need to have OTR
functionality built on top of it. By performing these OTR-type
functionalities natively in Telehash provides a significant benefit
of computing efficiencies by a computer processor since there is
only one protocol to be process for a secure and private
communication rather than using two disparate protocols in
combination.
[0038] Lastly, a federated model may be insufficient, as it has
been seen with XMPP. True end-to-end networking is necessary to
avoid the consolidation of federated systems as seen in the XMPP
environment. The consolidation of the federated systems in the XMPP
environment raises the same and/or similar issues apparent in
systems having a central authority. Specifically, systems having
central authorities governing, managing, or otherwise interacting
with multiple devices may be compromised and therefore, affecting
multiple and if not all devices in a network. This configuration
should be avoided to mitigate the possibility of compromise.
[0039] Before getting into the underlying process of Telehash, a
relevant terms glossary is provided in the following paragraphs
which may be helpful when discussing the operation of Telehash, to
avoid confusion with other network protocols.
[0040] Packet refers or relates to an encapsulated format for
JavaScript Object Notation (JSON) and binary data using an encoding
format that allows combined JSON and binary data
[0041] Hashname refers or relates to an endpoint identifier,
calculated from its public key Endpoint, which refers or relates to
a participant in the Telehash network identified by a single
hashname.
[0042] Message refers or relates to an asynchronous encrypted
packet between two endpoints; Channel, which refers or relates to a
virtual stream that allows two endpoints to exchange data reliably
or unreliably.
[0043] Chunking refers or relates to a packet is chunked into
smaller pieces for low-MTU or streaming transports.
[0044] Cloaking (or Masking) refers or relates to method used to
hide Telehash traffic on the wire by randomizing all data sent in a
network of endpoints.
[0045] Exchange refers or relates to the currently encrypted
session state between two endpoints; Handshake, which refers or
relates to a message type used to establish an encrypted session
for channels; Link, which refers or relates to a connection between
two endpoints either directly or via a router; Mesh, which refers
or relates to a number of links with active encrypted sessions over
any transport; participants in the mesh are called endpoints.
[0046] Router refers or relates to an endpoint that will facilitate
link setup between two other endpoints; Transport--underlying
network responsible for packet transfer.
[0047] The core entity in a Telehash network is the endpoint.
Endpoints can be embedded devices, web browsers, mobile phone apps,
or server daemons. They are simply the original sender, or the
final recipient of any communication. Each endpoint has a globally
unique 32-byte or similar-sized address, called a hashname. This
hashname is how endpoints identify themselves and other
endpoints.
[0048] Endpoints establish secure communication with other
endpoints by first establishing a link--either directly or through
a router. These links can use any available underlying network
transports such as User Datagram Protocol (UDP), (Transmission
Control Protocol) TCP, or even Bluetooth, short-range
communications (e.g., radio), long-range sub-gigahertz radio, or a
combination thereof. Once the link is established between the
endpoints, a handshake message occurs to create a secure exchange
on the link between the endpoints.
[0049] Once this secure link is established, one or more channels
can be established on this link. A channel is analogous to a
traditional network socket.
[0050] Once one or more channels are established securely, packets
are passed between them directly. A collection of links to many
endpoints is considered a mesh.
[0051] When an endpoint does not already know how to find another
endpoint, it will request help from a router. The router will
facilitate a link setup between the two endpoints. Once the link is
set up, the router is no longer a part of the link, and the two
endpoints can continue to establish links directly until one or the
other is no longer at the same network address.
[0052] TMesh is a sub-protocol of the Telehash system, that extends
Telehash functionality onto low power, low bandwidth radio links.
TMesh is uniquely designed to be a secure physical (PHY) and Media
Access Control (MAC) protocol for long-range, sub-Gigahertz mesh
networking. It brings the same secure, private end-to-end
networking to the smallest of embedded devices that Telehash offers
in more powerful hardware, but works within the typically high
latency and low bandwidth that these very long-range radio
transceivers exhibit.
[0053] Accordingly, TMesh is the composite of three distinct
layers, the physical radio medium encoding (PHY), the shared
management of the spectrum (MAC), and the networking relationships
between two or more endpoints (Mesh).
[0054] A community is any set of endpoints that are using a common
medium definition and have enough trust to establish a Telehash
link for sharing peers and acting as a router to facilitate larger
scale meshing. Within any community, the endpoints that can
directly communicate over a medium are called neighbors, and any
neighbor that has a higher z-index is always considered the current
leader that may have additional responsibilities.
[0055] To provide proper context additional definitions of terms
used with TMesh are provided: medium refers and/or relates to a
definition of the specific channels/settings the physical
transceivers of endpoints use; community refers and/or relates to a
network of endpoints using a common medium to create a large area
mesh; neighbors refers and/or relates to nearby reachable endpoints
in a same community; z-index refers and/or relates to a
self-asserted resource level (e.g., available power capacity,
available memory, and other capacities of the limited capabilities
associated with an endpoint) from any endpoint; leader refers
and/or relates to a highest z-index endpoint in any set of
neighbors; knock refers and/or relates to a single transmission;
window refers and/or relates to a variable period in which a knock
is transmitted, 2 16 to 2 32 microseconds (<100 ms to >1 hr);
and window sequence refers and/or relates to each window will
change frequency/channels in a sequence.
[0056] Regarding context about PHY, a medium is a compact 5 byte
definition of the exact PHY encoding details required for a radio
to operate. The 5 bytes are always string encoded as 8 base32
characters for ease of use in JSON and configuration storage, an
example medium is azdhpa5r which is 0x06, 0x46, 0x77, 0x83,
0xb1.
[0057] Byte 0 is the primary type that determines if the medium is
for a public or private community and the overall category of PHY
encoding technique to use. The first/high bit of byte 0 determines
if the medium is for public communities (bit 0, values from 0-127)
or private communities (bit 1, values from 128-255). The other bits
in the type map directly to different PHY modes on transceivers or
different hardware drivers entirely and are detailed in the PITY
section.
[0058] Byte 1 is the maximum energy boost requirements for that
medium both for transmission and reception. While an endpoint may
determine that it can use less energy and optimize its usage, this
byte value sets an upper bar so that a worst case can always be
independently estimated. The energy byte is in two 4-bit parts, the
first half for the additional TX energy, and the second half for
the additional RX energy. While different hardware devices will
vary on exact mappings of mA to the 1-16 range of values, effort
will be made to define general buckets and greater definitions to
encourage compatibility for efficiency estimation purposes.
[0059] Each PHY driver uses the remaining medium bytes 2, 3, and 4
to determine the frequency range, number of channels, spreading,
bitrate, error correction usage, regulatory requirements, channel
dwell time, and similar details on the transmission/reception. The
channel frequency hopping and transmission window timing are
derived dynamically and not included in the medium.
[0060] Transmitted payloads do not generally need whitening as
encrypted packets are by nature DC-free. They also do not
explicitly require CRC as all Telehash packets have authentication
bytes included for integrity verification.
[0061] A single fixed 64 byte payload can be transmitted during
each window in a sequence, this is called a knock. If the payload
does not fill the full 64 byte frame the remaining bytes must
contain additional data so as to not reveal the actual payload
size.
[0062] WIP--determine a standard filler data format that will add
additional dynamically sized error correction, explore taking
advantage of the fact that the inner and outer bitstreams are
encrypted and bias-free (Gaussian distribution divergence?).
[0063] Each transmission window can go either direction between
endpoints, the actual direction is based on the parity of the
current nonce and the binary ascending sort order of the hashnames
of the endpoints. A parity of 0 (even) means the low endpoint
transmits and high endpoint receives, whereas a parity of 1 (odd)
means the low endpoint receives and high endpoint transmits.
[0064] Regarding MAC, there is no endpoint addressing or other
metadata included in the transmitted bytes, including there being
no framing outside of the encrypted ciphertext in a knock. The
uniqueness of each knock's timing and PHY encoding is the only
endpoint addressing mechanism.
[0065] Every window sequence is a unique individual encrypted
session between the two endpoints in one community using a randomly
rotating nonce and a shared secret key derived directly from the
medium, community name, and hashnames. All payloads are
additionally encrypted with the ChaCha20 cipher before transmission
regardless of if they are already encrypted via Telehash.
[0066] Each endpoint should actively make use of multiple
communities to another endpoint and regularly test more efficient
mediums to optimize the overall energy usage. Every endpoint
advertises their current local energy availability level as a
z-index (single byte value) to facilitate community-wide
optimization strategies.
[0067] There are two mechanisms used for enabling a larger scale
mesh network with TMesh, communities (MAC layer) and routers
(Telehash/app layer).
[0068] A community is defined by endpoints using a shared medium
and the automatic sharing of other neighboring endpoints that it
has active windows with in that medium. Each neighbor endpoint
hashname is listed along with next nonce, last seen, z-index, and
the signal strength. An endpoint may be part of more than one
community but does not share neighbor endpoint information outside
of each one.
[0069] The leader is always the neighbor with the highest z-index
reachable directly, this is the endpoint advertising that it has
the most resources available. The leader inherits the
responsibility to monitor each neighbor's neighbors for other
leaders and establish direct or bridged links with them.
[0070] Any endpoint attempting to connect to a non-local hashname
will use their leader as the Telehash router and send it a peer
request, whom will forward it to the next highest leader it is
connected to until it reaches the highest in the community. That
highest resourced leader is responsible for maintaining an index of
the available endpoints in the community. Additional routing
strategies should be employed by a mesh to optimize the most
efficient routes and only rely on the leaders as a fallback or
bootstrapping mechanism.
[0071] Any endpoint that can provide reliable bridged connectivity
to another network (wifi, ethernet, etc) should advertise a higher
z-index and may also forward any Telehash peer request to
additional Telehash router(s) in the mesh via those networks.
[0072] While Telehash and TMesh are not expressly discussed with
respect novel embodiments discussed below, it shall be understood
that Telehash protocols and TMesh protocols may be, especially if
using radio communication, the underlying communication security
and privacy protocols, which are implemented to ensure that the
embodiments and implementations thereof are not compromised.
[0073] OVERVIEW of IoT
[0074] Ushering in a new era revolving around IoT or generally,
digital connectivity of things (DGoT) requires a robust system for
connectivity and in the view of the present application, robust
methods and systems for implementing secure and private
connectivity with or involving those devices and other elements
that enable an IoT or DGoT environment are disclosed. In this
context, arises the several inventive concepts disclosed herein
which provide novel and nonobvious techniques and systems which
shore up the gaps in security and privacy that exist when IoT
devices and the like connect and communicate with one another. By
shoring up the security and privacy gaps in these devices, enhances
the autonomy of the devices to operate without a central authority
(e.g., a central server or the like) that may be used to manage the
device's privacy and security considerations.
[0075] In a typical IoT environment, there may be data capturing
devices and/or operational devices, such as sensors and/or
actuators which gather information associated with a machine (e.g.,
a thing) and connect to other sensors and/or actuators to
communicate the gathered information. In this basic example of an
IoT environment, the transmissions of the sensors and/or actuators
may be susceptible to attacks which aim to absorb observable
information about the transmission and absorb the gathered
information being transmitted and often, information about the
devices, themselves. Thus, with the prevalence of meta data attacks
and meta data surveillance to wrongfully obtain information from
IoT connectivity devices, such as the sensor and/or actuator,
raises an immediate concern particularly with communications
between IoT devices that are performed over radio frequency. This
is because with radio frequency communications there is not a
network access point that you have to worry about gathering meta
data from; rather, a real immediate concern is that anybody and/or
any receiver in proximity to the radio range of the radio frequency
communication can surveil the communication and record all of the
radio frequency communication in the air. There is virtually no way
to detect whether a receiver is surveilling and/or recording the
radio communication; however, if an entity chooses to invest
heavily in physical security it may be possible to mitigate the
opportunities others have to monitor and capture radio frequency
communication information between devices. This approach, however,
may be extremely expensive and cost prohibitive.
[0076] Thus, in a system that includes thousands of devices
communicating with each other over radio frequency, the issues
involving wrongful surveillance and information capture is
magnified even greater. This is problematic because any kind of
information including data management patterns, device management
patterns, sensor recording, sensor data patterns, type of sensors,
when schedules run, actuation timing and schedules, and the like
can become exposed from the meta data associated with radio
frequency traffic. Simply put, the wrongful surveillance and/or
capture of meta data from radio frequency communications allows the
surveilling entity to identify communication packets which have the
information of interest since the meta data in a radio frequency
transmission usually or possibly describes the general contents of
the communication packets. Once the general contents of the
communication packets are known, an entity who is surveilling the
radio transmissions can then allocate resources to hacking or
wrongfully obtaining the specific contents of the communication
packets. This situation can be substantially mitigated or
otherwise, completely avoided by diminishing, disguising,
obfuscating, or mitigating to a zero meta data state any useful
meta data that can be obtained by mere surveillance in a radio
transmission between two communicating parties. A zero meta data of
a preferred embodiment is a state in which at least two endpoints
in a mesh network or otherwise, which are establishing a link,
linked, or communicating with each do not reveal any kind of meta
data to a surveilling entity, such that zero meta data is exposed.
A zero meta data state ensures that the patterns, schedules, and
communication packets of the network of endpoints are securely and
privately protected.
[0077] Accordingly, there are three main recordable and/or
surveillable meta data attributes of a radio frequency
communication between at least two communicating parties that the
embodiments of the present application seek to protect using the
systems, methods, and protocols described herein. A first attribute
that the embodiments seek to protect include the channel (e.g.,
frequency) of communication of a transmission, a second attribute
includes a signal strength (e.g., the loudness of the transmission
or power) of a communication and/or a signal strength emanating
from the parties or devices involved in the radio transmission, and
the time of the radio transmission including a start time, duration
of transmission (e.g., total time of transmission, end time of
transmission, and even time between transmissions. Obviously, if
any of these attributes of a radio communication become accessible
to a wrongful observer, the content of the transmission including
the data of the transmission can be recorded.
[0078] Thus, each of these four parameters including the three meta
data attributes and data content of a radio transmission are
protected using the embodiments of the present application. It
shall be understood that, while the present application expressly
protects these forms of meta data from surveillable or noticeable
exposure, any and other forms of meta data associated with a radio
transmission or other susceptible forms of communication can be
protected, such as any other indirect transmission signals from
components of the communicating devices when processing signals,
such as an RF amplifier and also, meta data information from a
tuner or detector.
[0079] While cryptography can be used to strongly secure contents
or data contents of a communication packet, it is difficult to
apply cryptography to protect meta data attributes of a radio
transmission, such as timing, power, and frequency (e.g., channel)
being used in the transmission. Thus, the systems and protocols
associated with the system and methods of the present application
can be used to protect each of the above-noted parameters.
[0080] As mentioned previously, in the system(s) described herein
below, there is a fundamental requirement that each of the nodes
(e.g., autonomous devices) is able to perform full cryptography
protocols without any intervention or assistance of a central
authority or central connectivity server. This fundamental
functionality of the nodes lends to the autonomous nature of the
devices required in an IoT or DCoT of the future.
[0081] The systems and methods required for achieving such device
autonomy is described below, in part, as well as in the following
application, which is incorporated by reference in its
entirety:
[0082] Systems and Methods for Secure and Private Communications
application Ser. No. ______
[0083] Blocklet Overview
[0084] Blocklet protocol is fundamentally based on cryptography and
is organized or structured in such a manner in which any
implementation of blocklet protocol can be self-verified using the
protocols therein. The root of blocklet protocols include the data
structures available under the JavaScript Object Signing Encryption
(JOSE) stack of protocols. Specifically, the composition of
blocklet protocols includes, mainly, a number of JWTs and JWKs, as
defined by the JOSE specification.
[0085] Regarding a JWT, a JWT is a JavaScript Objection Notation
(JSON) Web Token (JWT), which is a compact data structure of JOSE
and a URL-safe means of representing claims or statements of
information to be transferred between two parties. Essentially, JWT
is a compact claims representation format intended for space
constrained environments. A claim in a JWT is encoded as a
JavaScript Object Notation (JSON) object that is used as the
payload of a JSON Web Signature (JWS) structure or as the plaintext
of a JSON Web Encryption (JWE) structure, enabling the claims to be
digitally signed or integrity protected with a Message
Authentication Code (MAC) and/or encrypted. Accordingly, a claim is
a piece of information asserted about a subject.
[0086] Additionally, the contents of a JOSE Header for a JWT
describe the cryptographic operations applied to the JWT claims. If
the JOSE Header is for a JWS, the JWT is represented as a JWS and
the claims are digitally signed or MACed with the JWT claims being
the JWS payload. IF the JOSE header is for a JWE, the JWT claims
being the plaintext encrypted by the JWE. A JWT may be enclosed in
another JWE or JWS structure to create a nested JWT, enabling
nested signing and encryption to be performed.
[0087] A JSON Web Key (JWK) is a JSON data structure that
represents a cryptographic key.
[0088] A JWS represents content or claims of a JWT that is secured
with one or more digital signatures or Message Authentication Codes
(MACs) using JSON-based data structures. Thus, JWS provides the
capability for a receiving party of an encrypted message or the
like to verify a creator of the message.
[0089] A JWE represents encrypted content of a JWT also using
JSON-based data structures. Applying JWE to encrypt JSON content
provides the capability to allow or the intended recipient to
decrypt and read the content.
[0090] Accordingly, the blocklet protocol stack provides a standard
access control mechanism for devices using data structures in the
JOSE stack including JWTs and JWKs, which may be encrypted using at
least one of JWS and JWE or the like. In addition to providing
access control of a device between any two parties, there is
another higher level activity is enabled by blocklet protocol,
which is contractual enforcement between a device using blocklet
protocols and another entity without intervention of an outside
controlling server and/or central authority.
[0091] Generally, access control in accordance with blocklet
protocols define parties, for example, other devices allowed to
communicate with this device, and contractual enforcement defines
under what conditions can those allowed to communicate with this
device do so and providing a cryptographically secure method for
doing so. The differences between these concepts are subtle but
important distinctions, and blocklet protocols handle both of these
concepts.
[0092] Traditionally, access control was typically handled by the
concept of an Access Control List (ACL), as discussed above, which
simply was a centrally-controlled list of other entities that were
allowed, or blocked, from accessing the particular resource (e.g.,
device). However, since DIST aims to offer both access control and
contractual enforcement in a single protocol (e.g., Blocklet), DIST
does so in a more sophisticated and autonomous way than just using
an ACL.
[0093] Significantly, Blocklet protocols add to the traditional
access control approach using ACL in the way of defining price and
receipts. Because DIST includes a first-class term for value
transfer, access control can now include a price at which
particular access to a device implementing blocklet protocol is
available, and can control access of the device if the appropriate
price is not paid. Price is then a validation term that must be
validated in an interaction between the device and another party in
order to grant access to one or more resources associated with the
device.
[0094] There are several ways to define the conditions under which
a device may be accessed. In some embodiments, a first type of
condition under which a device can be accessed includes on a
time-basis, where a third-party would gain access to a device over
a certain time duration. A time-basis access, in some embodiments,
could be granted at no cost or value exchange to select groups of
external parties based on one or more predetermined factors. In a
preferred embodiment, price is added to the access control terms,
or otherwise, recognized under DIST protocols as one of the
contractual terms. If price is added to the access control terms,
then additional access control is possible, such as access by
monthly payment for use of a device, a per-day contract, or an
annual contract. In the time-basis mode, the set of functionality
sold by the device is on a time-limited basis. The durations and
price for the contract are flexible for a set of functionality. The
time-basis mode is possible using only the blocklet protocol.
[0095] Additionally, and/or alternatively, a second type of
condition under which a device implementing blocklet protocol could
be accessed includes on a use-basis, where a customer would pay per
use for a device resource. This could be a payment for a given
sensor reading, or to actuate a machine that the device is operably
connected to or operably in communication with. In the use-basis
mode, there is a set of functionality that is sold per unit of
functionality provided by the device. In such embodiments, the
units of functionality and price for the contracts are flexible,
for an unlimited time. The use-basis mode is possible using both
the Blocklet and Penny Bank protocols, as described herein
below.
[0096] Accordingly, in the context of DIST protocols involving the
Blocklet protocol, a price-enabled access control list is referred
to herein as a smart contract. Though this term is used in many
different contexts within the cryptocurrency universe, the
definition provided above is strongly tied to the terms' original
definition, which is that of a self-executing, self-enforcing
contract implemented in software. Accordingly, in some or many
embodiments, the smart contract may also be a digital mirror of a
physical or orally negotiated contract and thus, is basically a
computer-readable and executable form of a real world contract.
[0097] In conventional service-based applications, permission to
interact with a device is typically granted through reference to an
access control list (ACL) such as a whitelist of privileged
entities. Although more sophisticated policy frameworks exist, in
general ACLs are relatively simplistic, allowing or disallowing
interaction in an all-or-nothing way. In any case, both ACLs and
policy frameworks are instantiated at the service or account level,
and thus require communication with a cloud-based API or other
remote centralized authority in order for the device to enforce
access decisions.
[0098] By contrast, the blocklet protocol stack leverages several
innovative solutions to enable smart contracts and autonomous
device transacting without the need for a central authority or
centrally controlled ACL. As mentioned above, this enabled smart
contract functionality includes: self-executing, self-enforcing
contracts that are implemented in software. These smart contracts
make it possible to specify the particular conditions under which a
device will interact with other entities, without reference to a
cloud service or other central authority. Such conditions can
include price or value to be exchanged, time period(s) during which
access is allowed, a per-use charge for defined functionality,
attribution for data provided, and other transaction or interaction
(e.g., contractual) terms that are required in some manner to
govern the overall interaction of the parties involved. These smart
contracts or defined set of conditional parameters governing an
interaction between entities are specified in a standardized JWT
format.
[0099] System for Implementing Blocklet
[0100] With Blocklet, there are four primary components necessary:
the digital smart contract, the physical hardware of the device,
the contract issuance/renewal capability, and the blockchain that
records the proof-of-payment receipt of the smart contract.
[0101] The smart contract itself represents a contractual agreement
between the buyer, the seller, the product capabilities offered for
sale, the contract term length, and any fees associated with the
contract. What makes this contract different from a traditional
legal contract is that it is implemented in software and generated
by the same using data structures in the JOSE stack, the smart
contract is self-executing and self-enforcing, and can be bought,
sold, renewed, revoked, and transferred in a completely digital
fashion. The actual terms within this smart contract can be nearly
anything, and is usually specific to the product and/or
service.
[0102] The smart contract's terms are specified in a standardized
format called JSON Web Token (JWT), a subset of the JavaScript
Object Signing and Encryption (JOSE) specification described at the
following links, the subject matters of which are incorporated by
reference in their entireties:
[0103] JSON Web Signature:
https://datatracker.ietf.org/doc/rfc7515/
[0104] JSON Web Encryption:
https://datatracker.ietf.org/doc/rfc7516/
[0105] JSON Web Key: https://datatracker.ietf.org/doc/rfc7517/
[0106] JSON Web Algorithm:
https://datatracker.ietf.org/doc/rfc7518/
[0107] JSON Web Token:
https://datatracker.ietf.org/doc/rfc7519/
[0108] This smart contract typically resides directly on the
DIST-capable hardware device in a secure storage area.
[0109] The DIST-capable physical hardware is the actual electronic
circuit board module that contains the DIST stack, and physically
controls the capabilities and features of the product as well as
handles the secure storage of the contract. It often includes
wireless communication for a completely standalone decentralized
connectivity solution for a product, and to receive smart contracts
over the air wirelessly.
[0110] As shown in FIG. 1, a schematic representation 100 is
illustrated of a system environment for implementing a transaction
involving one or more devices implementing Blocklet protocols.
Specifically, the system environment of FIG. 1 includes an
autonomous transaction device 110, a transacting party 120, a
network 130, a block chain ledger 140, and a provisioning device
150.
[0111] The autonomous transacting device 110, as shown in more
detail in FIG. 2, of system 100 may be any type of device and/or
software implemented on hardware of a device with capabilities of
self-enforcing one or more conditions and/or terms of a digital
smart contract 150 residing on a memory 112 of the autonomous
transacting device 110. Accordingly, the autonomous transacting
device 110 is a principally independent actor from a central
authority including any central server authority and including
manufacturers of the autonomous transacting device 110. That is,
the autonomous transacting device 110 is able to manage all of its
operations, transactions, access controls, transactions with other
devices and entities, an operational control of the device without
intervention of a central authority outside of the physical device.
Thus, the autonomous transacting device retains full control and
complete privacy at the autonomous transacting device, itself, when
in use and in operation.
[0112] As shown in FIG. 2, the autonomous transacting device
comprises one or more computer processors 111 (or a main processor
111), a memory 112, a communication interface 113. In one
variation, each autonomous device includes a microcontroller 114
having a small computer on a single integrated circuit containing a
processor core, memory, and programmable input/output peripherals.
The microcontroller 114, in some embodiments, is used in lieu of
the one or more computer processors 111 and in other embodiments,
the microcontroller is used in conjunction with the one or more
computer processors 111. Additionally, and/or alternatively, each
autonomous device of the plurality of nodes 110 includes a
cryptographic coprocessor 115 which is a hardware security module
or component which provides high security and high-throughput
cryptographic subsystems and a crypto-accelerator chip 116, which
may be integrated with the cryptographic coprocessor 115. The
autonomous transacting device may also include a modulator 117, an
oscillator 118, a timer/clock 119, and a power supply 120.
[0113] The autonomous transacting device 110 of FIG. 2 may also
include traditional elements of a device configured for radio
communication at the communication interface 113. Thus, the
communication interface 113 of node 110 of a preferred embodiment
includes a radio frequency (RF) scanner 121, RF transmitter 122, RF
receiver 123, RF tuner 124, an antenna 125, and a RF amplifier
126.
[0114] The memory 112 of the autonomous transacting device 110 in a
preferred embodiment includes one or more computer-executable
instructions and/or software applications with computer code for
executing the functionality and protocols of DIST including
blocklet and penny bank protocols and any other functionality or
protocols associated therewith, which are described herein required
for secure and private communications by and between each of the
autonomous transacting device and another party.
[0115] The cryptographic coprocessor 115 of the autonomous device
110 is configured to implement various cryptographic processes
including generating, managing, and storing cryptography keys and
encrypting and decrypting cryptographically secured communications.
Specifically, each autonomous device using the cryptographic
coprocessor 115 is able to generate private/public cryptography key
pairs that can be used to cryptographically secure communication
links and sessions between the device 110 and another party.
[0116] The autonomous transacting device 110 may be any type of
device, which may be coupled with one or more machines,
instruments, components, and/or real world operational devices or
elements to sense inputs and/or outputs thereof, to perform
actuation operations of one or more components thereof, to perform
transactions on behalf of the element or device to which the
autonomous device is coupled, and the like. For example, in some
embodiments, the autonomous device is a sensor integrated onto a
circuit board having cryptographic chips thereon that is able to
obtain readings and other information relating to or about one or
more devices to which the sensor is operably coupled and/or obtain
readings about the environment of the one or more devices.
Additionally, and/or alternatively, the autonomous device 110 may
be an actuator that performs and/or controls one or more actuation
operations of a device to which the actuator is a component and/or
is operably coupled to. In yet another example, the autonomous
device may be a transaction device which brokers transactions on
behalf of the device to which it is operably coupled and/or forms a
component thereof. The transaction may include an exchange of value
for a good, service, or other product offered to the autonomous
device or the device to which the autonomous device is coupled. In
such example, the autonomous device acting as a transaction device
is able to negotiate with other devices and/or other autonomous
devices to obtain resources for itself and the device to which it
is coupled or provide resources from the device to which it is
coupled for a negotiated value or the like from another device or
party.
[0117] The communication network 130 of system 100 may be any type
of communication network that is useable by the parties of a
transaction involving the autonomous device no. The communication
network 130 of the system 100 is preferably used only when the
autonomous device no and an another entity involved in a
transaction are not able to establish communication using a
decentralized communication means or method that does not rely on a
centrally controlled and/or managed communication scheme, such as
the Internet. For instance, if the autonomous device 110 and a
transacting party 120 cannot established a short-ranged radio
frequency communication or similar means for completing a
transaction, the parties can rely on the communication network 130,
as a backup communication network from establishing a proper
communication channel or the like for completing the transaction or
implementing an interaction.
[0118] As mentioned above, the communication network 130 may be any
type or kind of network that uses the Internet (e.g., GAN), WAN,
LAN, or other centralized communication network architectures to
facilitate communications between two or more parties including
transmitting and receiving information there between.
[0119] The blockchain ledger 140 is a distributed database that
maintains a continuously growing list of records called blocks
secured from tampering and revision. Each block contains a
timestamp and a link to a previous block. The block chain ledger
140 may be a private or a public ledger.
[0120] The configuration device 150 of a preferred embodiment is
configured to be used as a trusted third party for provisioning the
autonomous device no with a prime contract, one or more smart
digital contracts, shared secrets used in cryptography and as an
initialization and/or generally, a provisioning server for an
autonomous device; however, it shall be noted that once in
operation, an autonomous device operates independently of the
configuration device 150 and do not rely on the configuration
device 150 for access and/or operational control support or
management. The stateless configuration server is preferably a
management server which may be used in a device/node deployment
process. For example, the configuration device 150 in a
provisioning process is able to generate private/public cryptograph
key pairs and provision the autonomous device no with a public key
pair defining who and/or which devices/nodes the provisioned device
can trust. The prime contract that is provisioned onto the
autonomous device governs the contractual relation between the
acquirer (e.g., buyer) of the autonomous device 110 and the
provider (e.g., manufacturer). While the prime contract may be a
smart digital contract, the prime contract governs all subsequent
smart digital contracts provided by the autonomous device either
between the acquirer and the provider and also, between the
acquirer and a subsequent purchaser of one or more services and/or
goods provided by the autonomous device.
[0121] The autonomous devices/nodes can be provisioned online or
offline. In offline provisioning, it is possible to provision the
devices at initialization or at a time of manufacturing. Thus,
online configuration through a communication network is not
necessarily required; however, in some embodiments, when renewing a
digital smart contract or when it is required to provision the
autonomous device remotely, the configuration device 150 may be a
mobile terminal or remote terminal that can wirelessly communicate
with the autonomous device over the Internet or the like to provide
any provisioning downloads and the like.
[0122] It should be understood that in a transaction involving the
autonomous transacting device 110, the establishment of a
cryptographic communication and facilitating a transaction with
another party can be purely performed offline and without an
outside accessible network (e.g., LAN, WAN, GAN, etc.) or central
authority (e.g., a central/management server). The rationale for
configuring the autonomous transacting device 110 to perform
cryptographic functions without an area network or central
authority is to reduce, if not, eliminate any requirements that the
autonomous transacting device 110 will require intervention or
assistance from an outside central authority, which may be used to
compromise the autonomous transacting device 110, thereby
eliminating the need for a central authority or area network
enhances the autonomous nature of the autonomous transacting device
no.
[0123] As shown in FIG. 3, a process flow of a method 300 is
provided for initializing an autonomous transacting device using
blocklet protocols. At step 310, one or more conditions and/or
contractual terms are identified and defined for a digital smart
contract using one or more compact data structures. At step 320, a
provisioning device (e.g., provisioning server) provisions the
autonomous device with the digital smart contract. At step 330, the
conditions and/or terms of the smart contract are provided to
cryptographic-based ledger (e.g., blockchain).
[0124] At step 310, one or more digital smart contracts are
identified and defined. Specifically, a manufacturer and/or a
provider of a device having blocklet protocol modules or service
using one or more blocklet protocols determines and/or generates
the one or more terms for providing a performance of a service
and/or provisioning of one or more goods in accordance with the
digital smart contract to be imprinted on the device and/or
incorporated into a service. In some embodiments, the terms of the
digital smart contract are negotiated between the manufacturer and
an entity that will offer the services and/or goods of autonomous
transacting device.
[0125] Once the terms of the digital smart contract are identified,
the one or more terms of the digital smart contract are used to
define one or more JWTs (e.g., one or more contracts) and JWKs
(e.g., one or more cryptographic keys).
[0126] Defining the one or more JWTs include one or more of the
following steps, which can be done in any order where there are no
dependencies between the inputs and outputs of the steps. However,
if there are dependencies in the claims, then the order of defining
or creating the one or more JWTs must be followed. First step in
defining a JWT includes creating a JWT claims set containing the
desired claims, as shown FIG. 3A. FIG. 3A illustrates a schematic
representation of a JWT including a claim set. In this case, the
performance steps and value identified and/or negotiated terms for
the digital smart contract would be converted into one or more
claim statements in the JWT(s).
[0127] The JWT illustrated in FIG. 3A includes one or more claim
names including "iss", "sub", "aud", "exp", "nbf", "iat", and "jti"
where "iss" identifies the issuer of the contract, "sub" identifies
the subject of the contract, "aud" identifies the audience of the
contract, "exp" identifies the expiration of the contract, "nbf"
indicates a not before time, "iat" indicates issued at, and "jti"
indicates the JWT identifier.
[0128] As a second step, let the message be the octets of the UTF-8
representation of the JWT claims set. Thirdly, define a JOSE Header
containing the desired set of header parameters including the
cryptographic operations to be performed against the message and
any other information for processing the claims. Accordingly, the
JOSE Header must conform to either the JWS or JWE specification.
FIG. 3B illustrates a schematic representation of a JOSE Header. As
a final step, the message (e.g., the payload including the claims)
is digitally signed and then encrypted, in that order.
[0129] FIG. 3B includes contains a "cty" (i.e., content type)
value, which must be defined as a JWT.
[0130] Defining one or more JWKs to be included in the one or more
JWTs includes the following steps. FIG. 3C provides an example JWK
in which the members of the JWK represent properties of the key. In
such case, the JWK declares that the key is an Elliptic Curve key
(kty), that is used with P-256 Elliptic Curve (cry), and its x and
y coordinates are the base64url-encoded values shown. A key
identifier (kid) is also provided for the key. Accordingly, the
"kty" parameter identifies the cryptographic algorithm family used
with the key, such as "EC" but could also be "RSA", and is used to
match a specific key. The "use" (e.g., public key use) parameter
identifies the intended use of the public key. The "use" parameter
is employed to indicate whether a public key is used for encrypting
data or verifying the signature on data.
[0131] At step 320, the autonomous transacting device is
provisioned with the digital smart contract. In some embodiments,
the autonomous transacting device is provisioned with the digital
smart contract at the manufacturer of the autonomous transaction
device. Provisioning is typically performed in this manner when it
would be difficult to otherwise provision the autonomous
transacting device remotely due to connectivity concerns when the
device is implemented in remote areas.
[0132] The contract issuance software for provisioning the
autonomous transacting device usually resides on a provisioning
device or server separate from the autonomous transacting device.
This contract issuance software securely generates and renews
contracts, and cryptographically signs them before making them
available to the buyer of the autonomous transacting device. This
system is typically integrated into the manufacturer's web site or
mobile application, and may be made available to buyers by the
manufacturer in a number of ways including via the manufacturer's
web site. However, the contract generation of this software is part
of the Blocklet protocol specification, and as such, any Blocklet
contract issuance protocols will work to generate a new contract to
be presented.
[0133] Additionally, and/or alternatively, the autonomous
transacting device may be provisioned with the digital smart
contract remotely using a mobile computing device or terminal or
other computing device that is able to interact with the
cryptographic circuit board of the autonomous transaction device to
download the digital smart contract thereon and cryptographically
store the digital smart contract. This method of provisioning the
autonomous transacting device with the digital smart contract is
preferred when the terms of the digital smart contract are
negotiated between and a vendor or the like. Additionally, this
method of provisioning the autonomous transaction device is
preferred for autonomous devices which are currently in the field
(e.g., external to the manufacturer) and a contractual renewal is
required or a new digital smart contract is provided with new
terms.
[0134] At step 330, the digital smart contract and associated terms
are provided to a blockchain ledger. In particular, the digital
smart contract is provided to the blockchain together with details
for identifying the autonomous transacting device. By storing this
information at the blockchain ledger, enables the transaction
involving the autonomous transacting device to be verified without
the use of online central authority, such as a payment system
server or the like. Accordingly, in this manner, cryptocurrency may
be used as a form of payment to a cryptocurrency address associated
with the autonomous transaction device where the validity and
verification of the cryptocurrency payment may be performed solely
between the transacting parties.
[0135] Thus, the inclusion of a digital smart contract's
cryptographic fingerprint and metadata to a blockchain gives a
completely decentralized but verifiable assignment of contract
ownership, assignment, and payment. The manufacturer or provider of
the autonomous device can verify by whom a particular smart digital
contract has been paid for by checking the transaction output of
the particular contract receipt record within the blockchain. The
buyer can verify that its smart digital contract is valid and
current by checking the same record in the blockchain.
[0136] It shall be clarified that in order to truly realize a
decentralized ecosystem, once an autonomous transacting device is
provisioned once, it must always be possible to ensure that
device's contract can be paid for and renewed through at least one
decentralized method. The opcode logic of the transaction of a
blockchain must make available the ability to continue to pay for a
device's contract renewal through that blockchain itself. The
manufacturer can also provide for centralized contract issuance and
renewal using their own contract issuance software, but to ensure
true decentralization, once a contract is issued once, the device
must have the ability to be renewed by the cryptocurrency of the
blockchain to which it is assigned. In the case of Bitcoin, this
logic is added to the P2SH script of the transaction assigning the
contract.
[0137] Primarily, this is so that if a device outlives the company
who manufactured the device, the buyer of that device can continue
to use--and pay for--that device for as long as the device is
operational, and prevents planned obsolescence. Secondarily,
ensuring that device contracts can be renewed digitally gives
devices the ability to pay the contracts of other devices
themselves. This feature maximizes the idea of device autonomy,
which is a primary objective of the entire DIST protocol stack.
[0138] It should also be noted that more than one contract can be
assigned to a particular autonomous transacting device. This allows
the decoupling of the device from the number and type of buyers and
sellers of the services that the particular device provides. For
instance, there could exist one contract on a device that sells its
temperature data for a given price. There could exist another
contract on that same device that sells humidity data for another
price. Each of those contracts can be open--meaning anyone can
transact with them if the proper amount is paid. Or they can be
closed, where transactions are only allowed to a given whitelist of
buyers. And any number of customers can agree to any contract terms
that they have access to. So the particular device may have 10
different temperature customers, and 25 different humidity
customers, utilizing the same two contracts, and all sold by the
same physical device.
[0139] Digital smart contracts can also be combined, where two
sellers may decide to chain their contracts together. In this
situation, all chained contractual terms must be satisfied in order
for the transaction to complete. These are called chained
contracts. This allows situations where an OEM provides a given
module to a sensor device, and the device's manufacturer decides to
sell access to their device using Blocklet protocols. In this
situation, the OEM and manufacturer would each create a contract,
and chain them together with some percentage split agreed upon
between the both of them. When the payment for the device is
received from the buyer, both contracts must verify a payment
receipt in order for the device to sell the features. This could
also be considered a form of software or hardware licensing that's
built right into the purchase of the device's functionality itself,
without having to set up licensing agreements between the OEM and
manufacturer in the traditional way with paper contracts.
[0140] As shown in FIG. 4, a process flow of method 400 illustrates
one or more steps for facilitating a transaction between an
autonomous transacting device and another party in accordance with
blocklet protocols. At step 410, a transaction request is received
at the autonomous transacting device. At step 420, the autonomous
transacting device evaluates the transaction request against the
one or more conditions and/or terms in the digital smart contract.
At step 430, the autonomous transacting device confirms that price
and/or value is provided by the party initiating the transaction
request. At step 440, the autonomous transacting device provides
one or more resources and/or initiates the performance of one or
more services in accordance with the transaction request.
[0141] At step 410, an initiating party makes a request for a
transaction with the autonomous transacting device. The initiating
party may be any type of entity including a business organization,
another device that is autonomous or otherwise, a person having a
device with transacting capabilities, and the like. The transaction
request of a preferred embodiment may include a request for access,
a grant, an extension (e.g., renewal), a request for information
(e.g., sensor readings), request for routing assistance,
subcontracts (e.g., JWTs with equal or lesser scope that parent
smart contract) a request for performance of some work or service
by the autonomous device, and/or a request to perform a task or
provide a service in accordance with the capabilities of the
autonomous transacting device. It shall be understood that the
transaction request shall not be limited to the above examples;
rather, the transaction request may include any type of request
that is consistent with the one or more capabilities and/or
resources available to the autonomous transacting device.
[0142] At step 420, the autonomous transacting device generates an
addendum based on the transaction request. In particular, based on
the blocklet protocols, the autonomous transacting device converts
the transaction request into a format that is executable in
accordance with the JOSE protocols. Therefore, the addendum is
dynamically generated by the autonomous transacting device and in a
JWT format and is used to bind the parent smart digital contract.
The generated addendum must be signed by a JWK or JWT of the prime
smart digital contract hosted on the autonomous transacting device
and also must be signed with economic value (e.g., cryptocurrency).
Cryptographically signing the addendum with both a JWT or JWK of
the prime contract and cryptocurrency provided by the initiating
party authorizes the addendum.
[0143] The signature of the JWT or JWK of digital smart contract
(e.g., prime contract) of the autonomous transacting device
confirms that the addendum makes a valid transaction request that
the autonomous device can perform. In particular, the autonomous
transacting device compares the transaction request (e.g., terms)
of the addendum to the one or more claims in the exhibits of the
parent smart contract of the autonomous device. In such a case, the
exhibit is used as a reference validation for the performance to be
made under the parent smart digital contract. The exhibits in the
parent smart contract lists as claims actions performable with an
addendum. Accordingly, following the steps in the claims of the
exhibits of the parent smart digital contract allows for the
validation of digital contract formed by the addendum together with
the smart digital contract of the autonomous device. Accordingly,
one or more of the claims in the smart digital contract may require
that the addendum is signed by the autonomous transacting device,
itself, as well as a second signature of economic value. By
attributing a signature having economic value (e.g.,
cryptocurrency) by the initiating party allows the transaction to
be completed without intervention of any outside party and/or
device, such as a payment system, and additionally confirms that
consideration has been paid to bind the performance to be made
under the parent smart digital contract.
[0144] In some embodiments, the one or more claims of the exhibit
of the parent digital smart contract may not necessarily require a
second signature having economic value; rather, it is possible that
the second cryptographic signature merely identifies the initiating
party, which in some cases is sufficient to bind the digital smart
contract and render a performance by the autonomous device in
accordance with the transaction request in a validated
addendum.
[0145] At step 430, the autonomous transacting device confirms the
economic value and/or price is provided and further, confirms the
value of the signature having economic value. In embodiments where
the signature having economic value is a cryptocurrency signature,
the autonomous transacting device confirms that the value of the
cryptocurrency using the blockchain. In such embodiments, the
autonomous transacting device implements a simplified payment
verification, which is discussed in more detail below, using only
required portions of the blockchain needed to confirm that the
value of the cryptocurrency exists and that there has not been any
double spend of said cryptocurrency value. However, it shall be
understood that, if capable, the autonomous transacting device may
use the full blockchain to confirm the value of the cryptocurrency
signature. This may be helpful in some case when the initiating
party of the transaction is unknown, not trusted, or the value of
the cryptocurrency exchange is high.
[0146] Accordingly, at step 440, once the autonomous transacting
device has validated the addendum and has also verified the value
of the cryptocurrency signature, the autonomous transacting device
performs in accordance with the terms of the contract bound by the
addendum. In such embodiments, the autonomous provides one or more
resources and/or initiates performance of one or more services in
accordance with the transaction request.
[0147] As an example, often when discussing the ability to buy and
sell with connected devices, it's assumed that what's for sale is
the data from the sensors on the connected device itself, or
perhaps access to the machine that the connected device is attached
to. However, connected devices that create large-scale mesh
networks can also sell raw connectivity as well. Especially when
these devices bring network communication to areas where it's
difficult or expensive to otherwise communicate wirelessly.
Long-range communication becomes another sellable aspect of the
device.
[0148] Consider a company that makes a connected device that
monitors utility power poles. Perhaps the autonomous device is
monitoring the status of the pole itself, or the power transfer
efficiency of the electricity moving through the cables attached.
For the sake of this example, it is assumed that these power pole
monitoring devices are running an implementation of the DIST
stack.
[0149] Since DIST allows for multiple types of functionality to be
sold to multiple buyers, it's a simple extension of the same
principles to sell general network connectivity in addition to the
sensor data monitoring the power poles. So while power utility
company may be purchasing the monitoring of power pole health
through the devices deployed across all the power poles in a given
area, it's possible that others who need general network
connectivity could purchase it as well--not knowing or caring that
the devices that will transport their messages also happen to be
monitoring power poles.
[0150] Perhaps a trucking company is moving to automated telemetry
for their fleet, and the semi-trucks are outfitted with their own
telemetry system running a DIST implementation. And it so happens
that this trucking company has routes that traverse very rural
areas--areas where cellular access is non-existent or spotty at
best. The semi truck's telemetry system would discover a DIST
network provider within range of it on one of these remote
roads--the network provider being the power pole monitoring
system.
[0151] Once discovered, a price can be negotiated and agreed upon
between the truck's telemetry system and the power pole device, to
send a telemetry system message on behalf of the trucking company,
routed back hundreds of miles to an Internet backhaul connection,
and directly delivered to the trucking company's back-office
system. Since Telehash provides for multiple separate sockets of
encrypted communication on a given node, the power pole device acts
as a tiny network router that can have multiple clients connected
to it, routing data to multiple other destinations on behalf of
each client--and paid for with different prices.
[0152] It shall also be noted that the power utility company cannot
see any data sent on behalf of the trucking company, nor can the
trucking company see any data sent on behalf of the power utility
company. Just as multiple parties use cellular towers to gain
connectivity and privacy, one party of a cellular tower cannot see
or intercept data sent on behalf of another party.
[0153] Blocklet Receipts
[0154] As shown in FIG. 5, a process flow of a method 500
illustrates providing a cryptocurrency receipt for a transaction
involving an autonomous transacting device. Specifically, method
500 uses raw transaction information and blockchain information to
verify an exchange of cryptocurrency value and provide the
autonomous transacting device a cryptocurrency receipt as
verification that the cryptocurrency was actually paid as
consideration for resources and/or services provided by the
device.
[0155] A cryptocurrency-receipt is defined as a
cryptocurrency-based signature that must be presented to the
autonomous transacting device that indicates that the
cryptocurrency-based signature has a verified value exchange
required by the digital smart contract. The verification of value
exchange is provided to the autonomous transacting device which
hosts the digital smart contract as a cryptocurrency receipt. The
cryptocurrency receipt, in some embodiments, includes: 1) the raw
transaction and information, 2) block headers for the transaction,
3) block header after the transaction that confirms the
transaction, and 4) the portion of the Merkle tree necessary for
performing the verification of value.
[0156] Presenting the autonomous transacting device with the
crypto-receipt authorizes the addendum that is involved in the
transaction request. Effectively, the cryptocurrency receipt acts
as a cryptographic signature that the device recognizes as an
authorization to then perform the addendum. The cryptocurrency
receipt of a preferred embodiment verifies the value, itself, in
the value exchange. That is, the device performs a cryptocurrency
value verification that includes identifying an amount of
cryptocurrency required for the requested transaction, identifying
one or more cryptocurrency keys exchanged in the transaction,
verifying with blockchain ledger associated with the
transaction.
[0157] While it is preferable to verify a cryptocurrency value
exchange using the full blockchain, such verification would be
difficult to perform because the autonomous transacting device is
most likely a low-memory and low-compute power device (e.g.,
constrained autonomous device), which typically lacks sufficient
computing resources to perform such complex computations according
to its existing resources. Especially, in light of the fact that
the autonomous transacting device operates without the assistance
of an external central authority, such as a central server or the
like, which typically could perform a full verification of
cryptocurrency value exchange if provided with the full
blockchain.
[0158] Thus, in lieu of performing cryptocurrency value exchange
verification using the full blockchain, the autonomous transacting
device of a preferred embodiment performs a simple payment
verification (SPV) using only limited portions of the blockchain
associated with the transaction.
[0159] At step 510, upon receipt of a digitally signed addendum,
the autonomous transaction device identifies the cryptocurrency
value required to be exchanged for performing the addendum.
Specifically, in some embodiments, the autonomous transacting
device identifies the transaction request of an addendum generated
to the device and compares the transaction request of the addendum
to an exhibit (e.g., JWK) of the digital smart contract (e.g.,
JWT). In such embodiments, the autonomous device can determine a
required cryptocurrency value to be exchanged for performing the
transaction request of the addendum. That is, in most
circumstances, the requested action, performance, and/or resource
in the transaction request of the addendum should be associated
with a cryptocurrency value in the digital smart contract, that if
provided by the party initiating the transaction request, should be
sufficient to verify the addendum and therefore, allow the
autonomous transacting device to perform in accordance with the
terms of the addendum.
[0160] At step 520, once the cryptocurrency value for performing
the addendum by the autonomous transacting device is identified or
digitally signed to the addendum, the autonomous transacting device
implements a simple payment verification process in order to verify
that the actual cryptocurrency value required for the autonomous
device to execute the addendum has been transferred.
[0161] The simple payment verification process, in such
embodiments, is used to allow a device to operate without storing
the full blockchain. Accordingly, the autonomous transacting device
downloads only the block headers and do not download the
transactions included in each block. Thus, the resulting chain of
blocks, without transactions, is 1,000 times smaller than the full
blockchain. With this limited blockchain information, the
autonomous transacting device, in some embodiments, cannot
construct a full picture of all the cryptocurrency available for
spending by the party making the transaction request because the
device does not know about all the transactions on the network.
Accordingly, since the autonomous device only has a limited amount
of blockchain information for verifying the exchange of the
cryptocurrency value, a slightly different method for verification
is required that sometimes relies on peers to provide to provide
partial views of relevant parts of the blockchain on demand.
[0162] Regarding SPV, SPV verifies transaction by reference to
their depth in the blockchain instead of their height. Whereas a
full blockchain node will construct a fully verified chain of
thousands of blocks and transaction reaching down the blockchain
(e.g., back in time) all the way to the genesis block, an SPV node
will verify the chain of all blocks (but not all transaction) and
link that chain to the transaction of interest.
[0163] Specifically, using SPV the autonomous transacting device
will establish a link between the transaction and the block that
contains it, using a merkle path. Then, the device waits for blocks
following the transaction block piled on top of the block
containing the transaction and verifies is by establishing its
depth under the subsequent blocks. The fact that other nodes on the
blockchain network accepted the transaction block and did the
necessary work to produce subsequent blocks on top of the
transaction block is proof, by proxy, that the transaction was not
a double-spend.
[0164] Thus, using SPV, the device establishes the existence of a
transaction in a block by requesting a merkle path (e.g., part of a
Merkle tree) proof and by validating the proof of work in the chain
of blocks.
[0165] At step 530, once the simplified payment is completed, the
autonomous transaction device bundles together as a cryptocurrency
receipt two or more of the raw transaction, the transaction block
header, subsequent block headers (e.g., 6 or so blocks), and the
merkle tree path use to verify proof of work. The cryptocurrency
receipt is store at the autonomous transacting device and is also
used as an additional signature or at least, an additional
verification added to an addendum.
[0166] Pennybank Overview
[0167] Once an autonomous transacting device has the capability to
discover other participants, establish a secure communication
channel with them (e.g., using Telehash and TMesh protocols), and
decide to trust access from that device through Blocklet protocols,
there needs to be a way for a device to buy and sell very small
amounts of value between each other directly. Penny Bank protocols
sets out to solve this last problem--that of frictionless
micro-transaction capability directly between devices in a very
lightweight way, and not requiring immediate Internet connectivity
to do so or a traditional payment system, which includes some type
of central authority to process the payment.
[0168] Rather, Penny Bank is a mechanism for placing some amount of
value such as Bitcoin or other cryptocurrency on hold between two
parties without involving another third party, such that those two
parties can then exchange smaller amounts of value over time
independently. This requires that one or both parties be willing to
source that amount of value and have it locked in an escrow between
them, so that only through cooperation can it be unlocked
again.
[0169] Penny Bank protocols implement a zero-knowledge proof in
order to allow parties to pay each other without revealing any
information other than proving to each other that their payment is
valid. This mechanism also allows two parties to exchange payment
directly with each other without having Internet connectivity at
the time of transfer or a central transacting authority, such as a
central server, to reconcile the transaction. At any time during
the ongoing transactions between the two parties, either party that
has Internet access and wishes to do so or otherwise, has access to
the blockchain, can request to reconcile their balances and value
will be balanced between the two parties.
[0170] Accordingly, in cryptography, zero-knowledge proof is a
method by which one party (e.g., the prover) can prove to another
party, such as a verifier (e.g., blockchain) that a given statement
is true, without conveying any information apart from the fact that
the statement is indeed true.
[0171] If proving the statement requires knowledge of some secret
information on the part of the prover, the definition implies that
the verifier will not be able to prove the statement in turn to
anyone else, since the verifier does not possess the secret
information. Notice that the statement being proved must include
the assertion that the prover has such knowledge (otherwise, the
statement would not be proved in zero-knowledge, since at the end
of the protocol the verifier would gain the additional information
that the prover has knowledge of the required secret information).
If the statement consists only of the fact that the prover
possesses the secret information, it is a special case known as
zero-knowledge proof of knowledge, and it nicely illustrates the
essence of the notion of zero-knowledge proofs: proving that one
has knowledge of certain information is trivial if one is allowed
to simply reveal that information; the challenge is proving that
one has such knowledge without revealing the secret information or
anything else.
[0172] For zero-knowledge proofs of knowledge, the protocol must
necessarily require interactive input from the verifier, usually in
the form of a challenge or challenges such that the responses from
the prover will convince the verifier if and only if the statement
is true (i.e., if the prover does have the claimed knowledge). This
is clearly the case, since otherwise the verifier could record the
execution of the protocol and replay it to someone else: if this
were accepted by the new party as proof that the replaying party
knows the secret information, then the new party's acceptance is
either justified--the replayer does know the secret
information--which means that the protocol leaks knowledge and is
not zero-knowledge, or it is spurious--i.e. leads to a party
accepting someone's proof of knowledge who does not actually
possess it.
[0173] The Penny Bank protocols, which implements zero-knowledge
proof, are particularly helpful with microtransactions and/or
micropayments in which the transaction costs are high relative to
the overall value of the transaction amounts. In a traditional
blockchain transaction involving cryptocurrency, the cryptographic
costs for creating a transaction for each of the microtransactions
is high. For instance, if two parties contemplated ten
microtransactions, then each of the ten microtransactions would
require a separate cryptographic transaction to be created in the
blockchain therefore multiplying the cost of transacting between
the two parties by ten. However, using Penny Bank, the
cryptographic costs are significantly reduced because only a
limited number of cryptographic transactions are necessary. For
instance, the number of transaction incurring significant
cryptographic expense due to the use of block chain may be limited
to as little as two transactions.
[0174] In many common micro-transaction scenarios, there is some
prior trust or reputation with one of the parties (such as service
providers) where having some funds locked in an escrow with them is
not very risky. When there is limited or no trust, then the locked
value should be small to reduce the risk, the only side-effect
being a larger percentage of fees on the transaction to fund
it.
[0175] In particular, as shown in FIG. 6, the process flow of
method 600 implementing the Penny Bank protocols for facilitating
microtransactions and/or micropayments.
[0176] At step 610, a sidechain for the microtransactions is
created. A sidechain is separate from the main blockchain but would
be interoperable to allow for a transfer of cryptocurrency assets
between the sidechain and the main blockchain. Accordingly, the
sidechain is a blockchain that runs in parallel to the main
blockchain which extend functionality through interoperable
blockchain networks allowing decentralized way of
transferring/synchronizing cryptocurrency token between the two
chains.
[0177] Sidechains are decentralized like the blockchain. The
sidechain comprises a set of secrets for incremental performance of
an overall transaction or for each microtransaction in a set of
microtransactions between two parties.
[0178] At step 620, a set of shared secrets or key pairs are
generated prior to performing the microtransactions and prior to
establishing an escrow at the main blockchain. Each key in the pair
is split between the transacting parties and can be exchanged in
order to complete one microtransaction of a set of
microtransactions. The set of key pairs provided to the transacting
parties may be based on simple hashing (e.g., using 256 hashing) or
similar method thereby reducing the transaction costs
significantly.
[0179] At step 630, the parties to the transactions negotiate a
simple escrow where the party making the transactions request sets
aside funds for the transactions (e.g., a series of
microtransactions), which is guaranteed to be available to the two
parties. The cryptographic escrow is created at the main blockchain
and only when both parties cryptographically sign the escrow can
the funds of the escrow be released. Accordingly, all of the key
pairs or shared secrets between the parties are provided to the
escrow at the blockchain. In this way, the blockchain acting as a
third party verifier can implement zero-knowledge proofing if one
or both of the parties want only a portion of the funds set aside
in the escrow released.
[0180] Thus, if either party stops cooperating for any reason
including malfunction and/or intentional non-cooperation, then the
funds at that point remain frozen until cooperation begins again or
the party seeking to have the funds released from escrow is able to
prove that at least some of the microtransactions have been
completed thereby causing the blockchain to release spent or
unspent funds.
[0181] As mentioned above, in addition to locking the funds in the
escrow, the parties provide all of the shared secrets generated at
step 710 for each of the microtransactions into the cryptographic
escrow. Accordingly, with all of the generated shared secrets
stored in the cryptographic escrow at the block chain, the block
chain can be used as a third party to verify completion of all or a
portion of the microtransactions based on the number of shared
secret pairs that have been exchanged to form the sidechain.
[0182] At step 640, the parties (e.g., the autonomous device and
the transacting party) to the transaction may exchange shared
secret pairs for each increment of a transaction that is completed
or for each microtransaction that is completed. Each exchanged
shared secret key pair creates a block in the sidechain.
[0183] At step 650, a party to the transaction requests a release
of a portion of the escrowed funds. If either of the parties ceases
their performance of the microtransactions, by either a second
transacting party (e.g., payee) failing to continue using a
resource provided by a first transacting party (e.g., payor) or by
failing to provide a resource or service requested in the
microtransactions by the second transacting, at step 740, either
party may present the sidechain to the blockchain, even if not
fully completed with all shared secrets, to release funds in
accordance with the percentage completion of the sidechain.
[0184] The blockchain in such a case would act as a third party
verifier by implementing zero-knowledge proof. The blockchain, in
such embodiment, would present a challenge to the requester of the
release of funds. In some embodiments, the challenge is based on
the one or more shared secrets or key pairs escrowed at the
blockchain. In this way, if the requester intends to prove that 50%
of the microtransactions have been completed and that 50% of the
key pairs have been exchanged, the requester could most likely
respond to a challenge from the blockchain showing that a key from
the key pair of the other party is 50% percent up the chain.
[0185] Then, the blockchain can compare the key to the key pairs
stored in escrow to the key pair exchanged in the sidechain to
determine a percentage completion of the microtransactions. In this
instance, the blockchain may confirm that the key from the other
party is 50% up the chain and would release 50% of the funds to the
payee and refund the other 50% of the funds to the payor.
[0186] The current implementation of Penny Bank currently only
focuses on the core locking mechanism and exchanges. It is possible
to add timelocks and create more complex transactions that further
reduce the risk of funds remaining locked at an escrow account
[0187] The system and methods of the preferred embodiment and
variations thereof can be embodied and/or implemented at least in
part as a machine configured to receive a computer-readable medium
storing computer-readable instructions. The instructions are
preferably executed by computer-executable components. The
computer-readable medium can be stored on any suitable
computer-readable media such as RAMs, ROMs, flash memory, EEPROMs,
optical devices (CD or DVD), hard drives, floppy drives, or any
suitable device. The computer-executable component is preferably a
general or application specific processor, but any suitable
dedicated hardware or hardware/firmware combination device can
alternatively or additionally execute the instructions.
[0188] Although omitted for conciseness, the preferred embodiments
include every combination and permutation of the various system
components and the various method processes.
[0189] As a person skilled in the art will recognize from the
previous detailed description and from the figures and claims,
modifications and changes can be made to the preferred embodiments
of the invention without departing from the scope of this invention
defined in the following claims.
* * * * *
References