# Resilience Analysis for Double Spending via Sequential Decision Optimization
## 1 Introduction  
In recent years, concepts originating from the blockchain idea have gained popularity. Their software realizations are based on a mixture of traditional techniques (peer-to-peer networking, data encryption) and modern concepts (consensus protocols). Digital currencies represent assets of these systems, their transactions are written and kept in an electronic ledger as a part of operation of the blockchain system. Their main difference from a traditional financial system is that the assets (crypto-currencies) are not issued and supervised by a central authority, but by joint efforts of a network consisting of independent computers, all running the same/similar software. Such a network searches for consensus which yields a common version of the ledger shared by all participants. The consensus is reached in terms of a process, which is called _mining_ and is usually backed by economic incentives. Proponent of blockchain systems argue that they can achieve the same level of certainty and security as those governed by a central authority at significantly lower costs. In fact, (the author thanks an anonymous referee), costs can be lower in some cases for the users, because of the lack of the service provider fees. However, in general, blockchain systems are more resource and energy consuming than centralized ones. Still, in return they provide decentralization that is the \"splitting of trust\" among a set of entities (possibly the entire network). Furthermore, due to the distributed, decentralized, andhomogeneous architecture of the network, a blockchain system can reach a high level of stability due to data redundancy and hard/software replicability. Following a mining process, all network participants append, validate, and mutually agree on a common version of the data history, which is usually referred to as the _blackchain ledger_. Some authors consider the invention of mining as a real break-through which has solved a long-standing consensus problem in computer science, although this development must be considered in the context of notable research advances in consensus protocols like Byzantine fault tolerant protocols. There is also criticism of this approach. A critical point is that to reach a consensus, some real physical resources/efforts must be spent or at least allocated. For instance, the traditional Bitcoin protocol requires participants to solve cryptographic puzzles with real consumption of computing power and energy, in terms of the _proof of work_ (PoW). Other blockchain systems avoid resource consumption and require a temporary allocation of diverse resources, for instance the ownership of the underlying digital assets (proof of stake), or their spending (proof of burn). Furthermore, commitment of storage capacity (proof of storage), or a diverse combination of resource allocation/consumption are also used. Let us briefly elaborate on the proof of work whose details can be found in an excellent book by [PERSON]: \"Mastering Bitcoin\" [1]. We focus on the Bitcoin protocol which was initiated by [2], with refinement on the double-spending problem by [3], and later in [4] with further considerations addressing propagation delay in [5]. In this framework, the ledger consists of a chain of blocks and each block contains valid transactions. The nodes compete to add a new block to the chain, and doing so, each node attempts to collect transactions and to solve a mathematical puzzle. Once this puzzle is solved, it is made public to other nodes. This protocol also prescribes that if a peer node reports a completed block, then it must be verified, and if this block is valid, it must be attached to the chain, all uncompleted blocks shall be abandoned and a new block continuing the chain must be started. However, even following these rules, the chain forks regularly, which results in different nodes working on different branches. To reach a consensus in such cases, the protocol prescribes that a branch with shorter length must be abandoned as soon as a longer branch becomes known.