Toward Uncensorable, Anonymous and Private Access Over Satoshi Blockchains

We consider the model illustrated in Figure 1, where clients that are censored and under surveillance need to access sensitive content posted by publishers who are outside the censored area. For this, we define a storage system UWeb = $(\mathcal{B},ClientSetup,Store,Access)$ built over a blockchain $\mathcal{B}$ that consists of functions to setup client functionality, and store and access content.

Content publishers use the $Store$ function to embed data in the fields of cryptocurrency transactions that are persisted in the blockchain $\mathcal{B}$ at the cost of mining them. Consumers use the $Access$ function to access stored content for free. While UWeb’s reliance on cryptocurrency transactions can be leveraged to enable content publishers, content consumers and combinations thereof to pay for the storage of data, the specific payment arrangements are outside the scope of this paper.

Data can be stored in a single transaction or in multiple transactions. We view the blockchain $\mathcal{B}$ to be an ordered set of transactions of the simplified form $(i,d,u)$, where $i$ is the index of the transaction, $d$ is the transaction content, and $u$ is a boolean that specifies whether this is a financial transaction ($u$ = 0) or a data-storing transaction ($u$ = 1).

We assume that any publisher and consumer has control over her computer and can install arbitrary software, including a cryptocurrency node, the cryptocurrency reference software, and the UWeb client that we develop. We assume that developed software can only communicate through the gossip network and the blockchain. While other communication media would simplify the solution design, they often leak sensitive information to the provider [51, 52], and can be vulnerable to denial of service and insider attacks. While we assume that software cannot access off-chain storage services, we assume that it can access basic services, e.g., routing, DNS, certification authorities, and other cryptocurrency nodes.

We consider an adversary who seeks to monitor the access to content of users in a certain region, and even to prevent accesses to content considered sensitive, see Figure 1. In the following we first detail the monitoring adversary, then the censoring one.

In the following, we say that a network communication $\Gamma$ is possible when accessing transaction $T_{i}=(i,d_{i},u_{i})$ if $P(\Gamma|T_{i})$ > 0, i.e., the conditional probability that UWeb performed communication $\Gamma$ with the cryptocurrency network to access data $d$ is positive.

We consider adversaries that are able to monitor the communications of UWeb users and other Satoshi nodes, and arbitrarily inject, delete, and reorder messages. We assume however that the adversary cannot decrypt encrypted content or forge signatures, without knowledge of the decryption and signature generation keys, respectively. We assume that the adversary can run any number of clients and services, including of UWeb, and can publish content or access content published by others.

• –

  $\mathcal{C}$ installs required software (e.g., Satoshi client) and sets up functionality as described in $\S$ 4.3. $\mathcal{A}$ stores the blockchain $\mathcal{B}$ to serve its content over the cryptocurrency p2p network, upon request.

• –

  The adversary may perform a polynomially bounded number of operations to select 2 indices $i_{0},i_{1}$ of transactions in blockchain $\mathcal{B}$.

• –

  At a desired time, $\mathcal{A}$ sends to $\mathcal{C}$ the indices $i_{0}$ and $i_{1}$, where $T_{i_{0}}=(i_{0},d_{0},u_{0})\in\mathcal{B}$, $T_{i_{1}}=(i_{1},d_{1},u_{1})\in\mathcal{B}\}$.

• –

  $\mathcal{C}$ picks a bit $b\in_{R}\{0,1\}$ uniformly at random. $\mathcal{C}$ performs communication $\Gamma$ to access transaction $T_{i_{b}}$ from $\mathcal{A}$, then signals completion.

• –

  $\mathcal{A}$ performs additional computations and outputs bit $b^{\prime}$, his prediction of the bit $b$ chosen by $\mathcal{C}$.

We then introduce the following definition:

• –

  $\mathcal{C}$ installs required software (e.g., Satoshi client) and sets up functionality as described in $\S$ 4.3. $\mathcal{A}$ stores the blockchain $\mathcal{B}$ to serve its content over the cryptocurrency p2p network protocol upon request.

• –

  The adversary may perform a polynomially bounded number of operations to select $m+n>0$ indices $i\in\{1\dots m+n\}$ of transactions $T_{i}=(i,d_{i},u_{i})$ in blockchain $\mathcal{B}$ such that $m$ transactions have bit $u$ = 1 and $n$ transactions have bit $u$ = 0.

• –

  At a desired time, $\mathcal{A}$ sends to $\mathcal{C}$ the set of $m+n$ indices: $[i]=\{i\mid i\in 1..m+n,T_{i}=(i,d_{i},u_{i})\in\mathcal{B}\}$.

• –

  $\mathcal{C}$ selects a bit $b\in_{R}\{0,1\}$ uniformly at random. $\mathcal{C}$ then performs communication $\Gamma$ to collect all transactions $T_{i}=(i,d_{i},u_{i}=b)$ from $\mathcal{A}$ (either $m$ or $n$ of them) and signals completion.

• –

  $\mathcal{A}$ performs additional computations and eventually outputs $b^{\prime}$, his prediction of the bit $b$ chosen by $\mathcal{C}$.

We introduce then the following definition:

• Proof.

Let us assume that there exists a PPT adversary $\mathcal{A}$ with advantage $\epsilon$ in the anonymous network access security game (Definition 3.2). Then, we use that adversary against the challenger in the private network access security game (Definition 3.1) to achieve the same advantage $\epsilon$ against that challenger. Formally, we create a new adversary $\mathcal{A^{\prime}}$ that acts as a challenger with $\mathcal{A}$ in an anonymous access game, and acts as adversary against a challenger $\mathcal{C}$ in a private access game:

• –

  $\mathcal{A}$ sets $m$ = 1 and $n$ = 1, and chooses transactions $T_{i_{0}},T_{i_{1}}$ such that $u_{i_{0}}=0$ and $u_{i_{1}}=1$. $\mathcal{A}$ sends $i_{0}$ and $i_{1}$ to $\mathcal{A^{\prime}}$.

• –

  $\mathcal{A^{\prime}}$ forwards them to $\mathcal{C}$, then acts as a proxy between $\mathcal{A}$ and $\mathcal{C}$, enabling $\mathcal{C}$ to fetch blockchain $\mathcal{B}$ from $\mathcal{A}$.

• –

  $\mathcal{C}$ picks a bit $b$ randomly then accesses TX $T_{i_{b}}$.

• –

  $\mathcal{A}$ sends to $\mathcal{A^{\prime}}$ his guess bit $b^{\prime}$. $\mathcal{A^{\prime}}$ forwards $b^{\prime}$ to $\mathcal{C}$.

∎

However, we assume that the censor is not willing to block or significantly hinder cryptocurrency use inside the censored area, due to the associated collateral damage [58, 59]. For instance, China ranks first in the world on the “activity of non-professional, individual cryptocurrency users, based on how much cryptocurrency they are transacting compared to the wealth of the average person” [60], while Russia ranks second in the world in trading volume in Bitcoin [61].

We also assume that the censor controls gossip network nodes, mining nodes, and even mining pools. Such a censor can then further launch output and input script modification attacks, a.k.a., sniping and integrity attacks [62] (see Appendix B), which effectively corrupt data embedded in transactions that have not yet been mined. These attacks duplicate victim transactions, modify the duplicates at will, then rush the fabricated transactions in the p2p network in an effort to have them mined before the original transactions.

However, since a majority attack would damage the trust in the financial aspect of any cryptocurrency, we assume that the censor does not control more than half of the mining power of the network. Recent research [63] has shown that no country or mining pool controls 51% of the mining power in Bitcoin. Further, we assume that the censor cannot block the access of honest clients, to all the nodes with access to an honest pool. We now introduce the following definition:

We consider the problem of providing efficient storage of information such that access to the data is hard to monitor or censor. Developed solutions need to satisfy blockchain-imposed restrictions ($\S$ 3.1) and optimize several relevant metrics, which we now define. We use the term construct to refer to the solution’s basic unit of storing data, e.g., transaction or group of transactions.

We now define the data storage problem:

Further, we define the data access problem:

To satisfy Definition 3.4 we first develop input script-writing solutions that achieve optimal script utilization, i.e., maximize input goodput, and simultaneously prevent the input/output modification attacks of $\S$ 3.2 and satisfy the blockchain restrictions for standard transactions. We observe that the blockchain restrictions for standard transactions imply that optimal script utilization allows for a maximum of 3 large push operations (1,650 B / 520 B) and a few extra bytes per input script.

Algorithm 1 shows the proposed smart contract that achieves optimal utilization of the available storage space on an input script under these restrictions and also prevents the transaction integrity attacks described in Appendix B. Similar to Todd’s technique [48], we use hash lock constructs (lines 7-9) to protect the data pushed (lines 2-4). However, unlike Todd’s technique, we do not sacrifice one of the data push operations (lines 2-4) to include a public key and a signature verification on the redeeming script (lines 5-9). We do not need this verification because our outputs are simple OP_RET outpoints (right of Figure 2). Thus, the maximum storage capacity per input script is 1,568 bytes and after accounting for the overhead, the typical size of a funding/spending transaction pair is 1,703 bytes. We analyze the security that this technique provides against input and output modification attacks, in $\S$ 4.4.

We now leverage the above data storing script, to introduce max-rate transactions, the first practical, transaction-based data-storing construct that satisfied Definition 3.4). Given a single input address with sufficient funds, max-rate transactions achieve a throughput asymptotic to the available bandwidth, entirely through a Satoshi blockchain (gossip) network, at a minimum cost rate, satisfy the blockchain restrictions of $\S$ 3.1, and prevent the transaction integrity attacks of Appendix B.

To achieve this, we observe that factoring out the transaction overhead, a basic data-storing transaction can handle 59 data storing, spending input scripts (i.e. 100KB / 1,650 B, since the maximum size of a transaction is 100KB) while funding transactions can handle up to 2,937 outputs, with one output reserved for balance change (according to restriction 3.2, $\S$ 3.1). Figure 2 shows the optimal max-rate transaction construct that allows funding outputs to create spending inputs in a web of transactions that minimizes storage overhead. To optimize storage, we group the maximum amount of inputs into one transaction, thus reduce the overhead of using several transactions for this purpose.

The first issued, max-rate funding transaction (left of Figure 2) bundles funding outputs Out Addr 1,2,…, $n$, where the maximum $n$ is 2,936 + 1 change output. Each output is constructed with an address that references the redeeming script of the corresponding payload-storing input (Fat In Script 1,2,…, $n$) inside a max-rate spending transaction (right of Figure 2). As described above, each spending transaction can have a maximum of 59 such payload-storing inputs. A max-rate funding transaction can thus fund 49 (= 2,937 / 59) completely full, fat spending transactions and 1 more spending transaction with 46 inputs. Therefore, the largest amount of data that can be written with this construct (i.e., 1 funding and 50 spending transactions) is 4.6MB (2936*1568).

The max-rate funding transaction and subsequent spending transactions are separated by a confirmation boundary that represents a new block mining event and its respective waiting time. That is, the funding transaction needs to be mined and confirmed before we issue the spending transactions. This is imposed by the blockchain requirement that chains of unconfirmed transactions do not exceed 101KB in size (restriction 3.4, $\S$ 3.1). Thus, every funding output is already confirmed before any spending input enters the network. This ensures minimum wait time for payload storing transactions, since they are no longer constrained by the maximum chain of unconfirmed transactions. We further discuss this in $\S$ 4.4.

We now leverage max-rate transactions to build the UWeb storage system defined in $\S$ 3.1 and provide private, censorship resistant and efficient access to data stored in a blockchain among millions of transactions. To organize stored content, UWeb defines several content-storing transaction-based entry types, illustrated in Figure 4: DATA entries are transactions that store compressed content organized in files, and DIR entries organize information about directories and/or files. DIR entries point to either DATA entries or recursively to other DIR entries. DIR entries also store content meta-data, e.g., whether they point to a file or a directory, and a signature generated by the publisher over the entry’s previous fields, to provide integrity. In the following we define the UWeb functions of $\S$ 3.1.

All UWeb transaction entries may make use of multiple input addresses in order to ensure the ability to chain these entries even when an output address runs out of enough funding. However, output addresses consist of 1) one OP_RET output with directives and associated metadata and 2) one or more P2SH outputs for chaining. Because OP_RET outputs are limited to 80 bytes only, metadata larger than 80 bytes can be stored chaining more DIR INIT entries using the remaining P2SH outputs. In order to mark the end of a metadata chained in this way, we use the same variable length integer format used in Bitcoin [64]. All DIR entries should reserve one P2SH un-spent output in order to continue the chain of directives.

To discover content the first $Access$ function call needs to download the entire blockchain. Once the entire blockchain history is available, UWeb scans all transactions looking for DIR entries of different publishers and traverses the structure depicted in Figure 4. In order to do this, the client looks for OP_RET outputs that start with the DIR INIT tag ($0x44495220494E4954$ in hex) and reads off origin metadata including a public key certificate of the publisher. After validating this certificate, downstream content in this data structure can be verified with strong cryptographic assurances.

As UWeb discovers new content, either by traversing the entire blockchain or processing only new transactions, it builds an external database for content random access. When a user searches for content of interest, data is searched in this external database. Thus, accessing content is completely decoupled from the Satoshi reference client operation.

• Proof.

  The expected throughput $R(N)$ corresponding to a given size of payload $N$ is given by $R(N)=\frac{N}{w\times E+N/B}$, where $E$ is the number of confirmation epochs (i.e., mining events) required to generate the max-rate transaction, $w$ is the expected wait time for a confirmation event (e.g., $w=150$ secs for the Litecoin network) and $B$ is the upload bandwidth available to connect to the gossip network. Further, $E=1+\frac{N}{p\times F}$, where $p$ is the maximum payload size in a script and $F$ is the maximum number of funding outputs that fit in one block. For our max-rate transaction, $p=1,568$ and $F\approx 29,370$. For a 46MB payload and a 1Gbs upload bandwidth in our lab, the expected throughput is 154KB/s. Further, the throughput is hyperbolic with respect to the payload size. Thus, when $N\to\infty$, $R(N)\to B$, the available upload bandwidth. ∎

• Proof.

  For content of size $N$, the number of spending transactions is given by $Q(N)=\frac{N}{p\times m}$, where $m$ is the maximum number of max-size inputs ($\S$ 4.1) that fit in a transaction. For Bitcoin/Litecoin, $m=100$KB$/1,720\approx 59.5$. The number of funding transactions is given by $L(N)=\frac{N}{p\times f}$, where $f$ is the maximum number of funding outputs that fit in a transaction. For Bitcoin and Litecoin, $f=2,937$. Thus, the total size of max-rate transactions is $S(N)=ts\times\left(\frac{N}{p\times f}+\frac{N}{p\times m}\right)$, where $ts$ is the maximum size of a transaction. For Litecoin, $ts$ = 100KB. Then, the goodput of a max-rate transaction is $G(N)=\frac{N}{S(N)}$. ∎

We include the proof in Appendix A. Further, in Appendix A we also show that max-rate transactions prevent input and output modification attacks. Then, given that our blockchain-writing constructs are standard, maximize throughput and goodput and are secure against input and output modification attacks, we conclude that max-rate transactions satisfy the optimal blockchain storage problem (Def. 3.4).

• Proof.

  Following the private network access game (Definition 3.1), UWeb first downloads the entire blockchain before accessing all data-containing transaction $T_{i}$ (see $\S$ 4.3). Thus, the only possible communication $\Gamma$ is the entire log of transactions in blockchain $\mathcal{B}$ until all $T_{i}$ have been observed. Therefore, $P(\Gamma=\mathcal{B}\mid b)=P(\Gamma=\mathcal{B})=1$ for all of $\mathcal{C}$’s choices of $b$, i.e., no matter the choice of $b$, $\mathcal{A}$ always observes the same communication. This implies that knowledge of $\Gamma$ does not provide $\mathcal{A}$ with an advantage in the choice of $b$. Formally, for any PPT $\mathcal{A}$, the conditional probability of guessing $\mathcal{C}$’s $b$ value given communication $\Gamma$ is, according to Bayes’ theorem, $P(b^{\prime}=b\mid\Gamma=\mathcal{B})=P(\Gamma=\mathcal{B}\mid b)\times P(b)/P(\Gamma=\mathcal{B})$. Since the choice of $b$ is random (see the PNA game in $\S$ 3.2), $P(b)=1/2$, thus $P(b^{\prime}=b\mid\Gamma=\mathcal{B})=1\times(1/2)/1=1/2$. Thus, we have that for any adversary $\mathcal{A}$:

  	$\displaystyle\textbf{Adv}_{UWeb}^{PNA}(\mathcal{A})$	$\displaystyle=|P(b^{\prime}=b)-P(b^{\prime}\neq b)|$
  		$\displaystyle=|P(b^{\prime}=b)-(1-P(b^{\prime}=b))|$
  		$\displaystyle=|2\times P(b^{\prime}=b\mid\Gamma=\mathcal{B})-1|=0$

  ∎

UWeb also provides anonymous network access: due to Claim 1, since UWeb provides private network access it also provides anonymous network access.

A censor who seeks to block access to the whole blockchain will trivially deprive the entire censored area of access to the market of the corresponding cryptocurrency. A censor who seeks to selectively filter certain blocks, e.g., containing transactions that embed UWeb content, would generate a split universe with global impact on the consensus protocol, thus will eventually similarly deprive the entire censored area of access to the market of the corresponding cryptocurrency. Given that UWeb can be ported to all Satoshi compliant cryptocurrencies, a censor that wants to block UWeb needs to block all Satoshi compliant cryptocurrencies, thus depriving its economy from access to a market capitalization of p = $1 trillion (see Definition 3.3).

We note that promising research on redactable blockchains has been conducted by Deuber et al. [70], and also [71, 72, 73]. We envision a system where it is cheaper for a majority to delete undesirable content than for a minority to keep re-introducing it. Such a system would self-regulate the impact of arbitrary data insertions on the overall blockchain ecosystem. We acknowledge however that (1) content could be written encrypted, for valid confidentiality reasons, and (2) mining pools and regular nodes need incentives to correctly implement such blockchain redactions. Further, we observe that un-checked blockchain redactions are a threat to UWeb’s censorship-resistance.

We obtained permission from the British Broadcasting Corporation (BBC) to reproduce their web articles (only text) into the Litecoin blockchain. We created a crawler that de-fanged articles (also removed the ads) from all public BBC’s RSS feeds every day for 134 consecutive days. We daily bundled the text-only articles (average of 0\entries) daily articles, at an average of 0\totalarticles)  characters and 555 words per article) into categorized directories, compressed them into a gzipped file and wrote the archive using max-rate transactions ($\S$4.2).

In total, we performed \entries writing operations (1 per day) to store \size  Bytes for \totalarticles  articles with an accumulated cost of \FPeval\resultround(\cost,6)\result LTC ($\FPeval\resultround(\cost*239.40,4)\result at the time of writing). Thus, the average cost per article is \FPeval\resultround(\avgcost*100000000,0)\result Litoshi ($\FPeval\resultround(\avgcost*239.40,4)\result at the time of writing), and the average daily cost is 0.0041 LTC ($\FPeval\resultround(0.0041*239.40,4)\result). Assuming a daily average of 400 articles, at an average of 1000 characters per article, we expect the daily storage size to be around 400 KB. At this publication rate and current LTC price, we expect a monthly publication cost of $6 USD, which is below the average monthly news digital subscription price in the US of $9.24 [74].

Each daily storage operation required one funding transaction and four spending transactions. Each storing operation achieved an average transmission throughput of \FPeval\resultround(\avgswift,2)\result Bytes/sec and an average confirmation throughput of \FPeval\resultround(\avgonchain,2)\result Bytes/sec. Figure 5 shows the daily time required for all transactions to obtain at least one confirmation on the blockchain. This time corresponds to the confirmation time row in Table 1. The color intensity of each dot represents the size in bytes of the bundle of daily articles, whose statistics are shown in the size row of Table 1. Further, the dot radius in Figure 5 represents the cost in mLTC, which corresponds to the cost row in Table 1. These results suggest that the transaction cost and size do not have a consistent impact over the expected confirmation time. On the contrary, confirmation time may be more sensitive to block utilization and network congestion due to large mempool sizes, as we shall see in the following.

Further, we evaluated the impact of the BBC writing operations, on the time it takes Litecoin transactions of other users to be confirmed in the blockchain. Figure 7 shows the time required to achieve one confirmation for different fee rate levels during the March 20 - April 7 interval, over all the transactions posted on Litecoin during that interval. The time required to confirm new transactions is consistent with the expected 2.5 min epoch time. Moreover, for these levels of block utilization, the fee rate does not appear to have any significant impact over the network throughput.

To evaluate UWeb and max-rate transactions under large writing loads, we have collected a set of 41 censorship resistant (CR) tools from [75] that include Tor[76], Stegotorus[77], Uproxy-client[78], Bit-smuggler[79] and Shadowsocks. We excluded projects that did not publish an explicit re-distribution license. Table 3 in Appendix D provides the full list. The total compressed size of the 41 tools is 217 MB.

We designed our experiment in two phases. First, we almost-concurrently sent the first 3 largest size projects as individual archives, for a total of 140 MB. Second, we sent the rest of the tools compressed, in one split archive, for a total of 77 MB. This strategy allowed us to send files of size at most 45MB each, compatible with our virtual machine RAM memory resources. The total combined cost for this experiment was 2.51315448 LTC ($\FPeval\resultround(2.51315448*239.40,4)\FPeval\resultround(\result,2)\result at the time of writing).

We then measured the time each new unconfirmed transaction spent in the mempool before obtaining one confirmation on the Litecoin blockchain. Figure 9 compares the distribution of the confirmation time ($y$ axis, log scale) over transactions employing different fee rates ($x$ axis), during (1) our 140 MB writing experiment that lasted 7.6 hours from the first unconfirmed max-rate transaction observed in the mempool, until the last one received at least one confirmation (blue violins), and (2) before our experiment: since the start of the mempool instrumentation measurements on March 20, 2019, until the first unconfirmed transaction of the 140 MB experiment arrived to the mempool on April 7, 2019 (red violins). Interval (2) is the same 18 days when we monitored the mempool during the BBC experiment.

We observe that our significant writing experiment did not impact the confirmation times of financial transactions, including those employing the lowest fee rates (1- 50 lit/B). However, the maximum max-rate transaction confirmation time was 7.63 hours.

Financial transactions are unaffected because mining pools greedily select the next block to mine based on the fee rate of the transactions in the mempool [80]. Max-rate transactions have the lowest fee rate (1 litoshi per byte) thus have the lowest priority for selection. Only four financial transactions (of sizes up to 1,994B) had a fee rate of 1 litoshi/B. Their delays ranged from 69s to 527s (8.8 mins). This suggests that an overwhelming majority of financial transactions use fee rates that exceed the UWeb fee rate, thus are not impacted. While it is theoretically possible for minimum fee-rate transactions to be impacted by UWeb, this did not occur in our experiments.

Our large-scale writing experiments achieved a lifetime record high daily average block size as recorded by bitinfocharts [81]. Figure 10 shows the daily average block size of the Litecoin network for its entire lifetime. During the day of our experiments, the average daily block size reached 206KB, the largest ever recorded in the history of Litecoin.

In Appendix C we zoom-in into block utilization results when using UWeb to write the Tor source code [82] compressed archive (6.4 MB).

Table 2 compares max-rate transactions against state-of-the-art blockchain-writing solutions, on the metrics included in Definition 3.4. In our experiments, max-rate transactions achieve 2-3 orders of magnitude improvements in throughput and block utilizations and are the only solution that provides private access, censorship resistance, and resilience to integrity attacks. Catena [25] and Apertus [45] embed tens of bytes per input in a transaction, and have confirmation time requirements. This, coupled with the required transaction fees and the fact that often these transactions are non-redeemable, also leads to impractical costs for writers.

While Tithonus [47] has the same cost and slightly lower goodput to max-rate transactions, UWeb significantly improves on its throughput. Since UWeb does not attempt to publish content from within the censored region, it significantly improves on the throughput, goodput and cost efficiency of MoneyMorph [37].

Further, we notice that the goodput of max-rate transactions is consistent with the theoretical value derived in the proof of Claim 3. The throughput achieved by max-rate transactions is also consistent with the theoretical value derived in the proof of Claim 2. In contrast, the constructs used by Apertus [45], Catena [25] and Blockstack [23] have a constant relationship between payload size and throughput, thus cannot reduce the ratio between the maximum and their observed empirical throughput.

We performed simulations to understand the impact on the Litecoin blockchain of multiple concurrent UWeb writers and higher levels of financial transactions. The simulator generates the next block to be mined by prioritizing the transactions from the mempool that have the highest fee rate [80], and breaks the tie based on arrival times.

We have simulated between 1 and 3,000 concurrent writers, each writing 400KB in the same 4 hour interval. Thus, each writer is equivalent to the daily writing load from the BBC experiment ($\S$ 5.3). We have added max-rate transactions from each writer (four of size 99,931B one of 10,876B) at times randomly distributed in the same four-hour interval at the beginning the financial transaction trace. The case of 359 writers is roughly equivalent to the realnet experiment whose results are shown in Figure 9, where we wrote 140MB in the Litecoin blockchain. The 3,000 writers post 1.14GB of data-storing transactions.

Figure 12 shows the distributions of confirmation times of financial and max-rate transactions. We observe that financial transactions (red violins) are not impacted by the number of writers. This is because all financial transactions have a fee rate that exceeds UWeb’s 1 litoshi/B rate. The maxrate transactions of UWeb writers have similar confirmation times to financial transactions, up to a number of writers that do not consume the available space in a block. After that point the confirmation time for maxrate transaction increases linearly with the number of writers.