ArticlePDF Available

Abstract and Figures

Nowadays, an increasing number of third-party applications exploit the Bitcoin blockchain to store tamper-proof records of their executions, immutably. To this purpose, they leverage on the few extra bytes available for encoding custom metadata in Bitcoin transactions. A sequence of records of the same application can thus be abstracted as a stand-alone subchain inside the Bitcoin blockchain. However, several existing approaches do not make any assumptions about the consistency of their subchains, either (i) neglecting the possibility that this sequence of messages can be altered, mainly due to unhandled concurrency, network malfunctions, application bugs, or malicious users; or (ii) giving weak guarantees about their security. To tackle this issue, in this paper we propose an improved version of a consensus protocol formalized in our previous work, built on top of the Bitcoin protocol, to incentivize third-party nodes to extend consistently their subchains. Besides, we perform an extensive analysis of this protocol, both defining its properties and presenting some real-world attack scenarios, to show how its specific design choices and parameter configurations can be crucial to prevent malicious practices.
Content may be subject to copyright.
Analysis of a Consensus Protocol for Extending
Consistent Subchains on the Bitcoin Blockchain
Riccardo Longo 1,‡ , Alessandro Sebastian Podda 2,‡ and Roberto Saia 2,*,
Department of Mathematics, University of Trento, 38123 Povo, Trento, Italy;
2Department of Mathematics and Computer Science, University of Cagliari, 09124 Cagliari, Italy;
This paper is an extended version of our paper published in the proceedings of the International Conference
on Financial Cryptography and Data Security, Springer, Cham, 2017.
These authors contributed equally to this work.
Received: 4 June 2020; Accepted: 23 July 2020; Published: 27 July 2020
Currently, an increasing number of third-party applications exploit the Bitcoin blockchain
to store tamper-proof records of their executions, immutably. For this purpose, they leverage the
few extra bytes available for encoding custom metadata in Bitcoin transactions. A sequence of
records of the same application can thus be abstracted as a stand-alone subchain inside the Bitcoin
blockchain. However, several existing approaches do not make any assumptions about the consistency
of their subchains, either (i) neglecting the possibility that this sequence of messages can be altered,
mainly due to unhandled concurrency, network malfunctions, application bugs, or malicious users,
or (ii) giving weak guarantees about their security. To tackle this issue, in this paper, we propose an
improved version of a consensus protocol formalized in our previous work, built on top of the Bitcoin
protocol, to incentivize third-party nodes to consistently extend their subchains. Besides, we perform
an extensive analysis of this protocol, both defining its properties and presenting some real-world
attack scenarios, to show how its specific design choices and parameter configurations can be crucial
to prevent malicious practices.
Keywords: Bitcoin; blockchain; smart contracts
1. Introduction
In the last decade, the emergence of Bitcoin [
] and other cryptocurrencies has revolutionized
many sectors of modern society, as reported in [
], which provides a systematic review of the literature
on major topics related to the cryptocurrencies market: firstly, the financial one, as they represent
innovative assets, characterized by the concept of scarcity [
], and elusive to traditional market
logics; then, of course, the IT sector, since these technologies introduced, for the first time on a large
scale, the concept of the blockchain, a decentralized and secure data structure for the certification of
information (initially, payment transactions), immutable, and that does not require the intervention of
a central control authority such as a bank or a government; and last, but not least, the legal sphere,
where this lack of central control makes these instruments difficult to regulate, but at the same time
attractive, thanks to the collateral opportunities they offer.
The system is designed to be anonymous; hence, each user receives a digital identity.
The underlying idea is then to create a virtual currency, the Bitcoins, and use the blockchain as
a public record of payment transactions, in order to uniquely determine how many Bitcoins are
owned and transferred by each user. Indeed, once a certain amount of time has elapsed after the
Computation 2020,8, 67; doi:10.3390/computation8030067
Computation 2020,8, 67 2 of 22
publication of the transaction on the blockchain, it becomes no longer possible to change its content or
delete it, permanently.
Adding new transactions on the blockchain is the job of a peer-to-peer network of nodes,
called miners, through a distributed consensus protocol. Roughly, transactions are organized into
blocks: to publish a new block, the protocol requires solving a moderately difficult cryptographic
puzzle. The first miner who solves the puzzle earns some fresh coins for the mined block, plus a small
fee for each transaction included therein. Such a process is based on the fact that a cryptographic puzzle
is really hard to solve, but is very easy to prove [
]. In contrast, removing or modifying existing
blocks is computationally unfeasible: this would require an adversary with more computational power
than the rest of all the other nodes. According to its promoters, Bitcoin will resist attacks unless the
adversaries control the majority of total computing power of the Bitcoin network. In fact, even though
some vulnerabilities have been reported in the literature [
], the most known successful attacks
of Bitcoin are standard hacks or frauds [
], unrelated to the Bitcoin protocol. In [
], the authors
discussed the different types of attacks related to Bitcoin and other cryptocurrencies, whereas in [
the authors introduced and discussed, respectively, the security and privacy issues related to Bitcoin
and to the blockchain technology.
Additionally, Bitcoin transactions may also include some bytes of metadata, through the
instruction, as reported in the study performed in [
], where the authors identified
and classified real-life blockchain transactions embedding metadata, with regard to several major
protocols that operate over the Bitcoin blockchain. Recently, this led to an increase in the number of
third-party services that take advantage of this possibility, in order to permanently store messages,
digests, or information generated by their execution. This is the case, for example, of miscellaneous
decentralized applications, systems for the certification of documents and production chains,
smart contracts, distributed computing services, and tokenization platforms. In such a context,
a sequence of messages, embedded in the blockchain and related to the same decentralized application
or service, can therefore be abstractly interpreted as an independent subchain, meaningless for Bitcoin
nodes, but incremental and ideally contiguous for nodes running such an application.
However, since subchains often need to preserve the order of the messages they contain (mainly
to guarantee an agreement, between the distributed participants, on the application execution),
it is important to ensure that their contents are unambiguous and consistent. This would require,
e.g., a protocol for managing the simultaneous publication of (potentially conflicting) new messages,
as well as the possibility of recognizing invalid or fraudulent sequences. Nonetheless, the majority
of third-party applications that exploit the blockchain to store their messages do not use a secure
protocol to establish if their subchain is consistent. This is a serious issue, since it either limits the
expressiveness of the features offered by these applications (i.e., they must consider all messages
as consistent, then losing the notion of state) or, conversely, degrades their security level (because
adversaries can manage to publish inconsistent messages).
To cope with this issue, our protocol, based on proof-of-stake [
], requires providing a money
deposit in order to earn the right to extend the current subchain. Intuitively, a node that publishes
a consistent message gets back its deposit once the message is confirmed by the rest of the network,
while behaving dishonestly is discouraged and disincentivized.
In light of the above, the main original contributions of this work are:
a broad revision and extension of our protocol [
] that allows third-party decentralized
applications to maintain consistent subchains on Bitcoin;
a detailed analysis of the security properties and guarantees offered by the protocol, through the
definition of multiple attack scenarios and adversarial strategies;
a description of how to concretely implement in Bitcoin this revised protocol, adapted from its
original formulation.
Computation 2020,8, 67 3 of 22
The remainder of the paper is organized as follows. Section 2introduces the background and
related work of the scenario taken into account. Section 3formalizes the proposed consensus protocol
for Bitcoin subchains. Section 4evaluates the security of such a protocol, whereas Section 5describes a
possible implementation in Bitcoin. Some concluding remarks and future work are finally given in
Section 6.
2. Background and Related Work
To better present the rest of our work, we start by giving a general overview on Bitcoin and how
it works, along the lines of our conference paper in [
]. Basically, Bitcoin is a cryptocurrency and a
digital open-source payment infrastructure, conceived of by an anonymous inventor, known under the
pseudonym Satoshi Nakamoto, and launched for the first time on 3 January 2009. This cryptocurrency
gave rise to an exponentially growing number of applications, representing the basis of many other
cryptocurrencies, as highlighted in the bibliometric analysis of the literature on Bitcoin performed
in [
]. Moreover, an overarching in-depth study of the phenomenon originated from Bitcoin itself
was instead made in [17].
The main peculiarity of Bitcoin lies in the fact that it does not require the control of any central
authority, relying instead on a peer-to-peer network of nodes called miners that are responsible for
maintaining a public ledger called the blockchain [
]. The advantages and disadvantages of this
decentralized scheme were discussed in [
], where the authors evaluated the benefits of decentralized
finance, identifying the existing business models, and evaluating the potential limits.
The underlying intuition is that, compared to a conventional payment intermediary, in Bitcoin,
all currency transfers are permanently stored in this public ledger, through which it is possible
to reconstruct, at any time and in a deterministic way, the balance held by each Bitcoin owner.
Indeed, the virtual currency exchanged in such an infrastructure is the Bitcoin (
). Each Bitcoin
user owns one or more personal wallets, which essentially consist of pairs of asymmetric cryptographic
keys: the public key uniquely identifies the user address, to receive funds, while the private key is
used to authorize payments. To do so, they attest to their transfer of Bitcoins with digital transactions,
validated through cryptographic methods, and registered on the blockchain, neatly organized into
blocks. A simplified scheme of a Bitcoin transaction is shown in Figure 1.
scriptPubKey(t,σ): verk(t,σ)
Figure 1. Simplified scheme of a Bitcoin transaction.
The transaction
enables a transfer of
, which are redeemed from a previous transaction by
referring to
in the infield. To prove that
is the rightful recipient of
, its scriptSig field contains
a witness value that makes the scriptPubKey of
, a Boolean programmable function, evaluate to
true. If
respects this condition and is published in the blockchain, the value of
is transferred to
, and
is no longer redeemable. Similarly, a new transaction can then redeem
by satisfying its
respective scriptPubKey. Figure 1shows the standard form of scriptPubKey: it essentially evaluates
to true when the redeeming transaction (e.g.,
) provides a valid digital signature
. In particular,
denotes the signature verification with the public part of the key pair
, while
the signature itself, performed with the private part of
, on the body (i.e., all parts except its scriptSig)
of the redeeming transaction.
However, Bitcoin transactions may be more general than those illustrated by the previous
example: first, they may contain multiple inputs and outputs (we denote them with the array notation).
In particular, each output has its own scriptPubKey and value and can be redeemed independently
of the others. Consequently, in fields must specify which output of a transaction they are redeeming
Computation 2020,8, 67 4 of 22
in the figure), and each must be associated with a scriptSig that satisfies the corresponding
scriptPubKey. The values of the inputs are aggregated and can be distributed freely among the outputs,
with the condition that the sum of the values of all the inputs must be greater than or equal to the sum
of the values of all outputs. As a side effect, it is therefore possible to spend only part of the value
associated with the transaction, with the difference still redeemable by the owner.
More thoroughly, scriptPubKey describes a Boolean function, expressed in a not Turing-complete
scripting language, and featuring a limited set of logic, arithmetic, and cryptographic operators.
Finally, the lockTime field specifies the earliest moment in time (block number or timestamp) when the
transaction can appear on the blockchain.
To reach a consensus on new blocks of transaction to be published, Bitcoin implements a
proof-of-work system [
]. It consists of a protocol that essentially pushes miners to compete with
each other for the right to add these blocks to the blockchain: indeed, to append a new block
to the
blockchain, each miner has to solve a cryptographic challenge, which requires a high consumption of
computational resources. This challenge involves the hash
of the last published block
the sequence of unconfirmed transactions
contained in
, and some salt
. As soon as a miner
finds a solution to the current challenge, it can add
to the blockchain, obtain a reward in Bitcoins,
and start mining a new block on top of
. In this way, the other miners are incentivized to discard
their attempts, update their local copies of the blockchain with the new block
, and start over with
new transactions. The PoWprotocol ensures each new block is mined every 10 min, on average.
Finally, note that when two or more miners solve the current challenge simultaneously,
they generate a fork in the blockchain (i.e., two or more parallel valid branches). When such a
fork happens, miners must choose a branch wherein the mining process is carried out; roughly,
the divergence is resolved once one of the branches becomes longer than the others. In this case,
the other branches are discarded, and all the orphan transactions contained therein are nullified. As a
side effect, this mechanism encourages miners to properly verify the validity of blocks and transactions,
since an honest majority of miners will discard branches containing invalid transactions, causing their
respective miners to lose the associated fees and rewards.
2.1. Smart Contracts and Decentralized Applications
As previously mentioned, one of the most interesting features of Bitcoin and other
cryptocurrencies is the possibility, beyond the exchange of digital currency, to deploy so-called smart
contracts. This concept was introduced for the first time, at the beginning of the 1990s, by Nick
Szabo [
], which defines them as agreements between two or more entities, which can be applied
automatically without the need for a trusted intermediary. In other words, a smart contract represents
a self-executing contract with the terms of the agreement between entities (e.g., buyer and seller),
which have been defined in lines of code in the context of a distributed, decentralized blockchain
network [21].
The cryptocurrencies scenario has provided a first concrete example of this intuition, since in this
context, actors operate in a decentralized way, in order both to create and transfer crypto-assets [
Indeed, the blockchain and its protocol can enforce the contract execution, since each transaction is
traceable and irreversible. In particular, Bitcoin offers the possibility to specify some simple contracts
in transactions through short programs expressed in a Forth-like scripting language. These contracts
are evaluated by the miners before the respective transactions are appended to the blockchain and
often contain clauses that involve the transfer of some Bitcoins among nodes.
The idea of using the blockchain and its consensus protocol as foundations for a decentralized
contract-oriented interaction has been explored by several recent works. For instance,
References [2330]
proposed protocols for secure multiparty computations, fair lotteries, and (decentralized) role-based
access control; Reference [
] implemented decentralized authorization systems on Bitcoin;
Reference [
] allowed users to log statements on the blockchain; Reference [
] was a key-value
database with get/set operations; Reference [
] extended Bitcoin with advanced financial operations
Computation 2020,8, 67 5 of 22
(like, e.g., the creation of virtual assets, payment of dividends, etc.), by embedding its own messages in
Bitcoin transactions.
Later approaches, such as that of Ethereum [
], have been developed, by-design, to be natively
oriented to the implementation of smart contracts and decentralized applications in a more general
sense [
], rather than payments. For instance, in [
], the authors proposed a security framework that
integrates the blockchain technology with smart devices to provide a secure communication platform
in a smart city; Reference [
] discussed a blockchain application developed for the energy sector that
enables distributed market coordination for decentralized energy systems; Reference [
] presented
a survey on couponing platforms where coupons are implemented as smart contracts; and in [
the authors introduced a novel blockchain-based distributed paradigm for data exchange between
wireless-based devices. Overall, since this technology grants the security and immutability of the
involved data, it is suitable for the smart contract implementation. However, in addition to creating
new opportunities, this novel form of smart contract implementation generates also new types of
fraud [
], which effectively circumvent the canonical fraud detection approaches [
], making it
necessary to develop new targeted countermeasures [
]. Since smart contracts usually handle
crucial data, their implementation should be secure against attacks that aim at stealing or tampering
with the data [
]. This aspect has been faced by an increasing number of literature works, such as [
where the authors proposed a survey on the attacks related to the Ethereum smart contracts; or [
which aims to develop secure Bitcoin contracts; or more generally, in [
], the authors, respectively,
provided a systematic survey about the security, performance, and applications of smart contracts and
presented a study about their formal verification.
However, specifically for Bitcoin, the possible contracts that are natively supported by this
platform are very limited, since its language is not Turing-complete, an aspect investigated by the
authors in [53].
Nonetheless, its protocol allows clients to embed a few extra bytes as metadata in transactions,
and many third-party decentralized applications (or smart contracts) exploit these metadata to store a
persistent, timestamped, and tamper-proof historical record of all their execution messages [
Usually, metadata are stored in transactions by using the
field [
], making them
meaningless to the Bitcoin network. With this approach, the sequence of application-dependent
messages forms a subchain, whose content can only be interpreted by the nodes that execute
that application, thus potentially extending the decentralization power of Bitcoin to more complex
computational models.
2.2. Subchains and Consistency
To formally describe the concept of a Bitcoin subchain and, more specifically, of a consistent
subchain, we now briefly recall a set of definitions, previously introduced in [
]. To do so, let us define
a set
. . .
of participants, who want to extend the subchain by appending messages
. . .
to it.
We call a label a pair consisting of a participant
and a message
, written
. In such a context,
subchains can be considered as finite sequences of labels, written A1:a1· · · An:an, embedded in the
Bitcoin blockchain. This can be interpreted as the participant
that embedded the message
some transaction of the blockchain, and subsequently, the participant
appended a new transaction
that embeds
, and so on. We also alternatively denote (long) sequences of labels with
, thus writing,
e.g., ηA:afor the subchain obtained by appending A:ato η.
To be more general, we model subchains as traces of Labeled Transition Systems (LTS). An LTS
is a tuple
, where: (i)
is a set of states (ranging over
. . .
); (ii)
is a set of labels
(in our case, of the form
); (iii)
is the initial state; and (iv)
→ ⊆ Q×L×Q
is a transition
relation. In particular, we write
q0)∈ →
, and we require the relation
to be
deterministic, i.e., if qA:a
q0and qA:a
q00, then it must be q0=q00.
Given this model, we then assume that the subchain has a state, and each subsequent message
(appended to it) updates its state according to the transition relation. More formally, if the current
Computation 2020,8, 67 6 of 22
subchain state is
, then a participant
who sends a message
makes the state evolve to
, only if:
is a transition of the LTS. However, it can be observed that for some state
and label
it may happen that no state
exists such that
. The goal is that, in this case, it would be hard
for a participant to append such a message. Indeed, it could be the case of an adversary who tries to
subvert the messages produced by the (decentralized) application execution. Therefore, we informally
say that a subchain
A1:a1· · · An:an
is consistent if, starting from the initial state
, there exist the
states q1, . . . , qnsuch that, from each qk, there is a transition labeled Ak+1:ak+1to qk+1.
We also notice that, in general, application messages—since they are embedded in Bitcoin
transactions—can also produce side effects on the Bitcoin blockchain. Thus, we indicate with
a message that, besides updating the subchain, also transfers
Bitcoins) from a
to a participant
. In other words, when this message is on the subchain, it also makes
in a transaction of
redeemable by
, acting as a money transfer, and therefore, making it possible
to potentially define smart contracts external to the native Bitcoin protocol. Finally, note that, for the
sake of clarity, if the value vis zero, we simply write arather than a(vB).
Below, we now formalize some of the intuitions previously described.
Definition 1
(Consistent subchain)
A subchain
η=A1:a1· · · An:an
is consistent if and only if there
exists ¯
q such that: q0
· · · An:an
We also observe that, whenever a subchain is consistent, the required property of determinism
enforces the existence of
and its uniqueness. Consequently, a consistent sequence of messages
uniquely identifies the state of the subchain, and a node can reconstruct the application computation
as q0
Following the same approach, we assume that an adversary can append a label
such that
, so making the subchain inconsistent. However, upon receiving such a label, honest nodes will
discard it. To do so, they apply a function
that, given a subchain
(possibly inconsistent), filters all
the invalid messages. The function Γis defined as follows:
Γ(ηA:a) =
Γ(η)A:aif q,q0:q0
with Γ(e) = e.
Finally, to model labels that are appended to the subchain without breaking its consistency, we
recall below the auxiliary relation
. Informally, given a consistent subchain
, the relation
holds whenever the subchain ηA:ais consistent.
Definition 2
(Consistent update)
A label
is a consistent update of a subchain
, written
if and only if the subchain built by extending Γ(η)with A:ais still consistent.
Given the above definitions, we can now introduce the description and properties of our protocol
to incentivize mutually distrusted participants to consistently extend a subchain embedded in the
Bitcoin blockchain.
3. Overview of the Extended Protocol
Hereafter, we present an extended and revised version of the protocol preliminarily described
in [
]. It introduces several new elements, such as the refund policies, which, as will be shown in
following Section 4, have an important impact in limiting or preventing certain types of attack to which
the simplified version of the protocol could be subject.
Computation 2020,8, 67 7 of 22
This protocol relies on a Proof-of-Stake (PoS) consensus mechanism, built on top of Bitcoin’s
native proof-of-work and handled by a set of nodes
. . .
, called meta-nodes to distinguish them
from the nodes of the Bitcoin network. The intuition is that such nodes would ensure that any client of
a decentralized application, which (abstractly) stores its execution data on a Bitcoin subchain, can trust
the consistency and reliability of these data.
The protocol’s main assumption is that the overall stake retained by honest meta-nodes of a certain
application is greater than the stake owned by dishonest ones. Note that an equivalent hypothesis,
but related to computational power rather than stake, also holds in Bitcoin, where honest miners are
supposed to control more computational power than dishonest ones. On the other hand, the main
purpose of the protocol is to allow honest participants (i.e., those who follow the protocol) to perform
consistent updates of the subchain, while disincentivizing adversaries who attempt to make the
subchain inconsistent.
Meta-nodes use their stake to vote for approving messages sent by participants. These messages
are embedded into Bitcoin transactions and called update requests. We indicate with
the update request issued by
to extend the subchain with the message
. To vote for such an
update request, a meta-node essentially puts a deposit of
on it, where
is a constant specified by
the protocol.
Each message, encoded as an update request, needs the vote of a meta-node in order to be
appended to the subchain; otherwise, this message will be ignored by the other participants. Therefore,
meta-nodes are strictly required to vote for a request
only if
is a consistent update of
the current subchain
, i.e., if
. To incentivize meta-nodes to vote, then approve, their update
requests, participants must pay them a constant fee
that can be redeemed by the respective
meta-nodes only after the request is published on the Bitcoin blockchain.
The protocol is organized into rounds, and it ensures that exactly one label is appended to
the subchain for each round
. To guarantee this uniqueness, the protocol exploits an arbiter
a distinguished node of the network that is assumed to be honest (this hypothesis is discussed in
Section 3.4).
The main steps of the protocol, for each round i, are summarized as follows:
1. A meta-node Nreceives an update request UR[A:a]from the client A;
2. N
checks the consistency of the message, i.e., whether the relation
holds; if true,
it proceeds with Step 3, otherwise it discards the request and goes back to Step 1;
3. Nvotes for the request during a voting phase of duration and adds it to the request pool;
4. When expires, the arbiter signs all the well-formed URs in the request pool;
All the requests signed by the arbiter are sent to the Bitcoin miners, to be published on the
blockchain. The first to be mined, indicated with
, extends the subchain with its
-th message.
To vote for an update request, as indicated in Step 3,
must confirm some of the past
1 is the cutoff window, a constant fixed by the protocol and described in Section 3.1).
To confirm an update,
uses the
to pay the meta-nodes who respectively appended each chosen
) to the subchain. The way to choose the updates
to be confirmed
is called the refund policy and is deepened in Section 3.1. In particular, the request pool is the set
of all voted requests of the current round, which is emptied at the beginning of each round. Finally,
the choice of (the duration of the voting phase) is discussed in Section 5.
Note also that, in Step 4, the arbiter
signs all well-formed request transactions: such transactions
are those that correctly adhere to the format specified in Section 5. In the same section, we also describe
the mechanism to ensure that, at each round
, exactly one transaction
, in Step 5, is published
on the Bitcoin blockchain. When this happens, the label A:ais appended to the subchain.
Overall, the protocol depends on the parameters
Π= (C
, which are, respectively, the cutoff
window size, the amount required to vote an update request, the fee payed by the client, and the
Computation 2020,8, 67 8 of 22
maximum transferable amount in special updates in the form
(where, by definition,
3.1. Refund Policies
A refund policy can be formally defined as a function
that, given a subchain
and the protocol
parameters Π= (C,κ,f,r), outputs a sequence of refunds ρi= (ρi
1. . . ρi
C), where:
represents, at each round
of the protocol, the amount to pay to the meta-node who voted
, for every
s.t. 1
(only updates inside the current cutoff window can be refunded);
(the policy specifies how to split the vote and the fee among the voters of the
updates inside the cutoff window).
To enforce good behavior, updates whose voters did not follow the prescribed policy are
considered not refundable. This means honest meta-nodes penalize not only inconsistent labels,
but also illegal refunds.
Definition 3
(Refundable update)
be the subchain after the completion of the
-th protocol round,
be a published update, and
be the refund made by its voter. Then, we say
is refundable if and
only if it is consistent (η[1...(j1)] |=A:a) and it follows the refund policy ( ¯
Thus, at each round
, we can define the set of indexes of refundable updates in the current
cutoff window. Suppose that the subchain starts with
predetermined and consistent updates
URi, 1 iC, then:
since all initial updates are considered refundable. Then, for i>0:
ξi={1jC:URijis refundable according to Θ}(2)
Note that checking if the voter of the j-th update (with j<i) has followed the refund policy just
requires examining the updates with index
. Thus, this check may depend only on
and never
on ξi.
As an example, some possible refund policies are now presented.
This policy refunds only the newest refundable update in the cutoff window (if any),
the newest in general otherwise:
κ+fif ξi6=j=min(ξi)
κ+fif ξi=j=1
0 otherwise
This policy refunds the oldest consistent update (if any), the oldest in general otherwise
(note that it coincides with the newest-firstif C=1):
κ+fif ξi6=j=max(ξi)
κ+fif ξi=j=C
0 otherwise
3.2. Proof-of-Burn
To expand the possibilities for meta-nodes and increase the security of the protocol, as will
be discussed in depth in Section 3.3, the sequence of refunds
can be extended to include a
Computation 2020,8, 67 9 of 22
special value
. This value represents the amount that should be paid to a pre-set fictional address
(e.g., an all-zero address). Refunding such an address effectively corresponds to burning the money
sent, making it unspendable.
With this enhancement, the policies defined previously can be improved, removing the case
ξi=and adding:
0=(κ+fif ξi=
0 otherwise (5)
which can be interpreted as follows: if no update in the cutoff window is refundable, burn vote and
fee. The variants of the previous policies, after the inclusion of the proof-of-burn condition, are called
. This change avoids the (forced) confirmation of
a non-refundable update that is allowed in the previous definitions of the
oldest-first policies.
Now, recall that in Section 3, the condition C1 is provided. However, the choice C=1 makes
sense only if there is the possibility of burning the vote. On the contrary, voters would have no other
choice besides confirming the previous update (refundable or not). Introducing the proof-of-burn,
instead, the following policy for C=1 can be defined and used.
harsh policy This policy refunds the previous update if refundable, burns the money otherwise:
1=(κ+fif ξi={1}
0 otherwise ρi
0=(κ+fif ξi=
0 otherwise (6)
3.3. Properties of the Protocol
Our extended protocol provides some properties, which in part differ from those presented in its
original formulation. Nonetheless, both versions rely on the same underlying assumptions. In detail:
Assumption 1.
The honest meta-nodes control the majority of the total stake of the network, and this amount
is denoted by S.
Assumption 2.
The overall stake needed to vote on pending update requests is greater than the overall stake
detained by honest meta-nodes.
Assumption 3. Each honest meta-node votes for as many requests as is allowed by its stake.
Hence, if its stake is
, any honest meta-nodes votes on
requests per round. Consequently,
the rest of the network—which may include dishonest meta-nodes not following the protocol—can
vote on at most
. In this regard, note that assuming the ability of the adversary to delay some
messages (as in the Dolev–Yao model [
]), and thus reducing the honest meta-nodes’ actual voting
power (since their voted requests might not reach the request pool), is equivalent to considering an
adversary with a higher stake.
From these assumptions, it follows that:
Lemma 1.
The probability that an honest meta-node with stake
updates the subchain is at least
each round.
Lemma 1is a direct consequence of Assumptions 2and 3. Moreover, since in Assumption 1,
we assume that honest meta-nodes control the majority of the stake, Lemma 1also limits the capabilities
of the adversary, leading to the following:
Lemma 2.
If the global stake of honest meta-nodes is
, then dishonest ones update the subchain with
probability at most (SSH)/S at each round.
Computation 2020,8, 67 10 of 22
However, note that although inconsistent updates are ignored by honest meta-nodes, their side
effects as standard Bitcoin transactions (i.e., transfers of
in labels
) cannot
be revoked once they are included in the Bitcoin blockchain. Indeed, even though the goal of the
protocol is to let meta-nodes get revenues proportionate to their probability of updating the subchain
(as defined in Lemmas 1and 2), the adversary might exploit these side effects to earn more than it is
due by publishing inconsistent updates. Therefore, we show how the incentive system in our protocol
reduces the feasibility of such inconsistent updates.
In light of the above, according to Lemma 2, if
has stake
, and the other meta-nodes are
honest, then
has probability at most
of extending the subchain in a given round of the protocol.
Since rounds can be seen as independent events, we obtain the following:
Lemma 3.
The probability that an adversary with stake
saturates a cutoff window with its updates only
(consistent or not) is µC, where C is the cutoff window size, and µ=m/S.
Since Lemma 3represents the core property of the described protocol, the demonstration of its
validity will be the full subject of the discussion in Section 4.
Finally, note that, to simplify the terminology, hereafter, we consider a consistent update to be
also refundable. Indeed, publishing a consistent update that is not refundable does not break the
consistency of the subchain, but it causes the meta-node who voted for the update to be (eventually)
not refunded for its effort. Therefore, this behavior cannot be considered an attack.
3.4. Honesty of the Arbiter
The protocol exploits a distinguished meta-node, the arbiter
, to ensure that only one transaction
per round is appended to the blockchain, and that its choice is random as well. In order to simplify the
description of the protocol, the arbiter
is assumed to behave honestly. However, if this prerequisite
proves to be false, the main properties of the protocol would be preserved, but at the cost of a
deterioration in its execution performance.
To clarify this point, observe that although the arbiter introduces a point of centralization, it does
not play the role of a trusted authority. Indeed, recall that the update requests to be voted on are
chosen by the meta-nodes, and once they are added to the request pool, the arbiter is expected to sign
all of them, without taking part in the validation, nor in the voting. Transactions are first signed by
clients and voters; thus, neither the arbiter, nor other nodes can modify their content once sent to the
request pool. This means that a dishonest arbiter can only refuse to add its signature to a subset of
them, i.e., prevent their publication (which corresponds to isolating some meta-nodes in the network
or, in other words, amplifying the voting power of malicious nodes). However, since everyone can
inspect the request pool, any misbehavior of the arbiter can be easily detected by the meta-nodes,
which can proceed to replace it. For these reasons, the presence of the arbiter cannot affect the
decentralization of the approach, but without the assumption of its honesty, it would be necessary
to take into consideration some possible performance attacks like, e.g., temporary denial-of-service
attacks performed by the arbiter. This is still an open issue, and in this regard, Section 6presents
our future research directions on algorithms that allow meta-nodes to safely replace the arbiter when
misbehavior is detected.
4. Analysis of the Protocol
In this section, we evaluate the security of the protocol, providing some analytical results.
In particular, we illustrate some realistic attack scenarios and investigate how the choice of protocol
parameters and the refund policy can disincentivize adversaries from behaving dishonestly. We also
examine how possible attacks to Bitcoin may affect subchains built on top of its blockchain.
Computation 2020,8, 67 11 of 22
4.1. Self-Compensation and Reversed Self-Compensation Attacks
To start our analysis, we start by illustrating two attacks that could potentially compromise the
effectiveness of the protocol. Let us assume an adversary
that manages to publish
updates (consistent or inconsistent) starting from index
, with the probability given by Lemma 3.
can use each update at index
to recover its vote
and eventually the fee
for its
previous update at index k1, such that only the last update at index j+Cremains unrefunded.
In particular, if the protocol specifies a refund policy that does not admit the proof-of-burn
described in Section 3.2, at least one honest update at index
has to necessarily refund
, since
saturated the cutoff window with its updates only. Consequently, following this
strategy, the attacker does not lose any deposit and possibly earns an additional extra revenue
each inconsistent update published, if any. This extra revenue
models the case where
induces a
victim Ato publish an inconsistent update in the form A:a(rM).
Note also that, if
cannot manage to saturate the cutoff window immediately, it can delay the
completion of the attack by publishing at least one inconsistent update every
ones on the subchain
(to keep refunding itself the vote and the fee). We call the above behavior of
(and all its variants) the
self-compensation attack.
Now, we slightly change the attack scenario, assuming an adversary
that manages to append
two updates on the subchain, the first with index
and the second with index
Suppose that the update at index
is consistent, then the honest meta-node that publishes the update at
1 (recall that the considered refund policy is
) refunds
can use
these funds again to publish a new inconsistent update at index
, refunding its update again at index
(thus, also violating the refund policy). Therefore,
manages to earn the undeserved extra revenue
without having lost neither
, nor
, therefore performing a special case of the self-compensation attack.
Hence, consider a conservative strategy where the attacker
at first tries to publish consistent
updates only. When
manages to publish a few, it tries to publish just one inconsistent update until the
last consistent update published is beyond the cutoff window, then reverses again to consistent updates.
be the probability
has of successfully publishing an update, and suppose it published the
latest (consistent) update. We show that the expected payoff
, when it follows the described
dishonest strategy, is always greater than the expected payoff
can get if it follows the honest
strategy. The analysis is limited to the subsequent
updates, since the two strategies coincide
afterwards, and holds only for
2 (with
1, meta-nodes have no choice of refunding the
last update, so an inconsistent update is always more profitable than a consistent one). From the
hypothesis, it follows that:
µ(1µ)i1(f+r+µf(C1i)) (7)
φH=µf C (8)
In Equation (7),
describes the payoff of
for the first update it publishes, while the rest
denote the sum of the revenues obtained by publishing one or more updates in the subsequent cutoff
window, weighted for the respective probabilities to occur. Then, the gain
obtained by following the
dishonest strategy is:
φDφH=µf(1C) + µ
=µf C1
(1µ)i1(1+µ(C1i)) (C1)!+µr
Computation 2020,8, 67 12 of 22
The result of Equation (9) is justified by the following Lemma 4. Since 0
rs.t. r>
we get
. This means that, independently of the chosen protocol parameters
, a protocol that
uses the refund policy
admits at least one dishonest strategy, which is always more
profitable than the honest one. Note also that a similar result can be obtained for the
Lemma 4. For C 2, it holds:
(1µ)i1(1+µ(C1i)) (C1) = 0 (10)
(1µ)i1(1+µ(C1i)) (C1)
j=0 (µ)jC2
= (µ)0C2
0(C1) +
(µ)j C2
From the following Lemma 5, it follows that the coefficients of the polynomial in Equation (11)
are all zero, thus proving the above Lemma 4.
Lemma 5. For n 1, it holds:
j1(n+1i)=0 1 jn(12)
Proof. We prove it by induction over n. The base case is n=1; therefore, j=1.
0(2i)=11=0 (13)
For the inductive step:
To conclude, the results of the following Lemma 6are needed.
Computation 2020,8, 67 13 of 22
Lemma 6. For n 1, it holds:
Proof. The proof is again by induction over n. The base case is n=1; thus, k=1.
For the inductive step:
In the aforementioned scenario, we showed a dishonest strategy that exploits a variant of the
self-compensation attack (which we call reversed self-compensation attack), and through Equation (9),
we proved that it is always more profitable than the honest strategy whether the chosen refund policy
. This led us to conclude that the choice of the protocol parameters and, in particular,
the refund policy is crucial to force the honest strategy to be more profitable than any dishonest one.
4.2. General Attacker Model
To analyze other possible attacks, we now define a more general attacking strategy,
which considers an adversary who can craft any update (consistent or not) and controls one meta-node
with stake ratio
, where
0, 1
is the stake controlled by the adversary, and
the total stake of the network (assuming a single adversary is not less general than having many
non-colluding meta-nodes that carry out individual attacks. Indeed, in this setting, meta-nodes do not
join their funds to increase the stake ratio
). Suppose that each meta-node can vote on as many update
requests as possible, spending all its stake, and that the network is always saturated with pending
updates, which globally amount to the entire stake of honest meta-nodes (note that saying the update
queue is not always saturated is equivalent to modeling an adversary with a stronger
: this is because
honest meta-nodes cannot spend all their stake in a single protocol round, i.e., reducing their actual
power. Thus, studying this particular case will not give any additional contribution to the analysis).
To evaluate its security, we model the protocol as a game, in which the attacker
is a player that
adopts a possibly dishonest strategy, thus trying to publish either consistent or inconsistent updates.
Conversely, the other players are the honest meta-nodes, which follow the protocol and therefore
adopt a honest strategy, trying to publish consistent updates only. Suppose also that
follows an
optimal strategy, i.e., according to the current state, the choice of voting for a consistent or inconsistent
update—at each protocol round—is made with the goal of maximizing its final revenue. In particular,
the current state depends on the content of the current cutoff window, and not on the full history of
the subchain:
Computation 2020,8, 67 14 of 22
Lemma 7.
The revenue of an update published by an adversary
, at the protocol round
, depends only on the
state of the cutoff window in that round (i.e.,
), on the protocol parameters
, on the refund policy
Θ, and on the adversary ratio µ.
To justify Lemma 7, observe that, by the definition of refund policy
, no update with index
can be refunded, neither of the vote
, nor the fee
, in a protocol round with index
Thus, no matter
chooses at the current round, there is no additional revenue (but also no loss)
for any update outside the cutoff window.
Now, let
be a function that maps a subchain
into a sequence of labels
s=σ1:: . . . :: σk
A label
can assume one of the following values:
, which indicates an inconsistent update
published by
, which represents a consistent update published by
, and
, which denotes a
(consistent) external update published by the rest of the network, assumed to be honest.
Furthermore, let
C=G(η[(kC)...(k1)] )
be the sequence that represents the cutoff window state at
This sequence is used to generate two new sequences
Con =sk
C:: Con
Inc =sk
C:: Inc
represent the possible continuations of the chain if the adversary manages to publish the next update.
We also need a function
that, given the protocol parameters
and the refund policy
, takes a
as input and computes the a posteriori attacker revenue associated with
. Moreover, let
be a variant of
that, in addition, takes into account the possible refunds generated appending
updates at the end of s(this models the case of an attack that terminates).
and given the attacker’s ratio
, it is possible to define a payoff function
with depth
. Let
s=σ1:: . . . :: σN
be a sequence of length
s0=σ2:: . . . :: σN
be the same
sequence of s, where the first label is elided. The payoff function is defined recursively as:
Φd(s) = (φ(s) + (1µ)Φd1(s0:: Ext) + µmax(Φd1(s0:: Con),Φd1(s0:: Inc)) d>1
With all these ingredients, we can formulate the following:
Definition 4
(Optimal choice)
Given a sequence
that represents the state of the current cutoff window,
the optimal choice with depth
for the adversary is to try to publish a consistent update if
an inconsistent one otherwise.
In particular, consider an adversary that plans to meddle with the protocol for a limited amount
of time, say for
rounds, starting at round
. In this scenario, the optimal strategy for the adversary
would require, at each round nkn+d1, making the optimal choice with depth n+dk.
This guarantees
, to get the maximum possible revenue at the end of the attack: in fact,
the optimal choice of depth
(i.e., the initial choice) takes into account every possible evolution of the
protocol for the duration of the attack, weighted for its probability to occur, and considers the best
outcome at every step. At last, note that the optimal strategy cannot be well defined for an adversary
that plans to attack the protocol for an indefinite number of rounds; however, it can be effectively
approximated by considering—at each step—making the optimal choice of fixed depth
, for a big
enough d.
4.3. Analytical Results
In what follows, we show the results of the security analysis of the protocol, under the
attack scenario in which the adversary adopts an optimal strategy, and only for the
which provides the best security performance among the policies shown in Section 3.1 (according
to some simulated preliminary experiments shown in Figure 2). The results are summarized by
the following:
Computation 2020,8, 67 15 of 22
Lemma 8.
If the protocol prescribes to use the
policy, an adversary with stake ratio
, who adopts an
optimal strategy in pursuing an attack of arbitrary length, behaves necessarily honest iff µ<1r/(κ+f).
Note that, if the prescribed policy is the
, any update after a
must necessarily
refund the vote and the fee to the adversary, independently of its type. Thus, this additional gain can
be included in the revenue, having:
φ(,Con) = f
where the symbol “” indicates an indifference condition.
On the other side, the revenue for an inconsistent update can be quantified in:
φ(Ext,Inc) = rκ
φ(Inc,Inc) = r+f(vote and fee are self-refunded)
φ(Con,Inc) = rκ(the refund of fand κhas already been counted for Con)
Note that, when considering to publish an inconsistent update, a cutoff that contains
equivalent to one with
. Finally, observe that computing the revenue in this way gives
φ(,Ext) = 0
and therefore, φ=φ0.
Figure 2.
We simulated the revenue of an adversary
who participates in subchains of length 100
and uses the optimal strategy. Each curve represents the revenue of
increases, and for a
different refund policy. We fixed the protocol parameter as follows:
0.03, and
all conventionally expressed in Bitcoins.
Now, note that, at the terminal rounds of the attack, the adversary is encouraged to publish
consistent updates, since it has to publish at least two consecutive
to outdo the honest behavior
) and the chances to do so decrease. The only exceptions are the
rare cases in which a streak of consecutive
occurs in the terminal rounds: here, the adversary is
motivated to continue publishing inconsistent updates. However, as soon as an attempt fails (an
breaks the sequence) and if the end is near enough, the adversary switches to the honest behavior.
On the contrary, at the early rounds, a high enough
ensures that, on average, a sufficient number
of consecutive
will be published to gain an advantage over the honest behavior. In this case,
, it follows that if publishing an inconsistent update is the optimal choice
at the step k, then it was the optimal choice at the step k1 as well.
Computation 2020,8, 67 16 of 22
Under these assumptions, we can conclude that the optimal strategy can be either completely
honest or starting dishonest (always trying to publish
items) and then switching to the honest one
as the end of the attack approaches. Thus, for our analysis, we can only consider the early rounds,
in which publishing inconsistent updates can be more profitable than publishing consistent ones.
Here, the adversary that publishes
with probability
(recall that
is the probability that the adversary manages to publish an update in a
given round). Therefore, the adversary chooses the honest strategy right from the start if and only if:
φ(,Con)>(1µ)·φ(Ext,Inc) + µ·φ(Inc,Inc)
f>rκ+ ( f+κ)µ
The value of
is assumed to be strictly smaller than
, in order to incentivize the participation
of meta-nodes in the protocol. In fact, with
very close to (or even greater than)
, clients have no
evident benefit from delegating meta-nodes to vote on their updates (since the required economical
effort does not change significantly). This is similar to providing a protocol with no fees, in which it is
less attractive for meta-nodes to participate. However, a large participation in the protocol reduces the
possibility that single or colluding entities control the majority of the stake.
Under this assumption, Equation (17) shows that the security of the protocol is essentially
proportional to the ratio
: the higher this ratio, the more convenient an honest behavior becomes.
Figure 3finally illustrates how the switch point (i.e.,
such that
φInc φCon
) varies for different
combinations of κand r, with a small fixed fee ( f=0.01B).
Figure 3.
The plot shows how the switch point (
such that
φInc φCon
) varies for different
combinations of κand r, when the refund policy is harsh-policy and fis fixed to 0.01B.
5. Implementation Concept in Bitcoin
We describe now how the extended version of the protocol can be implemented in Bitcoin.
Note that this implementation, which differs in some aspects from the original one, is conceptual,
Computation 2020,8, 67 17 of 22
although the validity of the transactions has been tested using BitMLcalculus [
], and a preliminary
implementation is under development.
Specifically, a label
at position
of the subchain is implemented as the Bitcoin
. In order to generate it, clients produce an incomplete form of such a
transaction, consisting only of the following input and output fields:
the input in
, which redeems funds from some client’s previous transaction
. These funds
are used to charge the participant fee for the update request (and the value v, if applicable);
scriptPubKey at Index 0, which embeds the label
, properly binary encoded through a custom
enc() function, through the OP_RETURN instruction [55].
scriptPubKey of Index 3, which is only required for messages of the type
i.e., those that also transfer funds between participants. In this case, participant
can redeem
from this output script by providing its signature.
Then, the incomplete transaction is sent to a meta-node, which respectively adds:
the input in
, to put the required
(from some transaction
that in a stage of the protocol
must be different for every vote, to prevent attackers to vote for more
s with the same funds);
the input in[2], to declare they want to extend the last published update Confirmi1;
scriptPubKey at Index 1, which links the transaction to the previous confirmed request of the
subchain, pointed to by
. This link requires the arbiter signature. Note that this field always
points to the element immediately preceding it, regardless of whether it is consistent or not;
scriptPubKey of Index 2, which implements the incentive mechanism, i.e., the explicit confirmation
of the last consistent
of the subchain. Thus, the script rewards the meta-node
that has
voted for URjby κB plus the participant fee.
All transactions also specify a lockTime
, where
is the current Bitcoin block number and
a positive constant. This ensures that a transaction can be mined only after
blocks. In this way, even if
a transaction is signed by the arbiter and sent to miners before the others, it has the same probability
as the others of being appended to the blockchain. The overall general scheme of such a transaction is
finally depicted in Figure 4.
Figure 4. Encoding of an update request as a Bitcoin transaction.
To initialize the subchain, the arbiter puts a special
transaction on the Bitcoin blockchain,
formed as in Figure 5. This transaction secures a very small fraction of Bitcoins, which can be redeemed
Computation 2020,8, 67 18 of 22
through the arbiter signature. This value is then transferred to each subsequent update of the
subchain. In particular, observe that, since all the update requests in the same stage redeem the same
output (i.e., the arbiter’s one), exactly one of them can be mined, thus avoiding forks.
As seen in Section 3, the protocol runs in rounds of fixed duration
, where
is the time
length of the voting phase. Due to the mechanism for choosing the message to append to the subchain
among all the ones in the request pool, the protocol allows each application to publish at most one
transaction per Bitcoin block. This means that the Bitcoin block interval time (
10 min) necessarily
represents a lower bound for
. Furthermore, to monitor the arbiter behavior during protocol rounds,
all meta-nodes should share a coherent view of the request pool: a naive solution to achieve this goal,
similar to that used by Bitcoin, requires meta-nodes to broadcast their request pool lists at each stage.
For these reasons,
needs to be large enough to let each node synchronize the request pool with the
rest of the network. This leads to some minor issues, which will be discussed in Section 6.
Figure 5. Genesis transaction.
Note also that, since Bitcoin limits the size of such metadata to 80 bytes, this might not be enough
to store the data needed by platforms. To overcome this issue, meta-nodes can maintain a parallel
Distributed Hash Table (DHT), like, for instance, Kademlia [
]. Therefore, message data are not
stored in the blockchain:
scripts would contain only the corresponding message digests,
while the full content is stored in the DHT. The unique identifier of the Bitcoin transaction can then be
used as the key to retrieve such a message.
Finally, a subchain implemented through our protocol can be then summarized as in Figure 6.
Figure 6. Abstract scheme of the implemented subchain.
6. Conclusions and Further Research
In this work, we proposed an extended version of our protocol for consistently extending
subchains embedded in the Bitcoin blockchain. The main scientific contributions of this protocol
are: (i) a detailed overview of the context in which this research falls, as well as an extensive review
of the state-of-the-art in blockchain and smart contracts, with particular attention on Bitcoin; (ii) a
Computation 2020,8, 67 19 of 22
formal definition of the problem we addressed, where peer nodes running decentralized third-party
applications or smart contracts want to achieve consensus on the data produced by their execution,
hence consistently and permanently storing the outputs of this execution on the blockchain; (iii) a
description of the proposed protocol to cope with this issue, largely revised with respect to its original
version, along with the definition of its basic properties and peculiarities, and a concept implementation
in Bitcoin; and (iv) an in-depth analysis of the security and limitations of our protocol, carried out
by defining multiple real-world attack scenarios, as well as the ideal configuration of parameters
necessary to prevent adversaries from subverting its correct execution.
However, as outlined in previous sections, some aspects of the proposed protocol have limitations
that need to be further investigated. One interesting open problem concerns the role of the arbiter,
which, as said in Section 3.4, does not play the role of a trusted authority. Indeed, it is only required to
sign voted updates, while it would participate in the consensus mechanism (i.e., voting and validating
update requests) if it were a trusted authority. Since the request pool is public, meta-nodes can verify
that the arbiter actually signs all and only the voted for updates, thus detecting any misbehavior.
Moreover, we assumed the arbiter to be honest, to simplify our presentation. Nevertheless, if the
arbiter stops behaving honestly, nodes can easily fork the subchain and elect a new arbiter, but this
could cause a significant overhead in the execution of the protocol, opening the way to potential
denial-of-service attacks. For this reasons, we are currently working on an extension of the protocol
in which the arbiter can be safely and quickly replaced in case of misbehaviors. The extension relies
on some properties of Elliptic-Curve Cryptography (ECC) [
], and its intuition consists essentially
of rotating the key used by the arbiter to sign transactions, through a secret sharing mechanism that
involves the nodes of the network. Since this extension introduces additional points of vulnerability in
the protocol, a wider security analysis is needed.
A second open issue concerns the synchronization time of the request pool between nodes. This is
crucial, since a too high latency could slow down the protocol execution time, which may be a limitation
for some categories of decentralized applications (e.g., real-time ones). A possible approach to cope
with this issue is to make meta-nodes broadcast their voted updates and to keep a list of the other ones
(considering only those that satisfy the format of transactions, as in Section 5). A clear drawback of this
solution is that it can cause a significant increase in the number of packets exchanged by the network.
Our future research direction is focused on finding a more efficient alternative, and approaches based
on distributed shared memories [60,61] seem promising.
Overall, as far as we know, most third-party services that store data on the Bitcoin blockchain do
not adopt truly secure solutions for maintaining their subchain. Therefore, our protocol, widely revised
compared to its initial version, can represent a starting point for those applications that want to
offer a better level of reliability to their users, taking full advantage of the potential offered by the
Bitcoin blockchain.
Author Contributions:
Conceptualization, R.L., A.S.P., and R.S.; data curation, R.L., A.S.P., and R.S.;
formal analysis, R.L., A.S.P., and R.S.; methodology, R.L., A.S.P., and R.S.; resources, R.L., A.S.P., and R.S.;
supervision, R.L.; validation, R.L., A.S.P. and R.S.; writing, original draft, A.S.P. and R.S.; writing, review and
editing, R.L., A.S.P., and R.S. All authors have read and agreed to the published version of the manuscript.
This research is partially funded and supported by the “Bando ‘Aiuti per progetti di Ricerca
e Sviluppo’—POR FESR 2014-2020—Asse 1, Azione 1.1.3. Project IntelliCredit: AI-powered digital
lending platform”.
Conflicts of Interest: The authors declare no conflict of interest.
Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. Available online:
pdf (accessed on 1 January 2020).
Corbet, S.; Lucey, B.; Urquhart, A.; Yarovaya, L. Cryptocurrencies as a financial asset: A systematic analysis.
Int. Rev. Financ. Anal. 2019,62, 182–199.
Computation 2020,8, 67 20 of 22
Böhme, R.; Christin, N.; Edelman, B.; Moore, T. Bitcoin: Economics, Technology, and Governance.
J. Econ. Perspect. 2015,29, 213–238, doi:10.1257/jep.29.2.213.
Ren, W.; Hu, J.; Zhu, T.; Ren, Y.; Choo, K.K.R. A flexible method to defend against computationally
resourceful miners in blockchain proof of work. Inf. Sci. 2020,507, 161–171.
Clohessy, T.; Acton, T.; Rogers, N. Blockchain adoption: Technological, organisational and environmental
considerations. In Business Transformation through Blockchain; Springer: Berlin/Heidelberg, Germany, 2019;
pp. 47–76.
Babaioff, M.; Dobzinski, S.; Oren, S.; Zohar, A. On Bitcoin and red balloons. In Proceedings
of the ACM Conference on Electronic Commerce (EC), Valencia, Spain, 4–8 June 2012; pp. 56–73,
Eyal, I.; Sirer, E.G. Majority Is Not Enough: Bitcoin Mining Is Vulnerable. In Financial
Cryptography and Data Security; Springer: Berlin/Heidelberg, Germany, 2014, Volume 8437, pp. 436–454,
Hern, A. A History of Bitcoin Hacks. Available online:
mar/18/history-of-Bitcoin-hacks- alternative-currency (accessed on 2020).
Shalini, S.; Santhi, H. A survey on various attacks in Bitcoin and cryptocurrency. In Proceedings of the 2019
International Conference on Communication and Signal Processing (ICCSP), Chennai, India, 4–6 April 2019;
pp. 0220–0224.
Conti, M.; Kumar, E.S.; Lal, C.; Ruj, S. A survey on security and privacy issues of Bitcoin. IEEE Commun.
Surv. Tutor. 2018,20, 3416–3452.
Huynh, T.T.; Nguyen, T.D.; Tan, H. A Survey on Security and Privacy Issues of Blockchain Technology.
In Proceedings of the 2019 International Conference on System Science and Engineering (ICSSE), Dong Hoi,
Vietnam, 20–21 July 2019; pp. 362–367.
Faisal, T.; Courtois, N.; Serguieva, A. The evolution of embedding metadata in blockchain transactions.
In Proceedings of the 2018 International Joint Conference on Neural Networks (IJCNN), Rio de Janeiro,
Brazil, 8–13 July 2018; pp. 1–9.
Bentov, I.; Gabizon, A.; Mizrahi, A. Cryptocurrencies Without Proof of Work. In Financial
Cryptography Workshops; Springer: Berlin/Heidelberg, Germany, 2016; Volume 9604, pp. 142–157,
Kiayias, A.; Konstantinou, I.; Russell, A.; David, B.; Oliynykov, R. Ouroboros: A Provably Secure
Proof-of-Stake Blockchain Protocol. IACR Cryptol. EPrint Arch. 2016,2016, 889.
Bartoletti, M.; Lande, S.; Podda, A.S. A Proof-of-Stake Protocol for Consensus on Bitcoin Subchains.
In Financial Cryptography and Data Security; Brenner, M., Rohloff, K., Bonneau, J., Miller, A., Ryan, P.Y.,
Teague, V., Bracciali, A., Sala, M., Pintore, F., Jakobsson, M., Eds.; Springer International Publishing: Cham,
Switzerland, 2017; pp. 568–584.
Merediz-Solà, I.; Bariviera, A.F. A bibliometric analysis of Bitcoin scientific production. Res. Int. Bus. Financ.
2019,50, 294–305.
Giudici, G.; Milne, A.; Vinogradov, D. Cryptocurrencies: Market analysis and perspectives. J. Ind. Bus. Econ.
2020,47, 1–18.
Chen, Y.; Bellavitis, C. Decentralized finance: Blockchain technology and the quest for an open financial
system. Stevens Inst. Technol. Sch. Bus. Res. Pap. 2019.
Dwork, C.; Naor, M. Pricing via Processing or Combatting Junk Mail. In CRYPTO; Springer:
Berlin/Heidelberg, Germany, 1993; Volume 740, pp. 139–147.
20. Szabo, N. Formalizing and Securing Relationships on Public Networks. First Monday 1997,2.
Cai, W.; Wang, Z.; Ernst, J.B.; Hong, Z.; Feng, C.; Leung, V.C. Decentralized applications:
The blockchain-empowered software system. IEEE Access 2018,6, 53019–53033.
22. Bartoletti, M.; Zunino, R. Formal models of Bitcoin contracts: A survey. Front. Blockchain 2019,2, 8.
Andrychowicz, M.; Dziembowski, S.; Malinowski, D.; Mazurek, L. Fair Two-Party Computations via Bitcoin
Deposits. In Financial Cryptography Workshops; Springer: Berlin/Heidelberg, Germany, 2014, pp. 105–121,
Banasik, W.; Dziembowski, S.; Malinowski, D. Efficient Zero-Knowledge Contingent Payments in
Cryptocurrencies Without Scripts. In ESORICS; Springer: Berlin/Heidelberg, Germany, 2016; Volume 9879,
pp. 261–280, doi:10.1007/978-3-319-45741-3_14.
Computation 2020,8, 67 21 of 22
Bartoletti, M.; Zunino, R. Constant-deposit multiparty lotteries on Bitcoin. In Financial Cryptography
Workshops; Also available as IACR Cryptology ePrint Archive 955/2016; Springer: Cham, Switzerland, 2017.
Bentov, I.; Kumaresan, R. How to Use Bitcoin to Design Fair Protocols. In CRYPTO; Springer:
Berlin/Heidelberg, Germany, 2014; Volume 8617, pp. 421–439, doi:10.1007/978-3-662-44381-1_24.
Kiayias, A.; Zhou, H.; Zikas, V. Fair and Robust Multi-party Computation Using a Global
Transaction Ledger. In EUROCRYPT; Springer: Berlin/Heidelberg, Germany, 2016; pp. 705–734,
Kumaresan, R.; Bentov, I. How to Use Bitcoin to Incentivize Correct Computations. In Proceedings of
the 2014 ACM SIGSAC Conference on Computer and Communications Security, Scottsdale, AZ, USA, 3–7
November 2014; ACM: New York, NY, USA, 2014; pp. 30–41, doi:10.1145/2660267.2660380.
Kumaresan, R.; Moran, T.; Bentov, I. How to Use Bitcoin to Play Decentralized Poker. In ACM CCS; ACM:
New York, NY, USA, 2015; pp. 195–206, doi:10.1145/2810103.2813712.
Chen, L.Y.; Reiser, H.P. (Eds.) Distributed Applications and Interoperable Systems-17th IFIP WG 6.1 International
Conference, DAIS 2017, Held as Part of the 12th International Federated Conference on Distributed Computing
Techniques, DisCoTec 2017, Neuchâtel, Switzerland, June 19–22, 2017, Proceedings, Lecture Notes in Computer
Science; Springer: Berlin/Heidelberg, Germany, 2017; Volume 10320, doi:10.1007/978-3-319-59665-5.
Crary, K.; Sullivan, M.J. Peer-to-peer affine commitment using Bitcoin. In ACM PLDI; ACM: New York, NY,
USA, 2015; pp. 479–488, doi:10.1145/2737924.2737997.
Ruffing, T.; Kate, A.; Schröder, D. Liar, Liar, Coins on Fire!: Penalizing Equivocation By Loss of Bitcoins. In
ACM CCS; ACM: New York, NY, USA, 2015; pp. 219–230, doi:10.1145/2810103.2813686.
Tomescu, A.; Devadas, S. Catena: Efficient Non-equivocation via Bitcoin. In Proceedings of the IEEE Symp.
on Security and Privacy, San Jose, CA, USA, 22–26 May 2017.
Blockstore: Key-Value Store for Name Registration and Data Storage on the Bitcoin Blockchain. Available
online: (accessed on 1 January 2020).
Dermody, R.; Krellenstein, A.; Slama, O.; Wagner, E. CounterParty: Protocol Specification. Available online: (accessed on 1 January 2020).
Buterin, V. Ethereum: A next generation smart contract and decentralized application platform. Available
online: (accessed on 1 January 2020).
37. Bhargava, R. Blockchain Technology and Its Application: A Review. IUP J. Inf. Technol. 2019,15, 7–15.
Biswas, K.; Muthukkumarasamy, V. Securing smart cities using blockchain technology. In Proceedings
of the 2016 IEEE 18th International Conference on High Performance Computing and Communications;
Proceedings of the IEEE 14th international conference on smart city; IEEE 2nd international conference on
data science and systems (HPCC/SmartCity/DSS), Sydney, Australia, 12–14 December 2016; pp. 1392–1393.
Hukkinen, T.; Mattila, J.; Ilomäki, J.; Seppälä, T. A Blockchain Application in Energy; Technical Report; ETLA
Report; The Research Institute of the Finnish Economy (ETLA): Helsinki, Finland; 2017.
Podda, A.S.; Pompianu, L. An overview of blockchain-based systems and smart contracts for digital
coupons. In Proceedings of the 2020 IEEE/ACM 3rd International Workshop on Emerging Trends in
Software Engineering for Blockchain, WETSEB 2020, Seoul, Korea, 23–29 May 2019; IEEE: Seul, Korea, 2020.
Saia, R.; Carta, S.; Recupero, D.R.; Fenu, G. Internet of entities (IoE): A blockchain-based distributed
paradigm for data exchange between wireless-based devices. In Proceedings of the 8th International
Conference on Sensor Networks, Prague, Czech Republic, 26–27 January 2019; pp. 26–27.
Bartoletti, M.; Carta, S.; Cimoli, T.; Saia, R. Dissecting Ponzi schemes on Ethereum: Identification, analysis,
and impact. Future Gener. Comput. Syst. 2020,102, 259–277.
Carta, S.; Fenu, G.; Recupero, D.R.; Saia, R. Fraud detection for E-commerce transactions by employing a
prudential Multiple Consensus model. J. Inf. Secur. Appl. 2019,46, 13–22.
Saia, R.; Carta, S. Evaluating Credit Card Transactions in the Frequency Domain for a Proactive Fraud
Detection Approach. In Proceedings of the 14th International Conference on Security and Cryptography
(SECRYPT 2017), Madrid, Spain, 26–28 July 2017, pp. 335–342.
Saia, R.; Carta, S. A Linear-dependence-based Approach to Design Proactive Credit Scoring Models. In
Proceedings of the 8th International Joint Conference on Knowledge Discovery, Knowledge Engineering
and Knowledge Management (IC3K 2016), Porto, Portugal, 9–11 Nov 2016; Volume 1, pp. 111–120. ISBN
Computation 2020,8, 67 22 of 22
Jung, E.; Le Tilly, M.; Gehani, A.; Ge, Y. Data Mining-based Ethereum Fraud Detection. In Proceedings
of the 2019 IEEE International Conference on Blockchain (Blockchain), Atlanta, GA, USA, 14–17 July 2019;
pp. 266–273.
Li, J.; Gu, C.; Wei, F.; Chen, X. A Survey on Blockchain Anomaly Detection Using Data Mining Techniques.
In International Conference on Blockchain and Trustworthy Systems; Springer: Berlin/Heidelberg, Germany, 2019;
pp. 491–504.
Li, X.; Jiang, P.; Chen, T.; Luo, X.; Wen, Q. A survey on the security of blockchain systems. Future Gener.
Comput. Syst. 2017,107, 841–853.
Atzei, N.; Bartoletti, M.; Cimoli, T. A survey of attacks on ethereum smart contracts (sok). In International
Conference on Principles of Security and Trust; Springer: Berlin/Heidelberg, Germany, 2017; pp. 164–186.
Atzei, N.; Bartoletti, M.; Lande, S.; Yoshida, N.; Zunino, R. Developing secure Bitcoin contracts with BitML.
In Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and
Symposium on the Foundations of Software Engineering, Tallinn, Estonia, 26–30 August 2019; ACM: New
York, NY, USA, 2019; pp. 1124–1128.
Rouhani, S.; Deters, R. Security, performance, and applications of smart contracts: A systematic survey.
IEEE Access 2019,7, 50759–50779.
Liu, J.; Liu, Z. A survey on security verification of blockchain smart contracts. IEEE Access
7, 77894–77904.
Jansen, M.; Hdhili, F.; Gouiaa, R.; Qasem, Z. Do Smart Contract Languages Need to Be Turing Complete?
In International Congress on Blockchain and Applications; Springer: Berlin/Heidelberg, Germany, 2019,
pp. 19–26.
Making Sense of Blockchain Smart Contracts. Available online:
smart-contracts/ (accessed on 22 October 2017).
55. Bartoletti, M.; Bellomy, B.; Pompianu, L. A journey into Bitcoin metadata. J. Grid Comput. 2019,17, 3–22.
56. Available online: (accessed on 10 November 2017).
57. Dolev, D.; Yao, A. On the security of public key protocols. IEEE Trans. Inf. Theory 1983,29, 198–208.
Maymounkov, P.; Mazières, D. Kademlia: A Peer-to-Peer Information System Based on the XOR Metric.
In Workshop on Peer-to-Peer Systems (IPTPS); Springer: Berlin/Heidelberg, Germany, 2002; Volume 2429,
pp. 53–65, doi:10.1007/3-540-45748-8_5.
Miller, V.S. Use of Elliptic Curves in Cryptography. In Advances in Cryptology—CRYPTO ’85 Proceedings;
Williams, H.C., Ed.; Springer: Berlin/Heidelberg, Germany, 1986; pp. 417–426.
Cai, M.; Chervenak, A.; Frank, M. A Peer-to-Peer Replica Location Service Based on a Distributed Hash
Table. In Proceedings of the ACM/IEEE Conference on High Performance Networking and Computing.
IEEE Computer Society, Pittsburgh, PA, USA, 6–12 November 2004; p. 56, doi:10.1109/SC.2004.7.
Iyer, S.; Rowstron, A.; Druschel, P. Squirrel: A decentralized peer-to-peer web cache. In PODC; ACM:
New York, NY, USA, 2002; pp. 213–222.
2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access
article distributed under the terms and conditions of the Creative Commons Attribution
(CC BY) license (
... It is is aimed to protect the system against alterations and other fraudulent activities, since it usually requires a very high computation load, which involves resources that are generally not available for a single user or a small group of users. Nowadays, the literature offers other consensus mechanisms to effectively replace the PoW, such as, for instance, the Proof-of-Stake (PoS) [14][15][16]. Blockchain as a Distributed Ledger. The core of functionality of the blockchain is the possibility to exploit it as a Distributed Ledger Technology (DLT). ...
... While an encryption process represents a two-way function based on the encryption and decryption operations, hashing represents a one-way function that irreversibly transforms the source data used as input into a plain text output (i.e., the hash of data). Data Consistency: A problem that could emerge adopting the proposed paradigm is certainly related to the consistency of the data stored on the blockchain [16,63,64]. In this sense, excessive network latency or the presence of malicious nodes could compromise the chronological order of entities' registration. ...
... However, regarding the chronological order, we remark that even a delayed (or missed) registration can generate, in some specific scenarios, significant limitations in the use of the IoE paradigm. Notably, several protocols [15,16,67,68] have been proposed in the literature to guarantee the consistency of transaction publication, mainly through incentive mechanisms parallel to those of the main consensus mechanism of the blockchain used. Although theoretically allowed, integrating such protocols with the IoE paradigm, as they are fundamentally domain-independent, represents a significant future development of this work to its more practical conceptualization. ...
Full-text available
In the last decades, modern societies are experiencing an increasing adoption of interconnected smart devices. This revolution involves not only canonical devices such as smartphones and tablets, but also simple objects like light bulbs. Named as the Internet of Things (IoT), this ever-growing scenario offers enormous opportunities in many areas of modern society, especially if joined by other emerging technologies such as, for example, the blockchain. Indeed, the latter allows users to certify transactions publicly, without relying on central authorities or intermediaries. This work aims to exploit the scenario above by proposing a novel blockchain-based distributed paradigm to secure localization services, here defined as Internet of Entities (IoE). It represents a mechanism for the reliable localization of people and things, and it exploits the increasing number of existing wireless devices and the blockchain-based distributed ledger technology. Moreover, unlike most of the canonical localization approaches, it is strongly oriented towards the protection of the users' privacy. Finally, its implementation requires minimal efforts since it employs the existing infrastructures and devices, thus giving life to a new and wide data environment, exploitable in many domains, such as e-health, smart cities, and smart mobility.
... A Byzantine fault is a particularly tricky failure where a component, such as a server, can inconsistently appear both failed and functioning, presenting different symptoms to different observers. The problem then evolved to model malicious behaviour in distributed and multi-party protocols, with natural applications in distributed ledgers such as blockchains, alongside Proof of Work and Proof of Stake solutions [10,11,13]. ...
Full-text available
In this paper we present the Multidimensional Byzantine Agreement (MBA) Protocol, a leaderless Byzantine agreement protocol defined for complete and synchronous networks that allows a network of nodes to reach consensus on a vector of relevant information regarding a set of observed events. The consensus process is carried out in parallel on each component, and the output is a vector whose components are either values with wide agreement in the network (even if no individual node agrees on every value) or a special value ⊥\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$\bot $$\end{document} that signals irreconcilable disagreement. The MBA Protocol is probabilistic and its execution halts with probability 1, and the number of steps necessary to halt follows a Bernoulli-like distribution. The design combines a Multidimensional Graded Consensus and a Multidimensional Binary Byzantine Agreement, the generalization to the multidimensional case of two protocols presented by Micali et al. (SIAM J Comput 26(4):873–933, 1997; Byzantine agreement, made trivial, 2016). We prove the correctness and security of the protocol assuming a synchronous network where less than a third of the nodes are malicious.
... The common vulnerabilities of a smart contract are reentrancy vulnerability, replay attack, access restriction, and timestamp dependency. Many viewpoints, such as confidentiality, data integrity, availability, authorization, and non-repudiation, have been put forward in the security analysis [27][28][29][30][31]. ...
Full-text available
Online auctions are now widely used, with all the convenience and efficiency brought by internet technology. Despite the advantages over traditional auction methods, some challenges still remain in online auctions. According to the World Business Environment Survey (WBES) conducted by the World Bank, about 60% of companies have admitted to bribery and manipulation of the auction results. In addition, buyers are prone to the winner’s curse in an online auction environment. Since the increase in information availability can reduce uncertainty, easy access to relevant auction information is essential for buyers to avoid the winner’s curse. In this study, we propose an Online Auction Price Suggestion System (OAPSS) to protect the data from being interfered with by third-party programs based on Intel’s Software Guard Extensions (SGX) technology and the characteristics of the blockchain. Our proposed system provides a smart contract by using α-Sutte indicator in the final transaction price prediction as a bidding price recommendation, which helps buyers to reduce the information uncertainty on the value of the product. The amount spent on the smart contract in this study, excluding deployed contracts, plus the rest of the fees is less than US$1. Experimental results of the simulation show that there is a significant difference (p < 0.05) between the recommended price group and the actual price group in the highest bid. Therefore, we may conclude that our proposed bidder’s price recommendation function in the smart contract may mitigate the loss of buyers caused by the winner’s curse.
... A lot of papers published every year analyze different additional properties and applications of PoS protocols. Among others, we can note [20], where the authors combine PoS protocol with secure BTC blockchain to obtain a consistent subchain; [21] analyzes the liveness of sidechains, built on PoS, using a special multisignature; [22] discusses PoS with a digital signature scheme that prevents the validators from creating multiple blocks at the same height; [23] considers two cases of smart-contracts of blockchain with PoS; [24] is also devoted to the use of smart-contracts on a private Ethereum blockchain. These works analyze some special aspects of PoS security, but none of them give the answer on such a simple, practical, and specific question: how many confirmation blocks is enough to guaranty block stability with a given probability? ...
Full-text available
Two double-spend attack strategies on a proof-of-stake consensus are considered. For each strategy, the probability of its success is obtained, which depends on the network parameters and the number of confirmation blocks. These results can be used to define how many confirmation blocks a vendor should wait after a correspondent transaction before sending goods or services.
... To enhance the profitability and efficiency of e-commerce firms, blockchain technology is incorporated in SMP. Blockchain technology has helped enhance the payment speed and data transmission dependability and transparency of data transmission [24,25]. Blockchain helps to ensure that the information involved is anonymized and immutable. ...
Full-text available
With the innovation of embedded devices, the concept of smart marketplace came into existence. A smart marketplace is a platform on which participants can trade multiple resources, such as water, energy, bandwidth. Trust is an important factor in the trading platform, as the participants would prefer to trade with those peers who have a high trust rating. Most of the existing trust management models for smart marketplace only provide a single aggregated trust score for a participant. However, they lack the mechanism to gauge the level of commitment shown by a participant while trading a particular resource. This work aims to provide a fine-grained trust score for a participant with respect to each resource that it trades. Several parameters, such as resource availability, success rate, and turnaround time are used to gauge the participant’s level of commitment, specific to the resource being traded. Moreover, the effectiveness of the proposed model is validated through security analysis against ballot-stuffing and bad-mouthing attacks, along with simulationbased analysis and a comparison in terms of accuracy, false positive, false negative, computational cost and latency. The results indicate that the proposed trust model has 7% better accuracy, 30.13% lower computational cost and 31.74% less latency compared to the existing benchmark model.
... In this way, the system is able to store only the information relevant for the traffic analysis, guaranteeing better storage space occupation and a longer time of data archiving. Moreover, such a specification is also effective where the public authority intends to permanently certify digests of these data in a distributed context, for instance by exploiting metadata storage on public blockchains [25,27,39]. In the remainder of this section, the approach adopted and the detailed functioning of these two modules are outlined. ...
Nowadays, Smart Cities applications are becoming steadily popular, thanks to their main objective of improving people daily habits. The services provided by the aforementioned applications may be either addressed to the entire digital population or narrowed towards a specific kind of audience, like drivers and pedestrians. In this sense, the proposed paper describes a Deep Learning solution designed to manage traffic control tasks in Smart Cities. It involves a network of smart lampposts, in charge of directly monitoring the traffic by means of a bullet camera, and equipped with an advanced System-on-Module where the data are efficiently processed. In particular, our solution provides both: i) a risk estimation module, and ii) a license plate recognition module. The first module analyses the scene by means of a Faster R-CNN, trained over an ad-hoc set of synthetically videos, to estimate the risk of potential traffic anomalies. Concurrently, the license plate recognition module, by leveraging on YOLO and Tesseract, is active for retrieving the plate number of the vehicles involved. Preliminary experimental findings, from a prototype of the solution applied in a real-world scenario, are provided.
... Moreover, recently, some security features offered by techniques typically exploited in other areas have been started to be taken into consideration for facing network security tasks, such as, for instance, those leveraging on the blockchain primitives (Vieira et al., 2020;Longo et al., 2020). ...
Conference Paper
Full-text available
Anyone working in the field of network intrusion detection has been able to observe how it involves an ever-increasing number of techniques and strategies aimed to overcome the issues that affect the state-of-the-art solutions. Data unbalance and heterogeneity are only some representative examples of them, and each misclassification operates in this context could have enormous repercussions in different crucial areas such as, for instance, financial, privacy, and public reputation. This happens because the current scenario is characterized by a huge number of public and private network-based services. The idea behind the proposed work is decomposing the canonical classification process into several sub-processes, where the final classification depends on all the sub-processes results, plus the canonical one. The proposed Training Data Decomposition (TDD) strategy is applied on the training datasets, where it applies a decomposition into regions, according to a defined number of events and features. The ratio that leads this process is related to the observation that the same network event could be evaluated in a different manner, when it is evaluated in different time periods and/or when it involves different features. According to this observation, the proposed approach adopts different classification models, each of them trained in a different data region characterized by different time periods and features, classifying the event both on the basis of all model results, and on the basis of the canonical strategy that involves all data.
... A Byzantine fault is a particularly tricky failure where a component, such as a server, can inconsistently appear both failed and functioning, presenting different symptoms to different observers. The problem then evolved to model malicious behaviour in distributed and multi-party protocols, with natural applications in distributed ledgers such as blockchains, alongside Proof of Work and Proof of Stake solutions [10,11,13]. ...
Full-text available
In this paper we will present the Multidimensional Byzantine Agreement (MBA) Protocol, a leaderless Byzantine agreement protocol defined for complete and synchronous networks that allows a network of nodes to reach consensus on a vector of relevant information regarding a set of observed events. The consensus process is carried out in parallel on each component, and the output is a vector whose components are either values with wide agreement in the network (even if no individual node agrees on every value) or a special value $\bot$ that signals irreconcilable disagreement. The MBA Protocol is probabilistic and its execution halts with probability 1, and the number of steps necessary to halt follows a Bernoulli-like distribution. The design combines a Multidimensional Graded Consensus and a Multidimensional Binary Byzantine Agreement, the generalization to the multidimensional case of two protocols by Micali and Feldman. We prove the correctness and security of the protocol assuming a synchronous network where less than a third of the nodes are malicious.
Blockchain technology is suited to the high-quality development of the digital economy in addressing privacy and data security issues. This study explores the synergistic mechanism of the following six factors from three dimensions based on the Technology-Organization-Environment (TOE) framework theory with a fuzzy set qualitative comparative analysis (fs/QCA) method: technology, organization, and environment, namely, Blockchain service capability, Blockchain knowledge accumulation, government attention allocation, government funding support, industry carrying capacity and blockchain technology R&D environment, on the quality of the digital economy of 43 cities in China. The conclusions are as follows: (1) the absence of government funding regarding the blockchain domain is a condition contributing to the absence of high urban digital economy quality; (2) there are three driving configurations for the high-quality urban digital economy in the blockchain technology adoption perspective, which are as follows: knowledge-industry driven, government-service driven, and R&D-service driven; (3) there is one driving configuration for the absence of high urban digital economy quality, namely the knowledge-R&D-funding-inhibiting type. The relevant policy implications can provide theoretical references for local governments to develop the digital economy with the help of blockchain technology.
The cryptocurrency market, which has a rapidly growing market size, attracts the increasing attention of individual and institutional investors. While this highly volatile market offers great profit opportunities to investors, it also brings risks due to its sensitivity to speculative news and the unpredictable behaviour of major investors that can cause unsual price movements. In this paper, we argue that rapid and high price fluctuations or unusual patterns that occur in this way may negatively affect the functionality of technical signals that constitute a basis for feature extraction in a machine learning (ML)-based trading system and this may cause the generalization of the model to deteriorate. To address this problem, we propose an end-to-end ML-based trading system including a time series outlier detection module that detects the periods in which unusual price formations are observed. The training of the classification algorithms for the price direction prediction task was performed on the remaining data. We present the results related to the accuracy of the classification models as well as the simulation results obtained using the proposed system for real time trading on the historical data. The findings showed that the outlier detection step significantly increases return on investment for the machine learning-based trading strategies. Besides, the results showed that during the highly volatile periods the trading system becomes more profitable compared to the baseline model and buy&hold strategy.
Conference Paper
Full-text available
Among the accessory applications of the blockchain, the idea of using it as an immutable register for tracking and certifying documents is recently gaining interest in research and industry. The problems of traceability, non-counterfeiting and unique usage of digital coupons fall within this area; many couponing platforms are hence exploring the possibility of addressing the above limitations with blockchain technologies. In view of the foregoing, in this work we analyse and compare several blockchain-based couponing systems. To do so, we first propose a general schema of digital coupon and define the desirable properties of a couponing system. Then, we select a sample of these systems and we examine them, describing their design choices and summarizing their relevant properties. Finally, we inspect their code and study how the notion of couponing system is interpreted in their smart contracts. We also highlight their distinctive features and relevant implementation solutions. We conclude by discussing what emerged from our analysis and proposing some possible future investigations.
Full-text available
Although Bitcoin is mostly used as a decentralized application to transfer cryptocurrency, over the last 10 years there have been several studies on how to exploit Bitcoin to execute smart contracts. These are computer protocols which allow users to exchange bitcoins according to complex pre-agreed rules. Some of these studies introduce formal models of Bitcoin contracts, which specify their behavior in non-ambiguous terms, in some cases providing tools to automatically verify relevant contract properties. In this paper, we survey the formal models proposed in the scientific literature, comparing their expressiveness and applicability in the wild.
Conference Paper
Full-text available
We present a toolchain for developing and verifying smart contracts that can be executed on Bitcoin. The toolchain is based on BitML, a recent domain-specific language for smart contracts with a computationally sound embedding into Bitcoin. Our toolchain automatically verifies relevant properties of contracts, among which liquidity, ensuring that funds do not remain frozen within a contract forever. A compiler is provided to translate BitML contracts into sets of standard Bitcoin transactions: executing a contract corresponds to appending these transactions to the blockchain. We assess our toolchain through a benchmark of representative contracts.
Full-text available
Ponzi schemes are financial frauds which lure users under the promise of high profits. Actually, users are repaid only with the investments of new users joining the scheme: consequently, a Ponzi scheme implodes soon after users stop joining it. Originated in the offline world 150 years ago, Ponzi schemes have since then migrated to the digital world, approaching first the Web, and more recently hanging over cryptocurrencies like Bitcoin. Smart contract platforms like Ethereum have provided a new opportunity for scammers, who have now the possibility of creating "trustworthy"' frauds that still make users lose money, but at least are guaranteed to execute "correctly"'. We present a comprehensive survey of Ponzi schemes on Ethereum, analysing their behaviour and their impact from various viewpoints.
A smart contract is an agreement between two or more parties, which is executed by the computer code. The code does the execution without giving either party the ability to back out, so it ensures the trustless execution. The smart contract is one of the most important features in blockchain applications, which implements trusted transactions without third parties. However, with the rapid development, blockchain smart contracts have also exposed many security problems, and some attacks caused by contract vulnerabilities have led to terrible losses. In order to better deal with such dilemma, making a comprehensive survey about the security verification of blockchain smart contracts from major scientific databases is quite indispensable. Even though the significance of studying security verification of blockchain smart contracts is evident, it is really fresh yet. The major contributions of our survey work come from three aspects. First, after retrieving all-sided research studies, we select 53 most related papers to show the state-of-the art of this topic, where 20 papers focus on dealing with security assurance of blockchain smart contracts, and 33 papers focus on the correctness verification of blockchain smart contracts. Second, we propose a taxonomy toward the topic of security verification of blockchain smart contracts and discuss the pros and cons of each category of related studies. Third, through in-depth analysis of these studies, we come to know that the correctness verification of smart contracts based on the formal method has already become the more significant and more effective method to validate whether a smart contract is credible and accurate. So, we further present representative studies of formal verification of smart contracts in detail to demonstrate that using a formal method to validate blockchain smart contracts must have a promising and meritorious future.
With the more and more extensive application of blockchain, blockchain security has been widely concerned by the society and deeply studied by scholars, of which anomaly detection is an important problem. Data mining techniques, including conventional machine learning, deep learning and graph learning, have been concentrated for anomaly detection in the last few years. This paper presents a systematic survey of the blockchain anomaly detection results using data mining techniques. The anomaly detection methods are classified into 2 main categories, namely universal detection methods and specific detection methods, which contain 8 subclasses. For each subclass, the corresponding research are listed and compared, presenting a systematic and categorized overview of the current perspectives for blockchain anomaly detection. In addition, this paper contributes in discussing the advantages and disadvantages for the data mining techniques employed, and suggesting future directions for anomaly detection methods. This survey helps researchers to have a general comprehension of the anomaly detection field and its application in blockchain data.
The papers in this special issue focus on the emerging phenomenon of cryptocurrencies. Cryptocurrencies are digital financial assets, for which ownership and transfers of ownership are guaranteed by a cryptographic decentralized technology. The rise of cryptocurrencies’ value on the market and the growing popularity around the world open a number of challenges and concerns for business and industrial economics. Using the lenses of both neoclassical and behavioral theories, this introductory article discusses the main trends in the academic research related to cryptocurrencies and highlights the contributions of the selected works to the literature. A particular emphasis is on socio-economic, misconduct and sustainability issues. We posit that cryptocurrencies may perform some useful functions and add economic value, but there are reasons to favor the regulation of the market. While this would go against the original libertarian rationale behind cryptocurrencies, it appears a necessary step to improve social welfare.
Blockchain is well known as a decentralized and distributed public digital ledger, and is currently used by most cryptocurrencies to record transactions. One of the fundamental differences between blockchain and traditional distributed systems is that blockchain’s decentralization relies on consensus protocols, such as proof of work (PoW). However, computation systems, such as application specific integrated circuit (ASIC) machines, have recently emerged that are specifically designed for PoW computation and may compromise a decentralized system within a short amount of time. These computationally resourceful miners challenge the very nature of blockchain, with potentially serious consequences. Therefore, in this paper, we propose a general and flexible PoW method that enforces memory usage. Specifically, the proposed method blocks computationally resourceful miners and retains the previous design logic without requiring one to replace the original hash function. We also propose the notion of a memory intensive function (MIF) with a memory usage parameter k (kMIF). Our scheme comprises three algorithms that construct a kMIF Hash by invoking any available hash function which is not kMIF to protect against ASICs, and then thwarts the pre-computation of hash results over a nonce. We then design experiments to evaluate memory changes in these three algorithms, and the findings demonstrate that enforcing memory usage in a blockchain can be an effective defense against computationally resourceful miners.