├── .gitignore ├── economics ├── pricing_protocol │ ├── NuCypher_Network__Pricing_Protocol_Economics.pdf │ ├── pp.bib │ └── pp.tex └── staking_protocol │ ├── NuCypher_Staking_Protocol_Economics.pdf │ ├── Two_phase_model.png │ ├── graphs │ ├── CrossCorr_SR_DIF_14.pdf │ ├── CrossCorr_SR_DIF_21.pdf │ ├── CrossCorr_SR_DIF_28.pdf │ ├── CrossCorr_SR_DIF_7.pdf │ ├── CrossCorr_Yields_DIF_14.pdf │ ├── CrossCorr_Yields_DIF_21.pdf │ ├── CrossCorr_Yields_DIF_28.pdf │ ├── CrossCorr_Yields_DIF_7.pdf │ ├── SubsidyP1.pdf │ ├── SubsidyP2.pdf │ ├── one-step.png │ └── two-steps.png │ ├── main.tex │ ├── python_scripts │ ├── SubsidyP1.py │ └── SubsidyP2.py │ └── staking_protocol.bib ├── makefile ├── pdf ├── centralized-kms.pdf ├── decrypt.pdf ├── delegate.pdf ├── encrypt.pdf ├── hierarchical.pdf ├── miners-ruler.pdf ├── pre-kms.pdf └── pre.pdf ├── svg ├── centralized-kms.svg ├── decrypt.svg ├── delegate.svg ├── encrypt.svg ├── hierarchical.svg ├── miners-ruler.svg ├── pre-kms.svg ├── pre.svg └── templates │ ├── Locked.svg │ ├── Octicons-key.svg │ ├── cloud-2.svg │ ├── group.svg │ ├── human-figure.svg │ ├── kms.svg │ ├── mesh.svg │ ├── storage.svg │ ├── template.svg │ └── text-x-generic.svg ├── watch.sh ├── whitepaper.bib ├── whitepaper.pdf └── whitepaper.tex /.gitignore: -------------------------------------------------------------------------------- 1 | /whitepaperNotes.bib 2 | /arxiv-submission 3 | /*.tar.gz 4 | *.swp 5 | *.bbl 6 | -------------------------------------------------------------------------------- /economics/pricing_protocol/NuCypher_Network__Pricing_Protocol_Economics.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/pricing_protocol/NuCypher_Network__Pricing_Protocol_Economics.pdf -------------------------------------------------------------------------------- /economics/pricing_protocol/pp.bib: -------------------------------------------------------------------------------- 1 | 2 | @misc{statista1, 3 | title = {Number of monthly active WhatsApp users worldwide from April 2013 to March 2020}, 4 | year = {2020}, 5 | url = "https://www.statista.com/statistics/260819/number-of-monthly-active-whatsapp-users/#:~:text=Number%20of%20monthly%20active%20WhatsApp%20users%20as%20of%202013%2D2020&text=As%20of%20March%202020%2C%20WhatsApp,billion%20MAU%20in%20February%202016." 6 | } 7 | 8 | @misc{statista2, 9 | title = {Number of Snapchat users worldwide from 2018 to 2023}, 10 | year = {2020}, 11 | url = "https://www.statista.com/statistics/626835/number-of-monthly-active-snapchat-users/" 12 | } 13 | 14 | @misc{statista3, 15 | title = {Number of unique Viber user IDs from June 2011 to March 2020}, 16 | year = {2020}, 17 | url = "https://www.statista.com/statistics/316414/viber-messenger-registered-users/" 18 | } 19 | 20 | @misc{statista4, 21 | title = {Number of estimated Skype users registered worldwide from 2009 to 2024}, 22 | year = {2020}, 23 | url = "https://www.statista.com/statistics/820384/estimated-number-skype-users-worldwide/" 24 | } 25 | 26 | 27 | @misc{statista4, 28 | title = {Number of estimated Skype users registered worldwide from 2009 to 2024}, 29 | year = {2020}, 30 | url = "https://www.statista.com/statistics/820384/estimated-number-skype-users-worldwide/" 31 | } 32 | 33 | 34 | @misc{RTprogress, 35 | title = {Two‐sided markets: a progress report 36 | }, 37 | author = {Jean‐Charles Rochet and Jean Tirole}, 38 | year = {2006}, 39 | url = "https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1756-2171.2006.tb00036.x", 40 | } 41 | 42 | @misc{ethgas, 43 | title = {Empirically Analyzing Ethereum’s Gas Mechanism 44 | }, 45 | author = {Renlord Yang and Toby Murray and and Paul Rimba and Udaya Parampalli}, 46 | year = {2019}, 47 | url = "https://arxiv.org/pdf/1905.00553.pdf", 48 | } 49 | 50 | @misc{ethgas, 51 | title = {Empirically Analyzing Ethereum’s Gas Mechanism 52 | }, 53 | author = {Renlord Yang and Toby Murray and and Paul Rimba and Udaya Parampalli}, 54 | year = {2019}, 55 | url = "https://arxiv.org/pdf/1905.00553.pdf", 56 | } 57 | 58 | @misc{discrim, 59 | title = {Price Discrimination in Two-Sided Markets}, 60 | author = {Qihong Liu and Konstantinos Serfes}, 61 | year = {2007}, 62 | url = "https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1022422", 63 | } 64 | -------------------------------------------------------------------------------- /economics/pricing_protocol/pp.tex: -------------------------------------------------------------------------------- 1 | \documentclass[longbibliography,nofootinbib]{revtex4-1} 2 | 3 | \usepackage{listings} 4 | \usepackage{graphicx} 5 | \usepackage{amsmath} 6 | \usepackage{subcaption} 7 | \usepackage[labelformat=parens,labelsep=quad, skip=3pt]{caption} 8 | \usepackage[usenames]{color} 9 | 10 | \usepackage{natbib} 11 | \bibliographystyle{unsrtnat} 12 | 13 | \renewcommand{\baselinestretch}{1.4} 14 | \setlength{\parskip}{1em} 15 | \definecolor{darkgreen}{rgb}{0.00,0.50,0.25} 16 | \definecolor{darkblue}{rgb}{0.00,0.00,0.67} 17 | \newcommand{\figref}[1]{Fig.~\ref{#1}} 18 | \usepackage[breaklinks,pdftitle={NuCypher Network: Pricing Protocol \& Economics}, pdfauthor={Arjun Hassard},colorlinks,urlcolor=blue,citecolor=darkgreen,linkcolor=darkblue]{hyperref} 19 | \graphicspath{{pdf/}} 20 | 21 | \usepackage[T1]{fontenc} 22 | \usepackage{lmodern} 23 | \lstset{ 24 | basicstyle=\ttfamily, 25 | basewidth={0.5em, 0.5em}, 26 | columns=fullflexible, 27 | } 28 | 29 | \begin{document} 30 | 31 | \title{NuCypher Network: Pricing Protocol \& Economics} 32 | 33 | \email{arjun@nucypher.com} 34 | \affiliation{NuCypher} 35 | 36 | \date{\today} 37 | \maketitle 38 | 39 | \section{Overview} 40 | \subsection{Motivation} 41 | 42 | The first products offered via the NuCypher network, dynamic access control and secrets management, are leveraged by developers to constitute a component of an application or information system’s underlying technology infrastructure. Through novel cryptography and a distributed network of independent service-providers, applications that have integrated NuCypher’s runtimes and interfaces may then support end-to-end encrypted data sharing between end-users and/or endpoints. These encrypted data sharing workflows are scalable, redundant, extensible, censorship-resistant, and verifiably protect the privacy of the application's end-users, a combination of value propositions that is unique in the digital service marketplace at the time of writing. 43 | \\\\ 44 | Pricing the NuCypher service appropriately and expediently is not a straightforward exercise. Although end-to-end encryption has become so prevalent on mainstream digital platforms that in 2020 at least 4 billion user accounts are protected in this manner \cite{statista1}\cite{statista2}\cite{statista3}\cite{statista4}, it is not typically outsourced to a third-party in a commercial sense, and hence no well-known market price point or price structure for an ‘end-to-end encryption service’ exists. The products most similar to NuCypher’s access control and secrets management service, for which publicly available pricing exists, are cloud-based Key Management Systems (KMS), such as AWS KMS or Azure KeyVault. These provide a useful reference point for both the viability of certain price points and customer expectations or anchoring to certain price structures. Ultimately, cloud KMS products confer a quite different set of benefits to customers – they do not guarantee the protection of end-user privacy, nor resistance from censorship – and therefore competition-based pricing development is not a comprehensive strategy. 45 | \\\\ 46 | Difficulties notwithstanding, appropriate pricing is critical for the network to flourish; to grow and retain the network’s user base, to support and sustain the network’s service-providers, and to maintain and improve the aforementioned value propositions. On the demand side, the service must be affordable to as many addressable customer segments as possible (or better, that price quotes match or improve upon their perceived value of the product). On the supplier side, the revenue generated for service-providers must sustain their operations at an achievable stage of network adoption (that is, a stage reached within a survivable timeframe). Thus, much of pricing development is evaluating these two primary requirements, and squaring the natural trade-off between them. 47 | 48 | \subsection{Network externalities \& two-sided market model} 49 | 50 | NuCypher’s pricing development must also account for the presence and evolution of network externalities. Customers benefit from increases to independent participation on the service-provider side, through, at the very least, gains in network security, redundancy and the geographical diversity of nodes (which can improve round-trip latency and choice of regulatory jurisdiction). Service-providers benefit from growth in the customer base, usage and the commensurate volume of fees paid into the network. Put simply, participation on one side of the network affects participation on the other – and hence we may model the network as a \textit{two-sided market}\footnote{A two-sided market is generally defined as one where the volume of transactions through the intermediary platform (or network) depend on the pricing \textit{decomposition} – i.e. the extent to which pricing and other economic levers are skewed to favor one side.}. This model enables the NuCypher community to draw insights from literature, and generate theoretical predictions of impact of certain pricing (and subsidy) structures. For example, Rochet \& Tirole's modification of the standard Lerner-index\footnote{Assuming an exchange of value between customers and service-providers by transacting through a platform, intermediary, digital market or decentralized protocol (hereafter referred to as the `intermediary'). In equation \ref{lerner}, $\eta^i$ is the elasticity of volume (demand) with respect to price on market-side $i$, $p^i$ is the per-transaction price charged to market-side $i$ by the intermediary, $p^j$ is the per-transaction price charged to market-side $j$ by the intermediary, and $c$ is the intermediary's marginal cost of facilitating the transaction. The intuition for this formula is that some non-trivial increase in the per-transaction price on side $i$ may result in the loss of at least one transaction. The extent of this loss, from the perspective of the intermediary, is fully captured with the \textit{opportunity cost} ($c - p^j$), which includes an additional loss of revenue that may have otherwise been extracted from side $j$ \cite{RTprogress}.} may be leveraged to optimally structure the network's pricing: 51 | 52 | \begin{equation} 53 | \label{lerner} 54 | \frac{p^i - (c - p^j)}{p^i} = \frac{1}{\eta^i} 55 | \end{equation} \ 56 | 57 | Unlike the commercial entities behind centralized two-sided markets (e.g. Uber, Microsoft/Xbox, Walmart.com), the NuCypher protocol does not extract a commission from service-providers or customers for transacting and exchanging value on the network. This means we cannot use off-the-shelf formulae that describe profit maximization of the intermediary platform itself, without some modification. Nonetheless, if any form of universal pricing is enforced by the NuCypher protocol, it is inevitable that the constraints will skew pricing to effectively favour one side of the market. Moreover, just like the aforementioned Uber, Microsoft and Walmart corporations, the NuCypher protocol heavily subsidizes service-provider operations. Subsidies are ‘paid for’ by a third group in NuCypher’s case, through the dilution of passive holders of the native token. Nonetheless, the subsidy mechanism still imposes an artificial economic influence and hence also skews the network’s effective pricing – though not necessarily in the same direction as universal pricing constraints (see section \ref{qup}). 58 | \\\\ 59 | In other words, the NuCypher protocol includes features that efficaciously redistribute value from one side of the market to the other. Endogenous mechanisms of this sort, whether they arise from corporate strategy (in the case of a profit-maximizing digital platform) or governance-driven protocol updates (in the case of a minimally extractive decentralized network), are designed and implemented with the explicit intent of maximizing the volume of market transactions. Not only does the objective function of transaction volume maximization serve as a decent approximation of intermediary profit maximization, there are similar levers available to adjust the pricing decomposition (skew) – for example, lowering the maximum universal fee rate chargeable by all service-providers, thereby skewing the pricing towards favoring the customer side of the market. 60 | \\\\ 61 | Hence, in evaluating characteristics of the NuCypher network as part of pricing development, one must account for these skews, consider the impact of positive (and negative) network externalities, and treat the NuCypher network as a variety of two-sided digital market. 62 | 63 | \subsection{Independent pricing (free market)} \label{fm} 64 | 65 | Given the permissionless, self-determining nature of service provision in decentralized networks, and the absence of profit maximization and marginal costs as formal objectives/attributes of the network itself, protocol designers may be tempted to leave the difficult task of pricing up to each individual service-provider. The consequences of mispricing will then fall on the shoulders of each independent operator – they’ll either adapt or die, but the network as a whole, boasting a diversity of prices and a replenishable array of service-providers, will survive. This is a reasonable assertion. Yet, a free market approach comes with a litany of issues: 66 | \begin{itemize} 67 | \item \textbf{Price instability}. The adoption of NuCypher by application developers necessitates irretrievable integration costs and a time lag between making the decision to integrate and commencing network usage. Adopters need a guarantee that the price quotes, on the basis of which they decide to leverage the service, do not change to such an extent by the time integration is complete that their application’s usage of the service is rendered unaffordable or undesirable. A free market, where service-providers can update their pricing whenever and however they want, does not provide this guarantee. 68 | \item \textbf{Multi-provider service coordination}. Typical usage of the NuCypher service necessitates concurrent work by multiple service-providers in order to be maximally secure and redundant. A free market, and higher variance in price points, increases procurement friction for customers and probabilistically increases the uniform fee they must pay to hire multiple service-providers. This feature of the NuCypher service also exacerbates the price stability problem, as it increases sensitivity to changes in pricing effectuated by some fraction of the service-provider population. 69 | \item \textbf{Undercutting \& centralization}. Fully independent pricing increases the scope of undercutting strategies, which generally favor deeper-pocketed or larger service-providers (through economies of scale and other advantaged) and therefore may cause or accelerate centralization trends. This problem is preempted by other decentralized networks, for example Ethereum; although gas pricing allows customers to expedite the execution of a transaction with a higher bid, the cost of computation and storage is fully standardised across opcodes (operations), which helps avoid further amplifying the advantage of more efficient, higher-resourced nodes \cite{ethgas}. 70 | \item \textbf{Lack of scope for product differentiation}. There is very little horizontal differentiation between the product offered by one service-provider running NuCypher software and the product offered by another\footnote{There may be some vertical differentiation through the geographical location of nodes and the associated latency and regulatory benefits. Whether this is a feature desired by network user remains to be empirically substantiated.}. Interoperability requirements between service-providers (essential for the multi-provider service mentioned above) mean there is limited scope and motivation to develop a differentiating feature that might be offered exclusively to users. This means that permitting price diversity is unlikely to benefit the network by fostering greater competition, raising service quality, or diversifying features. 71 | \item \textbf{Lack of scope for price discrimination}. Although in theory a service-provider could engage in price discrimination based on the funds in a customer’s wallet, this strategy is unlikely to succeed given the near-zero information asymmetry and near-zero switching costs. There is also research asserting that price discrimination in two-sided markets weakens rather than bolsters competition \cite{discrim}. Thus, permitting or encouraging the practice of price discrimination is unlikely to benefit the overall service. 72 | \end{itemize} 73 | 74 | \subsection{Quasi-universal pricing} \label{qup} 75 | 76 | \textit{Universal pricing} – a single price point for a standardized service unit, dictated by the protocol and adhered to by both users and service-providers without exception – addresses the problems listed in section \ref{fm}. 77 | \\\\ 78 | A major disadvantage of this approach is that the first few attempts to parametrize the price points will almost certainly be non-optimal. Prior to network launch there are major unknowns; including the value perception of the service and the prospective customers whose infrastructure budgets constrain their decision-making. Post-launch, this insight will slowly surface over time, anecdotally (e.g. customer integration announcements) and via network statistics (e.g. growth in daily transactions over time). Even so, unknowns about the \textit{next set} of would-be customer attributes will persist, which means a more robust solution is preferable: 79 | \\\\ 80 | Firstly, by instituting a global fee range (‘quasi-universal pricing’), within which all service-providers’ individually chosen minimum price points must fall. This broadens the protocol's corrective power. Service-providers holding diverse views on price optimality will reflect this in their individual parameters, and may rapidly toggle these price points in response to changing circumstances or new market information. 81 | \\\\ 82 | Secondly, by actively encouraging and enabling the regular modification of the global fee range through governance channels – including widening, narrowing and changing the bounds of the range in absolute terms. This exercise of collectively setting price constraints confers service-providers a window into the operational efficiency of others, as well as their views on critical considerations for pricing – e.g. the maximum price a target customer segment will tolerate. This information will surface via provider-authored proposals, community debate and upgrade proposal (in)validation. 83 | \\\\ 84 | These two mitigating modifications to universal pricing harness some of the crowd wisdom of the free market, without succumbing to the disadvantages of fully independent pricing explored above. In particular, tuning the width of the global fee range to account for this trade-off must be a regular community activity – see section \ref{width} for an extensive introduction to this topic. 85 | 86 | \subsection{Service unit \& payment} \label{su} 87 | 88 | In order for a global fee range to work in practice, NuCypher’s base unit of service must be defined, standardized and universally followed. At network launch, a customer will pay for dynamic access control and secrets management with the following attributes, together comprising the minimum chargeable unit: 89 | \begin{itemize} 90 | \item Per sharing policy 91 | \begin{itemize} 92 | \item Unique data controller (\textit{Alice}) 93 | \item Unique designated recipient (\textit{Bob}) 94 | \item Unique file directory address\footnote{No limit on the number or size of files stored at this address.} (\textit{label}) 95 | \end{itemize} 96 | \item Per 24-hour period 97 | \item Per service-provider 98 | \begin{itemize} 99 | \item Unique worker address (\textit{Ursula}) 100 | \end{itemize} 101 | \end{itemize} 102 | 103 | Note that this service unit does not include the number of access or re-encryption requests made to the service-providers managing the sharing policy whilst it is active, nor does it take into account the variation in the computational costs of re-encrypting. Although this service unit delineation is imperfect, the primary price-determining input for this service unit is rather simple: \textit{duration}. This input aligns with the primary cost-determining input for service-provider operations, in that the main overheads are infrastructural (e.g. hosting) and periodic chain interactions (i.e. gas costs), both of which are dependent on time. In other words, servicing a longer sharing policy costs more, and is compensated accordingly. 104 | 105 | \section{Reconciling demand-side \& service-side constraints} \label{dvss} 106 | 107 | Given our definition of the network's primary service unit in section \ref{su}, we may now derive expressions, constructed from an overlapping variable set, to describe and process key budgetary constraints for the demand-side (users/developers) and service-side (service-providers). 108 | \\\\ 109 | On the demand-side, we describe the annual cost per user ($ACPU$). This is a critical balance sheet overhead for the developers of digital applications and information systems, which will likely comprise the bulk of NuCypher network adopters. 110 | 111 | \begin{equation} 112 | ACPU = F_{pp} \cdot P_a \cdot P_d \cdot n 113 | \end{equation} \ 114 | 115 | $F_{pp}$ is the standardized cost of a single service unit – the fee users pay per sharing policy, per period, per worker\footnote{For this exercise we assume the fee parameter is a global invariant enforced by the network protocol.}. 116 | 117 | $P_a$ is the mean number of sharing policies generated by a single end-user of the application, annually. 118 | 119 | $P_d$ is the mean duration of all sharing policies created by all end-users of the application, in periods.| 120 | 121 | $n$ is the mean number of service-providers assigned to each sharing policy. 122 | \\\\ 123 | If we wish to include the main third-party costs of using the service, then the $ACPU$ is modified to: 124 | 125 | \begin{equation} 126 | ACPU = P_a \cdot \big((F_{pp} \cdot P_d \cdot n) + G\big) 127 | \end{equation} \ 128 | 129 | $G$ is the cost in Ethereum gas of creating a single sharing policy (`granting'). This cost may be internalized into the transaction through a discounted fee rate\footnote{It must be noted that since gas costs are per policy, there are end-user behavior scenarios in which the cost of gas far exceeds the total fees generated by those end-users' sharing policies. In other words, fees may absorb some of the cost of granting, but only until a certain point (with respect to $P_a$). This hypothetical discount must also take into account fluctuations in average gas prices, and the acceptable maximum duration for the grant function to execute (i.e. the choice of gas price), which depends on the use case.}. 130 | \\\\ 131 | On the service-side, we describe the annual revenue (AR) generated by serving the NuCypher network – a standard balance sheet metric for any commercial entity, and therefore all NuCypher service-providers. 132 | 133 | \begin{equation} 134 | AR = \frac{(ACPU - P_a \cdot G ) \cdot U_t}{S_t \cdot n} = \frac{F_{pp} \cdot P_a \cdot P_d \cdot U_t}{S_t} 135 | \end{equation} \ 136 | 137 | $U_t$ is the total number of end-users, spread across all adopting applications and systems, using the NuCypher network at a given moment in time. We assume their behavior is perfectly uniform with respect to $P_a$ and $P_d$. $S_t$ is the total number of service-providers supporting the NuCypher network\footnote{It is assumed for the purposes of this exercise that all service-providers receive an equal cut of total work allocation and fee revenue. In reality work allocation is probabilistic and weighted by relative stake size.}. 138 | \\\\ 139 | Using the variable $ACPU_{max}$ (the highest sum, per end-user, per year, an addressable customer segment is willing and able to pay), we now have an expression for the maximum chargeable fee from a demand-side perspective $F_{Dpp}$. 140 | 141 | \begin{equation} 142 | \label{FDPP} 143 | F_{Dpp} = \frac{ACPU_{max}}{P_a \cdot P_d \cdot n} 144 | \end{equation} \ 145 | 146 | If fees are discounted to absorb the gas costs of creating a sharing policy, then the maximum fee would be modified to the following: 147 | 148 | \begin{equation} 149 | F_{Dpp} = \frac{ACPU_{max} - (P_a \cdot G)}{P_a \cdot P_d \cdot n} 150 | \end{equation} \ 151 | 152 | Using the variable $AR_{min}$, the lowest sum of annual revenue a service-provider is willing or able to tolerate, we now have an expression for the minimum fee per service unit from a service side perspective $F_{Spp}$\footnote{Note that although $n$ cancels out in this expression, it still affects $F_{Dpp}$ above, which it is a determinant of the demand function (the uptake of the service at various prices), and therefore indirectly affects service-side revenue.}. 153 | 154 | \begin{equation} 155 | \label{FSPP} 156 | F_{Spp} = \frac{AR_{min \cdot S_t}}{P_a \cdot P_d \cdot U_t} 157 | \end{equation} \ 158 | 159 | To illustrate the utility of these expressions, we estimate fiat figures for $ACPU_{max}$ and $AR_{min}$, and test these with estimates for the other variables in equations \ref{FDPP} and \ref{FSPP}. The figures below are provisional and will change with further use case analysis, increasing insight into NuCypher customer priorities, behavior and budgets, service-providers' evolving operational efficiencies, and other network statistics available post-launch. 160 | \\ 161 | 162 | $ACPU_{max}$: \$0.50 developer budget per end-user per year for the NuCypher service 163 | 164 | $AR_{min}$: \$1,500 earned per year by each NuCypher service-provider 165 | \\ 166 | 167 | $S_t$: 50 total service-providers 168 | 169 | $U_t$: 100,000 total users 170 | 171 | $P_a$: 52 policies per year (mean) 172 | 173 | $P_d$: 90 periods per policy (mean) 174 | 175 | $n$: 5 service-providers per policy (mean) 176 | \\\\ 177 | These estimates yield a demand-driven $F_{Dpp}$ of \$2.14E-05 (67 GWEI) and a service-side $F_{Spp}$ of \$1.60E-04 (504 GWEI)\footnote{Note that the GWEI conversions are based on the 100-day rolling average of the ETHUSD exchange rate of \$318, as of October 14th, 2020.}. If we were to use $F_{Dpp}$ as our universal price point, ceteris paribus, service-providers would earn approximately \$200 annually. If we were to use $F_{Spp}$ the average cost imposed on developers (per user, per year) would be approximately \$3.75. 178 | \\\\ 179 | Though we have computed potential fee rates with very rough projections, this framework can be utilized to understand and reconcile the trade-off between $ACPU_{max}$ and $AR_{min}$. Therefore, the respective `extremes' of $F_{Dpp}$ and $F_{Spp}$ are a natural starting point for the global fee range. As the true values of $ACPU_{max}$ and $AR_{min}$ become elucidated, the global fee range boundaries should be adjusted accordingly. 180 | \\\\ 181 | A final variable we may now project is the number of total network users – i.e. in order to see what level of adoption the network needs to reach for the provisional constraints $ACPU_{max}$ and $AR_{min}$ to \textit{both} be satisfied. 182 | 183 | \begin{equation} 184 | \frac{ACPU_{max}}{P_a \cdot P_d \cdot n} = \frac{AR_{min \cdot S_t}}{P_a \cdot P_d \cdot U_t} 185 | \end{equation} 186 | 187 | \begin{equation} 188 | U_t = \frac{AR_{min} \cdot S_t \cdot n}{ACPU_{max}} = 750,000 189 | \end{equation}. \\ 190 | 191 | \section{Quasi-Universal Pricing} 192 | 193 | \subsection{Global fee range} 194 | 195 | When service-providers join the network, they specify a \textit{minimum fee rate}, on a per sharing policy and per 24h period basis, that their machine(s) will accept at the point of engagement with a network user. If the user’s offered per period rate for a specified policy duration computes as equal to or greater than the minimum fee rate, the sharing policy will be accepted by the service-provider and the access control service will commence. They service the sharing policy by being online and answering access requests, at that unchanging per period fee rate, until the specified policy expiration date or an early revocation is instigated by the user. 196 | \\\\ 197 | The \textit{global fee range} is a means of establishing quasi-universal pricing for the NuCypher service. \textbf{The minimum fee rate chosen by each service-provider must fall within the global fee range.} Hence, the global fee range is adhered to in identical fashion by all service-providers, regardless of their stake size or capacity. The fee range also applies to all sharing policies, irrespective of the volume of re-encryption requests or other distinguishing attributes. Finally, the global fee range applies consistently to all periods in the future, up until the period in which the global fee range’s parameters are adjusted or the range is removed via official governance processes. 198 | \\\\ 199 | Note that network users are technically free to offer and pay any fee rate they wish. However, users are able to discover all the fee rates available to them, by retrieving the list of active service-provider addresses, then querying the function `getMinFeeRate' in a public contract. Hence, there is little information asymmetry that could be leveraged to overcharge users. 200 | 201 | \subsection{Determining the width and position of the global fee range} \label{width} 202 | 203 | In parametrizing the global fee range, there are at least two trade-offs to analyse and resolve. Firstly, the \textbf{width} of the range must find the optima amongst the advantages and disadvantages of heterogeneous and homogeneous pricing. Greater price freedom brings greater self-correcting power, but also the potential for greater friction for adopting developers and network users. Secondly, with respect to the \textbf{absolute price figures} chosen as the range's upper and lower bound, a balance must be struck between the extremes of 1) unaffordability for early customers leading to low demand, and 2) unsustainability for service-providers leading to low participation. This second trade-off is formally described in section \ref{dvss}. 204 | \\\\ 205 | Notably, the protocol's subsidy mechanism is designed to steadily support service-providers for the first 5 to 8 years – conferring the community an extended window to trial various fee range parameters. 206 | 207 | \subsubsection{Case for a wider global fee range} 208 | 209 | Given limited insight into future customer budgets, willingness-to-pay and end-user behavior (for example, how many sharing policies an adopting platform's end-users will create per month), the range's parameters are likely to be non-optimal at network launch. The corollary to this is further uncertainty surrounding the characteristics of demand, including its volume, growth, retention and elasticity (with respect to price). A wider range allows greater scope for individual, quick correction instead of collective, slower intervention. 210 | \\\\ 211 | Regardless of the actual breakdown of future customer budgets and requirements, reducing the lower bound’s absolute value will capture a larger set of use cases and market segments, that otherwise are unable to afford the service. 212 | 213 | \subsubsection{Case for a narrower global fee range} 214 | 215 | Adopting the NuCypher service involves irretrievable integration costs, plus a time lag between making the decision to integrate and the commencement (and first payment for) network usage. Sensible customers need as strong a guarantee as possible that the available price quotes with which they decided to adopt the service do not rise unreasonably by the time integration is complete, rendering their usage of the network (and its unique attributes) unaffordable or undesirable. The wider the range, and the greater pricing freedom bestowed to service-providers, the less strategic certainty bestowed to prospective network users. 216 | \\\\ 217 | Aspects of NuCypher services necessitate concurrent work by multiple service-providers in order to be maximally secure and redundant. A wider price range, and consequently higher variance in acceptable price points amongst service-providers, increases engagement friction for customers. One option is to broadcast an inflated rate via the service-provider selection algorithm in order to guarantee acceptance of service, which means paying most service-providers more than their stated minimum rate. Alternatively, a customer might hand-pick service-providers they know are affordable – though their rates may have changed since last engagement. Finally, a customer might attempt to manually pay service-providers different rates – although this is not supported by the selection algorithm at the time of writing. The greater the variance in price points, the more difficult, more expensive, and higher-latency the engagement flow becomes, possibly requiring manual intervention by the customer following failed engagements. 218 | \\\\ 219 | A tighter range increases the predictability/stability of the service to customers over the long-term. For example, a very low lower bound enables service-providers to offer prices that are operationally unsustainable below a given subsidy value, which almost inevitably necessitates price rises later. This risks irrevocable damage to the network if customers with large sunk costs and technical dependence on the service are suddenly, or even gradually, are unable to afford it. 220 | 221 | 222 | \subsection{Pricing strategies} 223 | 224 | Setting a price point, even within a tight range, requires the evaluation and weighting of many factors against one another. Many of these considerations are unique to the staker, such as their ongoing operational costs, economy of scale (e.g. through participation in other networks) and participation timeframe. However, the most important factors to consider pertain to the holistic service from the perspective of network users – for example, the affordability, congruency, and stability, of all offered price points – i.e. how probable it is that prices remain affordable to a developer after they are irreversibly committed to integrating NuCypher access control into their application’s technology stack. 225 | 226 | \subsubsection{Divergent pricing} 227 | 228 | Service-providers may diverge from the dominant price point and offer lower prices in order to attract more business, in lieu of other options for a service-provider to differentiate themselves\footnote{One exception to the predominantly binary nature of NuCypher service quality is the latency with which request calls are answered. Thus an avenue for differentiation, besides price, may be the strategic placing of worker machines around the world paired with other optimisation (e.g. higher RAM). This will only be a fruitful differentiator if customers both need, and are optimising for, low-latency, and is a costly exercise if customers are not. This chicken-and-egg situation means latency differentiation of this sort will probably not occur in early epochs of the network.}. Customer perception of service ‘quality’ for a given engagement is relatively binary – a correct re-encryption or revocation is either delivered when expected, or it isn't. End-user tolerance of failed re-encryption on demand are likely to be near zero, hence customers may opt to simply blacklist unreliable service-providers rather than paying more for historically dependable service-providers. The pressure on service-providers to differentiate in some way is stronger in epochs of oversupply. Relatedly, service-providers may also attempt to undercut other service-providers and/or undermine their operational sustainability\footnote{Unlike in the traditional economy (particularly publicly traded companies), the finances and operational efficiency of other service-providers are highly opaque. Sacrificing revenue to put another service-provider out of business is an extraordinarily risky strategy, as they may have deeper pockets or other revenue streams that are unknowable.}. 229 | \\\\ 230 | Service-providers may offer lower prices in order to serve a customer segment or addressable market that cannot currently afford to leverage the NuCypher service. Though this strategy may be motivated by the prospect of additional income on an individual level, widening the overall demand for the service is beneficial to the whole network. 231 | 232 | \subsubsection{Convergent pricing} 233 | 234 | A key reason for service-providers to converge to the dominant or default price point is the serious lack of `relationship stickiness’ between customer and service-provider. Although some customers may configure their policies to persist for a long time (e.g. 1-2 years), there is almost nothing preventing the customer switching to another service-provider once these policies have expired, if they need other policies prior to expiry, or even revoking the original policies if a cheaper service-provider emerges (and receiving a near-full refund). In other words there is zero customer `lock-in’, either contractually or in terms of time, effort or opportunity cost\footnote{For example, the costs associated with the time it takes a sales force to learn a new CRM interface}. This means that offering unsustainably low prices in an attempt to secure customer lock-in or loyalty is an irrational strategy. 235 | \\\\ 236 | Undercutting strategies are difficult to achieve in practice because service-provider overheads are dominated by Ethereum gas costs, which are not malleable via economies of scale\footnote{If service-providers are allowed to mint their rewards with temporal flexibility, then there is greater scope for outperforming others by choosing the right moment for on-chain interactions (i.e. when gas prices are low). At the time of writing all service-providers must pay almost identical gas costs to receive subsidies, so greater operational efficiency is difficult to achieve.}. Thus, differentiation based on price can only go so far (i.e. as close as possible to the almost universal minimum overheads) if it is to be sustainable. Price wars may involve service-providers running at a loss, which is very risky given the opacity of other service-provider balance sheets. 237 | \\\\ 238 | Service-providers may choose to maximise the predictability and stability of the service to customers. If many service-providers offer prices that imply unsustainable operations (once subsidies dry up), this inevitably necessitates future price rises. Any prospect of price hikes risks damage to the network. Customers with large sunk costs may suddenly, or even gradually, be unable to afford the service. Service-providers vested in the network's long-term success will seek to avoid this scenario, even the prospect of which could seriously hamper medium and long-term adoption. 239 | \\\\ 240 | Finally, service-providers may converge simply because the majority of customers also do so. It is conceivable that application developers create a rule to only select service-providers at a lower-than-default price point, but this involves risk and proactivity and may be limited to a minority of sophisticated customers, especially in early epochs. 241 | 242 | 243 | \bibliography{pp} 244 | 245 | \end{document} 246 | -------------------------------------------------------------------------------- /economics/staking_protocol/NuCypher_Staking_Protocol_Economics.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/NuCypher_Staking_Protocol_Economics.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/Two_phase_model.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/Two_phase_model.png -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/CrossCorr_SR_DIF_14.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/CrossCorr_SR_DIF_14.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/CrossCorr_SR_DIF_21.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/CrossCorr_SR_DIF_21.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/CrossCorr_SR_DIF_28.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/CrossCorr_SR_DIF_28.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/CrossCorr_SR_DIF_7.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/CrossCorr_SR_DIF_7.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/CrossCorr_Yields_DIF_14.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/CrossCorr_Yields_DIF_14.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/CrossCorr_Yields_DIF_21.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/CrossCorr_Yields_DIF_21.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/CrossCorr_Yields_DIF_28.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/CrossCorr_Yields_DIF_28.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/CrossCorr_Yields_DIF_7.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/CrossCorr_Yields_DIF_7.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/SubsidyP1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/SubsidyP1.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/SubsidyP2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/SubsidyP2.pdf -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/one-step.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/one-step.png -------------------------------------------------------------------------------- /economics/staking_protocol/graphs/two-steps.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/economics/staking_protocol/graphs/two-steps.png -------------------------------------------------------------------------------- /economics/staking_protocol/python_scripts/SubsidyP1.py: -------------------------------------------------------------------------------- 1 | import matplotlib.pyplot as plt 2 | import math 3 | import numpy as np 4 | 5 | fig_size = plt.rcParams["figure.figsize"] 6 | fig_size[0] = 15 7 | fig_size[1] = 8 8 | 9 | withdraw_subsidy = lambda S, staker_kappa: staker_kappa / staking_rate * np.log(S) 10 | restake = lambda S, staker_kappa: S ** (staker_kappa / staking_rate) - 1.0 11 | 12 | staker_kappa = 1.0 13 | kappa_avg = (1.0 + (0.5+(0.5*(1/12)))) / 2 # uniform distribution of stake lock durations - k = 0.77 14 | staking_rate = 0.70 15 | T12 = 365 * 2 16 | T_modified = T12 / kappa_avg # actual halving time 17 | I_s = 1002509/1e9 18 | S_P1Max = 1829579800 19 | switch = S_P1Max / (I_s*1e9 * kappa_avg) 20 | 21 | def P1plot(staker_kappa, f=None, **kw): 22 | t = np.linspace(0, switch, 365) 23 | S = 1 + (I_s * kappa_avg * t) 24 | subsidy = f(S, staker_kappa) 25 | plt.plot(t/365, subsidy*100, **kw) 26 | 27 | if __name__ == '__main__': 28 | P1plot(staker_kappa=1.0, f=restake, color='blue', label='restaking, kappa = 1 year+') 29 | P1plot(staker_kappa=1.0, f=withdraw_subsidy, color='red', label='withdraw subsidy, kappa = 1 year+') 30 | P1plot(staker_kappa=0.5 * (1 + 1./12), f=restake, color='blue', 31 | linestyle='--', label='restaking, kappa = 1 month') 32 | P1plot(staker_kappa=0.5 * (1 + 1./12), f=withdraw_subsidy, color='red', 33 | linestyle='dotted', label='withdraw subsidy, kappa = 1 month') 34 | plt.title('Phase 1 cumulative subsidy earnings, various stake configurations | Staking rate: 70% | Kappa*: 0.77', fontsize=14) 35 | plt.xlabel('Time from network launch in years', fontsize=14) 36 | plt.ylabel('Cumulative subsidy earnings as % of stake', fontsize=14) 37 | plt.xticks(fontsize=14) 38 | plt.yticks(fontsize=14) 39 | plt.legend(loc=2, fontsize=14) 40 | plt.savefig('SubsidyP1.pdf') -------------------------------------------------------------------------------- /economics/staking_protocol/python_scripts/SubsidyP2.py: -------------------------------------------------------------------------------- 1 | import matplotlib.pyplot as plt 2 | import math 3 | import numpy as np 4 | 5 | fig_size = plt.rcParams["figure.figsize"] 6 | fig_size[0] = 15 7 | fig_size[1] = 8 8 | 9 | 10 | withdraw_subsidy = lambda S, staker_kappa: staker_kappa / staking_rate * np.log(S) 11 | restake = lambda S, staker_kappa: S ** (staker_kappa / staking_rate) - 1.0 12 | 13 | staker_kappa = 1.0 14 | kappa_avg = (1.0 + (0.5+(0.5*(1/12)))) / 2 # uniform distribution of stake lock durations - k = 0.77 15 | staking_rate = 0.70 16 | T12 = 365 * 2 17 | T_modified = T12 / kappa_avg # actual halving time 18 | I_s = 1002509/1e9 19 | S_P1Max = 1829579800 20 | switch = S_P1Max / (I_s*1e9 * kappa_avg) 21 | 22 | def P2plot(staker_kappa, f=None, **kw): 23 | t = np.linspace(0, switch*2, 365) 24 | S = 1 + S_P1Max/1e9 + (I_s * T12 / np.log(2) * (1.0 - 2 ** (- t / T_modified))) 25 | subsidy = f(S, staker_kappa) 26 | plt.plot(t/365, subsidy*100, **kw) 27 | 28 | if __name__ == '__main__': 29 | P2plot(staker_kappa=1.0, f=restake, color='blue', label='restaking, kappa = 1 year+') 30 | P2plot(staker_kappa=1.0, f=withdraw_subsidy, color='red', label='withdraw subsidy, kappa = 1 year+') 31 | P2plot(staker_kappa=0.5 * (1 + 1./12), f=restake, color='blue', 32 | linestyle='--', label='restaking, kappa = 1 month') 33 | P2plot(staker_kappa=0.5 * (1 + 1./12), f=withdraw_subsidy, color='red', 34 | linestyle='dotted', label='withdraw subsidy, kappa = 1 month') 35 | plt.title('Phase 2 cumulative subsidy earnings, various stake configurations | Staking rate: 70% | Kappa*: 0.77', fontsize=14) 36 | plt.xlabel('Time from phase switch in years', fontsize=14) 37 | plt.ylabel('Cumulative subsidy earnings as % of stake', fontsize=14) 38 | plt.xticks(fontsize=14) 39 | plt.yticks(fontsize=14) 40 | plt.legend(loc='center', fontsize=14) 41 | plt.savefig('SubsidyP2.pdf') -------------------------------------------------------------------------------- /economics/staking_protocol/staking_protocol.bib: -------------------------------------------------------------------------------- 1 | 2 | @misc{Decreasing-subsidy, 3 | title = {Coin Metrics Network Data Charts}, 4 | year = {2020}, 5 | url = "https://coinmetrics.io/charts/#assets=xmr,btc,zec,ltc,eth,grin_left=IssContPctAnn" 6 | } 7 | 8 | @misc{work-token, 9 | author = "Kyle Samani", 10 | title = "{New Models for Utility Tokens}", 11 | year = "2018", 12 | url = "https://multicoin.capital/2018/02/13/new-models-utility-tokens/" 13 | } 14 | 15 | @misc{cosmos, 16 | title = "{Mintscan Cosmos Validators}", 17 | year = "2020", 18 | url = "https://www.mintscan.io/validator2" 19 | } 20 | 21 | @misc{irisnet, 22 | title = "{Mintscan Irisnet Validators}", 23 | year = "2020", 24 | url = "https://irishub.mintscan.io/validators" 25 | } 26 | 27 | @misc{tezos, 28 | title = "{Tzstats Tezos Delegates}", 29 | year = "2020", 30 | url = "https://tzstats.com/cycle/229" 31 | } 32 | 33 | @misc{Pricing:AWS, 34 | title = {Amazon Web Services Key Management Service pricing}, 35 | year = {2020}, 36 | url = "https://aws.amazon.com/kms/pricing/" 37 | } 38 | 39 | @misc{Pricing:GC, 40 | title = {Google Cloud Key Management Service pricing}, 41 | year = {2019}, 42 | url = "https://cloud.google.com/kms/pricing" 43 | } 44 | 45 | @misc{Pricing:MS, 46 | title = {Microsoft Azure Key Vault pricing}, 47 | year = {2020}, 48 | url = "https://azure.microsoft.com/en-us/pricing/details/key-vault/" 49 | } 50 | -------------------------------------------------------------------------------- /makefile: -------------------------------------------------------------------------------- 1 | SVG = $(wildcard svg/*.svg) 2 | PDF = $(SVG:svg/%.svg=pdf/%.pdf) 3 | 4 | all: $(PDF) whitepaper.pdf whitepaper.lof 5 | 6 | whitepaper.pdf: whitepaper.lof 7 | bibtex whitepaper && pdflatex -halt-on-error whitepaper.tex && pdflatex -halt-on-error whitepaper.tex && rm -f *.aux *.log *.blg *.toc *.out 8 | whitepaper.lof: *.tex 9 | pdflatex -halt-on-error whitepaper.tex 10 | $(PDF): pdf/%.pdf: svg/%.svg 11 | inkscape "$<" --export-pdf="$@" 12 | 13 | arxiv: $(PDF) whitepaper.pdf whitepaper.lof 14 | tar -czf whitepaper.tar.gz whitepaper.tex whitepaper.bbl pdf/ 15 | -------------------------------------------------------------------------------- /pdf/centralized-kms.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/pdf/centralized-kms.pdf -------------------------------------------------------------------------------- /pdf/decrypt.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/pdf/decrypt.pdf -------------------------------------------------------------------------------- /pdf/delegate.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/pdf/delegate.pdf -------------------------------------------------------------------------------- /pdf/encrypt.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/pdf/encrypt.pdf -------------------------------------------------------------------------------- /pdf/hierarchical.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/pdf/hierarchical.pdf -------------------------------------------------------------------------------- /pdf/miners-ruler.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/pdf/miners-ruler.pdf -------------------------------------------------------------------------------- /pdf/pre-kms.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/pdf/pre-kms.pdf -------------------------------------------------------------------------------- /pdf/pre.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/pdf/pre.pdf -------------------------------------------------------------------------------- /svg/centralized-kms.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 19 | 41 | 46 | 47 | 49 | 57 | 63 | 64 | 73 | 79 | 80 | 89 | 95 | 96 | 104 | 110 | 111 | 112 | 114 | 115 | 117 | image/svg+xml 118 | 120 | 121 | 122 | 123 | 124 | 129 | 131 | 138 | 143 | 148 | 153 | 154 | 157 | 160 | 165 | 166 | 169 | 174 | 175 | 178 | 183 | 184 | 187 | 192 | 193 | 196 | 201 | 202 | 203 | Receiver 215 | 226 | 232 | 238 | 244 | 249 | 252 | 254 | 259 | 260 | 262 | 264 | 266 | 268 | 270 | 272 | 274 | 276 | 278 | 280 | 282 | 284 | 286 | 288 | 290 | 291 | 294 | 303 | 309 | 314 | 323 | 329 | 334 | 343 | 349 | 354 | 355 | 357 | 361 | [ ] 373 | 374 | 376 | 380 | [ ] 392 | 393 | 397 | 400 | 407 | 412 | 417 | 422 | 423 | = decrypt( , ) 435 | 439 | 442 | 449 | 454 | 459 | 464 | 465 | 466 | 467 | -------------------------------------------------------------------------------- /svg/hierarchical.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 19 | 21 | 29 | 35 | 36 | 45 | 51 | 52 | 61 | 67 | 68 | 77 | 83 | 84 | 92 | 98 | 99 | 107 | 113 | 114 | 122 | 128 | 129 | 130 | 152 | 157 | 158 | 160 | 161 | 163 | image/svg+xml 164 | 166 | 167 | 168 | 169 | 170 | 175 | 181 | 187 | 193 | 199 | 205 | r 216 | x 227 | y 238 | 1 250 | 2 262 | 267 | 272 | 277 | 282 | 287 | Recipient (b) 298 | re1x 315 | re2x 330 | rexr 347 | reyr 364 | rexb 378 | 379 | 380 | -------------------------------------------------------------------------------- /svg/pre-kms.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 19 | 41 | 46 | 47 | 49 | 57 | 63 | 64 | 72 | 78 | 79 | 88 | 94 | 95 | 96 | 98 | 99 | 101 | image/svg+xml 102 | 104 | 105 | 106 | 107 | 108 | 113 | 115 | 122 | 127 | 132 | 137 | 138 | 141 | 144 | 149 | 150 | 153 | 158 | 159 | 162 | 167 | 168 | 171 | 176 | 177 | 180 | 185 | 186 | 187 | Receiver 199 | 210 | 216 | 222 | 228 | 233 | 236 | 238 | 243 | 244 | 246 | 248 | 250 | 252 | 254 | 256 | 258 | 260 | 262 | 264 | 266 | 268 | 270 | 272 | 274 | 275 | 277 | 281 | [ ] 293 | 294 | 296 | 300 | [ ] 312 | 313 | 316 | 323 | 328 | 333 | 338 | 339 | = decrypt( , ) 351 | 356 | 359 | 366 | 371 | 376 | 381 | 382 | 385 | 389 | { } 401 | 402 | 406 | 412 | 418 | 424 | 430 | 436 | 441 | 446 | 451 | 456 | 461 | 466 | 467 | 472 | = decrypt( , ) 483 | 486 | 490 | { } 502 | 503 | 508 | 509 | 510 | -------------------------------------------------------------------------------- /svg/templates/Octicons-key.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | -------------------------------------------------------------------------------- /svg/templates/cloud-2.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 6 | 13 | 14 | -------------------------------------------------------------------------------- /svg/templates/group.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 13 | 14 | 15 | 17 | 18 | 19 | 22 | 23 | 24 | 27 | 28 | 29 | 31 | 32 | 33 | 36 | 37 | 38 | 44 | 45 | 46 | 49 | 50 | 51 | 57 | 58 | 59 | 63 | 64 | 65 | 68 | 69 | 70 | 76 | 77 | 78 | 81 | 82 | 83 | 84 | 85 | 86 | 88 | 89 | 90 | 92 | 93 | 94 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | -------------------------------------------------------------------------------- /svg/templates/human-figure.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | image/svg+xml -------------------------------------------------------------------------------- /svg/templates/kms.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 19 | 21 | 43 | 48 | 49 | 51 | 52 | 54 | image/svg+xml 55 | 57 | 58 | 59 | 60 | 61 | 66 | 68 | 77 | 83 | 88 | 97 | 103 | 108 | 117 | 123 | 128 | 129 | 130 | 131 | -------------------------------------------------------------------------------- /svg/templates/mesh.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 19 | 21 | 43 | 48 | 49 | 51 | 52 | 54 | image/svg+xml 55 | 57 | 58 | 59 | 60 | 61 | 66 | 72 | 78 | 84 | 90 | 96 | 101 | 106 | 111 | 116 | 121 | 126 | 127 | 128 | -------------------------------------------------------------------------------- /svg/templates/storage.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 5 | 6 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | -------------------------------------------------------------------------------- /svg/templates/template.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 19 | 21 | 39 | 42 | 43 | 45 | 46 | 48 | image/svg+xml 49 | 51 | 52 | 53 | 54 | 55 | 59 | 62 | 65 | 70 | 71 | 74 | 79 | 80 | 83 | 88 | 89 | 92 | 97 | 98 | 101 | 106 | 107 | 108 | 113 | 120 | 125 | 130 | 135 | 142 | EDEK 153 | 160 | 165 | 170 | 175 | 176 | 177 | -------------------------------------------------------------------------------- /svg/templates/text-x-generic.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 23 | 25 | 32 | 43 | 46 | 50 | 54 | 55 | 66 | 68 | 72 | 76 | 80 | 81 | 91 | 94 | 98 | 102 | 103 | 105 | 109 | 113 | 114 | 122 | 126 | 130 | 131 | 139 | 143 | 147 | 148 | 150 | 154 | 158 | 159 | 161 | 165 | 169 | 170 | 181 | 192 | 203 | 214 | 225 | 236 | 237 | 256 | 258 | 259 | 261 | image/svg+xml 262 | 264 | Generic Text 265 | 266 | 267 | text 268 | plaintext 269 | regular 270 | document 271 | 272 | 273 | 275 | 276 | 277 | Jakub Steiner 278 | 279 | 280 | http://jimmac.musichall.cz 281 | 282 | 284 | 286 | 288 | 290 | 291 | 292 | 293 | 297 | 301 | 308 | 313 | 318 | 319 | 320 | 325 | 333 | 342 | 345 | 349 | 357 | 361 | 365 | 366 | 370 | 378 | 382 | 386 | 387 | 391 | 392 | 396 | 400 | 401 | 406 | 411 | 412 | 417 | 420 | 429 | 438 | 447 | 456 | 465 | 474 | 483 | 492 | 501 | 510 | 519 | 528 | 537 | 546 | 547 | 548 | 549 | -------------------------------------------------------------------------------- /watch.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # This script compiles the document as soon as all the .tex files in the project are updated. 4 | # In debian-based distros, it needs inotify-tools and (optionally) libnotify-bin 5 | 6 | inotifywait -mr -e create ./ | while read dir event file; do 7 | if [[ $file =~ .*\.tex ]] 8 | then 9 | make && notify-send "Latex document compiled" || notify-send "Latex error" 10 | fi 11 | done 12 | -------------------------------------------------------------------------------- /whitepaper.bib: -------------------------------------------------------------------------------- 1 | @misc{cryptoeprint:2017:201, 2 | author = {Gabriel Kaptchuk and Ian Miers and Matthew Green}, 3 | title = {Managing Secrets with Consensus Networks: Fairness, Ransomware and Access Control}, 4 | howpublished = {Cryptology ePrint Archive, Report 2017/201}, 5 | year = {2017}, 6 | url = "http://eprint.iacr.org/2017/201", 7 | } 8 | 9 | @misc{wiki:pre, 10 | author = "Wikipedia", 11 | title = "Proxy re-encryption --- {Wikipedia}{,} The Free Encyclopedia", 12 | year = "2017", 13 | url = "https://en.wikipedia.org/w/index.php?title=Proxy_re-encryption&oldid=765960567", 14 | } 15 | 16 | @misc{wiki:kms, 17 | author = "Wikipedia", 18 | title = "Key management --- {Wikipedia}{,} The Free Encyclopedia", 19 | year = "2017", 20 | url = "https://en.wikipedia.org/wiki/Key_management#Key_management_system", 21 | } 22 | 23 | @misc{wiki:hsm, 24 | author = "Wikipedia", 25 | title = "Hardware security module --- {Wikipedia}{,} The Free Encyclopedia", 26 | year = "2017", 27 | url = "https://en.wikipedia.org/wiki/Hardware_security_module", 28 | } 29 | 30 | @misc{web:hashicorp-vault, 31 | author = "HashiCorp Inc.", 32 | title = "Vault by HashiCorp", 33 | year = "2017", 34 | url = "https://www.vaultproject.io/intro/index.html" 35 | } 36 | 37 | @misc{web:aws-cloudhsm, 38 | author = "Amazon Inc.", 39 | title = "AWS CloudHSM", 40 | year = "2017", 41 | url = "https://aws.amazon.com/cloudhsm/" 42 | } 43 | 44 | @misc{web:google-cloud-kms, 45 | author = "Alphabet Inc.", 46 | title = "Cloud Key Management Service", 47 | year = "2017", 48 | url = "https://cloud.google.com/kms/" 49 | } 50 | 51 | @misc{web:azure-key-vault, 52 | author = "Microsoft Inc.", 53 | title = "Key Vault", 54 | year = "2017", 55 | url = "https://azure.microsoft.com/en-us/services/key-vault/" 56 | } 57 | 58 | @misc{web:truevault, 59 | author = "TrueVault Inc.", 60 | title = "HIPAA Compliant API \& Secure Data Store", 61 | year = "2017", 62 | url = "https://www.truevault.com/" 63 | } 64 | 65 | @misc{web:nucypher-hadoop, 66 | author = "NuCypher", 67 | title = "NuCypher Hadoop: Delegated access control and encryption management system", 68 | year = "2017", 69 | url = "https://cdn2.hubspot.net/hubfs/2807639/Nucypher-June2017/Docs/NuCypher-White-Paper-1.pdf" 70 | } 71 | 72 | @misc{web:storj, 73 | author = "Storj Labs Inc.", 74 | title = "A Peer-to-Peer Cloud Storage Network", 75 | year = "2016", 76 | url = "https://storj.io/storj.pdf" 77 | } 78 | 79 | @misc{web:sia, 80 | author = "Nebulous Inc.", 81 | title = "Sia: Simple Decentralized Storage", 82 | year = "2014", 83 | url = "https://www.sia.tech/whitepaper.pdf" 84 | } 85 | 86 | @thesis{phd:nunez, 87 | author = {{N{\'{u}}{\~{n}}ez Monta{\~{n}}ez}, David Alejandro}, 88 | keywords = {Cifrado,Cloud computing,Computaci{\'{o}}n en nube,Criptograf{\'{i}}a (Inform{\'{a}}tica),Recifrado delegado,Seguridad,Tesis doctorales}, 89 | mendeley-groups = {Data security}, 90 | publisher = {Servicio de Publicaciones y Divulgaci{\'{o}}n Cient{\'{i}}fica}, 91 | title = {{New Security Definitions, Constructions and Applications of Proxy Re-Encryption}}, 92 | url = {http://riuma.uma.es/xmlui/handle/10630/13221}, 93 | year = {2015} 94 | } 95 | 96 | @misc{wiki:salsa20, 97 | author = "Wikipedia", 98 | title = "Salsa20 --- {Wikipedia}{,} The Free Encyclopedia", 99 | year = "2017", 100 | url = "https://en.wikipedia.org/w/index.php?title=Salsa20&oldid=766884579" 101 | } 102 | 103 | 104 | @misc{wiki:aes, 105 | author = "Wikipedia", 106 | title = "Advanced Encryption Standard --- {Wikipedia}{,} The Free Encyclopedia", 107 | year = "2017", 108 | url = "https://en.wikipedia.org/w/index.php?title=Advanced_Encryption_Standard&oldid=786245182" 109 | } 110 | 111 | @article{AFGH, 112 | author = {Ateniese, Giuseppe and Fu, Kevin and Green, Matthew and Hohenberger, Susan}, 113 | title = {Improved Proxy Re-encryption Schemes with Applications to Secure Distributed Storage}, 114 | journal = {ACM Trans. Inf. Syst. Secur.}, 115 | issue_date = {February 2006}, 116 | volume = {9}, 117 | number = {1}, 118 | month = feb, 119 | year = {2006}, 120 | issn = {1094-9224}, 121 | pages = {1--30}, 122 | numpages = {30}, 123 | url = {http://doi.acm.org/10.1145/1127345.1127346}, 124 | doi = {10.1145/1127345.1127346}, 125 | acmid = {1127346}, 126 | publisher = {ACM}, 127 | address = {New York, NY, USA}, 128 | keywords = {Proxy re-encryption, bilinear maps, double decryption, key translation}, 129 | } 130 | 131 | 132 | @inbook{BBS98, 133 | address = {Berlin, Heidelberg}, 134 | author = {Blaze, Matt and Bleumer, Gerrit and Strauss, Martin}, 135 | booktitle = {Advances in Cryptology --- EUROCRYPT'98: International Conference on the Theory and Application of Cryptographic Techniques Espoo, Finland, May 31 -- June 4, 1998 Proceedings}, 136 | doi = {10.1007/BFb0054122}, 137 | editor = {Nyberg, Kaisa}, 138 | isbn = {978-3-540-69795-4}, 139 | pages = {127--144}, 140 | publisher = {Springer Berlin Heidelberg}, 141 | title = {{Divertible protocols and atomic proxy cryptography}}, 142 | url = {http://dx.doi.org/10.1007/BFb0054122}, 143 | year = {1998} 144 | } 145 | 146 | @misc{wiki:ntru, 147 | author = "Wikipedia", 148 | title = "NTRUEncrypt --- {Wikipedia}{,} The Free Encyclopedia", 149 | year = "2017", 150 | url = "https://en.wikipedia.org/w/index.php?title=NTRUEncrypt&oldid=785525754", 151 | } 152 | 153 | @inproceedings{ntrureencrypt, 154 | author = {Nu\~{n}ez, David and Agudo, Isaac and Lopez, Javier}, 155 | title = {NTRUReEncrypt: An Efficient Proxy Re-Encryption Scheme Based on NTRU}, 156 | booktitle = {Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security}, 157 | series = {ASIA CCS '15}, 158 | year = {2015}, 159 | isbn = {978-1-4503-3245-3}, 160 | location = {Singapore, Republic of Singapore}, 161 | pages = {179--189}, 162 | numpages = {11}, 163 | url = {http://doi.acm.org/10.1145/2714576.2714585}, 164 | doi = {10.1145/2714576.2714585}, 165 | acmid = {2714585}, 166 | publisher = {ACM}, 167 | address = {New York, NY, USA}, 168 | keywords = {lattice-based cryptography, ntru, proxy re-encryption}, 169 | } 170 | 171 | @misc{ wiki:hmac, 172 | author = "Wikipedia", 173 | title = "Hash-based message authentication code --- Wikipedia{,} The Free Encyclopedia", 174 | year = "2017", 175 | url = {https://en.wikipedia.org/w/index.php?title=Hash-based_message_authentication_code&oldid=786918192} 176 | } 177 | 178 | @TechReport{enigma, 179 | author = {Guy Zyskind and Oz Nathan and Alex Pentland}, 180 | publisher = {MIT}, 181 | title = {Enigma: Decentralized Computation Platform with Guaranteed Privacy}, 182 | url = {http://enigma.co/enigma_full.pdf}, 183 | year = {2015}, 184 | } 185 | 186 | @article{truebit, 187 | title={A scalable verification solution for blockchains}, 188 | author={Teutsch, Jason and Reitwie{\ss}ner, Christian}, 189 | year={2017} 190 | } 191 | 192 | @misc{eth:whisper, 193 | title = "Whisper Overview", 194 | url = {https://github.com/ethereum/wiki/wiki/Whisper-Overview} 195 | } 196 | 197 | @misc{umbral-spec, 198 | title = "Umbral: a threshold proxy re-encryption scheme", 199 | url = {https://github.com/nucypher/umbral-doc} 200 | } 201 | 202 | @misc{whitepaper:ipfs, 203 | author = {Benet, Juan}, 204 | title = {{IPFS}~--- Content Addressed, Versioned, {P2P} File System}, 205 | url = {https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf}, 206 | year = {2014}, 207 | } 208 | 209 | @misc{swarm, 210 | title = {Smash-proof: auditable storage for swarm secured by masked audit secret hash}, 211 | author = {Tr{\'o}n, Victor and Fischer, Aron and Varga, Daniel}, 212 | url = {https://github.com/ethersphere/swarm}, 213 | year = {2016} 214 | } 215 | 216 | 217 | @article{nunez2017proxy, 218 | abstract = {This paper analyzes the secure access delegation problem, which occurs naturally in the cloud, and postulate that Proxy Re-Encryption is a feasible cryptographic solution, both from the functional and efficiency perspectives. Proxy re-encryption is a special type of public-key encryption that permits a proxy to transform ciphertexts from one public key to another, without the proxy being able to learn any information about the original message. Thus, it serves as a means for delegating decryption rights, opening up many possible applications that require of delegated access to encrypted data. In particular, sharing information in the cloud is a prime example. In this paper, we review the main proxy re-encryption schemes so far, and provide a detailed analysis of their characteristics. Additionally, we also study the efficiency of selected schemes, both theoretically and empirically, based on our own implementation. Finally, we discuss some applications of proxy re-encryption, with a focus on secure access delegation in the cloud.}, 219 | author = {Nu{\~{n}}ez, David and Agudo, Isaac and Lopez, Javier}, 220 | doi = {10.1016/j.jnca.2017.03.005}, 221 | issn = {1084-8045}, 222 | journal = {Journal of Network and Computer Applications}, 223 | pages = {193--209}, 224 | publisher = {Elsevier}, 225 | title = {{Proxy Re-Encryption: Analysis of Constructions and its Application to Secure Access Delegation}}, 226 | volume = {87}, 227 | year = {2017} 228 | } 229 | 230 | @misc{vitalik-secret-dao, 231 | title = {Secret Sharing DAOs: The Other Crypto 2.0}, 232 | author = {Buterin, Vitalik}, 233 | url = {https://blog.ethereum.org/2014/12/26/secret-sharing-daos-crypto-2-0/}, 234 | year = {2014} 235 | } 236 | 237 | 238 | @article{gpu-trusted, 239 | author = {Vasiliadis, Giorgos and Athanasopoulos, Elias and Polychronakis, Michalis and Ioannidis, Sotiris}, 240 | doi = {10.1145/2660267.2660316}, 241 | isbn = {978-1-4503-2957-6}, 242 | issn = {15437221}, 243 | journal = {Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security}, 244 | keywords = {gpu,isolation,ssl/tls,tamper resistance,trusted execution}, 245 | pages = {1131--1142}, 246 | title = {{PixelVault: Using GPUs for Securing Cryptographic Operations}}, 247 | url = {http://doi.acm.org/10.1145/2660267.2660316}, 248 | year = {2014} 249 | } 250 | 251 | 252 | @article{sgx-blockchain-encryption, 253 | author = {Kaptchuk, Gabriel and Miers, Ian and 0001, Matthew Green}, 254 | journal = {IACR Cryptology ePrint Archive}, 255 | mendeley-groups = {Data security}, 256 | number = {1}, 257 | pages = {201}, 258 | title = {{Managing Secrets with Consensus Networks: Fairness, Ransomware and Access Control.}}, 259 | url = {http://dblp.uni-trier.de/db/journals/iacr/iacr2017.html{\#}KaptchukMG17}, 260 | volume = {2017}, 261 | year = {2017} 262 | } 263 | 264 | 265 | @article{lwe-reencryption, 266 | author = {Phong, Le Trieu and Wang, Lihua and Aono, Yoshinori and Nguyen, Manh Ha and Boyen, Xavier}, 267 | journal = {IACR Cryptology ePrint Archive}, 268 | keywords = {chosen ciphertext security,key privacy,key rotation over,learning with errors,proxy re-encryption}, 269 | pages = {327}, 270 | title = {{Proxy Re-Encryption Schemes with Key Privacy from LWE.}}, 271 | url = {http://dblp.uni-trier.de/db/journals/iacr/iacr2016.html{\#}PhongWANB16}, 272 | volume = {2016}, 273 | year = {2016} 274 | } 275 | 276 | @misc{wiki:cca, 277 | author = "Wikipedia", 278 | title = "Chosen-ciphertext attack --- Wikipedia{,} The Free Encyclopedia", 279 | year = "2017", 280 | url = {https://en.wikipedia.org/w/index.php?title=Chosen-ciphertext_attack&oldid=782335246}, 281 | } 282 | 283 | @misc{consensys-snarks, 284 | author = "Consensys", 285 | title = "Introduction to {zk-SNARKs} with examples", 286 | year = "2017", 287 | url = {https://media.consensys.net/introduction-to-zksnarks-with-examples-3283b554fc3b}, 288 | } 289 | 290 | @misc{wiki:cpa, 291 | author = "Wikipedia", 292 | title = "Chosen-plaintext attack --- Wikipedia{,} The Free Encyclopedia", 293 | year = "2017", 294 | url = {https://en.wikipedia.org/w/index.php?title=Chosen-plaintext_attack&oldid=781752624}, 295 | } 296 | 297 | @misc{wiki:sgx, 298 | author = "Wikipedia", 299 | title = "Software Guard Extensions --- Wikipedia{,} The Free Encyclopedia", 300 | year = "2017", 301 | url = {https://en.wikipedia.org/w/index.php?title=Software_Guard_Extensions&oldid=791564290}, 302 | } 303 | 304 | @misc{dash:whitepaper, 305 | author = {Duffield, Evan and Diaz, Daniel}, 306 | title = "Dash: A Privacy-Centric Crypto-Currency", 307 | year = "2015", 308 | url = {https://www.dash.org/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf}, 309 | } 310 | 311 | 312 | @article{Ateniese-key-private, 313 | author = {Ateniese, Giuseppe and Benson, Karyn and Hohenberger, Susan}, 314 | doi = {10.1007/978-3-642-00862-7_19}, 315 | file = {:home/michwill/Documents/Mendeley Desktop/Ateniese, Benson, Hohenberger/Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)/Ateniese, Benson, Hohenberger - 2009 - Key-private proxy re-encryption.pdf:pdf}, 316 | isbn = {9783642008610}, 317 | issn = {03029743}, 318 | journal = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)}, 319 | mendeley-groups = {Data security}, 320 | pages = {279--294}, 321 | title = {{Key-private proxy re-encryption}}, 322 | volume = {5473}, 323 | year = {2009} 324 | } 325 | 326 | 327 | @misc{aont-bulk, 328 | author = {Steven Myers and Adam Shull}, 329 | title = {Efficient Hybrid Proxy Re-Encryption for Practical Revocation and Key Rotation}, 330 | howpublished = {Cryptology ePrint Archive, Report 2017/833}, 331 | year = {2017}, 332 | note = {\url{http://eprint.iacr.org/2017/833}}, 333 | } 334 | 335 | 336 | @article{Libert2008, 337 | author = {Libert, Beno{\^{i}}t and Vergnaud, Damien}, 338 | doi = {10.1007/978-3-540-85538-5_22}, 339 | isbn = {3540855033}, 340 | issn = {03029743}, 341 | journal = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)}, 342 | keywords = {Collusion detection and traceability,Transferability issues,Unidirectional proxy re-encryption}, 343 | pages = {332--353}, 344 | title = {{Tracing malicious proxies in proxy re-encryption}}, 345 | volume = {5209 LNCS}, 346 | year = {2008} 347 | } 348 | 349 | 350 | @article{Bentov2014, 351 | author = {Bentov, Iddo and Kumaresan, Ranjit}, 352 | doi = {10.1007/978-3-662-44381-1_24}, 353 | isbn = {9783662443804}, 354 | issn = {16113349}, 355 | journal = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)}, 356 | keywords = {Bitcoin,Fair exchange,Secure computation}, 357 | mendeley-groups = {Data security}, 358 | number = {PART 2}, 359 | pages = {421--439}, 360 | title = {{How to use Bitcoin to design fair protocols}}, 361 | volume = {8617 LNCS}, 362 | year = {2014} 363 | } 364 | 365 | @article{AccountableStorage, 366 | author = {Ateniese, Giuseppe}, 367 | mendeley-groups = {Data security}, 368 | pages = {1--18}, 369 | title = {{Accountable Storage}} 370 | } 371 | 372 | 373 | @article{BitcoinMPC2016, 374 | author = {Andrychowicz, Marcin and Dziembowski, Stefan and Malinowski, Daniel and Mazurek, $\backslash$Lukasz}, 375 | doi = {10.1145/2896386}, 376 | issn = {0001-0782}, 377 | journal = {Commun. ACM}, 378 | keywords = {bitcoin,lottery,multiparty}, 379 | mendeley-groups = {Data security}, 380 | number = {4}, 381 | pages = {76--84}, 382 | title = {{Secure Multiparty Computations on Bitcoin}}, 383 | url = {http://doi.acm.org/10.1145/2896386}, 384 | volume = {59}, 385 | year = {2016} 386 | } 387 | 388 | 389 | @article{Yang2011, 390 | author = {Yang, Yanjiang and Gu, Liang and Bao, Feng}, 391 | doi = {10.1007/978-3-642-25283-9_13}, 392 | isbn = {9783642252822}, 393 | issn = {03029743}, 394 | journal = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)}, 395 | keywords = {Proxy re-encryption,trusted computing}, 396 | mendeley-groups = {Data security}, 397 | pages = {189--199}, 398 | title = {{Addressing leakage of re-encryption key in proxy re-encryption using trusted computing}}, 399 | volume = {6802 LNCS}, 400 | year = {2011} 401 | } 402 | 403 | @incollection{Zhou2002, 404 | author = {Lin, Xiaodong and Lu, Rongxing}, 405 | doi = {10.1007/978-3-319-40367-0_8}, 406 | file = {:home/michwill/Documents/Mendeley Desktop/Zhou, Batten, Seberry/Unknown/Zhou, Batten, Seberry - 2002 - Proxy Re-encryption with Delegatable Verifiabilit.pdf:pdf}, 407 | isbn = {978-3-540-43861-8}, 408 | issn = {0302-9743}, 409 | keywords = {delegatable verifability,proxy re-encryption,trust level}, 410 | mendeley-groups = {Data security}, 411 | pages = {120--133}, 412 | title = {{Proxy Re-encryption with Delegatable Verifiability}}, 413 | url = {http://www.springerlink.com/content/5kvy3aqndlwkpgj6/ http://link.springer.com/10.1007/978-3-319-40367-0{\_}8}, 414 | volume = {2384}, 415 | year = {2016} 416 | } 417 | -------------------------------------------------------------------------------- /whitepaper.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/nucypher/whitepaper/24c8971f693199539deb8d17472046d98ae02604/whitepaper.pdf --------------------------------------------------------------------------------