├── .github └── ISSUE_TEMPLATE │ ├── bug_report.md │ ├── config.yml │ ├── documentation_needed.md │ └── feature_request.md ├── .gitignore ├── .remarkrc ├── LICENSE ├── README.md ├── executive-summary └── XYO-Executive-Summary.pdf ├── green-paper ├── XYO-Green-Paper.pdf └── XYO-Green-Paper.tex ├── red-paper └── XYO-Red-Paper.tex ├── smart-contract-audits └── Smart-Contract-Audit-XYO-Network.pdf ├── use-cases ├── UseCase_Airports.pdf ├── UseCase_Airports.tex ├── UseCase_AutomatedDrones.pdf ├── UseCase_AutomatedDrones.tex ├── UseCase_Hospitals.pdf ├── UseCase_Hospitals.tex ├── UseCase_Insurance.pdf ├── UseCase_Insurance.tex ├── UseCase_NationalSecurity.pdf ├── UseCase_NationalSecurity.tex ├── UseCase_RentalCarFacilities.pdf ├── UseCase_RentalCarFacilities.tex ├── UseCase_eCommerce.pdf └── UseCase_eCommerce.tex └── white-paper ├── PoE-White-Paper.pdf ├── XYO-White-Paper.pdf ├── XYO-White-Paper.tex └── images ├── boundwitness.png └── proofoforigin.png /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve the XYO Android SDK 4 | title: "[BUG]" 5 | labels: bug 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Observed behavior** 11 | A clear and concise description of what exactly happened. 12 | 13 | **Expected behavior** 14 | A clear and concise description of what you expected to happen. 15 | 16 | **To Reproduce** 17 | Steps to reproduce the behavior: 18 | 1. Go to '...' 19 | 2. Click on '....' 20 | 3. Scroll down to '....' 21 | 4. See error 22 | 23 | **Screenshots** 24 | If applicable, add screenshots to help explain your problem. 25 | 26 | **Smartphone (please complete the following information):** 27 | - Device: [e.g. Samsung Galaxy, Google Pixel] 28 | - OS: [e.g. Android 10] 29 | - Browser [e.g. stock browser, chrome] 30 | 31 | **Additional context** 32 | Add any other context about the problem here. 33 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled: false 2 | contact_links: 3 | - name: XYO Developer Portal 4 | url: https://developers.xyo.network/ 5 | about: XYO Foundation Developer Portal 6 | - name: XYO Foundation Site 7 | url: https://xyo.network/ 8 | about: Check out the fundamentals of our Foundation here -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/documentation_needed.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Documentation needed 3 | about: Suggest documentation that is needed 4 | title: "[DOCUMENTATION]:" 5 | labels: documentation 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Is your documentation request related to a problem? Please describe.** 11 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 12 | 13 | **Describe the documentation and format you would like** 14 | A clear and concise description of what documentation you would like to see and what type for format. 15 | Ex. Step-by-step, Paragraph explainer, screenshots, etc. 16 | 17 | **Additional context** 18 | Add any other context or screenshots about the document request here. -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for XYO SDK Android 4 | title: "[FEATURE]" 5 | labels: enhancement 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Is your feature request related to a problem? Please describe.** 11 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 12 | 13 | **Describe the solution you'd like** 14 | A clear and concise description of what you want to happen. 15 | 16 | **Describe alternatives you've considered** 17 | A clear and concise description of any alternative solutions or features you've considered. 18 | 19 | **Additional context** 20 | Add any other context or screenshots about the feature request here. This could include specific devices, android versions, etc. 21 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | 2 | *.aux 3 | *.glo 4 | *.ist 5 | *.log 6 | *.out 7 | *.synctex(busy) 8 | *.toc 9 | *.gz 10 | *.glg 11 | *.gls 12 | whitepaper/original/.DS_Store 13 | *.DS_Store 14 | .DS_Store 15 | usecases/.DS_Store 16 | whitepaper/.DS_Store 17 | whitepaper/original/.DS_Store 18 | whitepaper/XYOWhitePaper.fdb_latexmk 19 | whitepaper/XYOWhitePaper.fls 20 | whitepaper/XYOWhitePaper.glg 21 | whitepaper/XYOWhitePaper.gls 22 | whitepaper/XYOWhitePaper.glsdefs 23 | whitepaper/XYOBusinessPrimer.fdb_latexmk 24 | whitepaper/XYOBusinessPrimer.fls 25 | whitepaper/XYOBusinessPrimer.glg 26 | whitepaper/XYOBusinessPrimer.gls 27 | whitepaper/XYOBusinessPrimer.glsdefs 28 | red-paper/XYO-Red-Paper.pdf 29 | *.fls 30 | *.fdb_latexmk 31 | -------------------------------------------------------------------------------- /.remarkrc: -------------------------------------------------------------------------------- 1 | { 2 | 3 | } -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | GNU LESSER GENERAL PUBLIC LICENSE 2 | Version 3, 29 June 2007 3 | 4 | Copyright (C) 2007 Free Software Foundation, Inc. 5 | Everyone is permitted to copy and distribute verbatim copies 6 | of this license document, but changing it is not allowed. 7 | 8 | 9 | This version of the GNU Lesser General Public License incorporates 10 | the terms and conditions of version 3 of the GNU General Public 11 | License, supplemented by the additional permissions listed below. 12 | 13 | 0. Additional Definitions. 14 | 15 | As used herein, "this License" refers to version 3 of the GNU Lesser 16 | General Public License, and the "GNU GPL" refers to version 3 of the GNU 17 | General Public License. 18 | 19 | "The Library" refers to a covered work governed by this License, 20 | other than an Application or a Combined Work as defined below. 21 | 22 | An "Application" is any work that makes use of an interface provided 23 | by the Library, but which is not otherwise based on the Library. 24 | Defining a subclass of a class defined by the Library is deemed a mode 25 | of using an interface provided by the Library. 26 | 27 | A "Combined Work" is a work produced by combining or linking an 28 | Application with the Library. The particular version of the Library 29 | with which the Combined Work was made is also called the "Linked 30 | Version". 31 | 32 | The "Minimal Corresponding Source" for a Combined Work means the 33 | Corresponding Source for the Combined Work, excluding any source code 34 | for portions of the Combined Work that, considered in isolation, are 35 | based on the Application, and not on the Linked Version. 36 | 37 | The "Corresponding Application Code" for a Combined Work means the 38 | object code and/or source code for the Application, including any data 39 | and utility programs needed for reproducing the Combined Work from the 40 | Application, but excluding the System Libraries of the Combined Work. 41 | 42 | 1. Exception to Section 3 of the GNU GPL. 43 | 44 | You may convey a covered work under sections 3 and 4 of this License 45 | without being bound by section 3 of the GNU GPL. 46 | 47 | 2. Conveying Modified Versions. 48 | 49 | If you modify a copy of the Library, and, in your modifications, a 50 | facility refers to a function or data to be supplied by an Application 51 | that uses the facility (other than as an argument passed when the 52 | facility is invoked), then you may convey a copy of the modified 53 | version: 54 | 55 | a) under this License, provided that you make a good faith effort to 56 | ensure that, in the event an Application does not supply the 57 | function or data, the facility still operates, and performs 58 | whatever part of its purpose remains meaningful, or 59 | 60 | b) under the GNU GPL, with none of the additional permissions of 61 | this License applicable to that copy. 62 | 63 | 3. Object Code Incorporating Material from Library Header Files. 64 | 65 | The object code form of an Application may incorporate material from 66 | a header file that is part of the Library. You may convey such object 67 | code under terms of your choice, provided that, if the incorporated 68 | material is not limited to numerical parameters, data structure 69 | layouts and accessors, or small macros, inline functions and templates 70 | (ten or fewer lines in length), you do both of the following: 71 | 72 | a) Give prominent notice with each copy of the object code that the 73 | Library is used in it and that the Library and its use are 74 | covered by this License. 75 | 76 | b) Accompany the object code with a copy of the GNU GPL and this license 77 | document. 78 | 79 | 4. Combined Works. 80 | 81 | You may convey a Combined Work under terms of your choice that, 82 | taken together, effectively do not restrict modification of the 83 | portions of the Library contained in the Combined Work and reverse 84 | engineering for debugging such modifications, if you also do each of 85 | the following: 86 | 87 | a) Give prominent notice with each copy of the Combined Work that 88 | the Library is used in it and that the Library and its use are 89 | covered by this License. 90 | 91 | b) Accompany the Combined Work with a copy of the GNU GPL and this license 92 | document. 93 | 94 | c) For a Combined Work that displays copyright notices during 95 | execution, include the copyright notice for the Library among 96 | these notices, as well as a reference directing the user to the 97 | copies of the GNU GPL and this license document. 98 | 99 | d) Do one of the following: 100 | 101 | 0) Convey the Minimal Corresponding Source under the terms of this 102 | License, and the Corresponding Application Code in a form 103 | suitable for, and under terms that permit, the user to 104 | recombine or relink the Application with a modified version of 105 | the Linked Version to produce a modified Combined Work, in the 106 | manner specified by section 6 of the GNU GPL for conveying 107 | Corresponding Source. 108 | 109 | 1) Use a suitable shared library mechanism for linking with the 110 | Library. A suitable mechanism is one that (a) uses at run time 111 | a copy of the Library already present on the user's computer 112 | system, and (b) will operate properly with a modified version 113 | of the Library that is interface-compatible with the Linked 114 | Version. 115 | 116 | e) Provide Installation Information, but only if you would otherwise 117 | be required to provide such information under section 6 of the 118 | GNU GPL, and only to the extent that such information is 119 | necessary to install and execute a modified version of the 120 | Combined Work produced by recombining or relinking the 121 | Application with a modified version of the Linked Version. (If 122 | you use option 4d0, the Installation Information must accompany 123 | the Minimal Corresponding Source and Corresponding Application 124 | Code. If you use option 4d1, you must provide the Installation 125 | Information in the manner specified by section 6 of the GNU GPL 126 | for conveying Corresponding Source.) 127 | 128 | 5. Combined Libraries. 129 | 130 | You may place library facilities that are a work based on the 131 | Library side by side in a single library together with other library 132 | facilities that are not Applications and are not covered by this 133 | License, and convey such a combined library under terms of your 134 | choice, if you do both of the following: 135 | 136 | a) Accompany the combined library with a copy of the same work based 137 | on the Library, uncombined with any other library facilities, 138 | conveyed under the terms of this License. 139 | 140 | b) Give prominent notice with the combined library that part of it 141 | is a work based on the Library, and explaining where to find the 142 | accompanying uncombined form of the same work. 143 | 144 | 6. Revised Versions of the GNU Lesser General Public License. 145 | 146 | The Free Software Foundation may publish revised and/or new versions 147 | of the GNU Lesser General Public License from time to time. Such new 148 | versions will be similar in spirit to the present version, but may 149 | differ in detail to address new problems or concerns. 150 | 151 | Each version is given a distinguishing version number. If the 152 | Library as you received it specifies that a certain numbered version 153 | of the GNU Lesser General Public License "or any later version" 154 | applies to it, you have the option of following the terms and 155 | conditions either of that published version or of any later version 156 | published by the Free Software Foundation. If the Library as you 157 | received it does not specify a version number of the GNU Lesser 158 | General Public License, you may choose any version of the GNU Lesser 159 | General Public License ever published by the Free Software Foundation. 160 | 161 | If the Library as you received it specifies that a proxy can decide 162 | whether future versions of the GNU Lesser General Public License shall 163 | apply, that proxy's public statement of acceptance of any version is 164 | permanent authorization for you to choose that version for the 165 | Library. 166 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | [logo]: https://cdn.xy.company/img/brand/XYO_full_colored.png 2 | 3 | [![logo]](https://xyo.network) 4 | 5 | # Note: This documentation is for XYO 1.0 and thus is out of date. We will be updating this repo with information for XYO 2.0 very soon! 6 | 7 | # XYO Papers 8 | 9 | > The XYO Foundation provides this source documentation available in our efforts to advance the understanding of the XYO Procotol and its possible uses. We continue to maintain this software in the interest of developer education. Usage of this source code is not intended for production. 10 | 11 | ## Table of Contents 12 | 13 | - [Sections](#sections) 14 | - [Title](#xyo-papers) 15 | - [Description](#description) 16 | - [Paper Listing](#paper-listing) 17 | - [Maintainers](#maintainers) 18 | - [License](#license) 19 | - [Questions](#questions) 20 | - [Credits](#credits) 21 | 22 | ## Description 23 | 24 | The paper library for the XYO Foundation. These papers detail every considered operation and expectation of the Foundation, its network performance, governance, and proposals. 25 | 26 | If you want to learn more about XYO. these documents are a great step to understanding of our proposals, approach, and considerations. We recommend starting with the [Whitepaper](./white-paper/XYO-White-Paper.pdf) which explains our concepts of a proof or origin cryptographic network. 27 | 28 | ## Paper Listing 29 | 30 | - Whitepaper 31 | - Primary network description 32 | - Lime Paper 33 | - Cryptoeconomics 2.0 with information on Token reserve and its use 34 | - Greenpaper 35 | - Token Economics 36 | - Yellowpaper 37 | - Network Implementation 38 | - Redpaper 39 | - Security Risks and considerations 40 | 41 | Feel free to visit our research page by [clicking here](https://xyo.network/research 42 | ). This webpage has links to all of the papers described above. 43 | 44 | ## Maintainers 45 | 46 | - Arie Trouw 47 | - Scott Scheper 48 | - Christine Sako 49 | - Maryann Cummings 50 | - Erik Saberski 51 | 52 | ## License 53 | 54 | See the [LICENSE](LICENSE) file for license details. 55 | 56 | ## Questions 57 | 58 | If you have any questions or concerns, please go to our developer portal at [**developers.xyo.network**]( 59 | ). Please feel free to visit our ongoing projects at github.com/XYOracleNetwork. You may also contact directly at **developer@xyo.network**. 60 | 61 | ## Credits 62 | 63 | Made with 🔥and ❄️ by [XYO](https://www.xyo.network) 64 | -------------------------------------------------------------------------------- /executive-summary/XYO-Executive-Summary.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/executive-summary/XYO-Executive-Summary.pdf -------------------------------------------------------------------------------- /green-paper/XYO-Green-Paper.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/green-paper/XYO-Green-Paper.pdf -------------------------------------------------------------------------------- /red-paper/XYO-Red-Paper.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | filecolor=black, 14 | citecolor=blue, 15 | urlcolor=blue, 16 | } 17 | \usepackage{graphicx} % Add pictures to your document 18 | \usepackage{listings} % Source code formatting and highlighting 19 | \usepackage{framed} % Source code formatting and highlighting 20 | \usepackage{appendix} % Source code formatting and highlighting 21 | \usepackage{csquotes} % Pretty quotes 22 | \usepackage[automake]{glossaries} 23 | \usepackage{xcolor} 24 | \usepackage{pagecolor} 25 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 26 | 27 | \graphicspath{ {images/} } 28 | 29 | \makeglossary 30 | 31 | %******************************* 32 | %**** Begin Glossary Section ***** 33 | %******************************* 34 | \newglossaryentry{sentinel} 35 | { 36 | name={Sentinel}, 37 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 38 | } 39 | 40 | \newglossaryentry{bridge} 41 | { 42 | name={Bridge}, 43 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 44 | } 45 | 46 | \newglossaryentry{archivist} 47 | { 48 | name={Archivist}, 49 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 50 | } 51 | 52 | \newglossaryentry{diviner} 53 | { 54 | name={Diviner}, 55 | description={A Diviner answers a given query by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 56 | } 57 | 58 | \newglossaryentry{webble} 59 | { 60 | name={webble}, 61 | description={Everything in the world is defined spatially by its \textit{X,Y,Z,T} coordinate and nothing can leave that space. Objects are thus confined to ``webbubbles'', or what are referred to as \textit{webbles}.} 62 | } 63 | 64 | \newglossaryentry{gas} 65 | { 66 | name={gas}, 67 | description={The cost of a transaction (i.e. query) in the form of XYO Tokens} 68 | } 69 | 70 | \newglossaryentry{proof-of-origin} 71 | { 72 | name={Proof of Origin}, 73 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a private key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 74 | } 75 | 76 | \newglossaryentry{proof-of-work} 77 | { 78 | name={Proof of Work}, 79 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 80 | } 81 | 82 | \newglossaryentry{bound-witness} 83 | { 84 | name={Bound Witness}, 85 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 86 | } 87 | 88 | \newglossaryentry{smart-contract} 89 | { 90 | name={smart contract}, 91 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 92 | } 93 | 94 | \newglossaryentry{cryptoeconomics} 95 | { 96 | name={cryptoeconomics}, 97 | plural={cryptoeconomic}, 98 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 99 | } 100 | 101 | \newglossaryentry{xyo-network} 102 | { 103 | name={XYO Network}, 104 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 105 | } 106 | 107 | \newglossaryentry{certainty} 108 | { 109 | name={certainty}, 110 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 111 | } 112 | 113 | \newglossaryentry{accuracy} 114 | { 115 | name={accuracy}, 116 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 117 | } 118 | 119 | \newglossaryentry{oracle} 120 | { 121 | name={oracle}, 122 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 123 | } 124 | 125 | \newglossaryentry{heuristic} 126 | { 127 | name={heuristic}, 128 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 129 | } 130 | 131 | \newglossaryentry{transient-key-chain} 132 | { 133 | name={Transient Key Chain}, 134 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 135 | } 136 | 137 | \newglossaryentry{best-answer} 138 | { 139 | name={Best Answer}, 140 | description={We define the Best Answer as the single answer, amongst a list of Answer Candidates, that returns the highest validity score and has a higher accuracy score than the minimum required accuracy.} 141 | } 142 | 143 | \newglossaryentry{best-answer-score} 144 | { 145 | name={Best Answer Score}, 146 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 147 | } 148 | 149 | \newglossaryentry{best-answer-algorithm} 150 | { 151 | name={Best Answer Algorithm}, 152 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 153 | } 154 | 155 | \newglossaryentry{origin-chain-score} 156 | { 157 | name={Origin Chain Score}, 158 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 159 | } 160 | 161 | \newglossaryentry{proof-of-origin-chain} 162 | { 163 | name={Proof of Origin Chain}, 164 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 165 | } 166 | 167 | \newglossaryentry{origin-tree} 168 | { 169 | name={Origin Tree}, 170 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 171 | } 172 | 173 | \newglossaryentry{crypto-location} 174 | { 175 | name={crypto-location}, 176 | description={The realm of cryptographic location technology} 177 | } 178 | 179 | \newglossaryentry{trustless} 180 | { 181 | name={trustless}, 182 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol} 183 | } 184 | 185 | \newglossaryentry{xyomainchain} 186 | { 187 | name={XYOMainChain}, 188 | description={An immutable blockchain in the XYO Network that stores query transactions along with data gathered from Diviners and their associated origin score} 189 | } 190 | 191 | \newglossaryentry{xyo-miner} 192 | { 193 | name={XYO Miner}, 194 | description={Sentinels, Bridges, Archivists, and Ddiviners who take part in answering queries to the XYO Network in an XYO crypto-location mining pool} 195 | } 196 | 197 | \newglossaryentry{ideal-state} 198 | { 199 | name={ideal-state}, 200 | description={The location-verification standard in an XYO crypto-location mining pool. It can be voted on amongst other XYO miners in the XYO Network system votes to increase or decrease this standard} 201 | } 202 | 203 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 204 | 205 | \definecolor{lightred}{rgb}{1,0.85,0.85} 206 | 207 | \title {XYO Network: Security Risks and Mitigations} 208 | 209 | \author{ 210 | Arie Trouw \thanks{XYO Network, \texttt{arie.trouw@xyo.network}} , Andrew Rangel, Jack Cable 211 | } 212 | 213 | \date{February 2018} 214 | 215 | \begin{document} 216 | 217 | \pagecolor{lightred} 218 | 219 | \maketitle 220 | 221 | \begin{center} 222 | \line(1,0){50} 223 | \end{center} 224 | 225 | \section{Introduction} 226 | The \Gls{xyo-network} is a \gls{trustless} and decentralized cryptographic location network that utilizes zero-knowledge proofs to establish a high degree of certainty regarding location verification. A primary concern for the XYO Network, like with all decentralized and trustless entities, is the security of the system. Vulnerabilities include, but are not limited to: design/architecture flaws, coding errors, incorrect economic motivation, and social engineering. The primary focus of this document pertains to design/architecture flaws and economic motivation. 227 | 228 | \begin{center} 229 | \line(1,0){50} 230 | \end{center} 231 | 232 | \section {Technical Considerations} 233 | \subsection{Summary} 234 | This paper addresses high level concepts in regards to potential attacks against the \Gls{xyo-network}. Due to the fact that the network utilizes a \gls{trustless} system, it is assumed that all participants in the network are vulnerable (e.g. \Glspl{sentinel}, \Glspl{bridge}, etc.). This section details some of the known protocol-level attacks along with industry standard safeguards against them. All other attacks assume the devices in the system are compromised. 235 | 236 | \subsection{Bluetooth} 237 | % Issues with Bluetooth protocols 238 | Most Bluetooth devices utilize a ``Long Term Key'' pairing setup that establishes a PIN used for encryption. If the key is discovered through an interception of the pairing process, all future traffic could easily be decrypted. There are tools that exist that could brute force the PIN. Even well-established schemes that establish a password outside of the protocol are usually executed in an unencrypted manner. This allows for multiple attack vectors to access the protocol. In addition, devices could be easily sourced to expedite these approaches. 239 | 240 | In order to prevent attacks of this nature, white-listing MAC addresses can prevent unauthorized devices from communicating with the \Glspl{sentinel} and \Glspl{bridge}. Another way to counter these attacks is to require a user to physically press a ``reset'' button in order to pair the device, which would prevent attacks from users who do not have direct physical access to the device. 241 | 242 | \subsection{Over the Air (OTA)} 243 | %OTA interception 244 | \Glspl{sentinel} need the ability to perform ``Over the Air'' (OTA) updates. OTA updates allow for quick patches in order to improve the stability and security of the device. A downside of this feature is the possibility of an attack that spoofs this update and appends malicious code. 245 | 246 | 247 | \subsection{Hardware} 248 | % For instance physically exploiting the device 249 | The devices on the \Gls{xyo-network} are physically dispersed in a wide range of locations throughout the globe. This means that there exists an ongoing potential to physically comprise a device. This is an integral reason for the XYO Network to be a completely \gls{trustless} network. The entirety of the system relies on complex algorithms that carefully and diligently parse the history and content of the data flowing into the system. Any data that doesn't pass as high-scoring, long-chain data is disregarded and the offending devices are penalized. 250 | 251 | \begin{center} 252 | \line(1,0){50} 253 | \end{center} 254 | 255 | \section{Poison the Well Attacks} 256 | %Andrew 257 | \subsection{Summary} 258 | A Poison the Well Attack occurs when a malfunctioning or malicious party creates and injects corrupted data which decreases the overall \gls{accuracy} and/or \gls{certainty} of results generated by the system. 259 | 260 | \subsection{Motivation} 261 | In a Poison the Well Attack, the bad actor's goal is to disrupt or \textit{poison} the data that is being sent to a particular \Gls{sentinel} or \Gls{bridge}. Achieving this would allow them to cause both short-term and long-term economic disruption. Given that the \Gls{xyo-network} is a \gls{trustless} system, there is a low tolerance for this type of bad data to enter the network. 262 | 263 | While there is no direct gain for the bad actor, there exist benefits in the disruption and/or tampering of other peoples' data \textit{reputation}. Suppose the XYO Network was employed to track the location of parolees in order to report any location-based violations of parole terms. If this were used to monitor the amount of time a serial DUI offender spends at a bar, an offending parolee could Poison the Well by feeding a bar-based \Gls{bridge} bad data until it is knocked off the network. The delinquent could then violate the terms of their parole and consume alcohol at the bar for as long as he or she pleases. Even if the provided data reported the offender as being at the bar's location, the poisoned data could reduce its certainty to the point that it is rendered invalid. 264 | 265 | \subsection{Technical Analysis} 266 | Location data of a \Gls{sentinel} could be affected by GPS jammers or illegal radio frequency transmitters that are designed to interfere with authorized radio communications. GPS spoofing devices \cite{jafarina-gps} have the ability to send false data to GPS radio receptors in order to falsify location. 267 | 268 | Sentinels communicating via Bluetooth present another vector for this type of attack. There are various methods in which a Bluetooth device could be spoofed into sending bad data \cite{padgette-bluetooth}. While the private keys created by the XYO Network are immediately deleted, it is possible that a device could listen to the communication between a Sentinel and a \Gls{bridge} and copy the data that is sent. This thief could then send bad data acting as the Sentinel and begin to poison the data the Bridge sends to the \Glspl{archivist}. 269 | 270 | \subsection{Protocol Mitigation Strategies} 271 | While active, a GPS jammer can be easily recognized due to the pollution it causes to the general area it is targeting. For example, any cell phone user in the targeted area would experience a sudden block out of many of the apps they use. It would only be a matter of time before multiple parties confirm similar issues and are able to confirm a jammer is the culprit. Given that this type of disruption is highly detectable combined with the fact that the FCC has explicitly ruled that invoking jammers is illegal \cite{chief-fcc}, the high risk associated with this type of attack renders the likelihood of its occurrence to be low. Even so, there are sophisticated GPS anti-spoofing techniques that are currently being developed both at the hardware and software levels for added security \cite{jafarina-gps}. 272 | 273 | In addition to these safeguards, there are current technologies and strategies that enable us to protect against Bluetooth spoofing and disruption, such as authenticating link keys with secure connections. \cite{dunning-bluetooth} 274 | 275 | \subsection{XYO Network Mitigation Strategies} 276 | The \Gls{archivist} network is a competitive network that returns verified data upon being queried by \Glspl{diviner}. At the point at which \Glspl{archivist} receive data (detailed in yellow paper), the network begins to prune bad data. The relaying of the information stored on the chain back to the origin allows for the detection of recently added bad data, even with spoofed information on a long chain. Each Archivist also cross-checks the other Archivists' data to build a valid consensus for the network. Due to the fact that Archivists get paid, along with \Glspl{bridge} and \Glspl{sentinel}, inherent \gls{cryptoeconomics} suppress attempts to poison lower-level components. 277 | 278 | \subsection{Conclusion} 279 | Considering an \Gls{archivist} pulls data from a wide geographical region and there is a necessity for it to be physically located somewhere in order to poison that region, this type of attack would result in the attacker being punished by the network. This is what makes an attacker economically disincentivized to conduct such an attack on the \Gls{xyo-network}. 280 | 281 | \begin{center} 282 | \line(1,0){50} 283 | \end{center} 284 | 285 | \section{Assassination Attacks} 286 | % Jack 287 | 288 | \subsection{Summary} 289 | 290 | An Assassination Attack is defined by a malicious actor attempting to discredit a node (character assassination) or render another node non-functional (technical assassination). 291 | 292 | \subsection{Motivation} 293 | 294 | In an Assassination Attack, an attacker is motivated to undermine the reputation of legitimate nodes in order to boost the relative credibility of other nodes controlled by the attacker. As the reputation of \Glspl{sentinel} on the \Gls{xyo-network} is fundamental for a functioning network, it is crucial that the reputation of nodes cannot be easily manipulated. 295 | 296 | Consider a situation where an attacker attempts to broadcast false location information on the XYO Network (detailed further in the Force Field Attack). In this case, the attacker must first target individual nodes to harm their reputation. One method in which this could be accomplished is via selective signing, where an attacker selectively provides false information to a legitimate Sentinel (rendering its data an outlier) in order to make the node less consistent with other nodes on the XYO Network. This causes the Sentinel's reputation to be lowered relative to other nodes on the network. 297 | 298 | Additionally, an attacker may engage in a technical assassination of a node, such as physically destroying a device. These types of attacks are also made in attempts to falsify location information on the network and result in non-functional devices. 299 | 300 | \subsection{Technical Analysis} 301 | 302 | An Assassination Attack on a \Gls{sentinel} requires an attacker to deploy at least one device to selectively communicate with the target Sentinel. Since other devices on the network do not generate signatures with the malicious node, the malicious node is only visible onto the target node. 303 | 304 | To \gls{bridge}s, external to the network, the information broadcast by the target node is inconsistent with the rest of the network. This has the effect of the target node losing reputation with respect to the rest of the network, which are consistent in not recognizing the malicious node. 305 | 306 | \subsection{Protocol Mitigation Strategies} 307 | 308 | Fundamental to the protection against an Assassination Attack is the establishment of punishing a node's reputation if it engages in selective signing. In this scenario, the malicious nodes engage in selective signing in order to make themselves appear invisible to other Sentinels on the network. 309 | 310 | Establishing a reputation of each Sentinel according to its consistency with the rest of the network makes it possible to punish nodes that engage in selective signing. A reputable node may issue a query to a less reputable node on the network. If the less reputable node is legitimate, it would be in its best interest to sign the query and make itself visible to the network, increasing its reputation. Thus, if a node were to practice selective signing, the more reputable node can broadcast that the malicious node refused to sign its query. This practice can not be exploited in the case where a node actually does sign the query, as the legitimate node can then broadcast its signature to disprove the selective signing accusation. 311 | 312 | The act of punishing selective signing within the \Gls{xyo-network} mitigates character assassination attacks, as each Sentinel has a defense mechanism for receiving inconsistent information. 313 | 314 | \subsection{XYO Network Mitigation Strategies} 315 | 316 | Establishing a reputation for each Sentinel discourages nodes from engaging in selective signing. This mitigates character assassination attacks by making any Sentinel on the network punishable for selective signing. Physical assassination attacks (e.g. destroying a device) are harder to prevent at the network level, but the \Gls{xyo-network} is resilient to attacks that target single devices. 317 | 318 | \subsection{Conclusion} 319 | 320 | The establishment of a reputation system allows Sentinels to enforce each other's good standing and eradicate bad actors. This is how the \Gls{xyo-network} mitigates Assassination Attacks. 321 | 322 | \begin{center} 323 | \line(1,0){50} 324 | \end{center} 325 | 326 | \section{Deception Attacks} 327 | %Jack 328 | \subsection{Summary} 329 | A Deception Attack occurs when a malicious actor tries to pass off incorrect, yet valid data to be used in the system for personal gain. 330 | 331 | One form of a Deception Attack occurs by Multi-Chain Forging, where an attacker maintains multiple versions of their own chain that could essentially exist in multiple places at once. 332 | 333 | \subsection{Motivation} 334 | 335 | An attacker could falsify information by forking their own location chain. This could be accomplished by sending the private key for one chain link, which is generated during the creation of new local blocks, to one or more colluding adversaries in different areas. This allows for continued creation of new location chains that branch from the same point of origin. 336 | 337 | An attacker could benefit from spreading false information about their location in situations where accuracy of location is imperative. Take for example the intent to establish an alibi to attest that the attacker was present at a specific location at a given time. By having multiple chains, the attacker could selectively report only the chain carrying information is most advantageous to them as an alibi. 338 | 339 | \subsection{Technical Analysis} 340 | 341 | A Deception Attack is increasingly difficult to execute as a chain grows longer. As time progresses, information from a particular node is broadcast across the \Gls{xyo-network}. This means any feasible attack would allow, at most, a few small changes to a chain at a given point in the past. 342 | 343 | This process does not completely diminish a potential for an attack. While syncing with a \Gls{bridge}, a malicious \Gls{sentinel} could choose one of its forked chains to share with the Bridge. Since both chains are valid, the Bridge and other devices upstream cannot immediately conclude that the chain has been forked. Instead, it is essential for nodes to cross-check with records of communication with other Sentinels on the network to verify that the node has not existed in multiple locations at once. 344 | 345 | \subsection{Protocol Mitigation Strategies} 346 | 347 | The \Gls{xyo-network}, by nature, can detect Multi-Chain attacks. Any long-term fork of a node's chain will be inconsistent with the general consensus of the network. In order to prevent small modifications, when the integrity of location data is paramount, a user may wait for additional confirmations from \Glspl{archivist} containing signatures from distributed nodes. As time progresses, any discrepancies resulting from a forked chain will become apparent. 348 | 349 | \subsection{XYO Network Mitigation Strategies} 350 | 351 | Data is distributed throughout the \Glspl{archivist} that contain signed ledgers of communications between \Glspl{sentinel}. In practice, even slight (though valid) modifications of an existing chain are detectable. If a Sentinel attempts to perform a Multi-Chain attack, other nodes with conflicting histories can broadcast the conflict to the network. As a result, the reputation of the rogue Sentinel will drop, forcing all its chains to be removed from the network. 352 | 353 | Thusly, \Gls{xyo-network} is designed to enable the cross-checking of these communications as a safeguard against these types of attacks. 354 | 355 | \subsection{Conclusion} 356 | 357 | The data redundancy in the \Gls{xyo-network} deters attempts to broadcast inconsistent data by lowering the reputation of any offending \Gls{sentinel} to a level that removes it from consideration in the network. 358 | 359 | \begin{center} 360 | \line(1,0){50} 361 | \end{center} 362 | 363 | \section{Same-Machine Sybil Attack} 364 | %Jack 365 | \subsection{Summary} 366 | A Same-Machine Sybil Attack occurs when a malicious actor creates multiple nodes from a single machine. Since devices on the \Gls{xyo-network} aren't assigned unique IDs, this is easily achievable. The malicious actor reinforces reputation by signing packets between the simulated nodes to portray the nodes as organic and pure. The attacker then lets the nodes each communicate with different groups of nearby nodes such that each simulated node keeps different information in their \Glspl{proof-of-origin-chain}. This results in all simulated nodes acquiring high \Glspl{origin-chain-score}. This attack allows malicious actors to inexpensively mass-produce nodes that can be used to conduct Sybil attacks on a local or even global network. 367 | 368 | \subsection{Motivation} 369 | 370 | An attacker may seek to engage in a Same-Machine Sybil Attack to inflate influence over a particular region. By creating multiple fake nodes from the same device, the barrier to execute a Sybil attack is lowered. It is much easier for an attacker to create many fake devices on one machine than create many malicious devices. 371 | 372 | \subsection{Technical Analysis} 373 | 374 | It is not difficult to spoof a Bluetooth device's information in order to appear indistinguishable from the device \cite{haxf4rall-bluetooth}. Thus, an attacker could create multiple devices from one computer that act and appear as separate devices. 375 | 376 | Once a number of virtual \Glspl{sentinel} have been created, an attacker can operate the Sentinels as if they were physically distinct. The Sentinels would appear to be organic and proceed to sign information related to other Sentinels in their proximity. Additionally, an attacker could create a virtual map of devices that are reflected in the signatures of the virtual Sentinels. 377 | 378 | \subsection{Protocol Mitigation Strategies} 379 | 380 | The key to defending against a Same-Machine Sybil Attack is the ability to detect duplicate data by analyzing signal strength. A computer running many virtual \Glspl{sentinel} would appear to have the same RSSI for each Sentinel. As a result, to an external Sentinel, each virtual Sentinel operating on the computer would appear to be close to each other (provided a certain fluctuation in signal strength). In order to prevent this type of attack, it is important for a legitimate Sentinel to detect bundled devices and treat their information as a single node. 381 | 382 | \subsection{XYO Network Mitigation Strategies} 383 | 384 | The \Gls{xyo-network}'s primary indicator for detecting Same-Machine Sybil Attacks is Bluetooth signal strength (RSSI). This is a two-way metric which can be agreed upon by two nodes. As a result, a node running a Same-Machine Sybil Attack will appear to have the same signal strength for each of its virtual nodes. De-duplication of node data is pruned by \Glspl{archivist}, causing all virtual nodes to be treated as a single node. This renders a Same-Machine Sybil Attack ineffective in representing one machine as several virtual nodes. 385 | 386 | \subsection{Conclusion} 387 | 388 | The \Gls{xyo-network}'s detection of Bluetooth signal strength coupled with its ability to de-duplicate data mitigates an attack from a machine that creates a cluster of virtual nodes by treating the cluster as a single node. 389 | 390 | \begin{center} 391 | \line(1,0){50} 392 | \end{center} 393 | 394 | \section{Force Field Attacks} 395 | %Jack 396 | \subsection{Summary} 397 | A Force Field attack combines an Assassination with a traditional Sybil attack in order to provide false data to a network. The attack is twofold: an attacker feeds inconsistent information to legitimate nodes while simultaneously allowing the attacker's network of nodes to serve as a consistent network for outside observers. 398 | 399 | \subsection{Motivation} 400 | 401 | This approach takes the form of a local Sybil, where the attacker aims to completely control the authority of a certain physical location. However, a pure Sybil attack on the \Gls{xyo-network} would require a large number of distributed devices with extensive histories in order to outnumber the existing reputable nodes. To circumvent this obstacle, a Force Field Attack employs a hybrid approach, which first targets the reputation of existing nodes via Assassination Attacks in order to create inconsistencies between legitimate nodes. 402 | 403 | Consider a situation where an attacker wishes to have complete authority of a certain local region. Employing a Force Field Attack, the attacker could first flood each legitimate node with inconsistent information. The reputation of these nodes on the network would consequently decrease, lowering the reputation qualification barrier. With this reduced barrier, an attacker could supply their own network of devices that outnumber the lowered reputation of legitimate devices, establishing singular authority for the targeted region. 404 | 405 | \subsection{Technical Analysis} 406 | 407 | In order to render an existing network inconsistent, an attacker utilizes selective signing in order to decrease the overlap between legitimate nodes. This could be done by bringing malicious nodes into the local network, and then allowing each node to only communicate with particular devices on the network. Each legitimate \Gls{sentinel} selected would broadcast the location of the malicious node it communicates with, while the malicious node remains invisible to surrounding Sentinels. On a large scale, this would cause each Sentinel to have a vastly different interpretation of the state of the network. To an outside source, such as a \Gls{bridge}, the reputation of each node would be lowered. 408 | 409 | Once this is accomplished, an attacker could take advantage of the reduced reputation of the entire system in order to inject their own network of Sentinels. It is possible that these devices have already existed on the network, they would simply become more significant as the reputations of other Sentinels are lowered. 410 | 411 | This method of attack is contingent on the number of existing nodes in the region and becomes increasingly difficult as this number grows. 412 | 413 | \subsection{Protocol Mitigation Strategies} 414 | 415 | Similar to prevention of Assassination Attacks, mitigation of Force Field Attacks relies on the punishment of selective signing. A Force Field Attack employs selective signing with a cartel of malicious nodes in order to make targeted legitimate nodes inconsistent with the \Gls{xyo-network}. 416 | 417 | Having reputable \Glspl{sentinel} poll less reputable nodes for signatures and reporting nodes that refuse to respond diminishes the ability of nodes to engage in selective signing. 418 | 419 | This makes a Force Field Attack much more difficult to execute, because any reputation built to execute the attack would quickly dissipate after engaging in selective signing. 420 | 421 | \subsection{XYO Network Mitigation Strategies} 422 | 423 | The \Gls{xyo-network} punishes nodes that attempt selective signing for not conforming with the rest of the system. This boosts the incentive for nodes to respond to signing requests and contribute data to the XYO Network. Incompliant nodes lose credibility in the form of lowered reputation, causing the Assassination component of a Force Field Attack to be economically inviable. This reduces a Force Field attack to a traditional Sybil attack, which requires an inordinate amount of devices and computing power. 424 | 425 | \subsection{Conclusion} 426 | 427 | The resulting cost to a \Gls{sentinel}'s reputation in a Force Field Attack on the \Gls{xyo-network} renders the attack economically impractical. 428 | 429 | \begin{center} 430 | \line(1,0){50} 431 | \end{center} 432 | 433 | \section{Teleportation Attack} 434 | %Andrew 435 | \subsection{Summary} 436 | A Teleportation Attack occurs when an attacker is able to falsify their location by ``teleporting'' to another location through the network. If a smart phone or Bluetooth beacon is utilized as the \Gls{sentinel} that provides an attacker's location data, an attacker could falsify their location by sending their Sentinel with someone else. If the network were utilized to establish an alibi, a bad actor could swap their Sentinel with someone else in order to falsify their reported location. 437 | 438 | \subsection{Motivation} 439 | A Teleportation Attack could also be achieved at the software level by an attacker sharing their private key with one or more individuals. If the network was employed to verify hotel reviews, it would only allow people to leave reviews that had trusted, on-chain history. A bad actor could remotely share their private key with an individual at the hotel and could appear as if they were located there without being in physical proximity of the area. 440 | 441 | \subsection{Technical Analysis} 442 | If the private key is provided to the user, it could be shared to create a spoofed device that appears as that users device. The utilization of Software Defined Radio would allow eligible parties to appear as any specific device on the network, provided it is associated with that device's private key. This would nullify attempts to validate a user's location. This could also affect data on the blockchain, as it is theoretically difficult to discern legitimate device travel from a Teleportation Attack. 443 | 444 | \subsection{Protocol Mitigation Strategies} 445 | Detection strategies against this type of attack are complex due to the natural breaks in the chain. For example, if a phone is utilized as a \Gls{sentinel} and it is turned off, it is not in communication with the network until it is turned back on. Gaps in information being sent require a sophisticated algorithm to distinguish natural gaps from potentially bad data points that must be penalized. 446 | 447 | \subsection{XYO Network Mitigation Strategies} 448 | The feasibility of a Teleportation Attack falters at the point where the \Glspl{archivist} are able to share information with each other and verify data viability. The number of eligible devices is further reduced upstream on the Network, where it is realistic for servers to compare data across large geographic areas. This allows \Glspl{diviner} to observe bad data in the form of duplicate locations and Teleportation, which can be filtered and punished with use of an algorithm. 449 | 450 | \subsection{Conclusion} 451 | While a Teleportation Attack is difficult to determine at the protocol-level, higher-level servers on the \Gls{xyo-network}, such as \Gls{archivist}, enables detection and punishment of malicious data on the Network. Information sharing between these servers will continually build and append trusted information in order to filter bad data from the system. 452 | 453 | \begin{center} 454 | \line(1,0){50} 455 | \end{center} 456 | 457 | \section{Stealth Attack} 458 | %Andrew 459 | \subsection{Summary} 460 | A Stealth Attack is defined by a device masking itself from the network. Various use cases of the \Gls{xyo-network} require the devices on the network to have a solid chain history. 461 | 462 | \subsection{Motivation} 463 | There is little incentive for a malicious user to conduct a Stealth Attack on the \Gls{xyo-network}. The network aims to provide certainty that something exists in a given location, not prove \textit{everywhere} it has been. This is an important distinction, as the protocol-level data can be inaccurate as nodes are not trusted. 464 | 465 | Even so, an offending user could strategically turn on and off the location services of their phone or beacon to create bad chain data that would otherwise appear valid. This would allow them to essentially hide themselves from the network when they do not wish to report data and re-appear to the network when it is advantageous to them. 466 | 467 | \subsection{Technical Analysis} 468 | A Stealth Attack could be achieved by turning off a device on the network. A more complicated approach could be to employ a Faraday cage that hides a device from the network. A non-physical approach to this type of attack could be persisted through Denial of Service Attacks. 469 | 470 | \subsection{Protocol Mitigation Strategies} 471 | Action against Stealth Attacks can be complex due to the ability of Bluetooth and other devices to be easily disconnected from the network. The main strategy to alleviate this vulnerability is the implementation and usage of a strong software layer that penalizes \Glspl{sentinel} and \Glspl{bridge} that broadcast broken chain data. Detection capabilities will learn and grow over time as the algorithm gets better at understanding the subtle differences between valid and invalid data. 472 | 473 | \subsection{XYO Network Mitigation Strategies} 474 | A gap in a node's history will be immediately suspicious in use cases that require a continuous Proof of Location on the \Gls{xyo-network}. When data reaches the \Glspl{archivist}, it undergoes a rigorous pruning and filtration process that can detect these gaps and punish inconsistencies. This primary feature of the XYO Network allows it to provide the most accurate location despite messy data that is inherent of the physical world. 475 | 476 | \subsection{Conclusion} 477 | A Stealth Attack is economically inviable given the use cases for the XYO Network. 478 | 479 | \begin{center} 480 | \line(1,0){50} 481 | \end{center} 482 | 483 | \section{Denial of Service Attacks} 484 | %Andrew 485 | 486 | \subsection{Summary} 487 | A Denial of Service Attack (DoS) occurs when a malicious or dysfunctional actor causes a local, regional, or system wide outage. 488 | 489 | \subsection{Motivation} 490 | 491 | An attacker may seek to disrupt the \Gls{xyo-network} in order to prevent it from being able to verify Proof of Location. 492 | 493 | \subsection{Technical Analysis} 494 | 495 | Due to the nature of the Bluetooth protocol, Bluetooth beacons can only connect to one device at a time. This means any device that accepts unauthenticated commands can easily be knocked off the network. This could be achieved by utilizing a mobile phone application, which would allow one device that broadcasts Bluetooth commands to do so continually with relative ease. Sending hex values to the device for given parameters, such as the ``play sound'' parameter on most beacons, creates a connection with that device. If this connection is established, it blocks any other device from communicating with it. This could be amplified by the use of Software Defined Radio that could run scripts to continually broadcast various hex values to any network beacon in range. 496 | 497 | \subsection{Protocol Mitigation Strategies} 498 | Bluetooth devices on the \Gls{xyo-network} should only accept authenticated commands or utilize a MAC address white-list. Reducing the number of write-authenticated commands minimizes access to this attack vector. 499 | 500 | \subsection{XYO Network Mitigation Strategies} 501 | The \Gls{xyo-network} is comprised of users who run \Gls{archivist} and \Gls{diviner} servers. Both of these components share information and validation with their peers. This allows a query to select from any ``stack'' of components to retrieve an answer. While it is possible to deny a small portion of the network service at the protocol level, the breadth and scale of the network makes this economically inviable. 502 | 503 | \subsection{Conclusion} 504 | Due to the distributed nature of the \Gls{xyo-network}, the network remains functional despite an attempted Denial of Service Attack. As a DoS requires heavy computing power and physical access to attack an entire stack, targeting even a small portion of the XYO Network is expensive and economically illogical. 505 | 506 | \begin{center} 507 | \line(1,0){50} 508 | \end{center} 509 | 510 | \section {Acknowledgements} 511 | This red paper is a security corollary to the \Gls{xyo-network} white paper and XYO Network green paper. We thank Christine Sako for her attention to detail and application of best-practices in her review of this work. 512 | 513 | \begin{thebibliography}{9} 514 | 515 | 516 | \bibitem{jafarina-gps} 517 | Jafarnia-Jahromi, Ali. Ali Broumandan, John Nielsen, and Gerard Lachapelle. 518 | \textit{GPS Vulnerability to Spoofing Threats and a Review of Antispoofing Techniques}. 519 | \\\texttt{https://www.hindawi.com/journals/ijno/2012/127072/cta/} 520 | International Journal of Navigation and Observation, Alberta, Canada, May 2012. 521 | 522 | \bibitem{padgette-bluetooth} 523 | Padgette, John, John Bahr, Mayank Batra, Marcel Holtmann, Rhonda Smithbey, Lily Chen, and Karen Scarfone. 524 | \textit{Guide to Bluetooth Security}. 525 | \\\texttt{http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf} 526 | U.S. Department of Commerce, National Institute of Standards and Technology, May 2017. 527 | 528 | \bibitem{dunning-bluetooth} 529 | Dunning, JP. 530 | \textit{Breaking Bluetooth by being bored}. 531 | \\\texttt{https://www.defcon.org/images/defcon-18/dc-18-presentations\-/Dunning/DEFCON-18-Dunning-Breaking-Bluetooth.pdf} 532 | DefCon, August 2010. 533 | 534 | \bibitem{haxf4rall-bluetooth} 535 | haxf4rall. 536 | \textit{Spoofing a Bluetooth device}. 537 | \\\texttt{http://haxf4rall.com/2016/05/11/spoofing-a-bluetooth-device/} 538 | May 11, 2016. 539 | 540 | \bibitem{chief-fcc} 541 | Chief, Enforcement Bureau. 542 | \textit{FCC Enforcement Advisory}. 543 | \\\texttt{https://apps.fcc.gov/edocs\_public/attachmatch/DA-14-1785A1.pdf} 544 | FCC.gov, December 8, 2014. 545 | 546 | \end{thebibliography} 547 | \printglossaries 548 | 549 | %******************************* 550 | %**** End Glossary Section ***** 551 | %******************************* 552 | 553 | \end{document} 554 | -------------------------------------------------------------------------------- /smart-contract-audits/Smart-Contract-Audit-XYO-Network.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/smart-contract-audits/Smart-Contract-Audit-XYO-Network.pdf -------------------------------------------------------------------------------- /use-cases/UseCase_Airports.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/use-cases/UseCase_Airports.pdf -------------------------------------------------------------------------------- /use-cases/UseCase_Airports.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | filecolor=black, 14 | citecolor=blue, 15 | urlcolor=blue, 16 | } 17 | \usepackage{graphicx} % Add pictures to your document 18 | \usepackage{listings} % Source code formatting and highlighting 19 | \usepackage{framed} % Source code formatting and highlighting 20 | \usepackage{appendix} % Source code formatting and highlighting 21 | \usepackage[automake]{glossaries} 22 | \usepackage{csquotes} 23 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 24 | 25 | \graphicspath{ {images/} } 26 | 27 | \newglossaryentry{sentinel} 28 | { 29 | name={Sentinel}, 30 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 31 | } 32 | 33 | \newglossaryentry{bridge} 34 | { 35 | name={Bridge}, 36 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 37 | } 38 | 39 | \newglossaryentry{archivist} 40 | { 41 | name={Archivist}, 42 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 43 | } 44 | 45 | \newglossaryentry{diviner} 46 | { 47 | name={Diviner}, 48 | description={A Diviner answers a given question by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 49 | } 50 | 51 | \newglossaryentry{gas} 52 | { 53 | name={gas}, 54 | description={The cost of a transaction (i.e. question) in the form of XYO Tokens} 55 | } 56 | 57 | \newglossaryentry{proof-of-origin} 58 | { 59 | name={Proof of Origin}, 60 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private Key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a Private Key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 61 | } 62 | 63 | \newglossaryentry{proof-of-work} 64 | { 65 | name={Proof of Work}, 66 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 67 | } 68 | 69 | \newglossaryentry{bound-witness} 70 | { 71 | name={Bound Witness}, 72 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 73 | } 74 | 75 | \newglossaryentry{smart-contract} 76 | { 77 | name={smart contract}, 78 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 79 | } 80 | 81 | \newglossaryentry{cryptoeconomics} 82 | { 83 | name={cryptoeconomics}, 84 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 85 | } 86 | 87 | \newglossaryentry{xyo-network} 88 | { 89 | name={XYO Network}, 90 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 91 | } 92 | 93 | \newglossaryentry{certainty} 94 | { 95 | name={certainty}, 96 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 97 | } 98 | 99 | \newglossaryentry{accuracy} 100 | { 101 | name={accuracy}, 102 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 103 | } 104 | 105 | \newglossaryentry{oracle} 106 | { 107 | name={oracle}, 108 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 109 | } 110 | 111 | \newglossaryentry{heuristic} 112 | { 113 | name={heuristic}, 114 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 115 | } 116 | 117 | \newglossaryentry{transient-key-chain} 118 | { 119 | name={Transient Key Chain}, 120 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 121 | } 122 | 123 | \newglossaryentry{best-answer-score} 124 | { 125 | name={Best Answer Score}, 126 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 127 | } 128 | 129 | \newglossaryentry{best-answer-algorithm} 130 | { 131 | name={Best Answer Algorithm}, 132 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 133 | } 134 | 135 | \newglossaryentry{origin-chain-score} 136 | { 137 | name={Origin Chain Score}, 138 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 139 | } 140 | 141 | \newglossaryentry{origin-chain} 142 | { 143 | name={Origin Chain}, 144 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 145 | } 146 | 147 | \newglossaryentry{origin-tree} 148 | { 149 | name={Origin Tree}, 150 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 151 | } 152 | 153 | \newglossaryentry{crypto-location} 154 | { 155 | name={crypto-location}, 156 | description={The realm of cryptographic location technology} 157 | } 158 | 159 | \newglossaryentry{trustless} 160 | { 161 | name={trustless}, 162 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol.} 163 | } 164 | 165 | \newacronym{pow}{PoW}{Proof of Work} 166 | 167 | \newacronym{poo}{PoO}{Proof of Origin} 168 | 169 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 170 | 171 | 172 | \makeglossary 173 | 174 | \title {XYO Network in Airports} 175 | \author{Johnny Kolasinski, Christine Sako} 176 | \date{January 2018} 177 | 178 | \begin{document} 179 | \maketitle 180 | \tableofcontents 181 | 182 | \begin{center} 183 | \line(1,0){50} 184 | \end{center} 185 | 186 | \begin{abstract} 187 | One of the largest fears an airline traveler faces is having their luggage lost or stolen. Accounting for all baggage moving through TSA checkpoints, gates, and airplanes is important not only for travelers' piece of mind, but to the overall safety and security of airports as a whole. The \Gls{xy-oracle-network} can provide independently verified location data that can help minimize luggage mishandling and can ultimately save travelers and airport staff time and money spent trying to track down missing baggage. Due to its decentralized nature, the integration of the \Gls{xyo-network}'s unique blockchain technology also allows different airlines to access the same data without needing to implement of a unifying system. Usage of the XYO Network's technology to improve efficiency and safety for airlines has long-term benefits which include increased cost reduction, customer loyalty, and better business reputation. 188 | 189 | \end{abstract} 190 | 191 | \begin{center} 192 | \line(1,0){50} 193 | \end{center} 194 | 195 | \section {Problem} 196 | Lost and mishandled luggage costed airlines \$2.1 billion dollars in 2016, according to a study by SITA \cite{garcia-luggagelost}. While systems are improving, the complexities of air travel still result in millions of angry passengers with lost bags each year. The baggage-handling and tracking systems currently used by airlines is not only error-prone, but also lacks transparency and the proper infrastructure needed to track and verify the location of their passengers' items. 197 | 198 | 199 | \section {Solution} 200 | The \Gls{xyo-network} has implemented a decentralized, \gls{trustless} system for tracking and locating luggage. Its decentralized nature even allows airlines to utilize each other's networks without compromising the airlines' network security or needing to coordinate system updates - this means that if you're at the United desk in Dallas, but your bag is at the Delta desk at SFO, the bag can still be instantly located by accessing the \Gls{xyo-network} Ledger. Should a bag be permanently lost and a passenger file a claim with the airline, the decentralized and trustless nature of the blockchain ledger allows both parties (the airline and the passenger) to independently verify who had possession of it last. 201 | 202 | \section {How it Works} 203 | The XY Oracle Network makes use of affordable hardware devices called ``\Glspl{sentinel},'' which record \gls{heuristic} data like location, temperature, motion and other signals. Each of these Sentinel also share and record the activity of other nearby Sentinel creating a blockchain (decentralized ledger). For example, every bag in a cargo hold would be able to communicate with other bags in the hold, sharing information like when they were checked in, when they were moved, and what baggage handlers or TSA staff handled them. IoT devices called \Glspl{bridge} hand off all of this heuristic data to decentralized nodes. These nodes will be rewarded with XYO Tokens for relaying and archiving the information. This way, a cryptoeconomics-based incentive aggregates within the system to provide accurate and \gls{trustless} historical data. 204 | 205 | The decentralized nature of the \Gls{xyo-network} means that the tracking systems put in place by the different airlines can support each other without the need for the airlines themselves to implement a unified baggage handling system. As in the example above, a Delta-owned \Gls{bridge} will be able to report the history reported by a United-owned \Gls{sentinel}, and vice versa. Since the location and tracking information is communicated via a decentralized ledger, there will be no need for Delta and United (nor any other airline) to waste resources building out systems that need to communicate directly. 206 | 207 | \begin{center} 208 | \line(1,0){50} 209 | \end{center} 210 | 211 | 212 | \clearpage 213 | 214 | \begin{thebibliography}{9} 215 | 216 | \bibitem{garcia-luggagelost} 217 | Garcia, Marisa. 218 | \textit{This is How Much Luggate the Airlines Lost Last Year} 219 | Fox News Travel, May 5, 2017. 220 | 221 | \end{thebibliography} 222 | 223 | 224 | \printglossaries 225 | 226 | \end{document} 227 | -------------------------------------------------------------------------------- /use-cases/UseCase_AutomatedDrones.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/use-cases/UseCase_AutomatedDrones.pdf -------------------------------------------------------------------------------- /use-cases/UseCase_AutomatedDrones.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | filecolor=black, 14 | citecolor=blue, 15 | urlcolor=blue, 16 | } 17 | \usepackage{graphicx} % Add pictures to your document 18 | \usepackage{listings} % Source code formatting and highlighting 19 | \usepackage{framed} % Source code formatting and highlighting 20 | \usepackage{appendix} % Source code formatting and highlighting 21 | \usepackage[automake]{glossaries} 22 | \usepackage{csquotes} 23 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 24 | 25 | \graphicspath{ {images/} } 26 | 27 | \newglossaryentry{sentinel} 28 | { 29 | name={Sentinel}, 30 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 31 | } 32 | 33 | \newglossaryentry{bridge} 34 | { 35 | name={Bridge}, 36 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 37 | } 38 | 39 | \newglossaryentry{archivist} 40 | { 41 | name={Archivist}, 42 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 43 | } 44 | 45 | \newglossaryentry{diviner} 46 | { 47 | name={Diviner}, 48 | description={A Diviner answers a given question by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 49 | } 50 | 51 | \newglossaryentry{gas} 52 | { 53 | name={gas}, 54 | description={The cost of a transaction (i.e. question) in the form of XYO Tokens} 55 | } 56 | 57 | \newglossaryentry{proof-of-origin} 58 | { 59 | name={Proof of Origin}, 60 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private Key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a Private Key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 61 | } 62 | 63 | \newglossaryentry{proof-of-work} 64 | { 65 | name={Proof of Work}, 66 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 67 | } 68 | 69 | \newglossaryentry{bound-witness} 70 | { 71 | name={Bound Witness}, 72 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 73 | } 74 | 75 | \newglossaryentry{smart-contract} 76 | { 77 | name={smart contract}, 78 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 79 | } 80 | 81 | \newglossaryentry{cryptoeconomics} 82 | { 83 | name={cryptoeconomics}, 84 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 85 | } 86 | 87 | \newglossaryentry{xyo-network} 88 | { 89 | name={XYO Network}, 90 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 91 | } 92 | 93 | \newglossaryentry{certainty} 94 | { 95 | name={certainty}, 96 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 97 | } 98 | 99 | \newglossaryentry{accuracy} 100 | { 101 | name={accuracy}, 102 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 103 | } 104 | 105 | \newglossaryentry{oracle} 106 | { 107 | name={oracle}, 108 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 109 | } 110 | 111 | \newglossaryentry{heuristic} 112 | { 113 | name={heuristic}, 114 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 115 | } 116 | 117 | \newglossaryentry{transient-key-chain} 118 | { 119 | name={Transient Key Chain}, 120 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 121 | } 122 | 123 | \newglossaryentry{best-answer-score} 124 | { 125 | name={Best Answer Score}, 126 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 127 | } 128 | 129 | \newglossaryentry{best-answer-algorithm} 130 | { 131 | name={Best Answer Algorithm}, 132 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 133 | } 134 | 135 | \newglossaryentry{origin-chain-score} 136 | { 137 | name={Origin Chain Score}, 138 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 139 | } 140 | 141 | \newglossaryentry{origin-chain} 142 | { 143 | name={Origin Chain}, 144 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 145 | } 146 | 147 | \newglossaryentry{origin-tree} 148 | { 149 | name={Origin Tree}, 150 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 151 | } 152 | 153 | \newglossaryentry{crypto-location} 154 | { 155 | name={crypto-location}, 156 | description={The realm of cryptographic location technology} 157 | } 158 | 159 | \newglossaryentry{trustless} 160 | { 161 | name={trustless}, 162 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol.} 163 | } 164 | 165 | \newacronym{pow}{PoW}{Proof of Work} 166 | 167 | \newacronym{poo}{PoO}{Proof of Origin} 168 | 169 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 170 | 171 | 172 | \makeglossary 173 | 174 | \title {XYO Network in Automated Drone Technology} 175 | \author{Johnny Kolasinski, Christine Sako} 176 | \date{January 2018} 177 | 178 | \begin{document} 179 | \maketitle 180 | \tableofcontents 181 | 182 | \begin{center} 183 | \line(1,0){50} 184 | \end{center} 185 | 186 | \begin{abstract} 187 | There has been significant buzz recently around drone technology and the role it will play in our future. From emergency medical supply delivery to one-hour eCommerce delivery, advancements in drone automation bring these applications closer to reality each day. This raises very valid and practical questions for both the entities that will use drone technology and those affected by it. Where will the drones be able to fly? How will accidents be prevented? How will package delivery be confirmed? The \Gls{xy-oracle-network} can provide independently verified location data that can help keep drones within approved flight paths, avoid collisions with both moving and stationary objects, and report package location at key points. According to Amazon CEO Jeff Bezos, the platform's current plans for delivery confirmation require the customer to print out their own pre-generated symbol from a physical printer \cite{nickelsburg-amazondrones}. The \Gls{xyo-network} provides \gls{trustless} location verification that eliminates this requirement, making the overall process and user experience smoother for the customer. The integration of the \Gls{xyo-network}'s unique blockchain technology will maximize the efficiency of the implemented drone systems, which is imperative for all newly-established industries to thrive and scale. 188 | 189 | \end{abstract} 190 | 191 | \begin{center} 192 | \line(1,0){50} 193 | \end{center} 194 | 195 | \section {Problem} 196 | Numerous entities are very close to implementing automated drone services, from eCommerce giants like Amazon and Walmart to Google/Alphabet's Project Wing to the numerous drone mapping services already in operation. Ensuring public safety, securing personal privacy, and maintaining compliance with FAA regulation will become increasingly challenging as guidelines are altered and skies become more crowded. 197 | 198 | \section {Solution} 199 | By utilizing the \Gls{xyo-network}, automated drones operating independently of each other will be able to communicate their relative and absolute locations using a universal protocol. Drones that are not inherently able to communicate with one another can take advantage of the XYO Network and still interact through third-party intermediaries, including independent devices or other drones. Interactions between devices on the XYO Network are also recorded on the blockchain, a decentralized ledger. This means that all automated drones are held publicly accountable in the event of an accident, regulation infringement, or breach in safety or personal privacy through the availability of a permanent and unalterable record of all device interactions. 200 | 201 | \section {How it Works} 202 | Every drone that is connected to the \Gls{xyo-network} will include a device called a \Gls{sentinel}. Sentinels record and transmit \gls{heuristic} data like time, location, speed and temperature. They also communicate with other Sentinels and keep a record of these interactions. This history is transmitted to the blockchain via an XYO \Glspl{bridge}, which can either be included on the drones themselves, or as independent devices. The entire history of heuristic data and device interactions is archived on a decentralized, publicly accessible blockchain. 203 | 204 | Drones operated by different companies or produced by different manufacturers may very likely lack a universal standard of wireless communication necessary to communicate directly with each other. The XYO Network is platform-agnostic and is not tied to any one radio broadcast band or communication protocol. This means that Bridges can act as middlemen between devices that would otherwise not be able to correspond with each other. Devices on the XYO Network can help improve each other's data, allowing for greater \gls{accuracy} among all drones. For example, if one drone uses GPS for location calculation, and another triangulates off of cell towers, comparing their data at the time of interaction will independently verify both devices' histories. A device on the XYO Network that doesn't have an independent geo-positioning system will also be able to use the drones' heuristics to confirm its own location. 205 | 206 | Participation in the XYO Network is incentivized by XYO Tokens - Sentinels and Bridges are awarded XYO Tokens when the accurate information they provide to the XYO Network is accessed, as well as other devices on the XYO Network that are responsible for archiving and analyzing the data that is provided. 207 | 208 | 209 | \begin{center} 210 | \line(1,0){50} 211 | \end{center} 212 | 213 | 214 | \clearpage 215 | 216 | \begin{thebibliography}{9} 217 | 218 | \bibitem{nickelsburg-amazondrones} 219 | Nickelsburg, Monica. 220 | \textit{Jeff Bezos: Amazon Drones Will Find Landing Spots Using Symbols Printed Out By Customers}. 221 | GeekWire, October 24, 2016. 222 | 223 | \end{thebibliography} 224 | 225 | \printglossaries 226 | 227 | \end{document} 228 | -------------------------------------------------------------------------------- /use-cases/UseCase_Hospitals.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/use-cases/UseCase_Hospitals.pdf -------------------------------------------------------------------------------- /use-cases/UseCase_Hospitals.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | filecolor=black, 14 | citecolor=blue, 15 | urlcolor=blue, 16 | } 17 | \usepackage{graphicx} % Add pictures to your document 18 | \usepackage{listings} % Source code formatting and highlighting 19 | \usepackage{framed} % Source code formatting and highlighting 20 | \usepackage{appendix} % Source code formatting and highlighting 21 | \usepackage[automake]{glossaries} 22 | \usepackage{csquotes} 23 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 24 | 25 | \graphicspath{ {images/} } 26 | 27 | \newglossaryentry{sentinel} 28 | { 29 | name={Sentinel}, 30 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 31 | } 32 | 33 | \newglossaryentry{bridge} 34 | { 35 | name={Bridge}, 36 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 37 | } 38 | 39 | \newglossaryentry{archivist} 40 | { 41 | name={Archivist}, 42 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 43 | } 44 | 45 | \newglossaryentry{diviner} 46 | { 47 | name={Diviner}, 48 | description={A Diviner answers a given question by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 49 | } 50 | 51 | \newglossaryentry{gas} 52 | { 53 | name={gas}, 54 | description={The cost of a transaction (i.e. question) in the form of XYO Tokens} 55 | } 56 | 57 | \newglossaryentry{proof-of-origin} 58 | { 59 | name={Proof of Origin}, 60 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private Key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a Private Key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 61 | } 62 | 63 | \newglossaryentry{proof-of-work} 64 | { 65 | name={Proof of Work}, 66 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 67 | } 68 | 69 | \newglossaryentry{bound-witness} 70 | { 71 | name={Bound Witness}, 72 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 73 | } 74 | 75 | \newglossaryentry{smart-contract} 76 | { 77 | name={smart contract}, 78 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 79 | } 80 | 81 | \newglossaryentry{cryptoeconomics} 82 | { 83 | name={cryptoeconomics}, 84 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 85 | } 86 | 87 | \newglossaryentry{xyo-network} 88 | { 89 | name={XYO Network}, 90 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 91 | } 92 | 93 | \newglossaryentry{certainty} 94 | { 95 | name={certainty}, 96 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 97 | } 98 | 99 | \newglossaryentry{accuracy} 100 | { 101 | name={accuracy}, 102 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 103 | } 104 | 105 | \newglossaryentry{oracle} 106 | { 107 | name={oracle}, 108 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 109 | } 110 | 111 | \newglossaryentry{heuristic} 112 | { 113 | name={heuristic}, 114 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 115 | } 116 | 117 | \newglossaryentry{transient-key-chain} 118 | { 119 | name={Transient Key Chain}, 120 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 121 | } 122 | 123 | \newglossaryentry{best-answer-score} 124 | { 125 | name={Best Answer Score}, 126 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 127 | } 128 | 129 | \newglossaryentry{best-answer-algorithm} 130 | { 131 | name={Best Answer Algorithm}, 132 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 133 | } 134 | 135 | \newglossaryentry{origin-chain-score} 136 | { 137 | name={Origin Chain Score}, 138 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 139 | } 140 | 141 | \newglossaryentry{origin-chain} 142 | { 143 | name={Origin Chain}, 144 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 145 | } 146 | 147 | \newglossaryentry{origin-tree} 148 | { 149 | name={Origin Tree}, 150 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 151 | } 152 | 153 | \newglossaryentry{crypto-location} 154 | { 155 | name={crypto-location}, 156 | description={The realm of cryptographic location technology} 157 | } 158 | 159 | \newglossaryentry{trustless} 160 | { 161 | name={trustless}, 162 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol.} 163 | } 164 | 165 | \newacronym{pow}{PoW}{Proof of Work} 166 | 167 | \newacronym{poo}{PoO}{Proof of Origin} 168 | 169 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 170 | 171 | 172 | \makeglossary 173 | 174 | \title {XYO Network in Hospitals} 175 | \author{Johnny Kolasinski, Christine Sako} 176 | \date{January 2018} 177 | 178 | \begin{document} 179 | \maketitle 180 | \tableofcontents 181 | 182 | \begin{center} 183 | \line(1,0){50} 184 | \end{center} 185 | 186 | \begin{abstract} 187 | Hospitals are among the most demanding and perilous establishments in the medical field. From medical equipment to identification of both patient and staff, a single misplacement or mistake could mean the difference between life and death. The \Gls{xy-oracle-network} can provide \gls{trustless}, verified location reporting that is critical in such a sensitive environment. The feasibility of error reduction and increased efficiency in hospitals is made possible with the \Gls{xyo-network}'s unique blockchain technology. The implications could reduce prescription dosage errors, prevent unnecessary procedures, and ultimately, save lives. 188 | 189 | \end{abstract} 190 | 191 | \begin{center} 192 | \line(1,0){50} 193 | \end{center} 194 | 195 | \section {Problem} 196 | Medical errors are the third leading cause of death in the United States, according to a study released by the Johns Hopkins School of Medicine \cite{makary-medicalerrors}. Many of these preventable deaths are a result of operational or record-keeping errors, including adverse drug interactions, improper medical records, and even unnecessary surgeries. In a letter to the Centers for Disease Control and Prevention, the study's author, Dr. Martin Makary, stated: 197 | 198 | \begin{displayquote}\textit{``It is time for the country to invest in medical quality and patient safety proportional to the mortality burden it bears. This would [include] research in technology that reduces harmful and unwarranted variation in medical care.''} \cite{makary-johnshopkins} 199 | 200 | \vspace{2mm} 201 | ---Dr. Martin Makary 202 | \end{displayquote} 203 | 204 | 205 | \section {Solution} 206 | By tying the \Gls{xyo-network} into the operational frameworks that are already in place in Hospitals, care providers can significantly reduce failures in communication and record keeping that result in patient injury and death. Utilizing the XYO Network and XYO Tokens can provide a \gls{trustless}, decentralized, and independently verifiable record of all patient interactions with any staff as well as a log of relevant patient data such as the patient's vitals, treatment details, and test results for the duration of their stay. 207 | 208 | \section {How it Works} 209 | The \Gls{xyo-network} is a web of devices that record and archive \gls{heuristic} data using a blockchain ledger. Whenever a device on the XYO Network interacts with another XYO device, it logs this interaction. By reviewing this ledger of interactions and the additional data it provides, it's possible to verify with a high degree of \gls{certainty} that a specific interaction happened at a specific time in a specific location. 210 | 211 | For example, imagine a patient, John Doe, who is admitted to the E.R. John is given an identification bracelet that is also an \Gls{xyo-network} \Gls{sentinel}, which keeps a record of any XYO Network devices John interacts with. The monitor that reads John's vital signs is also a Sentinel. It logs John's vitals as heuristic data, and the communication between the two devices eliminates the potential for human error in record keeping. The monitor also serves as an XYO Network \Gls{bridge}, reporting and archiving the blockchain ledgers of any Sentinels it interacts with. 212 | 213 | When John is treated by a doctor or nurse, these interactions are recorded on John's ledger, the monitor's ledger, and the ledger of a \Gls{sentinel} embedded in the staff member's hospital ID. The XYO Network could even keep a log of medications John receives, and because a Sentinel could be linked to the medication itself, it could provide confirmation that the correct dosage of the correct medication was administered, confirming the accuracy of John's medical record. 214 | 215 | \begin{center} 216 | \line(1,0){50} 217 | \end{center} 218 | 219 | 220 | \clearpage 221 | 222 | \begin{thebibliography}{9} 223 | 224 | \bibitem{makary-medicalerrors} 225 | Makary, Martin and Michael Daniel. 226 | \textit{Study Suggests Medical Errors Now Third Leading Cause of Death in the U.S.} 227 | John Hopkins Medicine, May 3, 2016. 228 | 229 | \bibitem{makary-johnshopkins} 230 | Makary, Martin. 231 | \textit{Johns Hopkins professor: CDC should list medical errors as 3rd leading cause of death}. 232 | Washington Report, Baltimore, MD, May 4, 2016. 233 | 234 | \end{thebibliography} 235 | 236 | \printglossaries 237 | 238 | \end{document} 239 | -------------------------------------------------------------------------------- /use-cases/UseCase_Insurance.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/use-cases/UseCase_Insurance.pdf -------------------------------------------------------------------------------- /use-cases/UseCase_Insurance.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | filecolor=black, 14 | citecolor=blue, 15 | urlcolor=blue, 16 | } 17 | \usepackage{graphicx} % Add pictures to your document 18 | \usepackage{listings} % Source code formatting and highlighting 19 | \usepackage{framed} % Source code formatting and highlighting 20 | \usepackage{appendix} % Source code formatting and highlighting 21 | \usepackage[automake]{glossaries} 22 | \usepackage{csquotes} 23 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 24 | 25 | \graphicspath{ {images/} } 26 | 27 | \newglossaryentry{sentinel} 28 | { 29 | name={Sentinel}, 30 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 31 | } 32 | 33 | \newglossaryentry{bridge} 34 | { 35 | name={Bridge}, 36 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 37 | } 38 | 39 | \newglossaryentry{archivist} 40 | { 41 | name={Archivist}, 42 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 43 | } 44 | 45 | \newglossaryentry{diviner} 46 | { 47 | name={Diviner}, 48 | description={A Diviner answers a given question by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 49 | } 50 | 51 | \newglossaryentry{gas} 52 | { 53 | name={gas}, 54 | description={The cost of a transaction (i.e. question) in the form of XYO Tokens} 55 | } 56 | 57 | \newglossaryentry{proof-of-origin} 58 | { 59 | name={Proof of Origin}, 60 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private Key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a Private Key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 61 | } 62 | 63 | \newglossaryentry{proof-of-work} 64 | { 65 | name={Proof of Work}, 66 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 67 | } 68 | 69 | \newglossaryentry{bound-witness} 70 | { 71 | name={Bound Witness}, 72 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 73 | } 74 | 75 | \newglossaryentry{smart-contract} 76 | { 77 | name={smart contract}, 78 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 79 | } 80 | 81 | \newglossaryentry{cryptoeconomics} 82 | { 83 | name={cryptoeconomics}, 84 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 85 | } 86 | 87 | \newglossaryentry{xyo-network} 88 | { 89 | name={XYO Network}, 90 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 91 | } 92 | 93 | \newglossaryentry{certainty} 94 | { 95 | name={certainty}, 96 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 97 | } 98 | 99 | \newglossaryentry{accuracy} 100 | { 101 | name={accuracy}, 102 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 103 | } 104 | 105 | \newglossaryentry{oracle} 106 | { 107 | name={oracle}, 108 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 109 | } 110 | 111 | \newglossaryentry{heuristic} 112 | { 113 | name={heuristic}, 114 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 115 | } 116 | 117 | \newglossaryentry{transient-key-chain} 118 | { 119 | name={Transient Key Chain}, 120 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 121 | } 122 | 123 | \newglossaryentry{best-answer-score} 124 | { 125 | name={Best Answer Score}, 126 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 127 | } 128 | 129 | \newglossaryentry{best-answer-algorithm} 130 | { 131 | name={Best Answer Algorithm}, 132 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 133 | } 134 | 135 | \newglossaryentry{origin-chain-score} 136 | { 137 | name={Origin Chain Score}, 138 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 139 | } 140 | 141 | \newglossaryentry{origin-chain} 142 | { 143 | name={Origin Chain}, 144 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 145 | } 146 | 147 | \newglossaryentry{origin-tree} 148 | { 149 | name={Origin Tree}, 150 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 151 | } 152 | 153 | \newglossaryentry{crypto-location} 154 | { 155 | name={crypto-location}, 156 | description={The realm of cryptographic location technology} 157 | } 158 | 159 | \newglossaryentry{trustless} 160 | { 161 | name={trustless}, 162 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol.} 163 | } 164 | 165 | \newacronym{pow}{PoW}{Proof of Work} 166 | 167 | \newacronym{poo}{PoO}{Proof of Origin} 168 | 169 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 170 | 171 | 172 | \makeglossary 173 | 174 | \title {XYO Network in Insurance} 175 | \author{Johnny Kolasinski, Christine Sako} 176 | \date{January 2018} 177 | 178 | \begin{document} 179 | \maketitle 180 | \tableofcontents 181 | 182 | \begin{center} 183 | \line(1,0){50} 184 | \end{center} 185 | 186 | \begin{abstract} 187 | Loss and theft protection is a major feature that many insurance companies offer. From mobile phones to sports cars, owned assets that roam around on a regular basis are prime candidates to be covered under this type of insurance. The \Gls{xy-oracle-network} can report an insured item's location by providing independently verified and \gls{trustless} location data. The ability to recover an item that has been reported as lost or stolen satisfies the insured party, and the ability to locate such an item in the case of a falsely reported claim protects the insurer from fraud. The \Gls{xyo-network}'s decentralized blockchain technology thusly gives both the insurer and the insuree access to the same verified data and ultimately establishes unprecedented accountability for both parties. 188 | 189 | \end{abstract} 190 | 191 | \begin{center} 192 | \line(1,0){50} 193 | \end{center} 194 | 195 | \section {Problem} 196 | Insurance for vehicles, modular homes, and other high-value, high-mobility objects can reimburse for theft, but can't inherently assist in locating the original good. The insurance industry is also susceptible to fraud, especially in the case of insured items that are highly mobile. 197 | 198 | 199 | \section {Solution} 200 | XY is already working with an insurance company that covers high value, high mobility goods to help them process claims and recover insured goods. Using the \Gls{xyo-network}, a decentralized and \gls{trustless} location-based blockchain ledger, the company and its customers have access to an independently verifiable location history in the event of a claim. Additionally, police investigators can access this location history in their attempt to recover stolen goods. 201 | 202 | \section {How it Works} 203 | Each insured good is equipped with an \Gls{xyo-network} device that serves as both a ``\Gls{sentinel}'' and a ``\Gls{bridge}.'' Sentinels record \gls{heuristic} data like location, temperature, speed, and other situationally appropriate information. They also record their connection with other nearby Sentinels along with the history of those Sentinels, building a distributed ledger or blockchain. Bridges are IoT devices that report data received from Sentinels to decentralized nodes, creating a decentralized ledger (blockchain). The interaction history between Sentinels and Bridges, combined with the heuristic data that is recorded, allows for a high degree of both \gls{accuracy} and \gls{certainty} for each individual Sentinel's record. Nodes which report and archive highly accurate and certain data will be rewarded with XYO Tokens, which provides a \gls{cryptoeconomics}-based incentive to expand and grow the \Gls{xyo-network}. 204 | 205 | When a claim is made on an insured item that is connected to the XYO Network, the owner and the company can access its Sentinel's historical data on the blockchain. The decentralized and \gls{trustless} nature of the blockchain helps prevent insurance fraud, as data archived in the blockchain cannot be altered and can be accessed by either the company or the insured party. The installed XYO Network Sentinel/Bridge will also continue actively reporting, aiding in the recovery of the insured item. Unlike systems like the Lojack, XYO Network devices record location history and can be accessed by the devices' owners, not just law enforcement. 206 | 207 | 208 | \begin{center} 209 | \line(1,0){50} 210 | \end{center} 211 | 212 | 213 | \clearpage 214 | 215 | \printglossaries 216 | 217 | \end{document} 218 | -------------------------------------------------------------------------------- /use-cases/UseCase_NationalSecurity.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/use-cases/UseCase_NationalSecurity.pdf -------------------------------------------------------------------------------- /use-cases/UseCase_NationalSecurity.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | filecolor=black, 14 | citecolor=blue, 15 | urlcolor=blue, 16 | } 17 | \usepackage{graphicx} % Add pictures to your document 18 | \usepackage{listings} % Source code formatting and highlighting 19 | \usepackage{framed} % Source code formatting and highlighting 20 | \usepackage{appendix} % Source code formatting and highlighting 21 | \usepackage[automake]{glossaries} 22 | \usepackage{csquotes} 23 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 24 | 25 | \graphicspath{ {images/} } 26 | 27 | \newglossaryentry{sentinel} 28 | { 29 | name={Sentinel}, 30 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 31 | } 32 | 33 | \newglossaryentry{bridge} 34 | { 35 | name={Bridge}, 36 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 37 | } 38 | 39 | \newglossaryentry{archivist} 40 | { 41 | name={Archivist}, 42 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 43 | } 44 | 45 | \newglossaryentry{diviner} 46 | { 47 | name={Diviner}, 48 | description={A Diviner answers a given question by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 49 | } 50 | 51 | \newglossaryentry{gas} 52 | { 53 | name={gas}, 54 | description={The cost of a transaction (i.e. question) in the form of XYO Tokens} 55 | } 56 | 57 | \newglossaryentry{proof-of-origin} 58 | { 59 | name={Proof of Origin}, 60 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private Key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a Private Key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 61 | } 62 | 63 | \newglossaryentry{proof-of-work} 64 | { 65 | name={Proof of Work}, 66 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 67 | } 68 | 69 | \newglossaryentry{bound-witness} 70 | { 71 | name={Bound Witness}, 72 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 73 | } 74 | 75 | \newglossaryentry{smart-contract} 76 | { 77 | name={smart contract}, 78 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 79 | } 80 | 81 | \newglossaryentry{cryptoeconomics} 82 | { 83 | name={cryptoeconomics}, 84 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 85 | } 86 | 87 | \newglossaryentry{xyo-network} 88 | { 89 | name={XYO Network}, 90 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 91 | } 92 | 93 | \newglossaryentry{certainty} 94 | { 95 | name={certainty}, 96 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 97 | } 98 | 99 | \newglossaryentry{accuracy} 100 | { 101 | name={accuracy}, 102 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 103 | } 104 | 105 | \newglossaryentry{oracle} 106 | { 107 | name={oracle}, 108 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 109 | } 110 | 111 | \newglossaryentry{heuristic} 112 | { 113 | name={heuristic}, 114 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 115 | } 116 | 117 | \newglossaryentry{transient-key-chain} 118 | { 119 | name={Transient Key Chain}, 120 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 121 | } 122 | 123 | \newglossaryentry{best-answer-score} 124 | { 125 | name={Best Answer Score}, 126 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 127 | } 128 | 129 | \newglossaryentry{best-answer-algorithm} 130 | { 131 | name={Best Answer Algorithm}, 132 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 133 | } 134 | 135 | \newglossaryentry{origin-chain-score} 136 | { 137 | name={Origin Chain Score}, 138 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 139 | } 140 | 141 | \newglossaryentry{origin-chain} 142 | { 143 | name={Origin Chain}, 144 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 145 | } 146 | 147 | \newglossaryentry{origin-tree} 148 | { 149 | name={Origin Tree}, 150 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 151 | } 152 | 153 | \newglossaryentry{crypto-location} 154 | { 155 | name={crypto-location}, 156 | description={The realm of cryptographic location technology} 157 | } 158 | 159 | \newglossaryentry{trustless} 160 | { 161 | name={trustless}, 162 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol.} 163 | } 164 | 165 | \newacronym{pow}{PoW}{Proof of Work} 166 | 167 | \newacronym{poo}{PoO}{Proof of Origin} 168 | 169 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 170 | 171 | 172 | \makeglossary 173 | 174 | \title {XYO Network in National Security} 175 | \author{Johnny Kolasinski, Christine Sako} 176 | \date{January 2018} 177 | 178 | \begin{document} 179 | \maketitle 180 | \tableofcontents 181 | 182 | \begin{center} 183 | \line(1,0){50} 184 | \end{center} 185 | 186 | \begin{abstract} 187 | The presence of government-regulated firearms in establishments where weapons are strictly prohibited fundamentally introduces a considerable risk. Tightly controlled security is imperative at major transportation hubs (i.e. international airports) where traffic volume is high and potential dangers are inherently evident. Firearms are not only carried by security and police forces on the ground, but also by Federal Air Marshals in the sky. The \Gls{xy-oracle-network} can confirm a weapon is exactly where it is intended to be by reporting independently verified and \gls{trustless} location data. Through its decentralized blockchain technology, the \Gls{xyo-network} is able to provide an unparalleled element of safety and accountability to arguably the most targeted, at-risk establishments in the world. 188 | \end{abstract} 189 | 190 | \begin{center} 191 | \line(1,0){50} 192 | \end{center} 193 | 194 | \section {Problem} 195 | In operations requiring a high level of security, it is crucial to ensure that any authorized firearms are strictly and safely controlled. Creating a system that is secure, reliable, and publicly accountable poses an operational challenge. 196 | 197 | \section {Solution} 198 | A high-profile government security agency has contracted with XY to secure firearms in major transportation hubs throughout the United States. The use of XY's existing technology saves the agency millions of dollars, and the decentralized nature of its blockchain creates a system that is both independently secure and publicly accountable. 199 | 200 | \section {How it Works} 201 | The \Gls{xyo-network} is a web of devices that record and archive \gls{heuristic} data using a blockchain ledger. Whenever a device on the XYO Network interacts with another XY device, it logs this interaction. By reviewing this ledger of interactions and the additional data they provide, it can be guaranteed with a high degree of \gls{certainty} that a specific interaction happened at a distinct time in a precise location. 202 | 203 | Each firearm protected by the XYO Network is affixed with a device called a ``\Gls{sentinel}'' which records heuristic data like its location, temperature and movement. The Sentinel also records any interaction it has with other nearby Sentinels, and both devices share their histories with each other. IoT devices called ``\Glspl{bridge}'' relay Sentinels' records to decentralized nodes which archives this data on a decentralized ledger or blockchain. These nodes are rewarded with XYO tokens when they archive, process or relay accurate historical data. In this way, the XYO Network leverages \gls{cryptoeconomics} to create a \gls{trustless}, decentralized, unalterable location and interaction history for each protected firearm. 204 | 205 | In other words, when the firearms are securely stored, they create a record of where they are stored and what other firearms are in storage with them. When a firearm is removed, each firearm's record is updated, noting what firearm was removed and by whom. The firearm's Sentinel records where it is taken, when it moves, who interacts with it, and when it is returned. Any other XYO Network Sentinels also record their interactions with the firearm's Sentinel. 206 | 207 | This decentralized ledger serves two important purposes. First, it provides an unalterable, auditable archive of when a firearm was accessed and by whom, where it was taken, and when it was returned. Second, the XYO Network's decentralized nature means that the information in this archive can be independently audited and confirmed. This feature can also be implemented in other industries where accountability is critical, such as law enforcement, corrections, and health care. 208 | 209 | 210 | 211 | \begin{center} 212 | \line(1,0){50} 213 | \end{center} 214 | 215 | 216 | \clearpage 217 | 218 | \printglossaries 219 | 220 | \end{document} 221 | -------------------------------------------------------------------------------- /use-cases/UseCase_RentalCarFacilities.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/use-cases/UseCase_RentalCarFacilities.pdf -------------------------------------------------------------------------------- /use-cases/UseCase_RentalCarFacilities.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | citecolor=gray, 14 | filecolor=black, 15 | citecolor=blue, 16 | urlcolor=blue, 17 | } 18 | \usepackage{graphicx} % Add pictures to your document 19 | \usepackage{listings} % Source code formatting and highlighting 20 | \usepackage{framed} % Source code formatting and highlighting 21 | \usepackage{appendix} % Source code formatting and highlighting 22 | \usepackage[automake]{glossaries} 23 | \usepackage{csquotes} 24 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 25 | 26 | \graphicspath{ {images/} } 27 | 28 | \newglossaryentry{sentinel} 29 | { 30 | name={Sentinel}, 31 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 32 | } 33 | 34 | \newglossaryentry{bridge} 35 | { 36 | name={Bridge}, 37 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 38 | } 39 | 40 | \newglossaryentry{archivist} 41 | { 42 | name={Archivist}, 43 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 44 | } 45 | 46 | \newglossaryentry{diviner} 47 | { 48 | name={Diviner}, 49 | description={A Diviner answers a given question by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 50 | } 51 | 52 | \newglossaryentry{gas} 53 | { 54 | name={gas}, 55 | description={The cost of a transaction (i.e. question) in the form of XYO Tokens} 56 | } 57 | 58 | \newglossaryentry{proof-of-origin} 59 | { 60 | name={Proof of Origin}, 61 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private Key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a Private Key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 62 | } 63 | 64 | \newglossaryentry{proof-of-work} 65 | { 66 | name={Proof of Work}, 67 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 68 | } 69 | 70 | \newglossaryentry{bound-witness} 71 | { 72 | name={Bound Witness}, 73 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 74 | } 75 | 76 | \newglossaryentry{smart-contract} 77 | { 78 | name={smart contract}, 79 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 80 | } 81 | 82 | \newglossaryentry{cryptoeconomics} 83 | { 84 | name={cryptoeconomics}, 85 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 86 | } 87 | 88 | \newglossaryentry{xyo-network} 89 | { 90 | name={XYO Network}, 91 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 92 | } 93 | 94 | \newglossaryentry{certainty} 95 | { 96 | name={certainty}, 97 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 98 | } 99 | 100 | \newglossaryentry{accuracy} 101 | { 102 | name={accuracy}, 103 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 104 | } 105 | 106 | \newglossaryentry{oracle} 107 | { 108 | name={oracle}, 109 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 110 | } 111 | 112 | \newglossaryentry{heuristic} 113 | { 114 | name={heuristic}, 115 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 116 | } 117 | 118 | \newglossaryentry{transient-key-chain} 119 | { 120 | name={Transient Key Chain}, 121 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 122 | } 123 | 124 | \newglossaryentry{best-answer-score} 125 | { 126 | name={Best Answer Score}, 127 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 128 | } 129 | 130 | \newglossaryentry{best-answer-algorithm} 131 | { 132 | name={Best Answer Algorithm}, 133 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 134 | } 135 | 136 | \newglossaryentry{origin-chain-score} 137 | { 138 | name={Origin Chain Score}, 139 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 140 | } 141 | 142 | \newglossaryentry{origin-chain} 143 | { 144 | name={Origin Chain}, 145 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 146 | } 147 | 148 | \newglossaryentry{origin-tree} 149 | { 150 | name={Origin Tree}, 151 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 152 | } 153 | 154 | \newglossaryentry{crypto-location} 155 | { 156 | name={crypto-location}, 157 | description={The realm of cryptographic location technology} 158 | } 159 | 160 | \newglossaryentry{trustless} 161 | { 162 | name={trustless}, 163 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol.} 164 | } 165 | 166 | \newacronym{pow}{PoW}{Proof of Work} 167 | 168 | \newacronym{poo}{PoO}{Proof of Origin} 169 | 170 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 171 | 172 | 173 | \makeglossary 174 | 175 | \title {XYO Network in Rental Car Facilities} 176 | \author{Johnny Kolasinski, Christine Sako} 177 | \date{January 2018} 178 | 179 | \begin{document} 180 | \maketitle 181 | \tableofcontents 182 | 183 | \begin{center} 184 | \line(1,0){50} 185 | \end{center} 186 | 187 | \begin{abstract} 188 | There are many businesses whose main source of revenue comes from offering the rental of goods. Being able to track the location of rented goods is especially important in order to reduce replacement costs of lost or stolen items. The \Gls{xy-oracle-network} can provide independently verified location data that can help minimize loss of goods and ultimately save the rental industry millions of dollars each year. The integration of the \Gls{xyo-network}'s unique blockchain technology also increases rental companies' overall efficiency, as time spent on loss-procedures is reduced. Utilizing the \Gls{xyo-network}'s technology to improve performance and proficiency have long-term benefits which include increased customer satisfaction, higher business volume, and larger profits. 189 | 190 | \end{abstract} 191 | 192 | \begin{center} 193 | \line(1,0){50} 194 | \end{center} 195 | 196 | \section {Problem} 197 | The number one problem that rental car agencies face are logistical ones. Simple events, such as the customer losing their keys, results in millions upon millions of dollars in lost opportunity cost for car rental companies each year. And the issue continues to get worse; not better. The most common issue rental car companies have revolves around loss of rental vehicle keys. Most often, this is because the customer fails to return the keys when they return the car. Each misplaced key costs the company hundreds of dollars, not only in replacement costs, but in lost revenue. 198 | 199 | 200 | \section {Solution} 201 | XY has already implemented a pilot program with one of the largest US rental car agencies to help cut down on the number of keys that aren't returned at major airports. By expanding the program to make use of the \Gls{xyo-network}, the rental car company and its customers can reduce the number of lost keys. In the event of a dispute, both the company and the customer will have access to an independently verifiable, \gls{trustless} location ledger that has logged the location of the keys during and after the time of the return. 202 | 203 | \section {How it Works} 204 | The \Gls{xyo-network} has already experimented with the implementation of their location network at airports in order to prevent customers from accidentally leaving without returning the keys to their rental car. By adding XYO Network \Glspl{bridge} to the system, rental car companies can have \gls{trustless}, independent confirmation that keys are returned. An accessible ledger will not only help prevent loss, but help locate lost keys more efficiently in the case of misplacement. It's easy to imagine the larger scope of such a technology. The installation of XYO Network \Glspl{sentinel} and Bridges in vehicles also serves as an excellent fleet management tool. 205 | 206 | \begin{center} 207 | \line(1,0){50} 208 | \end{center} 209 | 210 | 211 | \clearpage 212 | 213 | \printglossaries 214 | 215 | \end{document} 216 | -------------------------------------------------------------------------------- /use-cases/UseCase_eCommerce.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/use-cases/UseCase_eCommerce.pdf -------------------------------------------------------------------------------- /use-cases/UseCase_eCommerce.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | filecolor=black, 14 | citecolor=blue, 15 | urlcolor=blue, 16 | } 17 | \usepackage{graphicx} % Add pictures to your document 18 | \usepackage{listings} % Source code formatting and highlighting 19 | \usepackage{framed} % Source code formatting and highlighting 20 | \usepackage{appendix} % Source code formatting and highlighting 21 | \usepackage[automake]{glossaries} 22 | \usepackage{csquotes} 23 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 24 | 25 | \graphicspath{ {images/} } 26 | 27 | \newglossaryentry{sentinel} 28 | { 29 | name={Sentinel}, 30 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 31 | } 32 | 33 | \newglossaryentry{bridge} 34 | { 35 | name={Bridge}, 36 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 37 | } 38 | 39 | \newglossaryentry{archivist} 40 | { 41 | name={Archivist}, 42 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 43 | } 44 | 45 | \newglossaryentry{diviner} 46 | { 47 | name={Diviner}, 48 | description={A Diviner answers a given question by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 49 | } 50 | 51 | \newglossaryentry{gas} 52 | { 53 | name={gas}, 54 | description={The cost of a transaction (i.e. question) in the form of XYO Tokens} 55 | } 56 | 57 | \newglossaryentry{proof-of-origin} 58 | { 59 | name={Proof of Origin}, 60 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private Key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a Private Key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 61 | } 62 | 63 | \newglossaryentry{proof-of-work} 64 | { 65 | name={Proof of Work}, 66 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 67 | } 68 | 69 | \newglossaryentry{bound-witness} 70 | { 71 | name={Bound Witness}, 72 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 73 | } 74 | 75 | \newglossaryentry{smart-contract} 76 | { 77 | name={smart contract}, 78 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 79 | } 80 | 81 | \newglossaryentry{cryptoeconomics} 82 | { 83 | name={cryptoeconomics}, 84 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 85 | } 86 | 87 | \newglossaryentry{xyo-network} 88 | { 89 | name={XYO Network}, 90 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 91 | } 92 | 93 | \newglossaryentry{certainty} 94 | { 95 | name={certainty}, 96 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 97 | } 98 | 99 | \newglossaryentry{accuracy} 100 | { 101 | name={accuracy}, 102 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 103 | } 104 | 105 | \newglossaryentry{oracle} 106 | { 107 | name={oracle}, 108 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 109 | } 110 | 111 | \newglossaryentry{heuristic} 112 | { 113 | name={heuristic}, 114 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 115 | } 116 | 117 | \newglossaryentry{transient-key-chain} 118 | { 119 | name={Transient Key Chain}, 120 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 121 | } 122 | 123 | \newglossaryentry{best-answer-score} 124 | { 125 | name={Best Answer Score}, 126 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 127 | } 128 | 129 | \newglossaryentry{best-answer-algorithm} 130 | { 131 | name={Best Answer Algorithm}, 132 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 133 | } 134 | 135 | \newglossaryentry{origin-chain-score} 136 | { 137 | name={Origin Chain Score}, 138 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 139 | } 140 | 141 | \newglossaryentry{origin-chain} 142 | { 143 | name={Origin Chain}, 144 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 145 | } 146 | 147 | \newglossaryentry{origin-tree} 148 | { 149 | name={Origin Tree}, 150 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 151 | } 152 | 153 | \newglossaryentry{crypto-location} 154 | { 155 | name={crypto-location}, 156 | description={The realm of cryptographic location technology} 157 | } 158 | 159 | \newglossaryentry{trustless} 160 | { 161 | name={trustless}, 162 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol.} 163 | } 164 | 165 | \newacronym{pow}{PoW}{Proof of Work} 166 | 167 | \newacronym{poo}{PoO}{Proof of Origin} 168 | 169 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 170 | 171 | 172 | \makeglossary 173 | 174 | \title {XYO Network in eCommerce} 175 | \author{Johnny Kolasinski, Christine Sako} 176 | \date{January 2018} 177 | 178 | \begin{document} 179 | \maketitle 180 | \tableofcontents 181 | 182 | \begin{center} 183 | \line(1,0){50} 184 | \end{center} 185 | 186 | \begin{abstract} 187 | The \Gls{xy-oracle-network} incentivizes the reporting of locations and archiving of ledgers by awarding XYO Tokens to nodes within the web. For example, when a last-mile courier like a UPS driver encounters an XYO Network node on their route, the node will record their XYO Network ledger to be archived. Leveraging \gls{cryptoeconomics} in this way takes advantage of a key feature of blockchain technology - it's a \gls{trustless}, decentralized system. This means it can offer third-party verification and a degree of reliability that current tracking systems simply can't provide. 188 | 189 | \end{abstract} 190 | 191 | \begin{center} 192 | \line(1,0){50} 193 | \end{center} 194 | 195 | \section {Problem} 196 | According to a recent study released by Comcast, more than 30\% of Americans have had a package stolen from their porch or doorstep \cite{comcast-packagesurvey}. As the market share of eCommerce continues to grow, this problem will only become more prevalent. Megasites like Amazon are experimenting with different solutions to offer confirmed secure delivery as a premium service to their customers. 197 | 198 | \section {Solution} 199 | By utilizing the \Gls{xyo-network} and XYO Tokens, companies like Amazon and UPS can offer, as a premium service, an independently confirmed ledger to track every step of a shipment's progress, starting at the fulfillment center and ending with the package's secure delivery within the customer's home. As a \gls{trustless} and decentralized system, the XYO Network provides independent confirmation not only of a package's delivery, but of its entire shipping history. This also allows a retailer or eCommerce site to offer payment-upon-delivery, utilizing an Ethereum smart contract to protect the merchant from fraud or loss. 200 | 201 | \section {How it Works} 202 | When a customer finalizes an order, an Ethereum \gls{smart-contract} is created which will release payment to the merchant upon successful delivery of the purchased product. The shipment will include an \Gls{xyo-network} \Gls{sentinel}, a low-cost electronic device that records its interactions with other devices on the XYO Network on its blockchain ledger. Other XYO Network devices will likewise record their interactions with packages being shipped. Every one of these interactions will be independently verifiable, asserting a web of locational certainty that stretches all the way back to the shipment's point of origin. When the shipment reaches its destination, as confirmed by its interaction with XYO Network devices within the buyer's home, the smart contract will be fulfilled, and payment will be released. Should there be a dispute, the ledger will provide a history that can confirm the delivery of the shipment or show where it went off track. 203 | 204 | The terminal point of the transaction - the point where the package is delivered and payment is released - will be determined at the time the order is placed. Amazon has experimented with multiple secure delivery systems, including lockers in public places like convenience stores and even electronic locks that give their delivery team access to customers' homes. XYO Network devices within these secure locations will confirm delivery. In an Amazon locker, the shipped package will interact not just with its locker, but with XYO Network devices in other lockers and the customers that use them. In the customer's home, the XYO Network nodes could include the customer's phone, IoT devices, and even the Amazon Echo that was used to place the order. 205 | 206 | 207 | \begin{center} 208 | \line(1,0){50} 209 | \end{center} 210 | 211 | 212 | \clearpage 213 | 214 | \begin{thebibliography}{9} 215 | 216 | \bibitem{comcast-packagesurvey} 217 | Comcast. 218 | \textit{Survey: Nearly One-Third of Americans Have Had Packages Stolen from Their Doorsteps}. 219 | Business Wire, Philadelphia, PA, December 14, 2017. 220 | 221 | 222 | \end{thebibliography} 223 | 224 | \printglossaries 225 | 226 | \end{document} 227 | -------------------------------------------------------------------------------- /white-paper/PoE-White-Paper.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/white-paper/PoE-White-Paper.pdf -------------------------------------------------------------------------------- /white-paper/XYO-White-Paper.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/white-paper/XYO-White-Paper.pdf -------------------------------------------------------------------------------- /white-paper/XYO-White-Paper.tex: -------------------------------------------------------------------------------- 1 | % Preamble 2 | % --- 3 | \documentclass{article} 4 | 5 | % Packages 6 | % --- 7 | \usepackage{amsmath} % Advanced math typesetting 8 | \usepackage[utf8]{inputenc} % Unicode support (Umlauts etc.) 9 | \usepackage{hyperref} % Add a link to your document 10 | \hypersetup{ 11 | colorlinks=true, 12 | linkcolor=black, 13 | filecolor=black, 14 | citecolor=blue, 15 | urlcolor=blue, 16 | } 17 | \usepackage{graphicx} % Add pictures to your document 18 | \usepackage{listings} % Source code formatting and highlighting 19 | \usepackage{framed} % Source code formatting and highlighting 20 | \usepackage{appendix} % Source code formatting and highlighting 21 | \usepackage{csquotes} % Pretty quotes 22 | \usepackage[automake]{glossaries} 23 | \usepackage[letterpaper, portrait, margin=1.5in]{geometry} 24 | 25 | \graphicspath{ {images/} } 26 | 27 | \makeglossary 28 | 29 | %******************************* 30 | %**** Begin Glossary Section ***** 31 | %******************************* 32 | 33 | \newglossaryentry{sentinel} 34 | { 35 | name={Sentinel}, 36 | description={A Sentinel is a heuristic witness. It observes heuristics and vouches for the certainty and accuracy of them by producing temporal ledgers. The most important aspect of a Sentinel is that it produces ledgers that Diviners can be certain came from the same source by adding Proof of Origin to them} 37 | } 38 | 39 | \newglossaryentry{bridge} 40 | { 41 | name={Bridge}, 42 | description={A Bridge is a heuristic transcriber. It securely relays heuristic ledgers from Sentinels to Diviners. The most important aspect of a Bridge is that a Diviner can be sure that the heuristic ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional Proof of Origin metadata} 43 | } 44 | 45 | \newglossaryentry{archivist} 46 | { 47 | name={Archivist}, 48 | description={An Archivist stores heuristics as a part of the decentralized data set with the goal of having all historical ledgers stored, but without that requirement. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can return a string of ledger data if needed. Archivists store raw data only and get paid solely for retrieval of the data. Storage is always free} 49 | } 50 | 51 | \newglossaryentry{diviner} 52 | { 53 | name={Diviner}, 54 | description={A Diviner answers a given query by analyzing historical data that has been stored by the XYO Network. Heuristics stored in the XYO Network must have a high level of Proof of Origin to determine the validity and accuracy of the heuristic. A Diviner obtains and delivers an answer by judging the witness based on its Proof of Origin. Given that the XYO Network is a trustless system, Diviners must be incentivized to provide honest analyses of heuristics. Unlike Sentinels and Bridges, Diviners use Proof of Work to add answers to the blockchain} 55 | } 56 | 57 | \newglossaryentry{webble} 58 | { 59 | name={webble}, 60 | description={Everything in the world is defined spatially by its \textit{X,Y,Z,T} coordinate and nothing can leave that space. Objects are thus confined to ``webbubbles'', or what are referred to as \textit{webbles}.} 61 | } 62 | 63 | \newglossaryentry{gas} 64 | { 65 | name={gas}, 66 | description={The cost of a transaction (i.e. query) in the form of XYO Tokens} 67 | } 68 | 69 | \newglossaryentry{proof-of-origin} 70 | { 71 | name={Proof of Origin}, 72 | description={Proof of Origin is the key to verifying that ledgers flowing into the XYO Network are valid. A unique ID for source of data is not practical since it can be forged. Private key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the potential for a bad actor to steal a private key is too feasible. To solve this, XYO Network uses Transient Key Chaining. The benefit of this is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island} 73 | } 74 | 75 | \newglossaryentry{proof-of-work} 76 | { 77 | name={Proof of Work}, 78 | description={Proof of Work is a piece of data that satisfies certain requirements, is difficult to produce (i.e. costly, time-consuming), but easy for others to verify. Producing a Proof of Work can be a random process with a low probability of generation so that rigorous trial and error is required on average before a valid Proof of Work is created} 79 | } 80 | 81 | \newglossaryentry{bound-witness} 82 | { 83 | name={Bound Witness}, 84 | description={Bound Witness is a concept achieved by the existence of a bidirectional heuristic. Given that an untrusted source of data for the use of digital contract resolution (an oracle) is not useful, there is a substantial increase in certainty of the data provided by the establishment of such a heuristic. The primary bidirectional heuristic is proximity since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other.} 85 | } 86 | 87 | \newglossaryentry{smart-contract} 88 | { 89 | name={smart contract}, 90 | description={A protocol coined by Nick Szabo before Bitcoin, purportedly in 1994 (which is why some believe him to be Satoshi Nakamoto, the mystical and unknown inventor of Bitcoin). The idea behind smart contracts is to codify a legal agreement in a program and to have decentralized computers execute its terms, instead of humans having to interpret and act on contracts. Smart contracts collapse money (e.g. Ether) and contracts into the same concept. Being that smart contracts are deterministic (like computer programs) and fully transparent and readable, they serve as a powerful way to replace middle-men and brokers} 91 | } 92 | 93 | \newglossaryentry{cryptoeconomics} 94 | { 95 | name={cryptoeconomics}, 96 | plural={cryptoeconomic}, 97 | description={A formal discipline that studies protocols that govern the production, distribution, and consumption of goods and services in a decentralized digital economy. Cryptoeconomics is a practical science that focuses on the design and characterization of these protocols} 98 | } 99 | 100 | \newglossaryentry{xyo-network} 101 | { 102 | name={XYO Network}, 103 | description={XYO Network stands for ``XY Oracle Network.'' It is comprised of the entire system of XYO enabled components/nodes that include Sentinels, Bridges, Archivists, and Diviners. The primary function of the XYO Network is to act as a portal by which digital smart contracts can be executed through real world geo-location confirmations} 104 | } 105 | 106 | \newglossaryentry{certainty} 107 | { 108 | name={certainty}, 109 | description={A measure of the likelihood that a data point or heuristic is free from corruption or tampering} 110 | } 111 | 112 | \newglossaryentry{accuracy} 113 | { 114 | name={accuracy}, 115 | description={A measure of confidence that a data point or heuristic is within a specific margin of error} 116 | } 117 | 118 | \newglossaryentry{oracle} 119 | { 120 | name={oracle}, 121 | description={A part of a DApp (decentralized application) system that is responsible for resolving a digital contract by providing an answer with accuracy and certainty. The term ``oracle'' originates from cryptography where it signifies a truly random source (e.g. of a random number). This provides the necessary gate from a crypto equation to the world beyond. Oracles feed smart contracts information from beyond the chain (the real world, or off-chain). Oracles are interfaces from the digital world to the real world. As a morbid example, consider a contract for a Last Will \& Testament. A Will's terms are executed upon confirmation that the testator is deceased. An oracle service could be built to trigger a Will by compiling and aggregating relevant data from official sources. The oracle could then be used as a feed or end-point for a smart contract to call out to in order to check whether or not the person is deceased} 122 | } 123 | 124 | \newglossaryentry{heuristic} 125 | { 126 | name={heuristic}, 127 | description={A data point about the real world relative to the position of a Sentinel (proximity, temperature, light, motion, etc...)} 128 | } 129 | 130 | \newglossaryentry{transient-key-chain} 131 | { 132 | name={Transient Key Chain}, 133 | description={A Transient Key Chain links a series of data packets using Transient Key Cryptography} 134 | } 135 | 136 | \newglossaryentry{best-answer} 137 | { 138 | name={Best Answer}, 139 | description={We define the Best Answer as the single answer, amongst a list of Answer Candidates, that returns the highest validity score and has a higher accuracy score than the minimum required accuracy.} 140 | } 141 | 142 | \newglossaryentry{best-answer-score} 143 | { 144 | name={Best Answer Score}, 145 | description={A score generated by a Best Answer Algorithm that ranks the quality of the score. The higher the score, the better it is, per the algorithm. This score is used to determine which answer is better given two analyzed answers} 146 | } 147 | 148 | \newglossaryentry{best-answer-algorithm} 149 | { 150 | name={Best Answer Algorithm}, 151 | description={An algorithm used to generate Best Answer Scores when a Diviner chooses an answer. The XYO Network permits the addition of specialized algorithms and allows the customer to specify which algorithm to use. It is required that this algorithm will result in the same score when run on any Diviner given the same data set} 152 | } 153 | 154 | \newglossaryentry{origin-chain-score} 155 | { 156 | name={Origin Chain Score}, 157 | description={The score assigned to an Origin Chain to determine its credibility. This assessment takes length, tangle, overlap, and redundancy into consideration} 158 | } 159 | 160 | \newglossaryentry{proof-of-origin-chain} 161 | { 162 | name={Proof of Origin Chain}, 163 | description={A Transient Key Chain that links together a series of Bound Witness heuristic ledger entries} 164 | } 165 | 166 | \newglossaryentry{origin-tree} 167 | { 168 | name={Origin Tree}, 169 | description={A data set of ledger entries taken from various Origin Chains to establish the origin of a heuristic ledger entry with a specified level of certainty} 170 | } 171 | 172 | \newglossaryentry{crypto-location} 173 | { 174 | name={crypto-location}, 175 | description={The realm of cryptographic location technology} 176 | } 177 | 178 | \newglossaryentry{trustless} 179 | { 180 | name={trustless}, 181 | description={A characteristic where all parties in a system can reach a consensus on what the canonical truth is. Power and trust is distributed (or shared) among the network’s stakeholders (e.g. developers, miners, and consumers), rather than concentrated in a single individual or entity (e.g. banks, governments, and financial institutions). This is a common term that can be easily misunderstood. Blockchains don’t actually eliminate trust. What they do is minimize the amount of trust required from any single actor in the system. They do this by distributing trust among different actors in the system via an economic game that incentivizes actors to cooperate with the rules defined by the protocol} 182 | } 183 | 184 | \newglossaryentry{xyomainchain} 185 | { 186 | name={XYOMainChain}, 187 | description={An immutable blockchain in the XYO Network that stores query transactions along with data gathered from Diviners and their associated origin score} 188 | } 189 | 190 | \newglossaryentry{xyo-miner} 191 | { 192 | name={XYO Miner}, 193 | description={Sentinels, Bridges, Archivists, and Deviners who take part in answering queries to the XYO Network in an XYO crypto-location mining pool} 194 | } 195 | 196 | \newglossaryentry{ideal-state} 197 | { 198 | name={ideal-state}, 199 | description={The location-verification standard in an XYO crypto-location mining pool. It can be voted on amongst other XYO miners in the XYO Network system votes to increase or decrease this standard} 200 | } 201 | 202 | 203 | \newacronym{pow}{PoW}{Proof of Work} 204 | 205 | \newacronym{poo}{PoO}{Proof of Origin} 206 | 207 | \newacronym{xy-oracle-network}{XY Oracle Network}{XYO Network} 208 | 209 | \title {The XY Oracle Network: The Proof-of-Origin Based Cryptographic Location Network} 210 | 211 | \author{ 212 | Arie Trouw 213 | \thanks{XYO Network, \texttt{arie.trouw@xyo.network}} 214 | , Markus Levin 215 | \thanks{XYO Network, \texttt{markus.levin@xyo.network}} 216 | , Scott Scheper 217 | \thanks{XYO Network, \texttt{scott.scheper@xyo.network}} 218 | } 219 | 220 | \date{January 2018} 221 | 222 | \begin{document} 223 | \maketitle 224 | 225 | \begin{center} 226 | \line(1,0){50} 227 | \end{center} 228 | 229 | %Abstract Section 230 | \begin{abstract} 231 | With the growing presence of connected, location-reliant technologies, our privacy and safety rely heavily on the \gls{accuracy} and validity of location information. Various attempts have been made to eliminate the need for centralized entities controlling the flow of location data, but every attempt has relied on the integrity of the devices collecting this data in the physical world. We propose a \gls{trustless}, cryptographic location network using a novel formulation reliant on a chain of zero-knowledge proofs to establish a high degree of data \gls{certainty} on location information. The \textbf{\Gls{xy-oracle-network}} is an abstraction that enables layered, location verification across many device classes and protocols. At its core sits a set of novel cryptographic mechanisms known as \textbf{\Gls{proof-of-origin}} \& \textbf{\Gls{bound-witness}} that tie together the power of blockchain technology and real world data collection into a system with direct applications today. 232 | 233 | \begin{center} 234 | \line(1,0){50} 235 | \end{center} 236 | \end{abstract} 237 | 238 | %Introduction 239 | \section{Introduction} 240 | With the advent of blockchain-based, \gls{trustless} \glspl{smart-contract}, the need for \gls{oracle} services that arbitrate the outcome of a contract has grown significantly. Most current implementations of smart contracts rely on a single or aggregated set of authoritative oracles to settle the outcome of the contract. In cases where both parties can agree on the authority and incorruptibility of the specified oracle, this is sufficient. However, in many cases, either an appropriate oracle does not exist or the oracle cannot be considered authoritative because of the possibility of error or corruption. 241 | 242 | Location oracles fall into this category. The divination of the location of a physical world item relies on the reporting, relay, storage, and processing components of the given oracle, all of which introduce error and can be corrupted. Risks include data manipulation, data pollution, data loss, and collusion. 243 | 244 | \clearpage 245 | Thus the following problem exists: \textbf{both \gls{certainty} and \gls{accuracy} of the location are negatively impacted by the lack of a trustless, decentralized location oracle.} Platforms such as Ethereum and EOS have been used extensively for their power to mediate interactions securely online with the primary use cases involving escrows for fundraising escrows in the form of ICOs. However, up to this point, every platform has focused entirely on the online world and not on the physical world due to noisy, corruptible data integrity of current information channels. 246 | 247 | The \Gls{xyo-network} has been working towards the concept of enabling developers, such as those writing smart contracts for blockchain platforms, to interact with the physical world as if it were an API. The XYO Network is the world's first oracle protocol that makes it possible for two entities to transact in the real world without a centralized third party. Our abstractions allow us to make location verification trustless for developers, creating a protocol with novel use cases that have not been possible until today. 248 | 249 | The XYO Network will be built upon an existing infrastructure of over 1,000,000 devices circulating in the world that were distributed through their consumer-facing findables business. XY's Bluetooth and GPS devices allow everyday consumers to place physical tracking beacons on the things they want to keep track of (such as keys, luggage, bikes and even pets). If they misplace or lose such an item, they can see exactly where it is by viewing its location on a smartphone application. In just six years, the XYO Network has created one of the largest consumer Bluetooth and GPS networks in the world. 250 | 251 | \section{Historical Background \& Previous Approaches} 252 | \subsection{Proof of Location} 253 | 254 | The concept of provable location has been around since the 1960s, and can even be dated back to the 1940s with ground-based radio-navigation systems, such as LORAN \cite{blanchard-loran}. Today, there are location services that stack multiple mediums of verification on top of one another to create a Proof of Location through triangularization and GPS services. However, these approaches have yet to address the most critical component we face in location technologies today: designing a system that detects fraudulent signals and disincentivizes the spoofing of location data. For this reason, we propose that the most significant crypto-location platform today will be the one that focuses most on proving the origin of physical location signals. 255 | 256 | Surprisingly, the concept of applying location verification to blockchain technologies first appeared in September 2016 at Ethereum's DevCon 2. It was introduced by Lefteris Karapetsas, an Ethereum developer from Berlin. Karapetsas' project, \textit{Sikorka}, enabled \glspl{smart-contract} to be deployed on the spot in the real world, using what he termed, ``\textit{Proof of Presence}.'' His application of bridging location and the world of blockchain focused primarily on augmented reality use cases; and he introduced novel concepts such as challenge questions in proving one's location \cite{karapetsas-sikorka}. 257 | 258 | %TODO(Christine - DONE) %https://www.reddit.com/r/ethereum/comments/539o9c/proof_of_location/ 259 | On September 17th, 2016, the term, ``\textit{Proof of Location},'' formally surfaced in Ethereum's community \cite{diferrante-proofoflocation}. It was then further expounded upon by Ethereum Foundation developer, Matt Di Ferrante: 260 | 261 | \begin{displayquote}\textit{``Proof of Location you can trust is honestly one of the most difficult things to implement. Even if you have many participants that can attest each other's location, there's no guarantee that they wouldn't just go sybil at any point in the future, and since you're always only relying on majority reporting it's a huge weakness. 262 | If you could require some type of specialized hardware device that has anti-tamper tech such that the private key is destroyed when one attempts to open it or change the firmware on it then you could possibly have greater security, but at the same time, it's not like it's impossible to spoof GPS signals either. 263 | A proper implementation of this requires so much fallback and so many different data sources to have any assurance of accuracy, it would have to be very well funded project.''} \cite{diferrante-proofoflocation} 264 | 265 | \vspace{2mm} 266 | ---Matt Di Ferrante, Developer, Ethereum Foundation 267 | \end{displayquote} 268 | 269 | 270 | \subsection {Proof of Location: Shortcomings} 271 | % The Importance of Location Being Platform-agnostic: 272 | 273 | In summary, Proof of Location can be understood as leveraging blockchain's powerful properties, such as time-stamping and decentralization, and combining them with off-chain, location-aware device(s) that are \textit{hopefully} resistant to spoofing. We refer to the realm of cryptographic location technology as ``\textit{\gls{crypto-location}}.'' Moreover, similar to how the weakness of \glspl{smart-contract} centers around \glspl{oracle} using a single source of truth (and thus have a single source of failure), crypto-location systems face the same problem. The vulnerability in current crypto-location technologies revolves around the off-chain devices that report back an object's location. In smart contracts, the off-chain data source is an oracle. In the \Gls{xyo-network}, the off-chain data source moves around in the real world as a specialized type of oracle we call a \Gls{sentinel}. The core innovation surrounding the XYO Network centers around an identityless, location-based proof underlying the components of our system to create a \gls{trustless}, crypto-location protocol. 274 | \begin{center} 275 | \line(1,0){50} 276 | \end{center} 277 | 278 | %****** 279 | %Begin The XY Oracle Network 280 | %****** 281 | \section {The XY Oracle Network} 282 | 283 | \begin{displayquote}\textit{``The need for a difficult-to-disrupt system to complement GPS has been well known for years. GPS is exceptionally accurate and dependable, yet jamming, spoofing, cyber attacks and other forms of interference appear to be growing in frequency and severity. This has the potential for devastating effects on our lives and economic activity.''} \cite{goward-resiliant} 284 | 285 | \vspace{2mm} 286 | ---Dana Goward, President, RNT Foundation 287 | \end{displayquote} 288 | 289 | \subsection{Introduction} 290 | The goal of the \Gls{xyo-network} is to create a \gls{trustless}, decentralized system of location \glspl{oracle} that is resistant to attack and produces the highest \gls{certainty} possible when queried for available data. We accomplish this through a set of abstractions that greatly reduces the risk of location spoofing through a chain of zero-knowledge proofs along the components of the system. 291 | 292 | \subsection {Network Overview} 293 | Our system provides an entry point into a protocol of connected devices that provides high \gls{certainty} on location data through a chain of cryptographic proofs. Users are able to issue transactions, called ``\textit{queries},'' in order to retrieve a piece of location data on any blockchain platform possessing \gls{smart-contract} functionality.\footnote{Ethereum, Bitcoin + RSK, Stellar, Cardano, IOTA, EOS, NEO, Dragonchain, Lisk, RChain, Counterparty, Monax and others} Aggregators from the \Gls{xyo-network} then listen to these queries issued to the contract and fetch the answers that have the highest accuracy from a decentralized set of devices that relay cryptographic proofs back up to these aggregators. These aggregators then feed these answers back into the smart contract after reaching a consensus on the answer with the best score. This network of components makes it possible to determine if an object is at a specific XY-coordinate at a given time, with the most provable, \gls{trustless} certainty possible. 294 | 295 | The XYO Network has four primary components: \textbf{\Glspl{sentinel}} (The Data Gatherers), \textbf{\Glspl{bridge}} (The Data Relayers), \textbf{\Glspl{archivist}} (The Data Storers), and \textbf{\Glspl{diviner}} (The Answer Aggregators). Sentinels gather location information via sensors, radios, and other means. Bridges take this data from Sentinels and provide them to Archivists. Archivists store this information for Diviners to analyze. Diviners analyze location \glspl{heuristic} from Archivists in order to generate answers to queries and assign accuracy scores to them. Diviners then relay these answers back into a smart contract (thusly, Diviners serve as \glspl{oracle}). The accuracy score, named the \textbf{\Gls{origin-chain-score}}, is determined through a set of zero-knowledge proofs known as a \textbf{\Gls{proof-of-origin-chain}}. This chain guarantees two or more pieces of data originated from the same source without revealing any underlying information. Each component along the query's path generates its own \Gls{proof-of-origin} that is then chained to each component it relays data to. Proof of Origin is a novel formulation that builds a chain of cryptographic guarantees along a path of relayers in the network in order to offer high confidence of real world data. This \textbf{Proof of Origin Chain} encapsulates the confidence we can have in a piece of location data all the way down to the very first devices that gathered the data. We will explore how Proof of Origin works in-depth in the following section. 296 | 297 | To establish a decentralized consensus mechanism among Diviners, the XYO Network will rely on a public, immutable blockchain known as the \textbf{\Gls{xyomainchain}} that stores query transactions along with data gathered from Diviners and their associated origin score. Before we dive into the details of the functionality of the entire system, we will clearly define the responsibilities of each component in our network. 298 | 299 | \subsubsection{Sentinels} 300 | 301 | \Glspl{sentinel} are location witnesses. They observe data \glspl{heuristic} and vouch for the \gls{certainty} and \gls{accuracy} of the heuristic by producing temporal ledgers. The most important aspect of Sentinels is that they produce ledgers that other components can be certain came from the same source. They do this by adding \Gls{proof-of-origin} to a relay chain of cryptographic proofs. Given that the \Gls{xyo-network} is a \gls{trustless} system, Sentinels must be incentivized to provide honest location information. This is done by combining a reputation component with a payment component. A Sentinel is rewarded with XYO Network Tokens (XYO) when their information is used to answer a query. To increase their odds of being rewarded, they must create ledgers that are consistent with that of their peers and provide Proof of Origin to identify themselves as the source of the location information. 302 | 303 | \subsubsection{Bridges} 304 | 305 | \Glspl{bridge} are location data transcribers. They securely relay location ledgers from \Glspl{sentinel} to \Glspl{archivist}. The most important aspect of a Bridge is that an Archivist can be sure that the \gls{heuristic} ledgers that are received from a Bridge have not been altered in any way. The second most important aspect of a Bridge is that they add an additional \Gls{proof-of-origin}. Given that the \Gls{xyo-network} is a \gls{trustless} system, Bridges must be incentivized to provide an honest relaying of heuristics. This is done by combining a reputation component with a payment component. A Bridge is rewarded with XYO Network Tokens (XYO) when the information that they have relayed is used to answer a query. To increase their odds of being rewarded, they must create ledgers that are consistent with that of their peers and provide Proof of Origin to identify themselves as the relay of the heuristic. 306 | 307 | \subsubsection{Archivists} 308 | 309 | \Glspl{archivist} store location information from \Glspl{bridge} in a decentralized form with the goal of having all historical ledgers stored. Even if some data is lost or becomes temporarily unavailable, the system continues to function, just with reduced accuracy. Archivists also index ledgers so that they can easily return a string of ledger data if needed. Archivists store raw data only and get paid XYO Network Tokens solely for retrieval of the data and its subsequent use. Storage is always free. 310 | 311 | Archivists are networked, so asking one Archivist will result in that Archivist asking other Archivists for data that it does not contain. An Archivist can optionally store any ledger information that is returned to it. This will most likely result in two types of Archivists: ones that are at the data production edge of the ``cloud'' and the ones that are at the data consumption edge of the ``cloud.'' Archivists in the middle will be hybrids. The choice to store data is not enforced, but can easily be done through IPFS or another decentralized storage solution. Each time data is handed off from one Archivist to another, additional Proof of Origin is appended in order to track payment, since all Archivists get paid. For a retrieval, a minimum Proof of Origin level can be set to increase validity. The interests of \Glspl{sentinel}, Bridges, and Archivists must be aligned to prevent data bloat. 312 | 313 | \subsubsection{Diviners} 314 | 315 | \Glspl{diviner} are the most complex part of the \Gls{xyo-network}. The overall goal of a Diviner is to fetch the most accurate data for a query from the XYO Network and relay that data back to the issuer of that query. Diviners poll the applicable blockchain platform (i.e. Ethereum, Stellar, Cardano, IOTA, etc.) for queries issued to the XYO \gls{smart-contract}. Then, they find the answer to the query by interacting directly with the \Gls{archivist} network to fetch the answer with the highest \gls{accuracy}/confidence score. They do this by judging the witness with the best \Gls{proof-of-origin} chain. The Diviners that fetched the answer with the best score in the shortest amount of time will have the ability to create a block on the main XYO blockchain (\Gls{xyomainchain}) through \Gls{proof-of-work}. Queries are prioritized by reward size and complexity, so the more XYO offered for an answer, the higher in priority the query would be. 316 | 317 | Other Diviners reach consensus on the validity of a block and digitally sign the block. The Diviner that was the coinbase address in that block will then send a transaction to the smart contract containing the answer along with its accuracy score. It also sends a list of other Diviners' signatures in order to prevent an attacker from issuing fake information into the blockchain by pretending to be a Diviner. The smart contract can then verify the integrity of this information by checking the payload's signature list. 318 | 319 | 320 | \subsection{End-to-End Functionality} 321 | 322 | Now that the responsibilities of each component are detailed, here is an end-to-end example of how the system will work: 323 | 324 | \begin{enumerate} 325 | \item \textbf{Sentinels Gather Data} 326 | \begin{itemize} 327 | \item \Glspl{sentinel} gather real world location heuristics and prepare their own \Gls{proof-of-origin} to be chained to nodes above them 328 | \end{itemize} 329 | \item \textbf{Bridges Gather Data From Sentinels} 330 | \begin{itemize} 331 | \item \Glspl{bridge} gather necessary data from online Sentinels and append Proof of Origin to their chain. Bridges then make themselves available to \Glspl{archivist} in the Network. 332 | \end{itemize} 333 | \item \textbf{Archivists Index/Assemble Data from Bridges} 334 | \begin{itemize} 335 | \item Bridges constantly send information to Archivists that are then kept on decentralized stores along with a location \gls{heuristic} index. 336 | \end{itemize} 337 | \item \textbf{Diviner Fetches a User's Query} 338 | \begin{itemize} 339 | \item \Glspl{diviner} poll for queries sent to the Ethereum \gls{smart-contract} and decide to begin the answer formulation process 340 | \end{itemize} 341 | \item \textbf{Diviner Collects Data From Archivists} 342 | \begin{itemize} 343 | \item Diviners then decide to take on a query by fetching the appropriate information needed from the Archivist network. 344 | \end{itemize} 345 | \item \textbf{Diviner Formulates Answer} 346 | \begin{itemize} 347 | \item Diviners choose the \Gls{best-answer} to the query from the Archivist network that contains the best \Gls{origin-chain-score}. 348 | \end{itemize} 349 | \item \textbf{Diviner Proposes Block} 350 | \begin{itemize} 351 | \item Diviners then propose blocks on the \Gls{xyomainchain} containing the answer contents, the query, and the XYO Tokens (XYO) paid through \Gls{proof-of-work}. Other Diviners on the network digitally sign the block's content, then the coinbase Diviner's account nonce is updated to showcase its Proof of Work in the system once a consensus on a valid block is reached. 352 | \end{itemize} 353 | \item \textbf{Diviner Returns Result to Query Initiator} 354 | \begin{itemize} 355 | \item Diviners package the answer, its Origin Chain Score, and its set of digital signatures and send them to an adapter component that securely connects to the XYO smart contract. The adapter is in charge of making sure the integrity of the Diviner has not been compromised and sends the set of digitally signed answers to the smart contract. This happens right after the block creation process. The coinbase Diviner is then paid for its efforts. 356 | \end{itemize} 357 | \item \textbf{XYO Network Components Get Rewarded for Their Work} 358 | \begin{itemize} 359 | \item The components along the \Gls{proof-of-origin-chain} get paid for their involvement in fetching the answer to the query. Sentinels, Bridges, Archivists, and Diviners are all rewarded for their work. 360 | 361 | \end{itemize} 362 | \end{enumerate} 363 | 364 | In the case that the same query is asked more than once, more than one answer may be produced since the answer that is produced at a given moment is based on the available heuristic the system can offer at that time. Submitting an answer to the blockchain takes two steps. First, an analysis must be done to determine the \Gls{best-answer} to a query. If multiple answers are generated by the system, then nodes will compare the answers and always choose the better answer. An example of a simple query would be: ``\textit{Where was a node on the network at a specific time in the past?}'' 365 | 366 | \subsection{Blockchain As a Single Source of Truth} 367 | 368 | At their core, \Glspl{diviner} simply transform relative data into absolute data. They are able to explore the entire \Gls{archivist} network to concretize an absolute answer to a query on the \Gls{xyo-network}. Diviners are also the nodes that propose and add blocks to the \Gls{xyomainchain}, and get rewarded for their \Gls{proof-of-work}. Because the Archivist network is a store of unprocessed data and the blockchain is a store of absolute, processed data, the network can eventually use the latest information on the XYOMainChain to answer future queries instead of relying on expensive computation through the Archivist Network. 369 | 370 | Since blocks on the XYOMainChain store the \Gls{proof-of-origin-chain} and graph of components that were used to answer queries, future Diviners can explore this absolute data to achieve accurate results with lower bandwidth usage. As such, the XYOMainChain will gradually become the most important source of truth of the system. However, an Archivist network will still be required in order to maintain the most up-to-date information on location \glspl{heuristic} gathered by \Glspl{sentinel}. 371 | 372 | \subsection{XYO Network’s Framework For Selecting The Best Answer Candidate} 373 | 374 | We define the \textit{\Gls{best-answer}} as the single answer, amongst a list of Answer Candidates, that returns the highest validity score and has a higher \gls{accuracy} score than the minimum required accuracy. The validity score is based on the \Gls{origin-chain-score}. The system knows what the highest record Origin Score is, which would be the 100 percent until a higher score is achieved, which then becomes the new 100 percent. The \Gls{xyo-network} allows selection of the \Gls{best-answer-algorithm} for determining the Best Answer. This creates expansion for future research into alternative algorithms. 375 | 376 | When data is excluded from an answer due to it being considered bad or incorrect, it will be circulated to archivists so that they can purge that data from their decentralized stores. 377 | 378 | \subsection{Initial Integration With Public Blockchains} 379 | 380 | The \Gls{xyo-network} is designed to be an abstraction that can interact with any \gls{smart-contract} capable, public blockchain such as Ethereum, Bitcoin + RSK, EOS, NEO, Stellar, Cardano and others. To interact with the XYO Network, users on Ethereum, for instance, can issue queries to our XYO smart contract and pay in XYO Tokens (ERC20). The nodes in our own XYO Blockchain, called \Glspl{diviner}, would constantly be polling Ethereum for these queries and be rewarded in the native currency of our own XYO Blockchain (also called XYO Tokens). In the future, we will do a one-to-one conversion from holders of our ERC20 token into our own blockchain's native currency in order to provide our platforms with transaction fees that support micropayment requirements necessary for scalable IoT use cases. In these cases, we will allow users to issue queries directly to our blockchain instead of interacting through a public smart contract. 381 | 382 | 383 | \begin{center} 384 | \line(1,0){50} 385 | \end{center} 386 | 387 | \section{Proof of Origin} 388 | \textbf{With a physical network comprised of untrusted nodes it is possible to determine the \gls{certainty} of data that has been provided by edge nodes based on a zero-knowledge proof that two or more pieces of data originated from the same source.} Using these data sets, combined with a number of similar data sets and the knowledge of at least one node’s absolute location, the absolute location of the other node can be ascertained. 389 | 390 | \subsection{Proof of Origin Introduction} 391 | 392 | Traditional \gls{trustless} systems rely on a private key for signing transactions or contracts in a system. This works very well with the assumption that the node on the network that signs the data in question is physically and virtually secure. However, if the private key is compromised, then the ability to prove origin falters. 393 | 394 | When applying trustless concepts to the Internet of Things, it must be assumed that edge nodes on the network are not physically or virtually secure. This brings forth the need to identify edge nodes without the use of unique IDs and to instead judge the data produced by them as being honest and valid without any knowledge from outside the network. 395 | 396 | \subsection{The Core of Proof of Origin: Bound Witnesses} 397 | 398 | \Gls{proof-of-origin} relies on the concept of a \textit{\Gls{bound-witness}}. Given that an untrusted source of data used to resolve a digital contract (an \gls{oracle}) is not useful, we can substantially increase the \gls{certainty} of the data provided by first establishing the existence of a bidirectional proof of location. The primary bidirectional location \gls{heuristic} is proximity, since both parties can validate the occurrence and range of an interaction by cosigning the interaction. This allows for a zero-knowledge proof that the two nodes were in proximity of each other. 399 | 400 | We then need to determine the certainty that an oracle witness node in a \gls{trustless} system gathered the data that it is sharing. In a trustless system, a witness node can either by defect or corruption produce false data. Invalid data can be detected and removed simply if it falls outside the allowed range for that heuristic. Valid but incorrect data (i.e. false data) is much more difficult to detect. 401 | 402 | \subsection {Unidirectional vs. Bidirectional Location Heuristics} 403 | Most data related to the physical world (a \gls{heuristic}) is unidirectional. This means that the element being measured cannot measure back, making unidirectional heuristic data very difficult to validate. A bidirectional heuristic is one where the measured element can report its own measurement back to the other party, which makes validation possible. Location is a rare heuristic in that it can be bidirectional, with two edge nodes reporting on each other. \textbf{A real-world example of this would be two people who are near each other taking a selfie, printing a copy for each party, and then both signing the selfie. This process would give both parties Proof of Proximity. The only way for these two people to have gotten this ``data'' would be from them having been together in the same location.} 404 | 405 | Next, let us discuss network effects: Imagine a system where every edge node is expected to constantly produce these ``selfies'' as they travel around, and store them in a binder. They are also expected to keep that binder in time-sequential order and are never allowed to delete one. This establishes a proximity recorder for each edge node that can be cross referenced with the recorders of the other edge nodes. 406 | 407 | \subsection {Non-Edge Nodes} 408 | All nodes are considered ``witnesses,'' including bridge, relay, storage, and analysis nodes. This allows for any data that is relayed from one node to the next to be bound. This is the concept of the \textbf{\Gls{bound-witness}}. 409 | 410 | \subsection {Cross Reference} 411 | Analyzing every set of ``selfies'' that is produced and chained together by every edge node allows the system to produce the \Gls{best-answer} from the relative proximity of all the nodes that are in the network. If every node reports honestly and accurately, the mapping of all the relative positions of the edge nodes will achieve the maximum \gls{certainty} and \gls{accuracy} possible: 100 percent. Conversely, if every node is either dishonest or flawed, the certainty and accuracy both can approach the minimum of 0 percent. 412 | 413 | Given a set of reported data and a query for a relative position of one of the edge nodes, an approximation of the position can be generated along with coefficients for certainty and accuracy. 414 | 415 | Given the same set of data and the same analysis algorithm, every calculation should arrive at the same position approximation and the same coefficients for certainty and accuracy. 416 | 417 | \subsection {Diagram} 418 | \textit{S'} and \textit{S''} (Figure 1.) are each a \Gls{sentinel} (edge node) that collect \glspl{heuristic}. When in contact with each other, they exchange heuristic data and public keys. Both build a full record of the interaction and sign the resulting interaction. That signed record then becomes the next entry in both of their local ledgers (\texttt{16} for \textit{S'} and \texttt{3} for \textit{S''}). This action binds these two witnesses as being within proximity of each other. 419 | 420 | \includegraphics [width=\textwidth]{boundwitness} 421 | \begin{center}\textbf{Figure 1.} Witness Binding Example Between Two Sentinels 422 | \end{center} 423 | 424 | \subsection{Origin Chains} 425 | 426 | Each origin maintains its own ledger and signs it to make a \Gls{proof-of-origin-chain}. Once information on the Proof of Origin Chain has been shared, it is effectively permanent. This is because the fork that happens after the share ends the chain and makes all future data from the witness to be treated as if it were from a new witness. To generate a link in a Proof of Origin Chain, the origin generates a public/private key pair. It then signs both the previous and next blocks with the same pair after including the public key in both blocks. Immediately after the signature is made, the private key is deleted. With the immediate deletion of the private key, the risk of a key being stolen or reused is greatly minimized. 427 | 428 | Proof of Origin Chains are the key to verifying that ledgers flowing into the \Gls{xyo-network} are valid. A unique ID for source of data is not practical since it can be forged. Private key signing is not practical since most parts of the XYO Network are difficult or impossible to physically secure, thus the ability for a bad actor to steal a private key is too feasible. To solve this, XYO Network utilizes \Glspl{transient-key-chain}. The benefit of their usage is that it is impossible to falsify the chain of origin for data. However, once the chain is broken, it is broken forever and cannot be continued, rendering it an island. 429 | 430 | Every time a \gls{heuristic} ledger is handed off in XYO Network, the receiver appends their own \Gls{proof-of-origin}, which makes the Proof of Origin Chain longer and generates a Proof of Origin Intersection. Proof of Origin Chains and Proof of Origin Intersections are the primary indicators used by \Glspl{diviner} to verify validity of ledgers. The equation for a Ledger Reputation is effectively what percent of the XYO Network was involved in making the Proof of Origin Ball associated with it. In theory, if 100 percent of the XYO Network records are linked with Proof of Origin and then fully analyzed, the odds of it being valid is 100 percent. If 0 percent of XYO Network records are available for analysis, then validity drops to 0 percent. 431 | 432 | For added security, the public key for a Chain Link is not provided until the second entry for it is made available. This also allows for the time interval between entries or other data to be stored in the previous or next link. 433 | 434 | \subsection {Origin Chain Score} 435 | \Gls{origin-chain-score} is calculated as follows (default algorithm): 436 | 437 | \begin{itemize} 438 | \item \textit{PcL} = \Gls{proof-of-origin-chain} Length 439 | \item \textit{PcD} = Proof of Origin Chain Difficulty 440 | \item \textit{Pc' Pc'' O} = Proof of Origin Chain Overlap for \textit{Pc'} and \textit{Pc''} 441 | \end{itemize} 442 | 443 | \begin{equation*}\tag{1} \label{eq1} 444 | Score = \prod_{i=0}^{i=n} \frac{PcL*PcD}{Pc' Pc'' O} 445 | \end{equation*} 446 | 447 | \subsection {Origin Tree} 448 | An \Gls{origin-tree} is used to calculate the approximate validity of an answer. It uses the data gathered to generate an Ideal Tree, which is the tree that best fits that data for a given asserted answer. If node \textit{N} is located at X,Y,Z,T location, the error across all the data in the set must hold a certain value. To compute this error, we would calculate the MIN, MAX, MEAN, MEDIAN, and AVERAGE DISTANCE FROM THE MEAN. 449 | 450 | Given a set \textit{S} of all scores \textit{s}, a \Glspl{proof-of-origin-chain} Difficulty \textit{PcD}, and an error factor \textit{error}, the \Gls{best-answer} determined as follows: 451 | 452 | \begin{equation*}\tag{2} \label{eq2} 453 | Best Answer Score = \max_{\forall s \in S_j}[PcD * (\texttt{1} - error)] 454 | \end{equation*} 455 | 456 | In other words, the asserted answer that has the highest Best Answer Score is the \Gls{best-answer}. Using the Proof of Origin Tree, we can identify and prune impossible branches (outliers). 457 | 458 | \subsection{Transient Key Chaining} 459 | 460 | A series of data packets can be chained together by using temporary private keys to sign two successive packets. When the public key paired with the private key is included in the data packets, the receiver can verify that both packets were signed by the same private key. The data in the packet cannot be altered without breaking the signature, assuring that the signed packets were not altered by a third party, such as a \Gls{bridge} or storage node. 461 | 462 | \subsection {Link Depth} 463 | At a minimum, a node generates a new public/private key pair for every link in the \Gls{proof-of-origin-chain}, which has a Link Depth of \texttt{1}. There may be \texttt{N} entries in the link table for a given \textit{Ledger Entry}, with each entry specifying the distance in the future when part two of the link will be added. No two links may have the same order of magnitude on a base 2 scale. For example, the entry \texttt{[1,3,7,12,39]} would be allowed, but \texttt{[1,3,7,12,15]} would not. 464 | 465 | The depth \texttt{1} link is created, used and deleted when the previous block is published. However, links of depth greater than \texttt{1} have their pair generated as the previous block is being signed, and the second signing does not happen until \texttt{N} blocks later, after which the private key is deleted. For this reason, links of depth greater than 1 are always considered to be less secure than links of depth \texttt{1}, but they can be used to improve performance and reduce data loss at the cost of that security. 466 | 467 | \subsection {Fixed Order} 468 | The key element in determining the sequence of ledgers is the order in which they were reported. Given that it is not possible for a device to change the order of any \Gls{proof-of-origin} signed ledger, an absolute order can be established by looking at all the ledgers collectively. 469 | 470 | \subsection {Second-to-Last Publishing} 471 | A primary method for establishing \Gls{proof-of-origin} is based on the fact that a \Gls{sentinel} always reports its second to last block without reporting the last block. This allows the last block to have the signed link to its predecessor as evidence of the link. 472 | 473 | \subsection {Empty Links} 474 | To make a \Gls{proof-of-origin-chain} more secure, it is required that the chain is updated no more than once every ten seconds and no less than once every sixty minutes. In the case that no new data is available, an empty block will be added to the chain. 475 | 476 | \subsection {Diagram} 477 | As time travels from left to right (Figure 2.), the \Gls{proof-of-origin-chain} that is being built gets longer. At any given time, the producer of the chain will only provide to the caller the entries with darkened borders, waiting for the second signing of the entry before making it available. For example, in the 3rd column, only entries \texttt{2} and \texttt{1} will be returned as being part of the chain. 478 | 479 | \includegraphics[width=\textwidth] {proofoforigin} 480 | \begin{center}\textbf{Figure 2.} Link inclusion example in a Proof of Origin Chain 481 | \end{center} 482 | 483 | \subsection {Summary} 484 | \textbf{Given a series of data packets that are signed in sequential pairs with temporary private keys and include the paired public keys, it can be determined with absolute \gls{certainty} that the packets came from the same origin.} 485 | 486 | \begin{center} 487 | \line(1,0){50} 488 | \end{center} 489 | 490 | \section{Security Considerations} 491 | 492 | \subsection{Fake Diviner Attack} 493 | 494 | A set of digital signatures are sent to the XYO \gls{smart-contract} because the contract needs to verify the integrity of the \Gls{diviner} that sent the answer. The contract can then verify the other Diviners that signed this list within a high confidence interval. Without this, the relaying oracle would be the single source of failure and risk within the system. 495 | 496 | \subsection{Sentinel DDoS Attacks} 497 | 498 | Another attack to consider is a Distributed Denial of Service (DDoS) among \Gls{sentinel} nodes in a particular region. An attacker could attempt to establish a large number of connections to Sentinels in order to prevent them from relaying the correct information or relaying any information at all to the \Glspl{bridge}. We can circumvent this problem by requiring a small cryptographic puzzle to be solved by anyone attempting to connect to a Sentinel. Since a query won't involve a very large number of connections to Sentinels, this will not impose a heavy bearing on the XYO relay system, and will require an attacker to spend a large amount of resources to execute a successful DDoS our network. At any given point in time, a \Gls{proof-of-origin-chain} can be verified by anyone as it is stored on the \Gls{xyomainchain}. This ensures that if a single entity along the chain was compromised, the accuracy of the query's answer (\Gls{origin-chain-score}) will drop to 0. 499 | 500 | \begin{center} 501 | \line(1,0){50} 502 | \end{center} 503 | 504 | \section {XYO Token Economy} 505 | 506 | \Glspl{oracle} stand as a significant portion of the power and infrastructure needs for decentralized applications, with most of the focus revolving around the connectivity and aggregation of authoritative oracles. We believe that the need for a fully decentralized and \gls{trustless} system of oracles is needed for decentralized applications to reach their maximum potential. 507 | 508 | 509 | \subsection {XYO Network Cryptoeconomics} 510 | We use XYO Tokens to incentivize the desired behavior of providing accurate, reliable location \glspl{heuristic}. XYO Tokens can be thought of as ``gas'' needed to interface with the real world in order to verify the XY-coordinate of a specified object. 511 | 512 | The process works like this: A token holder first queries the \Gls{xyo-network} with a query (e.g. \textit{``Where is my eCommerce order package with XYO Address} \texttt{0x123456789...?}''). The query then gets sent into a queue, where it waits to be processed and answered. A user can set their desired confidence level and XYO gas price at query creation. The cost of a query (in XYO Tokens) is determined by the amount of data required to provide an answer to the query as well as market dynamics. The more data needed, the more expensive the query and higher the XYO gas price. Queries to the XYO Network have the potential to be very large and expensive. For instance, a trucking and logistics company could query the XYO Network to ask, ``\textit{What is the location of every single car in our fleet?}'' 513 | 514 | Once the XYO Token holder queries the XYO Network and pays the requested gas, all \Glspl{diviner} working on the task call out to the relevant \Glspl{archivist} to retrieve the pertinent data needed to answer the query. The data returned is derived from the \Glspl{bridge}, who originally gathered the data from the \Glspl{sentinel}. Sentinels are essentially the devices or signals that verify the location of objects. These include entities such as Bluetooth trackers, GPS trackers, geo-location tracking built into IoT devices, satellite tracking technology, QR-code scanners, RFID scanning and many others. XY Findables has pioneered and launched its consumer Bluetooth and GPS business, which has allowed it to test and process real-world location heuristic. All efforts in developing the XY Findables consumer business have served to help significantly in designing the XYO Network Blockchain Protocol. 515 | 516 | If the data provided by a Sentinel device (such as a Bluetooth Beacon) is used to answer a query, then all four components involved in the transaction receive a portion of the XYO gas paid by the token holder: the Diviner (who searched for the answer), the Archiver (who stored the data), the Bridge (who transmitted the data) and the Sentinel (who recorded the location data). The distribution of the gas between 3 of the 4 components of the XYO Network is always given in the same proportion. The exception is that of Diviners, whose involvement in the process of providing an answer is more extensive. Within each component, gas gets distributed evenly. 517 | 518 | \subsection{Rewards for Independence} 519 | 520 | Location-gathering devices are the atomic blocks of the network, and a single device may act as one or more of the four components of the system. However, it would be rare, especially in a large \Gls{xyo-network}, that devices would be more than two of these components. Furthermore, a blockchain ledger that has more independent \Gls{proof-of-origin} will hold higher regard, so there is a \glspl{cryptoeconomics} penalty for a device acting as multiple components. 521 | 522 | \subsection{Rewards for Stationarity Integrity} 523 | 524 | \Glspl{sentinel} in the \Gls{xyo-network} are assigned a stationarity coefficient for their quantity of movement throughout their lifecycle. The less a Sentinel moves in a period of time, the more its data can be trusted. \Glspl{archivist} keep track and analyze these stationarity coefficients when considering which Sentinels to route queries to. 525 | 526 | \subsection{Incentivizing Token Usage} 527 | A system in which token holders are encouraged \textit{not} to use their tokens creates a long-term problem for the underlying economy. It creates an ecosystem with very scarce stores of value and triggers a natural impulse to invent reasons for \textit{not} using the token, instead of boosting utility and liquidity. 528 | 529 | The problem most \glspl{cryptoeconomics} incentives have is that the focus is placed too strongly on the token miners (e.g. \Glspl{sentinel}, \Glspl{bridge}, \Glspl{archivist}, \Glspl{diviner}), and not at all on the token users. The XYO Token takes both into account. 530 | 531 | The XYO Token model incentivizes the miner to not just provide accurate data, but to also know when to not provide data at all. The end user is rewarded to transact more when network liquidity is low, compared to when network liquidity is high. Thus the ecosystem of the XYO Token has the ability to remain well-balanced, fluid and robust. 532 | 533 | \subsection {XYO Token Specifications} 534 | The public token sale has a tiered pricing structure that starts at 1 ETH: 100,000 XYO and maxes out at 1 ETH: 33,333 XYO. Details regarding our volume and time based pricing structure will be announced soon. 535 | \begin{itemize} 536 | \item Smart contract platform: Ethereum 537 | \item Contract Type: ERC20 538 | \item Token: XYO 539 | \item Token Name: \Gls{xyo-network} Utility Token 540 | \item Token Address: 0x55296f69f40ea6d20e478533c15a6b08b654e758 541 | \item Total issuance: Finite and capped at the amount reached after the Token Main Sale 542 | \item Projected XYO Token Cap: \$48 Million 543 | \item Unsold and Unallocated tokens: Burned after the token sale event. No further XYO tokens will be generated after the Main Sale ends. 544 | \end{itemize} 545 | 546 | \begin{center} 547 | \line(1,0){50} 548 | \end{center} 549 | 550 | %Use Cases Section 551 | \section{XYO Network Use Cases} 552 | 553 | The \Gls{xyo-network}'s usage has vast applications that span a multitude of industries. Take for example an eCommerce Company that could offer its premium customers payment-upon-delivery services. To be able to offer this service, the eCommerce company would leverage the XYO Network (which uses XYO Tokens) to write a \gls{smart-contract} (i.e. on Ethereum's platform). The XYO Network could then track the location of the package being sent to the consumer along every single step of fulfillment; from the warehouse shelf to the shipping courier, all the way into the consumer's house and every location in between. This could enable eCommerce retailers and websites to verify, in a \gls{trustless} way, that the package not only appeared on the customer's doorstep, but also safely inside their home. Once the package has arrived in the customer's home (defined and verified by a specific XY-Coordinate), the shipment is considered complete and the payment to the vendor gets released. The eCommerce integration of the XYO Network thusly enables the ability to protect the merchant from fraud and ensure consumers only pay for goods that arrive in their home. 554 | 555 | Consider an entirely different integration of the XYO Network with a hotel review site, whose current problem is that their reviews are often not trusted. Naturally, hotel owners are incentivized to improve their reviews at any cost. What if one could say with extremely high \gls{certainty} that someone was in San Diego, flew to a hotel in Bali and stayed there for two weeks, returned to San Diego, and then wrote a review about their hotel stay in Bali? The review would have a very high reputation, especially if it was written by a serial reviewer who has written many reviews with verified location data. 556 | 557 | \begin{center} 558 | \line(1,0){50} 559 | \end{center} 560 | 561 | \section {XYO Network Expansion} 562 | We are fortunate to have a consumer business that has successfully built a real-world network with over one million (1,000,000) Bluetooth and GPS devices in the world. Most location networks fail to reach this phase and attain the critical mass necessary to build out an extensive network. The \Gls{sentinel} network we have created is only the starting point. The \Gls{xyo-network} is an open system that any operator of location devices can plug into and begin earning XYO Tokens. 563 | 564 | Generally, the greater the Sentinel cardinality in the XYO Network, the more reliable it is. To further grow its network, the XYO Network is engaging with other businesses to expand its network of Sentinels beyond its own network of XY Findables beacons. 565 | 566 | % TODO: 567 | \section {Acknowledgements} 568 | This white paper is the product of an inspiring team effort that was made possible through the belief in our vision from the following individuals: Raul Jordan (Harvard College, Thiel Fellow and \Gls{xyo-network} Advisor); for his contributions in making our white paper more concise and helping us elegantly communicate its technical details to the world. We thank Christine Sako for her exceptional work ethic and attention to detail in her review of our work. The consistency in structure and best-practices observed in our white paper is the product of Christine's efforts. We thank Johnny Kolasinski for his research and compilation of applicable use cases. Last, we thank John Arana for his careful review and creative input. 569 | 570 | \begin{center} 571 | \line(1,0){50} 572 | \end{center} 573 | 574 | 575 | % TODO: Christine - DONE 576 | 577 | \begin{thebibliography}{9} 578 | 579 | \bibitem{blanchard-loran} 580 | Blanchard, Walter. 581 | \textit{Hyperbolic Airborne Radio Navigation Aids}. 582 | Journal of Navigation, 44(3), September 1991. 583 | 584 | \bibitem{karapetsas-sikorka} 585 | Karapetsas, Lefteris. 586 | \textit{Sikorka.io}. 587 | \\\texttt{http://sikorka.io/files/devcon2.pdf}. 588 | Shanghai, September 29, 2016. 589 | 590 | \bibitem{diferrante-proofoflocation} 591 | Di Ferrante, Matt. 592 | \textit{Proof of Location}. 593 | \\\texttt{https://www.reddit.com/r/ethereum/comments/539o9c/proof\_of\_location/}. 594 | September 17, 2016. 595 | 596 | \bibitem{goward-resiliant} 597 | Goward, Dana. 598 | \textit{RNT Foundation Testifies Before Congress}. 599 | US House of Representatives Hearing: ``Finding Your Way: The Future of Federal Aids to Navigation,'' Washington, DC, February 4, 2014. 600 | 601 | \end{thebibliography} 602 | 603 | \clearpage 604 | 605 | \printglossaries 606 | 607 | %******************************* 608 | %**** End Glossary Section ***** 609 | %******************************* 610 | 611 | \end{document} 612 | -------------------------------------------------------------------------------- /white-paper/images/boundwitness.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/white-paper/images/boundwitness.png -------------------------------------------------------------------------------- /white-paper/images/proofoforigin.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/XYOracleNetwork/papers-xyonetwork/b97c32d8b284a305e48b946b3d10922d5a07e666/white-paper/images/proofoforigin.png --------------------------------------------------------------------------------