Transaction Fee Reduction in Coinblesk. Sebastian Stephan Baden, Switzerland Student ID:

Transcription

1 MASTER THESIS Communication Systems Group, Prof. Dr. Burkhard Stiller Transaction Fee Reduction in Coinblesk Sebastian Stephan Baden, Switzerland Student ID: Supervisor: Thomas Bocek Date of Submission: May 17, 2017 University of Zurich Department of Informatics (IFI) Binzmühlestrasse 14, CH-8050 Zürich, Switzerland ifi

2 Master Thesis Communication Systems Group (CSG) Department of Informatics (IFI) University of Zurich Binzmühlestrasse 14, CH-8050 Zürich, Switzerland URL:

3 Abstract Während das Bitcoin Netzwerk an seine Kapazitätsgrenzen stösst, haben Transaktionsgebühren einen neuen Höchstwert erreicht. Stand Mai 2017 kostet eine durchschnittliche Bitcoin Transaktion mittlerweile über 1 US Dollar. Dies macht Bitcoin zur einer ungeeigneten Währung, insbesondere für häufige kleinere Zahlungen. In dieser Arbeit wird ein neues Bezahlsystem vorgestellt, welches sogenannte micropayment channels benützt. Kleinere Beträge werden über einen zentralen Server geleitet. Dieses Modell wurde in Coinblesk, einem mobilen Bezahlsystem der Universität Zürich umgesetzt. Eine Simulation zeigt, dass es damit möglich ist Transaktionsgebühren für kleinere Zahlungen um 96% zu reduzieren. Zusätzlich konnte eine existierede Sicherheitslücke im alten System behoben werden. Recently transaction fees in the bitcoin network have risen to a new all-time high, as the network is closing in on its capacity limit. A median transaction as of May 2017 costs more than one US dollar, making it unfeasible to use bitcoin for everyday payments. In this thesis a new payment mechanism is presented, which uses micropayment channels to route payments over a central server which reduces transaction fees for smaller payments. The mechanism is implemented in Coinblesk, a mobile bitcoin payment solution developed at the University of Zurich. An evaluation shows that the new implementation reduces transaction fees by 96% for smaller payments and removes a previously existing security vulnerability based on transaction malleability. i

4

5 Acknowledgments I want to express my sincerest gratitude to my supervisor Dr. Thomas Bocek for his tireless support during this thesis. With his immense knowledge and passion in the field of cryptocurrencies, he was able to help me during all times of research and writing. Besides my advisor I would also like to thank Prof. Dr. Burkhard Stiller and the members of the Communication Systems Research Group for giving me the opportunity to work on such an interesting topic. Last but not least I would like to thank my friends and family for their constant support and encouragement. iii

6

7 Contents Abstract i Acknowledgments iii 1 Introduction Motivation Description of Work Thesis Outline Background and Related Work Transaction Fees in the Bitcoin Network Transaction Malleability Protocol Changes in Bitcoin Bitcoin Unlimited Segregated Witness Micropayment Channels Setup Micro Payments The Lightning Network Bi-directional Payment Channels Hashed Timelock Contracts Adoption v

8 vi CONTENTS 2.6 Coinblesk Payment Mechanism Problems Design Architecture Model Protocol User Operations Server Operations Transaction Fees Implementation Refactoring Spring Boot Token Security Signed Requests Data Model REST Endpoints /virtual-payment /payment /payout Offline Payments Testing Full Integration Test Load Test

9 CONTENTS vii 5 Evaluation Transaction Fees Features Summary and Conclusions 39 Abbreviations 43 List of Figures 43 List of Tables 45 A Installation Guidelines 49 B Contents of the CD 53

10

11 Chapter 1 Introduction Virtual currencies are on the rise. The global market capitalization of all cryptocurrencies has more than doubled to over USD 55 billion in the last two months alone 1. While new cryptocurrencies seem to emerge on a weekly basis, bitcoin remains the undisputed leader with a 56% market share, recently reaching an all-time high value of USD Yet the numbers are deceiving: as the number of bitcoin transactions rises, the network is pushed to its limit [22]. Transactions on average take more than three hours to confirm 2. Meanwhile the pool of unconfirmed transactions grows larger and larger. This has pushed transaction fees to unseen heights from a few cents back in 2015 to more than one US dollar as of May While this not be a problem for larger transactions, using bitcoin to buy your daily coffee becomes a rather expensive choice. The search for a solution to the scalability problem is ongoing. Developers and miners, however, seem unable to agree on how the future of bitcoin should look like. While one side pushes for more radical changes to the protocol, others advocate a simple increase of the block size. In the meantime a solution is needed that makes bitcoin again a viable choice for smaller everyday payments. 1.1 Motivation Coinblesk is a mobile bitcoin payment solution developed at the University of Zurich [2]. While originally intended to be used as a payment system for a cafeteria, it has seen many improvements over the last years [31] [10] and can now be used as a generalpurpose bitcoin wallet and payment solution. Coinblesk supports trust-less, zero-confirmation transactions and mobile payments over Near Field Communication (NFC) and bluetooth, making it a great fit for a point-of-sale system. However, the increasing transaction fees become a problem in such a scenario, as they make up a large portion 1 Source: coinmarketcap.com as of May 15, Source: blockchain.info as of May 15,

12 2 CHAPTER 1. INTRODUCTION of each payment. Therefore the main goal of this thesis is to find and implement a suitable solution to the problem of increased transaction fees in Coinblesk, while balancing trade-offs between cost, trust and complexity. Additionally, as the codebase of Coinblesk has become somewhat outdated, libraries should be upgraded to their latest versions and a general refactoring of the codebase should be performed to improve the quality and maintainability of the project for future iterations. 1.2 Description of Work This thesis covers the design, implementation and evaluation of a new payment system for Coinblesk, which reduces transaction fees in an everyday payment scenario. Existing concepts such as micropayment channels are explained and relevant current protocol change proposals introduced. A new model for instant payments is developed and compared against the previous version. The thesis also covers the refactoring of the existing codebase to improve the quality, stability and usability of the whole system. 1.3 Thesis Outline The remainder of this thesis is structured as follows. Chapter 2 provides background information on the scalability and security issues of bitcoin. Additionally, pending protocol changes and existing solutions to the problem are investigated. In Chapter 3 a new protocol for payments in Coinblesk is designed, based on the previous findings. Chapter 4 explains the implementation details of the new payment model. The new system is tested and evaluated against the previous version of Coinblesk in Chapter 5 and Chapter 6 concludes the thesis and outlines future work.

13 Chapter 2 Background and Related Work 2.1 Transaction Fees in the Bitcoin Network Transactions in the bitcoin network have to be validated and confirmed by miners. Miners take all unconfirmed transaction and group them into blocks. This process is intentionally made resource intensive and costs money in terms of computing power and electricity. The incentive to mine comes in the form of a coinbase transaction. This transaction is included by the miner and has no connected inputs, but sends a sum to an address chosen by the miner. This sum is defined to be a fixed block reward plus the sum of all transaction fees included in a block. The block reward is a fixed value of coins defined in the bitcoin protocol. At the beginning of the network 2009 it is set to 50 bitcoin and is halved every blocks or roughly every 4 years. As of May 2017 this reward is currently at 12.5 BTC. The block reward acts as a controlled money supply to the network. The halving of the block reward will move the incentive for mining over time from the block reward to transaction fees. The fee of a transaction is defined as the difference in value between inputs and outputs. This amount is set by the creator of a transaction. Miners have a right to collect the sum of all fees in a block by adding it to the coinbase transaction. Since blocks are by design of the protocol limited to 1 MB, miners optimize their profit by prioritizing transactions with a higher fee per byte. Fees have not played a large role in the beginning of bitcoin. As shown in Figure 2.1, besides a large exchange rate driven spike in 2014, they have risen almost constantly since One major reason is the increase in transaction volume. As of May 2017, almost 100% of all blocks have reached the 1 MB limit, while around 100 MB of transactions are constantly waiting to be included in a block. Paying a low fee can result in a transaction to take a long time to be confirmed. Therefore users include higher fees if they need a transaction to be included in the next block. As of May 2017 the fee 3

14 4 CHAPTER 2. BACKGROUND AND RELATED WORK 0.5 Transaction fee Full blocks ( 1MB) USD % full blocks Figure 2.1: Transaction fees and full blocks over time 0 needed to guarantee an inclusion in the next block is around 240 satoshis per byte 1. One satoshi is defined as one hundred millionth of a bitcoin. For the average transaction size of 226 bytes this means a required fee of satoshis or one US dollar Transaction Malleability Each transaction in the bitcoin network with the exception of the coinbase transaction uses the value of previous transaction outputs as inputs. The output being spent is referenced by the identifier (ID) of the containing transaction and an index. The ID is calculated by applying a the hash algorithm SHA-256 twice over all parts of the transaction. Transaction malleability refers to the attack, where parts of a transaction are changed possibly by a third party without invalidating the transaction itself, but causing the ID to change. This is possible from a broadcast until a transaction is included in a block. A modified transaction remains valid with all general properties, such as how many coins are moved to where. The changed ID, however, can be problematic, as depending transactions which use the ID in their inputs will be invalidated. Transaction malleability gained notoriety in February 2014, when the major bitcoin exchange Mt- Gox suspended trading, claiming that 850,000 bitcoins were stolen due to a malleability attack [11]. 1 Source: bitcoinfees.21.co as of May 11, Source: bitstamp.net as of May 11, 2017

15 2.3. PROTOCOL CHANGES IN BITCOIN 5 One attack vector of malleability is caused by the usage of the Elliptic Curve Digital Signature Algorithm or short ECDSA in the signatures of bitcoin transactions. The ECDSA signature consists of a tuple of integers (r, s) {1, N 1} 2 where N is a constant and defines the order of the used curve [14]. ECDSA signatures are inherently malleable, since replacing (r, s) with (r, s (mod N)) produces an equally valid signature [1]. This replacement can be performed by any relaying node or miner. Bitcoin Core nodes since version enforces the use of the lower s value when relaying or mining transactions [6]. However, transactions with high s values are still accepted when they are received in a block, making it possible for miners to change transaction IDs at will. Recently this could be observed in the network when two blocks mined by the mining pool BitClub contained modified transactions with high s values [3]. 2.3 Protocol Changes in Bitcoin Since the release of the original white paper by Satoshi Nakamoto in 2009 [19], bitcoin has undergone several protocol changes. Due to the decentralized design of the system, those changes come with additional challenges: it is important that at any time a majority of all users agree on the same set of rules. Otherwise the system might end up in a state, where some blocks are accepted by certain users, while being rejected by others, causing the block chain to fork into two different chains. The conventional process to implement a change in the bitcoin reference implementation Bitcoin Core [5] is to submit a standardized Bitcoin Improvement Proposal (BIP) [9] document, specifying the suggested changes. These proposals are then discussed openly with the help of mailing lists. After enough consensus is reached, BIPs change their status to from draft to final or active. Accepted BIPs are included in the next release of the Bitcoin Core client. Some changes that require consensus from miners are only activated when sufficient support from miners is reached. This again tries to reduce the risk of a forked chain. By setting predefined bits in the version header of a block, miners can voice their support for currently drafted proposals[32]. When a 95% majority of all blocks in a given 2016 block window are mined with support for a proposal, it will activate automatically. Since the bitcoin software is open-source and free, it is also possible to fork the main source repository and release a modified version as a separate client. This client can then also take part in the same network with other bitcoin implementations. The benefit of this approach is that it does not require the endorsement of the maintainers of the original bitcoin repository. However, it requires that a majority of users switch to the alternative client. Currently there exist three forks of Bitcoin Core, namely Bitcoin XT [8], Bitcoin Classic [4] and Bitcoin Unlimited [7]. Of those forks, so far none have gained the necessary support to impose protocol changes on the rest of the bitcoin network.

16 6 CHAPTER 2. BACKGROUND AND RELATED WORK 50 SegWit Bitcoin Unlimited 40 Support % Oct 2016 Dec 2016 Feb 2017 Apr 2017 Figure 2.2: Miner support for SegWit and Bitcoin Unlimited Bitcoin Unlimited Bitcoin Unlimited is a fork of the original Bitcoin Core client and was released in January It aims to solve the scalability issues of the current implementation of Bitcoin Core by increasing the maximum block size. In Bitcoin Unlimited the fixed block size limit of 1 MB is replaced by three configuration parameters, which can be set by all nodes running Bitcoin Unlimited. The Maximum Generation (MG) parameter defines the maximum size of produced blocks and is set by the miners. The default value of MG is 1 MB, to achieve compatibility with the current majority of Bitcoin Core clients. However, it is meant to be increased over time. The Excessive Block Size (EB) defines the size of blocks that nodes accept. Blocks exceeding this limit are ignored and not relayed. The third option is the Acceptance Depth (AD), which sets the maximum depth of blocks, after which the EB is ignored and overruled. This implements a strategy in which consensus on the block size limit can be found by all nodes in the network. Similar to the free market theory, Bitcoin Unlimited supporters believe that this should lead to a scalable and healthy block size equilibrium [25]. Bitcoin Unlimited has gained more popularity in the last year. Currently around 40% of all miners (see Figure 2.2) and roughly 10% of all nodes 3 run the Bitcoin Unlimited client. The produced blocks by the Bitcoin Unlimited miners are still capped at 1 MB, but when enough miners and nodes switch to Bitcoin Unlimited, this is expected to 3 Source: coin.dance as of May 15, 2017

17 2.3. PROTOCOL CHANGES IN BITCOIN 7 increase. However it is unclear when and if Bitcoin Unlimited will become the new de facto client. Even if a big majority of miners use Bitcoin Unlimited, mining a block with more than 1 MB could be infeasible, as the incompatibility with Bitcoin Core would most likely cause a fork in the chain and have a negative impact on the bitcoin network as a whole Segregated Witness Segregated Witness or short SegWit is a proposal to the bitcoin protocol made by Lombrozo, Lau, and Wuille in SegWit is split into different proposals from BIP , covering different aspects of the change, such as activation design, network protocol changes and API specification. SegWit is designed to be a backwards compatible change and is thus labeled as a soft-fork. SegWit aims to solve multiple issues with the current bitcoin protocol design. The core concept of SegWit is to move the transaction signatures from the transaction inputs into a separate structure called the witness, which will be located towards the end of a transaction (see Figure 2.3). The witness is not included when hashing the transaction and therefore does not influence the transaction ID. This solves many issues related to malleability as discussed in section 2.2. Further, SegWit changes the maximum block size to 4 MB with a different calculation method. Every non-witness byte is counted with a weight of four and witness data is weighted with a factor of one: size(data_witness) + 4 size(data_nonwitness) 4MB (2.1) This block size limit change is backwards compatible, as a non-upgraded nodes will receive a block without witness data, which can according to equation 2.1 be at most 1 MB in size. The total of 4 MB can never be reached, as a block consists of other non-signature data such as the block header, version bytes and transaction outputs. In practice a block containing mostly transactions in the new SegWit format is estimated be grow up to 2 MB [26]. The deployment of SegWit is defined by BIP 9 [32] and needs 95% of all blocks in a 2016 block period to signal for its activation. After that limit is reached, it will automatically become active in the next 2016 block period. However, so far SegWit has been met with resistance from mining companies who favor the deployment of Bitcoin Unlimited s proposed changes. Currently as of May 2017 only 30% of all blocks signal support (see Figure 2.2) and it is unlikely that SegWit will reach the 95% goal. Miners might fear a declining income from transaction fees, as the activation of SegWit would allow easier off-chain payment solutions. On the alternative cryptocurrency Litecoin, which is similar to Bitcoin, SegWit was recently successfully activated [13]. It remains to be seen whether this has any impact for bitcoin.

18 8 CHAPTER 2. BACKGROUND AND RELATED WORK Transaction Version 4 bytes Input Counter 4 bytes List of Inputs Prev Hash 32 bytes Index 4 bytes Signature length 1-9 bytes Signature (variable length) Sequence no. 4 bytes Output Counter 4 bytes List of Outputs Value 8 bytes Length of pubkeyscript 1-9 bytes pubkeyscript var length Locktime 4 bytes SegWit Transaction Version 4 bytes Input Counter 4 bytes List of Inputs Prev Hash 32 bytes Index 4 bytes Signature length 0x00 1 byte Sequence no. 4 bytes Output Counter 4 bytes List of Outputs Value 8 bytes Length of pubkeyscript 1-9 bytes pubkeyscript var length Witness data (variable length) Locktime 4 bytes Figure 2.3: Comparison of a standard transaction and a SegWit transaction. Shaded blocks are part of the transaction hash. 2.4 Micropayment Channels Each transaction broadcast needs to be relayed through the network and then mined in a block. This takes a considerable time and has recently become costly due to high transaction fees, as discussed in Section 2.1. For larger payments this might not be a problem, but for smaller, transactions this is very inefficient. In cases where small payments are made frequently to the same entity, a micropayment channel can be used to decrease costs and processing time. A micropayment channel is a construct using bitcoin transactions, which allows two parties to exchange bitcoin securely in an incremental way, without needing to broadcast each payment to the network. Instead of creating and broadcasting a transaction for each payment, a single transaction is updated for each payment and the broadcast is deferred to a later time. This construct can be made in such a way that it does not require trust between both parties Setup In the initial step of creating a micropayment channel, the sending entity transfers some funds to an address that both the sender and receiver control. These types of

19 2.4. MICROPAYMENT CHANNELS 9 1) Create funding Tx T1 2-of-2 2) Create time-locked refund Tx T2 Network 5) Broadcast T1 Sender 3) Send T2 for signing 4) Return signed T2 Receiver Figure 2.4: Micropayment channel setup using refund transaction addresses are known as MultiSig addresses. A n-of-m MultiSig address needs n out of m signatures to be spendable. In the case of a micropayment channel, a 2-of-2 address is used, meaning that neither the sender nor the receiver can spend the money on their own. The sender sets up the channel by sending money via a funding transaction to the MultiSig address. However, there must be some mechanism that allows him to get that money back eventually. Otherwise the money might be lost forever, should the receiver disappear. It would also be possible for the receiver to extort money from the sender by threatening to not sign any transactions from the newly created address. There are several ways to avoid this scenario. One solution is to use a refund transaction. This process is illustrated in Figure 2.4. Initially, a funding transaction T1 is created by the sender (1), which he keeps secret. He then creates a refund transaction which connects to the funding transaction and sends all coins in the 2-of-2 MultiSig address back to himself (2). This refund transaction additionally has a time lock, which prevents a broadcast before some time in the future. This is possible by using the nlocktime field in a transaction [20]. The refund transaction is then sent to the receiver (3), who signs it and sends it back to the sender (4). Now the sender owns a transaction which gives him the guarantee that he will eventually get back his money, should the receiver stop collaborating. In the worst case he has to wait until the lock time is reached. Knowing this, he can then safely broadcast T1 to the network, locking some moeny in the MultiSig address (5) and completing the setup. A better solution to a refund transactions exists since 2014, when the OP_CHECK- LOCKTIMEVERIFY command was added to the bitcoin scripting language [30]. This command allows for conditional script execution, depending on the current time. It makes it possible to construct a script, such that two signatures are only needed until a given time. After that only the signature of one entity in this case the sender is needed. Similar to the previous setup, this gives the same guarantees for both entities, but is much simpler in comparison to the refund transaction method. The current Coinblesk implementation already uses time-locked-addresses with OP_CHECKLOCK- TIMEVERIFY for securely locking funds in a MultiSig address.

20 10 CHAPTER 2. BACKGROUND AND RELATED WORK Inputs Outputs Inputs Outputs Sender: 9 Inputs Outputs Sender: 7Receiver: 1 MultiSig: 10 Sender: 6Receiver: 3 Signatures Receiver Sender Receiver: 4 Sender Sender Sender Time Figure 2.5: Updates to an open micropayment channel Micro Payments After some initial money is locked in the MultiSig address, the sender make a first payment. He creates a new transaction that spends the money in the MultiSig address and sends a small amount to the receiver and the rest back to himself. This channel transaction is then signed by the sender. At this point the transaction is still not valid, as it needs the second signature from the receiver. After the sender sends the channel transaction to the receiver, the payment is concluded. The receiver now owns a transaction that when signed and broadcast, pays him some amount. The sender on the other hand is missing the receiver s signature and is not able to broadcast on his own. As the receiver expects further payments, he will chose to defer the broadcast to a later time. The sender creates for the next payment an updated version of the last channel transaction, in which the balances to both parties is adopted accordingly: the output to the receiver is increased, while the output to the sender is decreased. This updated transaction is sent to the receiver and the previous version of the channel transaction is discarded. The process is repeated for every payment without needing to broadcast to the network (see Figure 2.5). Only when the funds in the MultSig address are depleted is the last channel transaction broadcast and the channel closed. However, the receiver must also broadcast the current transaction before that, should the lock-time of the MultiSig address run out. Otherwise the sender is be able to spend the entire amount in the current micropayment channel by himself. It is important to note that this micropayment channel can only be unidirectional, meaning it not possible to send money back with an updated transaction: a change of the channel transaction in favor of the sender would not prevent the receiver to broadcast an older transaction that is more beneficial for him.

21 2.5. THE LIGHTNING NETWORK The Lightning Network The lightning network as proposed by Poon and Dryja is an decentralized overlay network that builds on top of bitcoin. Lightning uses micropayment channels between nodes to enable highly scalable off-chain transactions [23]. Payments are routed over the mesh network of payment channels until they reach the receiver. This design is made in such a way, that avoids the need for trust. Assuming that participants cooperate with each other, apart from the initial funding transactions and the final closing transaction, payments can work outside the bitcoin network and can avoid high fees or delays for confirmation Bi-directional Payment Channels Micropayment channels as discussed in section 2.4 only allow for transfers in one direction. The lightning network suggests a new construct, that allows payments to be made in both directions without having to rely on trust. In comparison to plain micropayment channels, such a channel is initially funded by both parties equally. For each update inside the channel a pair of revocable commitment transactions is generated, equivalent to channel transactions. Both entities own a different version of this transaction, which allows to ascribe blame later in case of non-cooperation. A set of breach remedy transactions is used to invalidate prior channel transactions. These transactions revoke older commitment transactions by imposing a penalty upon a broadcast of an old commitment transaction. The penalty allows the other party to spend all funds inside the channel, leaving the non-cooperative party with nothing. This makes it save to send money in both directions, as no party has an incentive to broadcast an invalidated transaction [23] Hashed Timelock Contracts For the lightning network it is unfeasible to connect all nodes to a fully meshed network, as doing so would result in a quadratic increase of setup costs. Instead, users need to only have one open channel with a participating node. This requires payments to be routed across a network of payment channels. As intermediate nodes can not be trusted, this comes with with its own challenges. Lightning solves this by introducing the concept of hashed timelock contracts (HTLC). An HTLC is a contract with two possible execution paths: coins sent to an HTLC are spendable either by the sending party after a fixed timespan has passed, or by the receiver if he can provide a secret in form of a string. This construct can then be used to send coins along a path in the lightning network, by making each payment to the next hop contingent on the knowledge of the secret. This process works in the following way:

22 12 CHAPTER 2. BACKGROUND AND RELATED WORK Payment Channel Alice 0.5 Charlie 0.5 Payment Channel Charlie 0.5 Bob 0.5 (1) Alice Charlie Bob H S H Payment Channel Alice 0.4 Charlie 0.5 HTLC 2 days 0.1 Payment Channel Charlie 0.5 Bob 0.5 (2) Alice Charlie Bob H H S H Payment Channel Alice 0.4 Charlie 0.5 HTLC 2 days 0.1 Payment Channel Charlie 0.4 Bob 0.5 HTLC 1 day 0.1 (3) Alice Charlie Bob H H S H Payment Channel Alice 0.4 Charlie 0.5 HTLC 2 days 0.1 Payment Channel Charlie 0.4 Bob 0.6 (4) Alice Charlie Bob H S H S H Payment Channel Alice 0.4 Charlie 0.6 Payment Channel Charlie 0.4 Bob 0.6 (5) Alice Charlie Bob S H S H S H Figure 2.6: Routing payments with HTLC contracts

23 2.5. THE LIGHTNING NETWORK 13 Assuming Alice wants to send 0.1 BTC to Bob via an intermediate node Charlie. Alice is connected to Charlie and Charlie is connected to Bob each via a bi-directional payment channels as explained in Section After Alice made her intentions clear to Bob and a suitable routing is found from Alice to Bob, the following procedure illustrated in Figure 2.6 takes place: 1. Bob creates a secret string S and a corresponding hash H = hash(s), where hash is a cryptographic one-way hash function. Bob sends H to Alice. 2. Alice sends H to Charlie and they agree to update their payment channel by including a new 0.1 BTC HTLC output, which is redeemable after 2 days by Alice, or at any time by Charlie, if he can prove the knowledge of the secret S. 3. Charlie sends H to Bob, proving that he received a payment from Alice. They also create a HTLC output in their channel, which is redeemable after 1 day by Charlie or by Bob if he can provide the secret S. 4. Bob sends S to Charlie, which gives Charlie the guarantee that he can get 0.1 BTC immediately from Alice. Knowing that, Charlie agrees to update the channel with Bob, sending him 0.1 BTC. 5. Charlie sends S to Alice, proving that he has paid Bob and they agree to update their payment channel to send 0.1 BTC to Charlie. 6. The payment is concluded as the 0.1 BTC was successfully routed over the two payment channels. This routing design is fully trust-less, as no involved party is able to steal funds. Also the payment is atomic in that it either fully succeeds or is rolled back: If Charlie refuses cooperation after step 2, Alice can wait 2 days to get her money back. If Bob refuses cooperation after step 3, Charlie can wait 1 day to get his money back and then 1 day later Alice is paid back. If Bob does not send the secret to Charlie in step 4, he can not steal the BTC 0.1 HTLC output without revealing the secret: Charlie can monitor the network and then use the secret to retrieve the 0.1 BTC HTLC from Alice. If Charlie does not update the payment channel in step 4 after receiving the secret, Bob can use his secret to get the BTC 0.1 from the HTLC output with Charlie. If Alice refuses to update her channel with Charlie at step 5, he can use the secret to spend the 0.1 BTC HTLC output. With this setup, Transactions are only broadcast to the bitcoin network when nodes are uncooperative. In case of cooperation no broadcast is needed. However, nodes must monitor the blockchain and time-locks must be large enough to give them the ability to act in case of non-cooperation.

24 14 CHAPTER 2. BACKGROUND AND RELATED WORK Adoption Even though the lightning network has many advantages, it has not yet been activated on the bitcoin network. Since lightning heavily relies on chained off-chain transactions, malleability becomes a limiting factor. Although technically possible, lightning without malleability fix would be impractical as it would introduce further complications [21]. Recently an implementation of lightning was used on the bitcoin testnet [12] on which SegWit has been activated since May 2016 [27]. The testnet is an alternative bitcoin block chain which is mainly used for development purposes and in which coins do not have financial value. 2.6 Coinblesk Coinblesk is a mobile payment solution initially developed at the University of Zurich as part of a masters project [18]. It consists of a mobile android application and a central server providing payment services. The current version Coinblesk 3.0 is characterized by the following features: Trustless Design There is no trust involved in depositing money with the server. Funds are secured by using time-locked 2-of-2 MultiSig addresses. Zero Confirmation Transactions Payments between Coinblesk users are checked for double spends by the server and are confirmed in less than two seconds. Wireless Mobile Payments Wireless payments are possible via Near Field Communication (NFC) or bluetooth without requiring Internet connectivity from the sender Payment Mechanism Payments in Coinblesk 3.0 involve the following steps: 1. Key exchange: The client generates a new key pair and sends his public key to the server. The server also generates a new key pair and sends his public key back. The public key of the client is saved along with the server key pair on the server. This step is a requirement for all other operations with Coinblesk. 2. Create new address: The client creates a time-locked 2-of-2 MultiSig address and registers it with the server. Funds from this address require signatures from both the client and the server. A time lock on the address allows the client to spend any funds individually after a certain time, i.e. 3 months. This prevents extortion possibilities from the server and puts a time limit on the validity of the address. Periodically the client has to generate a new address when the lock-time runs out.

25 2.6. COINBLESK Placing funds The user sends bitcoin to the the newly created address. 4. Verify transaction When the client wishes to make a payment he creates a new transaction spending from the 2-of-2 MultiSig address created in step 2. He signs the transaction and sends it to the server. The server then verifies the transaction and signs with his own key before broadcasting it to the bitcoin network. Payments to other Coinblesk user s MultiSig addresses can be immediately spend again (instant payments). This is possible because the server keeps track of all payments made to its users and checks for double spending Problems The current system comes two main drawbacks: Transaction Fees The user has to pay a transaction fee for each payment made with Coinblesk. This cost can be a significant, especially for smaller purchases: a minimal transaction between two Coinblesk user currently costs at least USD Transactions with more inputs are even more expensive. This makes Coinblesk infeasible for point-of-sale purchases such as in the originally intended use-case as a payment solution for a cafeteria. Security When transactions are made between Coinblesk users, the resulting unspent transaction outputs (UTXO) can be immediately spent again. Due to the currently missing malleability fixes in the bitcoin protocol, this makes those chained transactions unsafe. A malleability attack such as the one observed in March 2017 [3] would have caused all chained transactions to become invalid, as the changed transaction ID would have broken the chain, resulting in lost funds for Coinblesk users. Other minor problems with the current system are: Non-deterministic Signatures in Requests Coinblesk uses signatures in the data transfer objects (DTO) to verify the authenticity and integrity of a request. Currently this is done by signing the hash of the JSON encoded payload and then adding the signature to the DTO as a separate field. However, in order to reproduce the same hash for signature validation, the system must currently transform the JSON to a canonical format by sorting the keys, removing whitespaces and forcing line breaks at specific positions. This process is error prone, as JSON object serialization can vary significantly between frameworks. Currently this does not cause issues, as both the server and client share the same codebase for DTO generation. But for the planned release of a web client, this could become an issue. 4 Assuming one input and two outputs resulting in a transaction size of 342 bytes. Fee: 240 satoshi/byte (bitcoinfees.21.com) Exchange rate: USD/BTC (bitstamp.net) as of May 11, 2017

26 16 CHAPTER 2. BACKGROUND AND RELATED WORK Fixed transaction fees Currently Coinblesk uses a fixed hard-coded fee for transactions. However the required fee for a fast block inclusion is dynamic and can change at any time. Requesting this fee from an external service would be the better option. Outdated Codebase Coinblesk has seen many iterations over the last years. This has left the codebase in a sub-optimal state. There are outdated library dependencies and unused or untested code paths. Additionally some unit tests are nondeterministic as they rely on a given execution order. Also development setup and deployment are non-trivial, as a specific application server is needed.

27 Chapter 3 Design In this chapter an improved protocol design for Coinblesk is presented, which solves the problems discussed in the previous chapter. The design focuses on reducing transaction fees for payments between Coinblesk users and solves security issues related to malleability. A high level overview of the new payment architecture is presented and then formalized. 3.1 Architecture The design leverages micropayment channels to reduce the transaction fees in subsequent small payments. One obvious method of using micropayment channels would be to connect all Coinblesk users in a fully meshed network. This however is not feasible, since the number of channels and the amount of locked funds would increase quadratic with the number of users. Instead, all users open a unidirectional payment channel with a central server. The channels use 2-of-2 MultiSig addresses and are funded by the users. The server tracks a virtual balance for each user, which indicates the amount owed by the server. Small payments between users can be made by sending coins over the payment channel to the server, which will then increase the virtual balance of the intended receiver. Users can request to be paid their virtual balance. The server has an initial buffer of funds and closes channels if needed, to ensure that payouts can be fulfilled at any time. The server also closes channels shorty before the lock-time of a MultiSig address runs out. For larger payments, the receiver s address can be directly added to the current channel transaction and then broadcast, closing any existing channel. Figure 3.1 illustrates this concept. It shows the state of the system after the follwing steps: 1. The server has an initial pot of 100 BTC 17

28 18 CHAPTER 3. DESIGN Alice Channel Server: 8 Alice: 2 Server Channel <none> Carol User Balance Alice 0 Bob 3 Carol 0 Dan 5 Server Pot: 93 Bob Channel Server: 7 Bob: 3 Channel <none> Dan Figure 3.1: Users open micropayment channels with the server. The server has an internal accounting for each user and a buffer to pay out balances. 2. Alice and Bob load 10 BTC to their MultiSig addresses. 3. Alice sends 3 BTC to Bob 4. Alice sends 5 BTC to Dan 5. Bob sends 7 BTC to Carol 6. Carol pays out her 7 BTC 3.2 Model This section describes the formal model for all payment operations in the new system. Definition 1. Let i denote a user in the system, b i the virtual balance of user i and c i the server output value in the current payment channel of user i, with c i = 0 if no channel is open. The maximum server output in a channel is given by c max and the initial pot size of the server is defined as p initial and the current pot size as p. Further C = {c 1,..., c n } is the set of all payment channels and B = {b 1,..., b n } is the set of all virtual balances. The server state can be defined by the tuple S = (p init, p, B, C, c max ) A virtual payment transfers balance from one user to another. No actual bitcoin transactions are created. The balance of the sender is decreased and the balance of the receiver increased. virtualpayment(i, j, a) transfers a coins from user i to user j:

29 3.2. MODEL 19 virtualpayment(i, j, a) : S S with virtualpayment(i, j, a) = (p init, p, B, C, c max ) for i =, a > 0 B = {b 1,..., b i a,..., b j + a,..., b n } A micropayment sends coins over the micropayment channel to the server and increases the receiver s virtual balance. micropayment(i, j, a) sends a coins from user i to user j: micropayment(i, j, a) : S S micropayment(i, j, a) = (p init, p, B, C, c max ) for a > 0, c i + a c max B = {b 1,..., b j + a,..., b n } C = {c 1,..., c i + a,..., c n } Closing the channel broadcasts the current channel transaction. closechannel(i) resets the channel for user i and increases the server pot by the amount c i : closechannel(i) : S S closechannel(i) = (p init, p, B, C, c max ) p = p + c i C = {c 1,..., c i 1, 0, c i+1,..., c n } A payout sends coins from the server pot to an address chosen by the user. This decreases the server pot and resets the virtual balance of the user to zero: payout(i) : S S payout(i) = (p init, p, V, C, c max ) V = {v 1,...v j 1, 0, v j+1,..., v n } p = p a Note that virtual balances are reflected by corresponding channel transactions until either the channel is closed or a payout occurs. This can be used to derive a equation for the equilibrium of the system which holds true at all times and can be used to check correctness:

30 20 CHAPTER 3. DESIGN Lemma 1. At any time the difference between the sum of all virtual balances and the sum of all pending channel transactions is equal to the difference of the current and the initial server pot size: n v i c i = c c init (3.1) i=1 3.3 Protocol The following sections describes the protocol for using the new payment model from the perspective of the user and the server. Implementation specific details are discussed in Chapter User Operations Coinblesk users are able to perform the following operations: Key Exchange A user sends his public key to the server, which will then respond with his own user specific public key. This is equivalent to the old system and acts as a registration process. The key exchange has to be done once per user. Create Timelocked Address After the initial key exchange, the user creates a new bitcoin address. This address is a 2-of-2 MultiSig address that requires both signatures from the exchanged keys. It is also defined by a user-chosen lock-time, a timestamp set in the future, after which the client is able to spend funds in the address without the involvement of the server. This lock-time gives the user the guarantee that he will eventually be able to retrieve his funds in case of an uncooperative server. The client then registers this new address with the server. After the lock-time is reached, he must create a new address, as the server will not accept any payments involving an unlocked address. The process must be repeated every 1 2 months, depending on the chosen lock-time. Funding of Address In order to make any payments, the user must load some funds into one of his time-locked addresses. The method of funding is left to the user. He can use any wallet or bitcoin exchange provider or be funded by a different Coinblesk user. After a funding transaction was made, he must wait for at least one block for the transaction to be confirmed. The server does not accept unconfirmed transactions. Micropayment to Coinblesk User Smaller payments to other Coinblesk users can be executed with a micropayment channel transaction. This requires some unspent and mined funds to be available in a time-locked address. It is possible to use multiple previously created addresses as inputs, as long as they are all locked. This operation depends on the existence of an open channel transaction:

31 3.3. PROTOCOL 21 1a) There is no current channel transaction: 1. The user creates a new channel transaction with inputs from his timelocked addresses. 2. An output to the server is added with the amount he wants to transfer 1b) There exists a current channel transaction: 1. The user retrieves the current channel transaction (possibly saved offline at the client or fetched from the server). 2. The output to the server is increased by the amount that should be transfered. 2) The transaction is signed by the user and sent to the server along with the receiver s public key. 3) The server adds his signature to the channel transaction and saves it for later broadcast. The receiver s virtual balance is increased. Virtual Payment to Coinblesk User A user that has received micropayments can use his virtual balance to directly transfer funds to other Coinblesk users. This is a very cheap and efficient way to transfer coins, as it is a simple database change and does not involve any bitcoin related operations. 1) The user creates a payment request that includes the amount to transfer and the public key of the receiving Coinblesk user. 2) The request is sent to the server. 3) The server decreases the balance of the sender and increases the balance of the receiver. External Payment Larger payments or payments to non-coinblesk users also require unspent and mined funds to be available in a time-locked address. Again, depending on the existence of an open channel transaction, the user performs the following steps: 1a) There is no current channel transaction: 1. The user creates a new transaction with inputs from his time-locked addresses. 2. An output to the receiver s address is added with the desired amount 1b) There exists a current channel transaction: 1. The user retrieves the current channel transaction (possibly saved offline at the client or fetched from the server). 2. The user adds an additional output to the transaction with the receiver s address and the desired amount. The output to the server remains unchanged. 2) The transaction is signed by the user and sent to the server. 3) The server adds his signature and broadcasts the transaction to the network. The sender s account is locked until the transaction is mined in a block.

32 22 CHAPTER 3. DESIGN Closing a Channel The user may chose to close his channel at any time: 1) The user retrieves the current channel transaction (possibly saved offline at the client or fetched from the server). 2) (Optional) The change address can be modified. This might be useful if the user wishes to send the change to a newer time-locked address, or if he wants to pay out the change to an external address. 3) The user signs the inputs and sends the channel transaction to the server. 4) The server adds his signature and broadcasts the transaction to the network. The sender s account is locked until the transaction is mined in a block. Payout If a user has a positive virtual balance he can request a payout: 1) He sends a payout request to the server with the desired destination address. 2) The server broadcasts a transaction sending the virtual balance of the user minus the required fee to the given address. The virtual balance of the user is reset to zero Server Operations The server performs the following operations: Closing of Channels The server can close a payment channel at any time. This is done by broadcasting the latest saved channel transaction to the network and locking the user s account until the transaction is mined in a block. The server closes a channel in the following cases: A payment channel is about to expire: The Server must close a channel before any of the input s time-locked addresses expires. Failing to do so would allow the user to spend the input, rendering the channel transaction invalid and result in lost funds for the server. The server pot is low: To retain the ability to meet payout requests, the server closes channels whenever tho pot falls below a configurable limit. The server closes channels in decreasing order of value until the limit is reached again. Rising transaction fees: The server closes a channel if the fee of a channel transaction becomes significantly lower than the current fee needed in the bitcoin network. This limits the risk of an unsuccessful broadcast due to low fees, which could cause lost funds for the server. Increasing/Decreasing Pot Size The server administrator might choose to increase the pot size for more liquidity in the system. Likewise coins can be taken out from the pot if they are needed elsewhere.

33 3.4. TRANSACTION FEES Transaction Fees Transaction fees have to be paid for every transaction broadcast to the network. Fees for the user occur during the following operations: Funding The initial and any subsequent funding of time-locked addresses are paid by the user. This process has to be repeated if the funds are depleted. The user can save transaction fees by transferring a larger initial amount to his time-locked address. Micropayments The first channel transaction sent to the server must include a valid fee. Subsequent transactions however are free for the user, as long as the channel stays open. If the network becomes more saturated, transactions might need larger fees for faster confirmation. In this case the additional costs are passed on to the user, who is forced to increase the fee in the channel transaction in his next micropayment. Payout When a users wants to retrieve his virtual balance, he has to pay the fee for the required transaction. The server subtracts the fee from the virtual balance. This also means that it is not possible to pay out very small amounts, lower than a single transaction fee. The server does not pay any transaction fees, except when increasing the server pot.