# A large-scale longitudinal structured dataset of the dark web cryptomarket
Evolution (2014–2015)

Hanjo D. Boekhout  Leiden University, Institute of Advanced Computer Science,
Niels Bohrweg 1, 2333 CA Leiden, Netherlands  corresponding author(s): Hanjo
D. Boekhout<EMAIL_ADDRESS> Arjan A.J. Blokland  Leiden
University, Institute of Criminal Law and Criminology, Steenschuur 25, 2311 ES
Leiden, Netherlands  Netherlands Institute for the Study of Crime and Law
Enforcement (NCSR), De Boelelaan 1077, 1081 HV Amsterdam, Netherlands  Frank
W. Takes  Leiden University, Institute of Advanced Computer Science, Niels
Bohrweg 1, 2333 CA Leiden, Netherlands

###### Abstract

Dark Web Marketplaces (DWM) facilitate the online trade of illicit goods. Due
to the illicit nature of these marketplaces, quality datasets are scarce and
difficult to produce. The Dark Net Market archives (2015) presented raw
scraped source files crawled from a selection of DWMs, including Evolution.
Here, we present, specifically for the Evolution DWM, a structured dataset
extracted from Dark Net Market archive data. Uniquely, many of the data
quality issues inherent to crawled data are resolved. The dataset covers over
500 thousand forum posts and over 80 thousand listings, providing data on
forums, topics, posts, forum users, market vendors, listings, and more.
Additionally, we present temporal weighted communication networks extracted
from this data. The presented dataset provides easy access to a high quality
DWM dataset to facilitate the study of criminal behaviour and communication on
such DWMs, which may provide a relevant source of knowledge for researchers
across disciplines, from social science to law to network science.

## Background & Summary

The online trade of illicit goods, from drugs and card information (credit/ID)
to far more sinister goods and services like weapons and assassinations, has
steadily grown since the launch of the first Dark Web Marketplace (DWM), Silk
Road, in 2011 [1]. In 2020, for the first time the reported total trade
volume, through DWMs, exceeded $1.5 billion [2]. One explanation for this
growth lies in the anonymity and reduced risk of violence, due to a lack of
face-to-face contact in DWMs. Anonymity is facilitated through browsers such
as The Onion Router (Tor) [3] and payment is typically made with crypto
currencies such as Bitcoin [4]. Additionally, many DWMs provide services such
as a moderated forum and escrow services to improve the trust between vendors
and their customers. Users can, for example, promote or review the goods on
sale on the forum. DWMs that provide these services are also referred to as
_cryptomarkets_ [5, 6]. Naturally, law enforcement has put continual effort in
disrupting cryptomarkets [6] and researchers have endeavoured to better
understand these markets and accompanying forums [7, 8, 9, 10, 11].

One complicating factor for research on cryptomarkets is obtaining data. As
cryptomarkets facilitate illegal trade they are naturally disinclined to share
such information. During the early years of DWMs an effort was made to scrape
a large set of the active DWMs. A comprehensive collection of these scrapes
called the _Darknet Market Archives_ was published by Branwen et al. [12] in
2015. This collection contains raw source files scraped from 99 different DWMs
and has been used in a plethora of research [8, 9, 10, 11]. A major downside
of the Dark Net Market archives for researchers is that it consists of raw
source files and relevant data must thus first be extracted before it can be
analysed. Such extraction is not (always) straightforward as the structure of
source files changes and the fora and marketplaces evolve over time.
Furthermore, source files can be incomplete, include captchas, or simply be
missing. Ideally the effort of extracting, cleaning, and resolving
inconsistencies in the data from the source files, would not need to be
repeated by each individual researcher. To assist with this, we present here a
(near) complete and cleaned structured dataset for one of the cryptomarkets
included in the Dark Net Market archives, _Evolution_.

Evolution was active from January 2014 until March 2015, when it closed due to
an exit scam. At the time, it was one of the most popular cryptomarkets [6].
It formed a combination of a carding forum, where card information (e.g.,
credit/debit/ID/etc.) is traded, and an underground drug market; and was in
essence the successor to the TCF carding forum [13]. The raw source files
obtained from the Dark Net Market archives consist of respectively 96 and 115
scrapes of Evolution’s forum and marketplace (see Figure 1).

Figure 1: Timeline of scrapes of the Evolution forum and marketplace

The Evolution forum consists of sequential posts in topics which are
themselves categorized within fora that group topics by general subject. From
this we extracted information regarding each scrape, forum, topic, post, and
user. The Evolution marketplace revolves around the products for sale and
their vendors. Store, product category, listing, and vendor profile source
pages provide varying types of information on product listings and vendors. As
such, we extracted information from the marketplace regarding each scrape,
product category, listing, vendor, and feedback message. Obviously, linking
data from both the forum and market is important for research on how the forum
communication impacts market performance and functioning. Unfortunately, the
source files provide no way to link forum user accounts to vendor accounts.
Therefore, we perform user matching based on usernames to provide a simple but
relatively effective method of linking the two types of data.

Finally, with this paper we share monthly snapshots of an extracted weighted
temporal communication network, which captures the indirect communication and
shared interest of forum users. These networks and the structured dataset were
used to investigate to what extent (future) successful vendors on the
Evolution cryptomarket could be predicted without knowledge of forum post
content [14]. For each month in the active period of Evolution, the set of the
most successful vendors were determined in terms of both current and future
sales. We then investigated the predictive performance of several forum
activity measures, directly computed from the structured dataset, and network
measures, computed from the network snapshots. We found that a particular
combination of activity and network measures were able to reliably reduce the
set of candidate users for law enforcement to investigate. Additionally, we
found that a significant proportion of the users with the highest forum
activity and network centralities could be classified as vendors or other key
players. Furthermore, we found that these measures could serve as early
warning signals for future vendor success. The extracted dataset and
communication networks may be of use for further studies of DWMs; and, the
included communication network(s) constitute a rare relatively large sized
weighted temporal network now available [15] open-source for use in network
science research.

## Methods

The process of extracting our dataset from the raw source files of the DNM
archives can be divided into four steps (as depicted in Figure 2): (1)
extraction of all relevant data from forum and market raw source files, on a
file by file basis; (2) creating a structured dataset; (3) matching forum
users to market vendors; and (4) extraction of weighted communication network
snapshots.

### Step 1: Extraction of forum and market data from source files

In its raw state, the data on the cryptomarket Evolution retrieved from the
Darknet Market Archives is split between forum and market data, which is
subsequently split into various _scrapes_. Each scrape is the culmination of
(several days worth of) capturing a great number of pages on the market or
forum as mostly _.html_ files (generated by _.php_ files). The relevant data
is hidden/distributed among these dumps of many files. Additionally, evolving
versions of the same files may exist among the various scrapes. Furthermore,
errors may have occurred while capturing the files and there likely was a lack
of access to the parts of the forum restricted to non-regular users. As such,
the data available in the captured files contains many of the common data
quality issues like: data duplication, (temporal) data inconsistencies,
missing and hidden data. As our first step in identifying and resolving these
issues, we extract all relevant data on a file by file basis, and store it in
a tabular format.

The extraction process (for both forum and market) starts off by indexing the
scrapes, which are organised in separate folders labelled by their date (see
Figure 1 for a timeline). For each of the 96 forum scrapes we can encounter
four types of files with relevant data: (1) _index_ files (1 or 2 per scrape),
which list the various fora, including descriptions, topic and post
statistics, and cumulative statistics on the number of topics, posts, and
users overall; (2) _viewforum_ files (26,115 total), which describe a single
page of topics that are part of a given forum (usually 30 topics); (3)
_viewtopic_ files ($\approx$5.2 million total), which describe a single page
of posts that are part of a given topic (usually 25 posts); and (4) _profile_
files (435,393 total), containing information on a given forum user. From
these files, we extract all available information regarding the various fora,
topics, posts and users.

The Evolution marketplace provided various ways to browse the available
listings: specific listing pages, store pages with listings sorted by vendor
and category pages with listings sorted by product type. Listing and vendor
information was extracted from each of these types of pages. We note that
listing pages come in three formats, each providing some shared and some
unique information. First, only the _generic format_ provides a product
description and available shipping destinations. Second, the _feedback format_
provides a single page of feedback on the listing. Finally, the _return
policy_ format provides the return policy associated with the listing.
Additionally, we extracted vendor information from vendor profile pages as
these provide additional information on the vendors themselves, irrespective
of their listings. We note that the vendor profile pages come in five formats:
a _generic format_ and _feedback format_ , providing no additional unique
information; a _legacy sales format_ detailing any (verified) sales this
vendor might have had on past DWMs; a _pgp format_ providing the vendor’s PGP-
key; and, a _return policy format_ listing the return policy the vendor
adheres to. We ignored feedback provided by profile pages of the feedback
format in favor of feedback obtained from listing pages.

In terms of missing data due to problems during the capture of pages, we found
a combined 329 empty files, 91 source files indicating an error occurred, and
830 partial files. Additionally, among the market files, we found 274 files
with no useful information due to the scraper being logged out and 2,591 files
with an Evolution market update and/or welcome message obscuring all relevant
information. Together this comes down to only 0.05% of all source files. Data
duplication and inconsistencies occur naturally due to shared information
between pages. Additionally, temporal data inconsistencies between the scrapes
occur as information gets updated and the forum continues to grow. We discuss
these data quality issues and how they were resolved in the next subsection.

We note that, some dates are indicated as “Today” or “Tomorrow” and that files
in a scrape may have been gathered over multiple days. Therefore, to determine
the actual dates in such cases, we rely on the (last) modification date and
time of the file. We store this date and time as the _retrieval time_ along
with the information extracted from each file. Though not perfect, the
retrieval time can serve as a proxy to determine the most ‘recent’
information.

Figure 2: Overview of the four processing steps applied to our dataset

### Step 2: Resolving data duplication and inconsistencies in extracted forum
and market data

At this stage, we have tabular data describing information as extracted from
single files. Next, want to merge and resolve this into structured datasets
for both the forum and market, such that we have one set of unified
information at either the scrape or dataset level. Below, we discuss our
attempts to resolve the various data quality issues during this process.

#### Forum

We resolve data issues for five types of forum data: scrape, user, post,
topic, and forum data.

First, for scrape data, we merely have to merge the indexed forum scrape dates
with the scrape global statistics retrieved from index pages. The global
statistics indicate the forum’s self-reported number of fora, topics, posts
and users at that time.

Second, we resolve user data. User data is retrieved from profile pages, but
also from posts’ poster and editor information and first and last post
information of topics. For all but five instances, the username appears
immutable throughout. However, on these five occasions the same _uid_ (user
identifier) is associated with two different usernames. For these rare cases a
manual choice was made such that each _uid_ consistently has the same username
attached. On 38 occasions two (or three) _uid_ ’s have the same username.
Evidence from manual inspection shows that these are likely cases of a user
being banned and subsequently creating a new account with the same username.
Although we could resolve this by combining these _uid_ s, we have chosen to
leave them be such that this behaviour is not lost.

A number of inconsistencies might occur. Data inconsistencies, at the level of
individual scrapes, occurred for the user’s title and number of posts. For the
former we rely on a manual ordering of importance: Administrator > Market
Moderator > Forum Moderator > Moderator > Public Relations > Banned > Vendor >
Resident Medical Expert > Troll > Member > Guest > Sports Referee > Sports
Fan. To resolve the latter, we take the maximum number of posts observed
(within the scrape).

Temporal data inconsistencies, from one scrape to the next, occur for the last
post and number of posts information. The former observes apparent mismatches
with the reported number of posts, where, for example, the last post
information may change from one scrape to the next without their number of
posts changing. Such mismatches occur because the last post information can
only be retrieved from the profile page of the user, while a post count is
reported on both the profile page and alongside each individual post. Since
the pages with posts may have been retrieved after the profile pages, the
maximum post count found can include posts beyond the last post reported on
the profile page. Additionally, because the posts list the number of posts at
time of retrieval and not at the time of post placement, there is no way to
tell if an apparent last post in our data is truly the last post. As such,
even when the number of posts of a user indicated by one of their posts is
higher than that reported on the profile page, there is no reliable way to
update the last post information. Thus, these temporal inconsistencies remain
unresolved and we simply store the last post information as presented on the
profile page.

Additional temporal inconsistencies occur for the registration date of users.
These inconsistencies can be attributed to cases where the registration date
was indicated with “Today” or “Tomorrow” for a given scrape. All
inconsistencies appear to have come about with a retrieval time shortly after
midnight while the true date was the day before. We consider it likely that
this was caused due to a difference between the scraper’s local time and the
server time zone. As such, the registration date inconsistencies were resolved
to always be the earlier date. However, we must note that due to a lack of
observable inconsistencies some retrieval time faults may remain undetected .

Third, we resolve post data. We store only a single entry for each post for
the entire dataset, instead of for each scrape. We do this to limit the size
of the dataset. Furthermore, since the posts themselves are timestamped, the
amount of information this discards is limited. The only information loss
occurs for posts that were (repeatedly) edited, since we only store the final
version of the post text and the details of the final edit (who and when). For
65 topics ($0.13\%$) one (or more) apparent gaps between retrieved posts was
found, with a cumulative size of 3,525 missing posts ($0.69\%$). However, post
deletion leads to temporal data inconsistencies w.r.t. the sequence id’s of
posts in a topic. As such, we chose to recompute a _seq_id_ based on all posts
(whether deleted or not) that we were able to retrieve. Thus, information on
the existence of these gaps is lost in the structured dataset. We report on
the exact topics and size of the gaps in post data in Table 2.

Further temporal data inconsistencies occurred for post placement dates.
Again, all of these inconsistencies could be attributed to cases where the
post placement date was indicated with “Today” or “Tomorrow”. The cause of the
inconsistency differed from those observed for the registration date of users
on only 52 occasions. On these occasions, the retrieval time we found was
exactly 7 days after the scrape date, an apparent impossibility. The retrieval
dates of these files were indeed found to be incorrect. Similar to the
registration date, post placement date inconsistencies were resolved to be the
earlier date. Note, that like for the registration date, faults may remain
undetected due to a lack of observable inconsistencies.

When a post was edited multiple times, it is impossible to tell if an
inconsistency of the date with the same username is due to a data
inconsistency or due to multiple edits by that user. As such, we simply store
the last edit information retrieved, regardless of whether this may rely on a
faulty date or not. Finally, we note that the editor’s _uid_ is not recorded
on the source page. Therefore, we use the previously resolved user data to
retrieve the _uid_ matching the username. Here, a _uid_ data inconsistency is
resolved by taking the largest _uid_.

Fourth, we resolve topic data. Topic data was retrieved from pages listing the
various topics in a forum and pages listing posts of the topic. Since topics
may be moved from one forum to another, separate entries are kept per scrape
for each forum it was found to be associated with in that scrape. Each entry
indicates whether the topic has been moved. Note that, for a given topic and
scrape, we report the expected number of posts, the actual number of posts
retrieved, and, based on the resolved post data, the number of posts with a
placement date up to and including the scrape date retrieved overall. This may
seem redundant, but it is not uncommon for these values to differ from one
another. In fact, they complement each other, as together they provide a
picture of what is expected and actually retrieved for a given scrape and what
was retrieved overall so far for a given topic.

Data inconsistencies, at the level of individual scrapes, occurred for the
topic title, expected number of posts, number of views, and last post
information. Topic title inconsistencies were resolved by choosing the title
with the latest retrieval time, i.e., the most recent title. Data
inconsistencies for the expected number of posts and views were resolved to
their maximum observed values. For the last post information, we always
resolved to the version associated with the ‘latest’ post placement date.
Finally, any (temporal) inconsistencies for first and last post user
information were conformed to previously resolved user data.

Fifth and last, we resolve forum data. For a given forum and scrape, we report
the expected number of topics, the actual number of topics retrieved, and,
based on the resolved topic data, the number of topics associated with the
forum for all scrapes up to and including this scrape. Furthermore, we report
the expected number of topics and, based on the resolved post data for the
topics associated with the forum up to and including this scrape, the number
of posts with a placement date up to and including the scrape date retrieved
overall. Similar as for topic data, these may appear redundant yet complement
one another.

Temporal data inconsistencies occurred only for the expected number of topics,
which were resolved to the maximum.

#### Market

We resolve data issues for five different levels of market data: scrape,
vendor, category, listing, and feedback data.

First, scrape data for the market has no observable data quality issues.
Therefore, we directly copied the indexed scrape data into the structured
dataset.

Second, we resolve vendor data. Vendor data was retrieved from both listing
and vendor profile pages. Similar to the forum usernames, vendor usernames
appear immutable throughout. On only seven occasions, the same _vid_ (vendor
identifier) is associated with two different usernames. Again, a manual choice
was made such that each vid is associated with a single username. On fifteen
occasions the same username was used for two different _vid_ ’s. Similar as
for forum users this appears to be associated with vendors being banned; thus,
again we have chosen to leave this be such that this behaviour is not lost.

Data inconsistencies, at the level of individual scrapes, occurred for
vendors’ rank, sales, positive/neutral/negative feedback statistics, approval
rating, and the disabled flag. Inconsistencies were resolved to the
information with the latest retrieval time. This ensured that the highest
rank, sales, feedback statistics and the most recent approval rating and
disabled status was kept.

Between scrapes 12 and 13 a change occurred in the ranking system (see Table 1
for details on the rankings). Note that the _Total Sales_ ranges of the right
ranking system, i.e., the latter system, are in practice only check after the
_Revenue_ and _Feedback_ requirements are met. Thus, the sales of a vendor
with a lower rank can exceed the indicated range. Feedback refers to the
_approval_rating_ , i.e., the proportion of positive and negative feedback
that is positive.

Table 1: An overview of the ranking system of vendors until (left) and after (right) May 5th 2014, showing the ranks and their requirements. Until May 5th 2014 | From May 5th 2014
---|---
Rank | Total Sales | Rank | Total Sales | Revenue | Feedback
Freshman | $\leq 4$ | Level 1 | 0–24 | n/a | n/a
Sophomore | $\leq 8$ | Level 2 | 25–99 | 1 BTC | 90%
Junior | $\leq 16$ | Level 3 | 100–249 | 10 BTC | 90%
Senior | $\leq 32$ | Level 4 | 250–499 | 50 BTC | 90%
Premium | $\leq 64$ | Level 5 | 500+ | 100 BTC | 90%
Advanced | $\leq 128$ |  |  |  |
Expert | $\leq 256$ |  |  |  |
Master | $\leq 512$ |  |  |  |
Grandmaster | $\leq 1024$ |  |  |  |
Godlike | $>1024$ |  |  |  |

Third, we resolve product category data. Category data was retrieved from
category pages and details the parental hierarchy and basic details of each
category. Although mostly static, the parental hierarchy experienced small
changes over time, such as introducing intermediate levels. We resolve the
parental hierarchy to a single hierarchy with the greatest amount of detail,
thus including intermediate levels. Furthermore, over time two categories were
renamed: Disassociatives $\to$ Dissociatives and Drug Paraphernalia $\to$
Paraphernalia. We enforced the former change, as this was a correction.
However, the latter was due to the category becoming a child category of the
Drugs category. As such, we chose to keep the initial more detailed name.

Fourth, we resolve listing data. Listing data was retrieved from store,
category and listing pages. Although each source provides a listing identifier
(_lid_) with each listing, we found this identifier to be unreliable. The
reason for this is that we found a large number of _lid_ s that were reported
as one higher or lower than their true value. Additionally, as listing titles
changed often to represent either new products or slight changes to a product,
resolving this issue becomes an extremely complex task. As our study did not
directly use the listing data, we chose not to resolve these issues
definitively. However, we did manually fix the egregious cases where an _lid_
would incorrectly have been associated with more than one vendor.
Additionally, we resolved, at the level of individual scrapes, titles that
were a substring of one another, to the longest version. Outside of these
cases, we simply preserve data by adding an entry for each title option for a
given scrape.

For individual scrape and title combinations, we find data inconsistencies for
price, product class, shipment origin, and product category identifiers. For
the product category identifiers, we first exclude parent options using the
resolved parental hierarchy such that we are left with the most specific
category option(s). For all other and the remaining product category
identifier conflicts, the information with the latest retrieval time is kept,
ensuring the most recent product information is stored.

Fifth and last, we resolve listing feedback data. Listing feedback was
provided near anonymously. That is, outside of 27 instances, only the first
and last letter (presumably) are reported of the usernames of those posting
the feedback. As such, our only resolution step is to remove duplicate data
with the same _lid_ , username, date, and message.

We note that for both forum and market data, information on various entities
may be incomplete due to missing source pages. We discuss how these cases can
be recognized in the structured dataset and report their frequency in the
Technical Validation section.

### Step 3: Forum user and market vendor matching

We now have structured datasets for the forum and market data. However, there
is not yet an identifier to connect users in the forum and market datasets.
Therefore, we require a method to link forum and market users not reliant on
the known identifiers. Perhaps the simplest, but also the most reliable,
method is to match forum users and market vendors based on their respective
usernames. After all, if vendors wish to promote their listings on the forum,
posting under the same username creates name recognition. Name recognition in
turn has been linked to improved trust [16] and market outcomes [17] (e.g.,
more sales). As such, vendors are naturally encouraged to use the same
username on both the forum as the market.

For matching forum users and market vendors based on username, we create the
_user-matching_ table. This table reports a _match_id_ , uniquely identifying
usernames with successful matches, along with the _username_ , _uid_ , and
_vid_ of the (non-)match. Unmatched forum users and market vendors are also
reported but without _match_id_. We find that out of the 4,275 vendor
usernames, 2,586 (i.e, 60.5%) could be matched to a forum username. In 35
cases, a single _match_id_ is associated with multiple matches, due to the
username being associated with multiple _uid_ and/or _vid_.

### Step 4: Network extraction

As our final methodological step, we extract a communication network [18, 19]
$G=(V,E)$, with node set $V$ and edge set $E$, from the resolved structured
dataset. Each node in $u\in V$ represents a single distinct forum user $u$
that has at least one post in our data. Note, we consider the uids with the
same username as the same user.

Let $p_{k,u,i}$ indicate the $i^{th}$ post by the user represented by node $u$
in the $k^{th}$ topic; let $\phi_{k,u,i}$ indicate the ordinal number
designating the place in the ordered sequence of posts of $k^{th}$ topic,
i.e., if $p_{k,u,i}$ is the $20^{th}$ post in $k^{th}$ topic then
$\phi_{k,u,i}=20$; finally, let $t_{k,u,i}$ be the timestamp indicating on
what day and at what time the post $p_{k,u,i}$ was placed. A timestamped
weighted directed edge $(u,v,t_{k,u,i},\omega_{k,u,i,v,j})\in E$ is included
for each pair of posts $p_{k,u,i},p_{k,v,j}$ that satisfy the following
conditions:

  * •

$u\neq v$, i.e., we do not include self-edges;

  * •

$\phi_{k,u,i-1}<\phi_{k,v,j}<\phi_{k,u,i}$, i.e, $p_{k,u,i}$ is user $u$’s
first post after $p_{k,v,j}$ was posted;

  * •

$\phi_{u,i}-\phi_{v,j}\leq\delta_{\phi}$, i.e., the posts are at most
$\delta_{\phi}$ posts apart; and

  * •

$t_{u,i}-t_{v,j}\leq\delta_{t}$, i.e., the posts are at most $\delta_{t}$ time
apart.

As such, each edge represents an (indirect) interaction between two users, but
also a shared common interest due to posting in the same topic. We add weights
($\omega_{k,u,i,v,j,}$) to each edge, to indicate how strong the connection
between the two users is based on how much time passed between their
respective posts. The logic being that a faster, and thus more direct response
equates to a stronger tie. Let $\omega_{lower}$ be the minimum edge weight and
$t_{lim}$ be the amount of time until the weight is reduced to this minimum.
Then the weight $\omega_{k,u,i,v,j}$ is computed using the following
exponential weighting function:

$\omega_{k,u,i,v,j}=\omega_{lower}+(1-\omega_{lower})*\frac{\exp(3\frac{t_{lim}+t_{k,v,j}-t_{k,u,i}}{t_{lim}})-1}{e^{3}-1}.$
(1)

Finally, for every topic, for which we have post data, we add edges
$(u,v,t_{k,u,i},\omega_{first})$ between the user ($v$) that posted the
initial post in the $k^{th}$ topic and every user ($u$) that posted in the
topic afterwards (once for every post). Here, $\omega_{first}$ is the same
value for every edge. We include these edges because each response in a topic
is in essence also an indirect response to the initial post, thus a connection
is established through shared interest.

For the communication network included with this data descriptor, we used
$\delta_{\phi}=10$, $\delta_{t}=1$ month, $\omega_{lower}=0.2$, $t_{lim}=7$
days, and $\omega_{first}=0.5$. Figure 3 plots the exponential weighting
function for these values. Different values for variables $\delta_{\phi}$,
$\delta_{t}$, $\omega_{lower}$, $t_{lim}$, and $\omega_{first}$ can be given
as parameters to the code published alongside this data descriptor to generate
networks adhering to those conditions.

Figure 3: Exponential weighting for $\omega_{lower}=0.2$ and $t_{lim}=7$ days.

From the full communication network, monthly communication networks are
formed. Each monthly network includes only those edges that are formed from
posts up to and including the final day of that month. As such, each monthly
network is a sub-graph of the subsequent monthly networks, i.e., the monthly
networks grow over time. A network is formed for each month that the Evolution
cryptomarket was active, i.e., from January 2014 until March 2015.

## Data Records

The resolved structured dataset consists of five tables on forum data, five
tables on market data, and one table on the results of the user matching.
Furthermore, the extracted monthly communication networks are presented in two
types of tables, describing the nodes and (monthly) edges, respectively. The
full dataset is available on Zenodo by Boekhout et al. [15]. All tables are
given in tab separated format such that commas in post text, titles, and such
did not need to be removed.

### Forum

The five tables describing forum data cover respectively: forum scrapes, fora,
topics, posts and users.

#### forum/scrapes.tsv

_scrape_id_

forum scrape unique identifier;

_scrape_year_

year in which scrape was completed;

_scrape_month_

month in which scrape was completed;

_scrape_day_

day on which scrape was completed;

_fora_

number of fora at the time of the scrape as reported by index page;

_topics_

number of topics at the time of the scrape as reported by index page;

_posts_

number of posts at the time of the scrape as reported by index page;

_users_

number of users at the time of the scrape as reported by index page.

#### forum/forum.tsv

_fid_

forum unique identifier;

_scrape_id_

forum scrape unique identifier (foreign key);

_category_

forum category to which this forum belongs, values are _Development,
Discussion, Events, Information, Marketplace, Newbie Zone, Scams & Trash_
(with earlier version _Trash_), and _TCF_ ;

_title_

forum title;

_description_

forum description;

_pages_

number of pages listing topics in this forum, as implied by forum pages;

_topics_

number of (expected) topics in this forum, as reported by statistics on index
page or implied by forum pages;

_topics_visible_

number of unique topics actually found through forum pages alone;

_topics_found_

number of unique topics associated with this forum found through either forum
or topic pages in all scrapes so far;

_posts_

number of (expected) posts in this forum, as reported by index page;

_posts_found_

number of unique posts with a placement date up to and including the current
scrape date in topics counted towards _topics_found_.

#### forum/topic.tsv

_fid_

forum unique identifier (foreign key) to which the topic belongs or belonged
(if _moved_ is True);

_tid_

topic unique identifier;

_first_uid_

user unique identifier (foreign key) of the forum user that placed the first
post of the topic;

_scrape_id_

forum scrape unique identifier (foreign key);

_title_

topic title;

_posts_

number of posts in this topic, as reported by statistics on forum pages or
implied by topic pages;

_posts_visible_

number of unique posts actually found on topic pages;

_posts_found_

number of unique posts found in all scrapes so far, with placement dates up to
and including the scrape date;

_views_

number of views of this topic, as reported by statistics on forum pages;

_lp_uid_

user unique identifier (foreign key) of user who placed the last post, as
reported on forum pages;

_lp_year_

year of last post, as reported on forum pages;

_lp_month_

month of last post, as reported on forum pages;

_lp_day_

day of last post, as reported on forum pages;

_lp_time_

time of last post, as reported on forum pages;

_closed_

boolean flag indicating whether this topic was closed;

_moved_

boolean flag indicating whether this topic was moved to another forum (fid).

#### forum/post.tsv

_tid_

topic unique identifier (foreign key), indicating to which topic this post
belongs;

_pid_

post unique identifier;

_seq_id_

sequence id, indicating where in the order of posts of the topic this post
belongs;

_year_

year that the post was placed;

_month_

month that the post was placed;

_day_

day that the post was placed;

_time_

time that the post was placed;

_uid_

user unique identifier (foreign key) of the user who placed the post;

_text_

the post’s message text, as directly copied from source topic pages;

_signature_

signature of the user who placed the post (most recent found for this post);

_edit_uid_

user unique identifier (foreign key) of the user who last edited the post;

_edit_year_

year of the last edit to the post;

_edit_month_

month of the last edit to the post;

_edit_day_

day of the last edit to the post;

_edit_time_

time of the last edit to the post.

#### forum/user.tsv

_uid_

user unique identifier;

_username_

username of user;

_reg_year_

registration year of user;

_reg_month_

registration month of user;

_reg_day_

registration day of user;

_scrape_id_

forum scrape unique identifier (foreign key);

_title_

member title of user, indicating their role on the forum;

_lp_year_

year of last post placement, as reported on profile page;

_lp_month_

month of last post placement, as reported on profile page;

_lp_day_

day of last post placement, as reported on profile page;

_lp_time_

time of last post placement, as reported on profile page;

_num_posts_

number of posts by user to date, as reported on profile page or alongside the
user’s posts;

_location_

self-reported location of forum user, highly unreliable.

### Market

The five tables describing market data cover respectively: market scrapes,
product categories, listings, vendors, and listing feedback. Note, neutral and
negative feedback had to include a message, but positive feedback did not.

#### market/scrapes.tsv

_mscrape_id_

market scrape unique identifier;

_scrape_year_

year in which scrape was completed;

_scrape_month_

month in which scrape was completed;

_scrape_day_

day on which scrape was completed.

#### market/categories.tsv

_cid_

product category unique identifier;

_category_

name of category;

_parent_cid_

product category unique identifier of parent category of category.

#### market/listings.tsv

_lid_

listing (unique) identifier;

_vid_

vendor unique identifier (foreign key);

_mscrape_id_

market scrape unique identifier (foreign key);

_title_

listing title, often includes basic description of product;

_price_

price in BTC per unit of listing;

_description_

description of product;

_cid_

product category unique identifier (foreign key);

_ships_from_

indication of from what part of the world the product can be shipped;

_ships_to_

indication of to which parts of the world product can be shipped;

_products_class_

indication of type of products (either _Digital_ or _Physical_);

_listing_available_

indication (boolean) of whether product of listing remains available;

_return_policy_

return policy associated with the listing.

#### market/vendors.tsv

_vid_

vendor unique identifier;

_mscrape_id_

market scrape unique identifier (foreign key);

_username_

username of vendor;

_rank_

rank of vendor (see Table 1 for details on the ranking systems);

_sales_

number of sales vendor has reportedly completed so far (only available from
market scrape 13 onwards);

_approval_rating_

rating computed as the proportion of positive and negative feedback received
over all the vendor’s listings that is positive;

_positive_feedback_

number of positive feedback responses the vendors has received on their
listings;

_neutral_feedback_

number of neutral feedback responses the vendors has received on their
listings;

_negative_feedback_

number of negative feedback responses the vendors has received on their
listings;

_legacy_sales_

self-reported and ‘verified’ sales of vendor on other Dark Web
cryptomarket(s);

_pgp_key_

PGP-key used by vendor for secure communication with customers;

_return_policy_

return policy of vendor;

_disabled_

indication (True or False) of whether the vendor account has been disabled.

#### market/listing-feedback.tsv

_lid_

listing unique identifier (foreign key) to which feedback was placed;

_username_

username of the one who posted the feedback, almost always hidden with only
first and last letter visible;

_year_

year that feedback was placed;

_month_

month that feedback was placed;

_day_

day that feedback was placed;

_message_

feedback message.

### User matching

The matching of forum users and market vendors resulted in the following
table.

#### forum-market/user-matching.tsv

_match_id_

successful username match unique identifier;

_username_

username upon which forum user(s) and market vendor(s) were matched;

_uid_

forum user unique identifier (foreign key);

_vid_

market vendor unique identifier (foreign key).

### Communication network

The two types of tables describing the extracted communication network cover
respectively the nodes and the (monthly) edges of the network. Each edge table
describes the edge list of a single monthly network and all edge tables follow
the same format.

#### network/nodes.tsv

_uid_

node identifier corresponding to forum user unique identifier (foreign key),
lowest option if multiple options exist for the given username;

_secondary_uid_

second uid associated with the same username (foreign key);

_tertiary_uid_

third (and highest) uid associated with the same username (foreign key);

_match_id_

successful username match unique identifier (foreign key);

_init_year_

first year that the user placed a post on the forum;

_init_month_

first month (within _init_year_) that the user placed a post on the forum.

#### network/edges-2014-1.tsv, network/edges-2014-2.tsv, $\cdots$,
network/edges-2015-3.tsv

_Source_

source node forum user unique identifier (foreign key);

_Target_

target node forum user unique identifier (foreign key);

_Weight_

weight of edge, as computed based on time passed;

_to_first_

boolean indication whether this edge is based on linking to initial post, if
True, _Weight_ $=0.5$;

_time_diff_

elapsed time in-between the posts that generated this edge, expressed in
seconds;

_seq_diff_

difference in _seq_id_ between the posts that generated this edge;

_timestamp_

timestamp of source post, expressed in seconds since January $1^{st}$ 2014;

_tid_

topic unique identifier (foreign key), wherein the posts that generated this
edge were placed.

## Technical Validation

In this section, we explore the technical quality of the dataset. For a
dataset extracted from scraped webpages over a period of time, the best way to
assess the technical quality is to explore its completeness at various points
in time and overall. We report both on the completeness in terms of records
and the frequency of missing fields on included records and their causes.
Additionally, we look at the amount of possible hidden data and discuss any
data that was purposely not extracted and thus not included in the structured
dataset. Next, we discuss the reliability of certain ‘self-reported’ data.
Finally, we have a look at the monthly communication networks that are
included, exploring their growth over time as well as some basic statistics of
the complete network.

### Forum and market data completeness

To investigate the completeness of the forum and market data we explore the
completeness of the extracted dataset’s records, look at the prevalence of
empty fields within records, and consider the amount of hidden and missing
data implied by entity identifier values.

#### Record completeness of forum and market data

(a) Forum topic statistics over time

(b) Market vendor statistics over time

(c) Forum post statistics over time

(d) Market listing statistics over time

(e) Forum user statistics over time

(f) Market sales statistics over time

Figure 4: Statistics on the completeness of various elements of the dataset
for each scrape, including statistics regarding the combined extracted data up
to and including each given scrape.

First, we analyse the record completeness of forum topics, posts, and users
and the market vendors, listings, and sales. In order to argue about
completeness we require some baseline truth to compare against. For the forum
data, we can compare the completeness of extracted data with the forum’s self-
reported statistics (obtained from the index pages). Unfortunately, for the
market no such statistics were reported. Instead we compare the number of
extracted vendors, listings, and sales overall with those associated with
vendors that were matched to forum users. This allows us to speculate whether
non-matched vendors are likely due to a problem at extraction, or a
fundamental lack of activity on the forum by these vendors. Figure 4 plots the
completeness for each of the various elements over time, with statistics
computed at the time of each scrape. They combine plots on statistics for what
was extracted for the specific scrape, with those displaying the cumulative
amount extracted up to and including that scrape.

Figure 4a shows that the cumulative number of topics for which we extracted
any data over time closely resembles the number of reported topics. We notice
that on a few occasions this cumulative number dips significantly while the
reported number does not. This phenomenon is caused by the “Trash Can” forum,
which disappeared from the visible part of the forum during these periods of
time while still being counted towards reported statistics. Thus, we have data
on (nearly) all topics on the part of the forum that is visible to all users.

We also consider the completeness of the extracted topics themselves, i.e.,
the number of topics for which posts were extracted at any point in time. From
Figure 4a we observe that, up to September 2014, posts were extracted for
nearly all started topics. However, during several scrapes in September and
October 2014, almost no posts were extracted while the number of new topics
continued its steady growth. After this, the growth trends of the number of
extracted topics and those for which posts were extracted are nearly
identical. As such, we conclude that it was primarily during this
September/October period that we have missing posts data. Specifically,
between September 9th and November 7th, 69% of the topics for which we were
unable to extract posts were started and missed during scraping (note that
another 12.5% was missed on the final day of the cryptomarket). In the end, we
are left with 3,810 topics (7.7% of total) with missing post data. We note
that there is no guarantee for all topics that if they include extracted post
data, that this includes all post data. After all, despite each scrape
targeting the most recent (and oldest) topics for each forum, any given scrape
only collected data on so many topics. To study this, we also plotted how many
topics had their posts extracted for the last time in any given scrape in
Figure 4a. This shows that nearly half of all topics had their posts extracted
for the last time on the last two days of the existence of the cryptomarket.
The remaining observed spikes are closely related to spikes in overall
extraction of topic post data for those scrapes. As such, instead of implying
that new post data was found for the last time at those times, the spikes more
likely imply that they rediscover a set of topics that had already gone
inactive at an earlier date for the last time. For the remainder of the
scrapes we observe a slow trickle of topics becoming inactive and no longer
being rediscovered throughout. Thus, outside of known missing posts due to
gaps, we expect post records for nearly all topics, that have any post data at
all, to be complete.

Figure 4c plots the reported and extracted number of posts over time. However,
as we only kept the final version of each post, we cannot plot for each scrape
how many posts were extracted. Instead, we plot the number of posts with a
timestamp up to and including the scrape date for every scrape. When comparing
the actual number of extracted posts to the number of reported posts by the
forum’s own statistics, we find that we extracted more posts than were
reported. This is due to deleted posts not being counted towards official
statistics, while still being included in our dataset. During the
September/October period, which resulted in 69% of the topics with missing
post data, the post surplus dropped by 9,940. This translates to on average
3.8 posts per such topic. Thus, the topics for which we have no post data at
all were generally shorter topics that quickly became inactive. Based on the
post surplus at the end of the data and the decrease in surplus during the
September/October period, we estimate an overall surplus of around 25 thousand
posts ($\approx$ 4.8% of reported posts). As previously reported in the
Methods section, gaps between posts were detected for 65 topics for a total of
3,525 presumed missing posts. Table 2 details for each topic (_tid_) the
observed gap sizes.

Table 2: List of all observed gaps between posts that were subsequently excluded from the structured dataset. Each lists the topic in which the gap occurred, the _pid_ directly after the gap (i.e., the gap precedes this post), and the size of the gap. _tid_ | Before _pid_ | Gap size | _tid_ | Before _pid_ | Gap size | _tid_ | Before _pid_ | Gap size
---|---|---|---|---|---|---|---|---
590 | 5874 | 1 | 9775 | 272486 | 1 | 29466 | 519090 | 48
616 | 6184 | 100 | 13698 | 393170 | 16 | 29604 | 540493 | 18
3116 | 547051 | 9 | 13698 | 424870 | 14 | 31243 | 396875 | 3
5029 | 536363 | 5 | 13698 | 444207 | 11 | 31656 | 551183 | 3
5029 | 553686 | 1 | 13698 | 553390 | 8 | 33679 | 306829 | 61
5275 | 547243 | 12 | 13698 | 555536 | 25 | 33865 | 304812 | 2
5275 | 558090 | 1 | 13698 | 557826 | 7 | 33865 | 304816 | 3
6549 | 229852 | 57 | 13961 | 199368 | 22 | 33865 | 307640 | 4
6549 | 231651 | 145 | 13961 | 203795 | 1 | 34282 | 311224 | 25
6549 | 245959 | 81 | 13961 | 261248 | 113 | 35324 | 555845 | 22
6549 | 306763 | 2 | 13961 | 325751 | 12 | 35506 | 395635 | 1
6549 | 312851 | 25 | 13961 | 399367 | 43 | 35506 | 551111 | 4
6549 | 492970 | 1 | 14267 | 132988 | 5 | 36363 | 343865 | 1
6549 | 503420 | 150 | 16751 | 543166 | 1 | 36573 | 548455 | 8
6549 | 554920 | 25 | 17259 | 269136 | 21 | 36831 | 519483 | 1
6549 | 558150 | 25 | 17437 | 519272 | 3 | 36831 | 519864 | 2
7354 | 557908 | 10 | 17967 | 557659 | 5 | 37091 | 528846 | 25
7448 | 191379 | 1 | 20772 | 198981 | 43 | 37615 | 351672 | 1
7448 | 205438 | 25 | 21107 | 467834 | 21 | 37615 | 358903 | 1
7448 | 228049 | 193 | 21897 | 552388 | 22 | 37750 | 524107 | 6
7448 | 231301 | 6 | 22305 | 546874 | 2 | 37750 | 535891 | 11
7448 | 271101 | 760 | 22410 | 523385 | 2 | 38449 | 537396 | 7
7448 | 496933 | 25 | 22410 | 531380 | 2 | 39031 | 522454 | 1
7448 | 498503 | 14 | 23010 | 219734 | 1 | 40089 | 553680 | 53
7448 | 557723 | 25 | 23010 | 549385 | 1 | 41410 | 557393 | 1
7906 | 542315 | 3 | 23337 | 255874 | 4 | 41804 | 540872 | 14
8746 | 549894 | 1 | 23337 | 258828 | 1 | 43961 | 557780 | 4
9543 | 199353 | 5 | 23635 | 554611 | 28 | 44789 | 551730 | 12
9543 | 374326 | 11 | 24517 | 512245 | 2 | 46401 | 554458 | 1
9543 | 392826 | 2 | 25810 | 239926 | 6 | 46403 | 537782 | 2
9543 | 429134 | 56 | 26245 | 231521 | 75 | 46847 | 545278 | 10
9543 | 442531 | 6 | 26551 | 245429 | 50 | 47391 | 557911 | 9
9543 | 501577 | 125 | 26910 | 245067 | 3 | 48606 | 518930 | 16
9543 | 554970 | 25 | 27273 | 550052 | 8 | 49823 | 478302 | 2
9543 | 558064 | 33 | 28178 | 336709 | 1 | 51493 | 556983 | 8
9775 | 229552 | 22 | 28178 | 427867 | 25 | 52862 | 552573 | 86
9775 | 237774 | 1 | 28178 | 517062 | 6 | 56556 | 559939 | 250
9775 | 265451 | 125 | 28178 | 558016 | 74 |  |  |

Completeness of forum user data is illustrated in Figure 4e. User data is
retrieved from profile pages, posts, post edit information, and topic
information on the initial and final post. Of these data sources, the profile
pages are by far the most important for completeness of user data, as that is
the only source to include users with zero posts. We can easily see this
reflected in the trends in Figure 4e. After all, the number of extracted users
only matches the reported number of users when all profile pages were included
in a scrape. The last time this occurred was near the end of September 2014,
leading to a subsequent continuously widening gap between the number of
extracted and reported users. The final deficit in extracted users was 10,715
users (27%). Due to our general completeness of post data, we can surmise that
the majority of users not included are likely those without any posts.

Despite that the majority of non-extracted forum users are likely without any
posts, the size of the deficit may still have consequences. After all, we
could speculate that, if these users were included, a greater portion of
vendors may have been matched to a forum user. However, Figure 4b, which shows
statistics on (matched) vendors, provides no evidence of this. After all, it
shows that the gap between the total number of vendors extracted and the
number of them that could be matched to a forum user, grows steadily over time
from the start. If, as we previously speculated, our matching results were
likely to have improved by including the missing forum users, we instead would
have expected to see a relatively smaller gap right up till the end of
September after which it would widen at a greater speed. Thus, the missing
forum users are unlikely to have posted nor to have been vendors.

Figure 4b shows that a significant number of vendors were not matched to a
forum user. In fact, at the end of our data only 60.6% of vendors were
matched. Figures 4d,f show that this set of matched vendors is responsible for
a much larger proportion of the overall listings and sales. By the end of the
data, the matched vendors cover respectively 79.3% of listings and 74.6% of
all recorded sales. Interestingly, each of the gaps between total and matched
totals starts widening more starkly from November 2014 onwards. Early that
month, a joint international law enforcement operation dubbed “Onymous” [6]
lead to the closure of six cryptomarkets. These closures aided in the growth
of the two most popular cryptomarkets at the time, including Evolution. The
trends shown in Figures 4b,d,f imply that this event may also have impacted
the behaviour of vendors and/or customers on the Evolution cryptomarket.
Vendors that emigrated to Evolution from one of the closed cryptomarkets may
have felt less secure promoting their sales on the forum, leading to fewer new
matches on average. Additionally, customers that emigrated to Evolution may
continue to purchase from their favourite vendors from previous cryptomarkets
without these vendors needing to promote their listings. This in turn could be
one way to explain the increasing proportion of sales by non-matched vendors.

#### Field completeness of forum and market records

So far we have discussed the completeness in terms of records. However, even
when records are included they are not always complete themselves, i.e., they
may contain empty fields. There are various reasons for fields of specific
records to be empty. In most cases, empty fields are due to missing source
pages. For example, we may have obtained data on a topic from topic pages, but
not encountered them on forum pages. In such a case, we would not have any
information on the last post nor view statistics nor have any idea whether the
topic had already been closed. Other reasons for empty fields may simply be
that the data did not exist to begin with. Tables 3 and 4 show, for the forum
and market data respectively, the frequency of each type of occurrence of
missing or otherwise distinctive field values, including the (likely) reasons
for them.

Table 3: Summary of reasons for empty fields (or specific values) in forum records, as well as their frequency w.r.t. all records of that type. Thus, lower frequency indicates greater completeness. Record type | Empty fields |  Reason | Frequency (% of records)
---|---|---|---
forum |  _pages_ _topics_visible_ |  Missing viewforum pages | 15 (0.76%)
_category_ _description_ _posts_ |  Missing on index page but included through viewforum pages | 5 (0.25%)
_description_ |  Information does not exist | 111 (5.64%)
topic |  _views_ _lp_uid_ _lp_year_ , _lp_month_ _lp_day_ , _lp_time_ _closed_ _moved_ $\to$ False |  Missing viewforum pages (single scrape) | 2,189 (0.32%)
Those listed above + _first_uid_ |  Missing viewforum pages for all scrapes for this topic | 165 (0.02%)
_views_ _lp_uid_ _lp_year_ , _lp_month_ _lp_day_ , _lp_time_ _closed_ $\to$ False _moved_ $\to$ True |  Topic that was moved which was found on a viewforum page of its former forum but not on a viewforum page of the forum it was moved to. Viewtopic pages were found. | 475 (0.07%)
Those listed above + _posts_ |  Same reasoning as above + missing viewtopic pages | 350 (0.05%)
_posts_visible_ $\to$ 0 |  Missing viewtopic pages | 239,398 (35.46%)
|  Only: _closed_ |  viewtopic pages were retrieved after topic was moved w.r.t. when viewforum pages were retrieved | 216 (0.03%)
|  _title_ |  Information does not exist | 35 (0.01%)
post |  _signature_ |  Information does not exist (poster had no signature) | 255,843 (49.74%)
_edit_uid_ _edit_year_ , _edit_month_ _edit_day_ , _edit_time_ |  Information does not exist (no edits occurred) | 455,254 (88.51%)
user |  _location_ |  Information does not exist or missing profile page | 465,706 (93.52%)
_lp_year_ , _lp_month_ _lp_day_ , _lp_time_ _num_posts_ > 0 _location_ |  Missing profile page & posts by user found | 62,845 (12.62%)
_lp_year_ , _lp_month_ _lp_day_ , _lp_time_ _num_posts_ $\to$ 0 |  No posts by user found | 48,351 (9.71%)
|  All except: _uid_ _username_ _scrape_id_ |  Missing profile page & no posts by user found | 105 (0.02%)
Table 4: Summary of reasons for empty fields (or specific values) in market records, as well as their frequency w.r.t. all records of that type. Thus, lower frequency indicates greater completeness. Record type | Empty fields |  Reason | Frequency (% of records)
---|---|---|---
categories |  _parent_cid_ |  Already top level category itself | 13 (13.27%)
listings |  _ships_from_ _ships_to_ _product_class_ _listing_available_ _return_policy_ |  Missing all listing pages (_mscrape_id_ <= 6) | 50 (0.00%)
_description_ _ships_from_ _ships_to_ _listing_available_ _return_policy_ |  Missing all listing pages (_mscrape_id_ > 6) | 614,628 (43.10%)
_description_ _ships_to_ _return_policy_ |  Missing generic and return policy format listing pages | 109,605 (7.69%)
_description_ _ships_to_ |  Missing only generic format listing page | 190,848 (13.38%)
|  _return_policy_ |  Missing only return policy format listing page | 508,435 (35.65%)
|  (_description_ OR _ships_to_ OR _ships_from_) _return_policy_ |  Partial generic format & missing return policy format listing pages | 1 + 2 + 1 (0.00%)
vendors |  _sales_ |  Always empty prior to _mscrape_id_ $=13$ | 8,040 (6.01%)
_approval_rating_ |  No listings retrieved for this vendor OR listed as “n/a” | 27,513 (20.56%)
_positive_feedback_ _neutral_feedback_ _negative_feedback_ _legacy_sales_ _pgp_key_ _return_policy_ _disabled_ |  Missing all profile pages | 36,122 (26.99%)
_legacy_sales_ _disabled_ $\to$ False |  Missing legacy sales format profile page, but at least one profile page found | 87,224 (65.17%)
_pgp_key_ _disabled_ $\to$ False |  Missing pgp format profile page, but at least one profile page found | 42,676 (31.89%)
_return_policy_ _disabled_ $\to$ False |  Missing return policy format profile page, but at least one profile page found | 65,376 (48.85%)
All except: _vid_ _username_ _mscrape_id_ _disabled_ $\to$ True |  Vendor has been disabled | 440 (0.33%)
As listed above, but _disabled_ $\to$ False |  Vendor is scraper | 91 (0.07%)
|  _rank_ |  Only an incomplete pgp format profile page | 1 (0.00%)
listing_feedback |  _username_ |  Unknown | 11 (0.00%)
_message_ |  Unknown | 42 (0.01%)

#### Hidden and not included data

Table 5: Statistics on possible hidden or otherwise missing forum data, based on ‘unique’ identifiers observed. The _Maximum_ reports the largest identifier found, while the _Surplus reported last scrape_ indicates how many more unique entities were reported to exist on the forum index page than were extracted for our dataset (_Unique found_). Identifier | Maximum | Unique found | Surplus reported last scrape | Hidden (or missing) data (% of maximum)
---|---|---|---|---
_fid_ | 40 | 30 | 0 | 10 (25.0%)
_tid_ | 56,826 | 50,271 | 610 | 5,945 (10.5%)
_pid_ | 560,023 | 514,256 | - | 45,767 ( 8.2%)
_uid_ | 39,849 | 28,951 | 10,715 | 183 ( 0.5%)

On nearly all fora, there exist parts that are only accessible to a select
group as users, such as the moderators and administrators. For our dataset,
hidden data refers to this part of the forum that was likely inaccessible to
those who gathered the data. Although possible, no such hidden part of the
marketplace is expected to exist, so we will not speculate on it here. We can
make an inference to the scope of hidden data on the forum by looking at the
id’s assigned to various elements. For example, the highest observed _fid_ is
40, yet only thirty _fid_ s are recorded in our dataset. This implies that
there were (at least) ten hidden fora.

Table 5 lists for each data element the maximum identifier, the number of
different identifiers found, the surplus reported on the index page of the
last scrape as compared to the number of unique found (when applicable), and
the resulting possible amount of hidden data. We note that the true amount of
hidden data is likely to be less. For example, we know that (at least) 3,525
posts are missing from topics with included posts and that for at least 3,810
topics no posts were extracted at all. As such, far fewer posts were likely to
have been associated with hidden fora than posited in Table 5. Similarly, it
is unclear if the reported number of topics on the index page includes the
1,287 closed topics we observed in our dataset. Thus, Table 5 clearly
overestimates the true amount of hidden data and should not be taken as face
value.

With respect to not included source data, the forum’s image, wiki, and style
files and the market’s image and css files were not included in our dataset,
but can easily be obtained from the original data source and were not suited
to a structured dataset format. The only remaining part of the source data
that has not been included in the extracted dataset, but could have been, is
the feedback on the vendor profile pages. Instead only feedback from listing
pages were obtained.

### Data reliability

Despite the (temporal) data inconsistencies discussed in the Methods section,
in general we can consider any information that is not self-reported by
users/vendors reliable. Self-reported information however, may not be
reliable. Here we make the distinction between self-reported data that is
considered a fact from the perspective of the forum/market, such as the post
_text_ or listing _description_ and _return_policy_ , and self-reported data
that adds subjective value, such as a forum user’s _location_. For the purpose
of this section, we only consider the latter type as self-reported and
potentially unreliable.

For the forum data, the only piece of self-reported data is the user’s
_location_. Looking at the actual contents of this field, for many records the
_location_ information is indeed highly unreliable with entries such as:
Everywhere, City of God, and Neptune. For the market data, self-reported data
consists of the listing’s _ships_from_ and vendor’s _legacy_sales_ and
_pgp_key_. The vendors’ _legacy_sales_ were (supposedly) verified by
administrators and/or moderators, before they were added. Furthermore,
vendors’ _pgp_key_ s were crucial for the ‘safe’ communication with the
customer. As such, the vendors’ _legacy_sales_ and _pgp_key_ s are likely to
be reliable. For the market data, the _ships_from_ field for listing records
is the most likely to be inaccurate. Like for the forum user’s _location_ ,
_ships_from_ information potentially exposes the vendor to discovery (by law
enforcement). Since the destination of a shipment is, form the customers
perspective, not reliant on the origin of that shipment, vendors may be
inclined not to report accurate information for _ships_from_. Thus, outside of
user/vendor location information, all other information is expected to be
reliable.

### Communication networks

(a) Degree distributions

(b) Communication network growth over time.

Figure 5: Degree distributions and communication network growth over time in terms of temporal and static edges. The darker parts indicate the edges formed solely by edges connecting to the initial posts of topics. Table 6: Basic statistics of full network (i.e., based on all data) Measure | Value
---|---
Nodes | 21,986
Isolated nodes | 548
Temporal edges | 2,502,592
Static edges | 974,508
Number of weakly connected components (WCC) | 14
Nodes in largest WCC (% of non-isolated nodes) | 21,411 (99.874%)
Edges in largest WCC (% of static edges) | 974,490 (99.998%)
Number of strongly connected component (SCC) | 2,151
Nodes in largest SCC (% of non-isolated nodes) | 19,279 (89.929%)
Edges in largest SCC (% of static edges) | 967,348 (99.265%)
Density (excluding isolated nodes) | 0.00212
Average clustering coefficient | 0.598
Average clustering coefficient largest WCC | 0.569
Diameter largest WCC (undirected, unweighted) | 7
Diameter largest WCC (directed, unweighted) | 7
Diameter largest WCC (undirected, weighted) | 8.28
Diameter largest WCC (directed, weighted) | 17.70

In this subsection, we explore the basic properties of the full communication
network based on all data. Since we are dealing with a communication network,
we only include those nodes with at least one post, thereby excluding the
6,925 nodes with no observed posts. Some basic statistics for the full
communication network are shown in Table 6. Here, isolated nodes are those
users with at least one post but whose posts were the only ones in those
topics, thereby establishing no links. The average clustering coefficients and
the sizes of the largest weakly and strongly connected components, tell us
that this is a highly connected network. Comparing with the networks in the
KONECT [20] database, we see that primarily some Human Contact and Human
social networks have similar average clustering coefficients, but also an
email communication network. As such, the statistics observed in Table 6 gives
us confidence that our extracted communication network is comparable to
networks in the KONECT database, which are in common use.

The unweighted degree distributions for several iterations of the
communication network are shown in Figure 5a. Over time, the distributions
start showing spikes at degrees around twenty posts, usually corresponding to
ten incoming and ten outgoing edges, that can be directly attributed to the
manner in which the network was generated. After all, given that each post
looks forward and backwards at most ten posts to create respectively incoming
and outgoing edges, it follows that many users with a single post in a
relatively longer topic, will end up with an in- and out-degree of (almost)
ten. Furthermore, the longer topics responsible for this phenomenon were
increasingly more likely to occur the older and more active the forum became.
For higher degree values, the degree distribution appears to follow a power
law distribution not unlike many other real-world networks.

Figure 5b shows the growth of the communication network over time in terms of
edges. We plotted this for both temporal and static edges and both including
and excluding the ‘special’ edges to the initial post. Notably, the growth
accelerates from November 2014 onwards. As previously mentioned, this
corresponds with the closure of several other cryptomarkets due to the joint
international law enforcement operation “Onymous” [6]. Thus, we can clearly
see that the closure of other cryptomarkets led to a marked increase in
activity on the Evolution cryptomarket.

These preliminary statistics convince us that the data is useful for further
studies of the Evolution cryptomarket and dark web market research, but also
for general use in network science research.

## Usage Notes

The dataset comes in tab separated format and can be loaded using any standard
data processing tool (python/R/etc.). Figure 2 illustrates how the data tables
can be linked through the various identifiers. Note that unlike all other
forum elements, posts are not stored on a scrape by scrape basis. Posts
relevant to a scrape should be determined based on their placement date and
the scrape date. Additionally, note that due to a small number of user
identifiers that are associated with the same username (for both $uid$ and
$vid$ as described in Methods), multiple entries with the same $match\\_id$
can exist. It is recommended for any analysis to combine data on users with
the same username, since the data suggests these are in fact the same users
who were banned but started a new account.

Since the dataset provides textual information on topic titles, post text,
listing titles, and listing descriptions (to name a few), text analysis can be
used, for example, to analyse drug overlap (the extent in which the same
vendors offer different types of drugs), or to gather information on modus
operandi and risk mitigation strategies. For all such analysis we remind
researchers that the textual information included in this dataset may still
include html elements, which may have to be removed before performing text
analysis tasks.

## Code availability

The code used to create, from the raw source files, the dataset described in
this Data Descriptor is included as Supplementary Information and will be
archived in a public repository upon acceptance. Included among these files is
a README file with details on software versions used and instructions on how
to reproduce our dataset using this code.

## Acknowledgments

The research that included the creation of this dataset, was funded by Politie
& Wetenschap as part of the ‘Criminaliteit en radicalisering voorspellen uit
dark web forumnetwerken’ project.

## Author contributions statement

H.B. extracted the dataset from the raw data, performed the data quality
resolution, extracted the communication networks and wrote the manuscript. All
authors reviewed the manuscript.

## Competing interests

The author(s) declare no competing interests.

## References

  * [1] Christin, N.  Traveling the silk road: A measurement analysis of a large anonymous online marketplace.  In _Proceedings of the 22nd international conference on World Wide Web_ , 213–224 (2013).
  * [2] Chainalysis.  The chainalysis 2021 crypto crime report.  https://go.chainalysis.com/2021-Crypto-Crime-Report.html (2021).
  * [3] Dingledine, R., Mathewson, N. & Syverson, P.  Tor: The second-generation onion router.  Tech. Rep., Naval Research Lab Washington DC (2004).
  * [4] Nakamoto, S.  Bitcoin: A peer-to-peer electronic cash system.  _Decentralized Business Review_ 21260 (2008).
  * [5] Martin, J.  Lost on the silk road: online drug distribution and the ‘cryptomarket’.  _Criminology & Criminal Justice_ 14, 351–367 (2014).
  * [6] Shortis, P., Aldridge, J., Monica, J. _et al._ Drug cryptomarket futures: structure, function and evolution in response to law enforcement actions.  In _Research Handbook on International Drug Policy_ , 355–380 (Edward Elgar Publishing, 2020).
  * [7] Van Hout, M. C. & Hearne, E.  New psychoactive substances (NPS) on cryptomarket fora: an exploratory study of characteristics of forum activity between NPS buyers and vendors.  _International Journal of Drug Policy_ 40, 102–110 (2017).
  * [8] Rhumorbarbe, D., Staehli, L., Broséus, J., Rossy, Q. & Esseiva, P.  Buying drugs on a darknet market: A better deal? studying the online illicit drug market through the analysis of digital, physical and chemical data.  _Forensic science international_ 267, 173–182 (2016).
  * [9] Li, Z., Du, X., Liao, X., Jiang, X. & Champagne-Langabeer, T.  Demystifying the dark web opioid trade: content analysis on anonymous market listings and forum posts.  _Journal of Medical Internet Research_ 23, e24486 (2021).
  * [10] Booij, T. M., Verburgh, T., Falconieri, F. & van Wegberg, R. S.  Get rich or keep tryin’trajectories in dark net market vendor careers.  In _2021 IEEE European Symposium on Security and Privacy Workshops (EuroS &PW)_, 202–212 (IEEE, 2021).
  * [11] Hiramoto, N. & Tsuchiya, Y.  Are illicit drugs a driving force for cryptomarket leadership?  _Journal of Drug Issues_ 53, 451–474 (2023).
  * [12] Branwen, G. _et al._ Dark net market archives, 2011-2015.  https://www.gwern.net/DNM-archives (2015).  Accessed: 2021-07-22.
  * [13] DEEPDOTWEB.  Evolution market background: carding forums, ponzi schemes & LE.  _DEEP.DOT.WEB article_ https://www.gwern.net/docs/darknet-markets/evolution/2015-03-18-the_avid-evolutionmarketbackground-cardingforumsponzischemesle.html (2015).
  * [14] Boekhout, H. D., Blokland, A. A. & Takes, F. W.  Early warning signals for predicting cryptomarket vendor success using dark net forum networks.  _arXiv preprint arXiv:2306.16568_ (2023).
  * [15] Boekhout, H. D., Blokland, A. A. & Takes, F. W.  A large-scale longitudinal structured dataset of the dark web cryptomarket Evolution (2014–2015), 10.5281/zenodo.10156522 (2023).
  * [16] Chen, S. C. & Dhillon, G. S.  Interpreting dimensions of consumer trust in e-commerce.  _Information technology and management_ 4, 303–318 (2003).
  * [17] Huang, R. & Sarigöllü, E.  How brand awareness relates to market outcome, brand equity, and the marketing mix.  _Journal of Business Research_ 65, 92–99 (2012).
  * [18] Fonhof, A. M., van der Bruggen, M. & Takes, F. W.  Characterizing key players in child exploitation networks on the dark net.  In _International Conference on Complex Networks and their Applications_ , 412–423 (Springer, 2018).
  * [19] Jo, W., Jang, S. H. & Shin, E. K.  Stage distinctive communication networks of the online breast cancer community.  _Scientific Reports_ 13, 1726 (2023).
  * [20] Kunegis, J.  KONECT – The Koblenz Network Collection.  In _Proc. Int. Conf. on World Wide Web Companion_ , 1343–1350 (2013).