A Progressive Web Application for Coinblesk · web application o ers similar functionalities as does the native Android client with the bene t of having secure device-independent

A Progressive WebApplication for Coinblesk

Sebastian SchrepferOberwil-Lieli, SwitzerlandStudent ID: 10-737-567

Supervisor: Thomas Bocek, Bruno RodriguesDate of Submission: August 24, 2017

University of ZurichDepartment of Informatics (IFI)Binzmühlestrasse 14, CH-8050 Zürich, Switzerland ifi

MA

ST

ER

TH

ES

IS–

Com

mun

icat

ion

Sys

tem

sG

roup

,Pro

f.D

r.B

urkh

ard

Stil

ler

Master ThesisCommunication Systems Group (CSG)Department of Informatics (IFI)University of ZurichBinzmühlestrasse 14, CH-8050 Zürich, SwitzerlandURL: http://www.csg.uzh.ch/

Abstract

German.

Mit Coinblesk, einer mobilen, an der Universitat Zurich entwickelten Bitcoin Bezahllosungkonnen Bitcoin Transaktionen mit geringen Transaktionskosten und sofortiger Bestati-gung durchgefuhrt werden. Die Anwendung ist bislang fur Android verfugbar, wobei derZugriff auf das Guthaben nur von einem einzigen Gerat aus moglich ist. Falls das Geratgestohlen wird oder durch einen Systemfehler unbenutzbar wird, ist der Zugriff auf dieBitcoins nicht mehr moglich. In Rahmen dieser Arbeit wurde eine alternative Losung ba-sierend auf einer Webanwendung erarbeitet. Die Coinblesk Webanwendung bietet ahnlicheFunktionalitaten wie die Android-Anwendung, jedoch mit dem Vorteil, dass vom Geratunabhangig und trotzdem sicher auf die in Coinblesk vorhandenen Bitcoins zugegriffenwerden kann. Durch die Vorteile des Konzepts eines Progressive Web Apps konnen auchBenutzer ohne Android Coinblesk als App benutzen. Schliesslich wird uber eine Integra-tion von Coinblesk in den aktuellen Bezahlvorgang an einer Verkaufsstelle (point-of-sale)diskutiert.

——

English.

Coinblesk, a mobile Bitcoin payment solution, developed at the University of Zurich, offerssmaller transaction fees and allows to make instant virtual payments between its users.The application is available for Android and the funds can only be accessed from a singledevice. In case of a theft or a system crash, the funds are not accessible anymore. In thisthesis, an alternative solution based on a web application is presented. The Coinbleskweb application offers similar functionalities as does the native Android client with thebenefit of having secure device-independent access to the Coinblesk Bitcoin funds. En-abled through the benefits of a progressive web app, non-Android users can use Coinbleskas an app. Finally, the integration of Coinblesk into the current payment process at apoint-of-sale is discussed.

i

Acknowledgments

First and foremost, I would like to express my sincere gratitude to my supervisor Dr.Thomas Bocek, who supported me throughout the course of this thesis. He offered hiscontinuous advice and encouragement. With his immense knowledge and passion in thefield of crypto currencies, he was able to help me resolve all issues which came up.

I would also like to thank Prof. Dr. Burkhard Stiller for giving me the opportunity towork on this interesting topic at the Communication Systems Group (CSG).

Further, I would like to thank Sebastian Stephan for his advice and support during theimplementation phase of the thesis.

My thanks also goes to Christian Davatz and Annika Sinkwitz for proofreading the thesis.

Last but not least, I would like to thank the 13 participants of the SUS questionnaire,who took their time to evaluate the product of this thesis.

iii

Contents

Abstract i

Acknowledgments iii

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Description of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background and Related Work 5

2.1 Evolution of Coinblesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Web Front-End Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Framework Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Progressive Web App . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 System Usability Scale (SUS) . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 SUS Score Calculation . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Design 13

3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Architecture and Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Authentication and Authorization . . . . . . . . . . . . . . . . . . . 16

3.3 Overview of the Components . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.1 User Account Management . . . . . . . . . . . . . . . . . . . . . . . 18

v

vi CONTENTS

3.3.2 Common Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.3 User Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.4 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Transferring to Bitcoin and E-Mail Addresses . . . . . . . . . . . . . . . . 32

3.4.1 Transferring to Unknown E-Mail Addresses . . . . . . . . . . . . . 33

3.5 Device-Independent Payments . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5.1 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5.2 Pass Phrase Strength Evaluation . . . . . . . . . . . . . . . . . . . 35

3.6 Progressive Web App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Implementation 39

4.1 Front-End Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Server Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1 Interceptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 State Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5 Progressive Web App (PWA) . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5.1 Standalone Application . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5.2 Offline Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Building Bitcoin Transactions with JavaScript . . . . . . . . . . . . . . . . 50

4.6.1 Supporting CLTV Redeem Scripts . . . . . . . . . . . . . . . . . . . 50

4.7 QR Code – Scanning and Displaying . . . . . . . . . . . . . . . . . . . . . 51

4.8 Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.8.1 Debug Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.8.2 Swagger UI and API Refactoring . . . . . . . . . . . . . . . . . . . 52

4.8.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

CONTENTS vii

5 Evaluation 55

5.1 SUS Usability Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.1.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2 Lighthouse Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6 Discussion 59

6.1 Coinblesk Integration into Payment Terminals . . . . . . . . . . . . . . . . 59

6.1.1 Current Situation: Stakeholders . . . . . . . . . . . . . . . . . . . . 60

6.1.2 Integration of Coinblesk via Virtual Debit Cards . . . . . . . . . . . 60

6.1.3 Pushbacks and Problems . . . . . . . . . . . . . . . . . . . . . . . . 62

6.1.4 Consequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6.2 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7 Summary and Conclusions 67

Bibliography 67

Abbreviations 75

Glossary 77

List of Figures 78

List of Tables 80

A Installation Guidelines 83

A.1 Installation and Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

A.2 Running in development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.3 Building for deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

A.4 Hints for Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

viii CONTENTS

B System Usability Scale: Evaluation Material 87

B.1 The full questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

B.2 SUS Score calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

C Contents of the CD 91

Chapter 1

Introduction

The market of crypto currencies is rising. The total market capitalization of all cryptocurrencies is currently as high as 154 billion US-Dollar [35]. The dominating position ofBitcoin is undefeated: Bitcoin has a market dominance1 of currently 45.3% [36]. Thedemand for Bitcoins is also on the rise: The exchange rate Bitcoin/US-Dollar more thanquadrupled since 1st January 2017 up to today.2

Bitcoin transactions cannot be used when the need for an instant confirmation is given [23].One situation where instant payments are required is the payment process at a point-of-sale (POS). With instant payments as a goal, a project at the University of Zurich wasestablished: Coinblesk [44]. By using an intermediary server, transactions were confirmedwithin a second which allowed for a use of Bitcoin payments at a canteen at the Universityof Zurich. A client application has been developed which communicated with another NFCdevice to instantly transfer some funds.

In a follow-up project, the application was then extended to use multi-signature ad-dresses [80]. This feature moved the possession of the funds back to the user: the server didnot have access to unspent funds anymore, but could still confirm a transaction instantly.The rise of transaction fees then led to the introduction of micro channel transaction andvirtual payments up to a certain threshold [76].

1The dominance is the percentage of a crypto currency market capitalization compared to the sum ofeach market capitalization of all crypto currencies [35].

2The exchange rate of Bitcoin on the 1st January 2017 was at around 980 US-Dollar, the exchangerate on the 23rd August, 2017 is around 4200 US-Dollar [35].

1

2 CHAPTER 1. INTRODUCTION

1.1 Motivation

At the time of the beginning of this Master Thesis, the Coinblesk application consists ofan intermediary server and an Android application. The Android application stored aprivate key to access the funds and sign transactions. Losing this private key is a largeproblem: Through the decentralized nature of the Bitcoin network and its lack of a centralauthority, the access to the funds cannot be restored. A user would lose all of his fundswhen the Android device was either lost or irreversible damaged. Even a reset of thedevice without remembering the stored funds would lead to an irreversible loss of thefunds.

Moreover, an access to the funds was only possible by using an Android device. Therewas at the time no other option to access the funds, neither on a desktop device nor withanother mobile operation system (e.g. Apple iOS).

Finally, through the introduction of micro channel transactions and virtual payments,the necessity of having a monitoring tool evolved. An administrator was not able toobserve and manage the integrity of server balance between micro channel transactionsand virtual payments. Furthermore, basic management functionalities such as the useraccount management or listing the current funds on Coinblesk was not possible.

1.2 Description of Work

This thesis addresses the aforementioned issues mentioned in the Motivation section byintroducing a separate Coinblesk web application which communicates with the existingCoinblesk server. The Android application, however, is not replaced by the new webapplication but rather complemented. The design, implementation and evaluation of theweb application is part of this thesis. The focus while building this application was tomake it compliant to the requirements of a Progressive Web Application. The thesis alsocovers refactorings made to the Coinblesk server. Finally, the potential introduction ofCoinblesk into a regular payment process at a point-of-sale is discussed.

1.3. THESIS OUTLINE 3

1.3 Thesis Outline

Chapter 2 starts by giving an overview on the evolution of Coinblesk. It then continueswith an evaluation of front-end web frameworks and the concept of a Progressive WebApp. The definition and description of the System Usability Scale SUS then concludesthis chapter.

Chapter 3 describes the requirements and the architecture of the web application. In orderto use Coinblesk, a certain trust in the server is necessary. The following section goes intodetail about how much trust is required. Then, the details of all web components aredescribed in Section 3.3. The chapter continues with the concept of transferring Bitcoinsto an e-mail or Bitcoin address, followed by the synchronization of the Bitcoin privatekey. This synchronization allows to make device-independent payments. The chaptereventually finishes with a section about how the notion of Progressive Web Apps is usedin Coinblesk.

The following Chapter 4 discusses the implementation of the aforementioned points. First,the front-end architecture and its build process are discussed. In the subsequent sections,the implementation of the server communication, the state management and the routingare covered. It goes on about the implementation details of the notion of a ProgressiveWeb in Coinblesk. Transactions must be made with JavaScript to keep the access of thefunds on the user’s device: The subsequent section discusses the process of building Bitcointransaction with the required redeem script. Scanning a QR code is used to simplify theprocess of transferring Bitcoins to another person. Section 4.7 talks about displaying andscanning QR codes. The chapter concludes with a section about the refactorings madeduring this thesis.

Chapter 5 then evaluates the resulting product. A System Usability Scale questionnairewas conducted to evaluate the usability of the Coinblesk web application. Furthermore,an automated analysis (Lighthouse) was realized to measure the quality of the application.

The subsequent Chapter 6 then discusses the opportunities of introducing a Bitcoin pay-ment with Coinblesk into point-of-sale payment terminals. This would offer the possibilityto pay directly at a store or another point-of-sale. It then finishes with a discussion aboutfuture work on Coinblesk.

Finally, the last Chapter 7 concludes this thesis with a summary.

Chapter 2

Background and Related Work

This chapter discusses related work and the technologies which this thesis is buildingon. First, an introduction to the current Coinblesk project is given. Then, the currentsituation of payment transactions over payment terminals is presented. In the subsequentSection 2.2 an evaluation is made between the various options for building a state-of-the-art web application. It also includes the concept of a progressive web application. Thechapter is concluded by a description of the System Usability Scale (SUS).

2.1 Evolution of Coinblesk

A valid payment via Bitcoin should be confirmed within at least 6 blocks [23]. With anaverage block creation time of 10 minutes, it takes about 60 minutes to confirm a payment.Therefore, regular Bitcoin transactions cannot be used adequately for point-of-sale (POS)purchases.

Coinblesk (previously Mobile Bitcoin Payment System MBPS) tries to circumvent thisproblem by introducing an intermediary server application. It was created in its firstversion as a Master Project at the University of Zurich [44]. The underlying idea was toplace a trusted intermediary between two users and immediately confirm payments withinthe Coinblesk network. The communication between two users was established using anNFC sensor in a smartphone. The concept was then live-tested in the canteen of theUniversity of Zurich: An NFC device was installed at the cashier and a customer couldsimply make a Bitcoin transaction with his smartphone running Coinblesk.

In this first version, payments were made outside the blockchain. This, however, hasseveral drawbacks: By introducing a server application, which controls all the moneyflows between the user, also a central point of failure was established. Furthermore, allBitcoins had to be transferred to a Bitcoin address of the server first. This means, that auser first had to give up the ownership of the funds in favor of the server. It was necessaryto completely trust the server application.

To confirm instant payments, the server needs to have full access to the funds and beable to withdraw them when required. In the first version, the funds were completely

5

6 CHAPTER 2. BACKGROUND AND RELATED WORK

owned by the server. During the further development of Coinblesk, time locked addresseswith a shared ownership of the funds were introduced [80]. This concept used a 2-of-2multi-signature Bitcoin P2SH script to access the funds. This means that both the serverand the client need to sign a transaction for it to be valid. To prevent a malicious serverto never sign a transaction and therefore locking the funds on a user’s account, this lockedbehavior was restricted to a certain amount of time. After usually 3 months, the addressgets unlocked and the user could access his funds again without a second signature ofthe server. This allowed the server to be minimally trusted but to still enable instantpayments.

The introduction of time locked addresses created a new problem: Every transactionis recorded on the blockchain and small payments have a relative high fee of at least2.48 USD1. Therefore, it is not feasible to use Coinblesk for smaller POS purchases any-more.

In the first Coinblesk version, fees occurred only when the user withdrew or depositedthe funds, because all payments were handled off-blockchain. Now, every transactionhas large fees. To circumvent this problem, channel transactions and virtual paymentswere introduced [76] as trade-off between an increased trust to the server and the user’sownership of the funds itself. Similar to the previous model, this version of Coinblesk alsouses time locked addresses. The funds require a signature of the client and the server. Themain difference is, however, that up to a certain threshold (e.g. 100 USD), the paymentsare made differently.

If a Coinblesk user wants to make a payment to another Coinblesk user, a channel trans-action is opened and the virtual balance of the recipient is increased by the amount ofthe transaction. The recipient of the actual channel transaction now holds only virtualBitcoins. The transaction, sent to the server, is not immediately broadcasted but ratherkept back. The following transaction of the same user to another Coinblesk user, thencontains the sum of the first and second payment. The server drops the first transactionand replaces it with the new one.

The recipient is also able to spend his virtual funds: If enough virtual funds are available,he can create a virtual payment directly to another user. Virtual payments do not includefees. They are not linked to the blockchain and only handled within the server application.The concept of virtual payments is similar to the first version of Coinblesk. The maindifference is that they are only possible up to a certain threshold. Amounts higher than thethreshold will be broadcasted immediately. The required trust to the server has thereforean upper bound.

A recipient can pay out the virtual balance anytime. This is required when a user wantsto transfer his funds to a regular Bitcoin address outside of Coinblesk.

The web application introduced in this thesis is based on this most recent version ofCoinblesk. Virtual payments and channel transactions are supported directly in the webbrowser.

1Assuming a Coinblesk transaction with one input/two signatures and two outputs, resulting in atransaction size of 342 Bytes. With a current (as of 2017-08-13) recommended fee of 180 Satoshi/Byte [24]and an exchange rate of 4030.70 USD/BTC [25], this leads to ∼2.48 USD/transaction.

2.2. WEB FRONT-END TECHNOLOGIES 7

2.2 Web Front-End Technologies

The following section discusses various web front-end frameworks and evaluates their ben-efits and disadvantages. Then, in Section 2.2.2, a progressive web application is describedin detail.

2.2.1 Framework Evaluation

With the rise of structural web frameworks, libraries such as jQuery became less signifi-cant [45]. In 2012, the first version of the web framework Angular 1.x was released [10]. Itintroduced the concept of data bindings and dependency injection, which eliminates muchof the code otherwise has to be written [9]. It is a framework which is in charge of theweb application and controls its life cycle [9]. A library like jQuery, however, only offersa collection of functions, which will possibly be used [9]. Angular 1.x also introducedthe concept of directives: New functionality is added to the HTML markup which willthen be parsed by the framework [9]. Examples for this are the data bindings and controlstructures like ng-for or ng-if which could directly be used in the markup to controlthe application.

React.JS took a similar approach to Angular 1.x but introduced the usage of a VirtualDOM [8]. The main problem which is solved by this, is the performance issue: DOMmanipulations are much slower than JavaScript operations [79]. For example, most frame-works rerender a table in the DOM completely if the dataset of a single row changes [79].Inefficient DOM updating has become to a problem because in a modern website, largeamounts of DOM manipulations are made [79]. To address this issue, a Virtual DOMwas introduced. An inefficient DOM update is done to the Virtual DOM instead [79].The Virtual DOM, however, has no visual representation and an update is very fast [79].Afterwards, both DOM’s are compared and only the necessary elements are transferredto the real DOM in a process called diffing [79]. Vue.JS adapted this technology andimproved it with a lighter-weight implementation of a Virtual DOM [81]. Angular 1.x,however, works with Watchers, which are not as performing as a Virtual DOM [8].

React.JS also introduced the JavaScript expression language JSX [46]. JSX producesReact elements which will then be injected into the DOM [46]. Even though the syntaxof JSX looks similar to HTML, JSX is closer to JavaScript than HTML [46]. By using it,injection attacks can be prevented [46]. Despite the benefits of JSX, Angular and Vue.JSuse plain HTML and CSS [81][7]. The creators of Vue.JS emphasize the flat learning curveof using plain HTML and CSS, because it makes it much easier to develop for designer andless experienced developers and to read and contribute to the codebase [81]. Furthermore,HTML-based templates can be much easier migrated from a previous codebase [81]. Andfinally, even pre-processors, such as Pug (formerly known as Jade) can be used to createVue templates [81].

Vue.JS offers a command-line (CLI) project-generator, which makes it easy to start anew project with an out-of-the-box generated complex build process [81]. The generatorsupports various build tools like Webpack or Browserify [81] and even an official adaption


of the build for progressive web apps (see Section 2.2.2) [82]. It can be used to start a large-scale project [81]. In contrast to React.JS, Vue.JS offers also a scaling-down solution [81].React.JS is often criticized for its steep learning curve because of JSX, the necessaryknowledge about EcmaScript 2015 (ES2015) and the build process. With Vue.JS on thecontrary, even simple web applications without a build process can be realized. This ispossible, because a Vue.JS template is valid HTML and the Vue.JS codebase is validJavaScript. Therefore, a simple inclusion of the Vue.JS dependency is already sufficientto start developing a simple single-page-application (SPA) [81].

Due to its core usage of the Virtual DOM, React.JS could natively render Android oriOS applications [81]. React Native is a framework based on this idea [81]. The Reactcomponent model is then used to create native iOS or Android layout components [66].Meanwhile, a cross-platform UX framework called Weex is developed with Vue.JS as itscore.

Table 2.1 depicts the various benefits and disadvantages of the aforementioned frameworksand the jQuery library in a structured way.

From the analysis above, Vue.JS seems to be equal or predominant in most categories.Especially the flat learning curve of this web framework was a crucial factor. Therefore,Vue.JS was selected to be the main framework for the Coinblesk web application.

Feature jQuery React.JS Angular.JS 1.x Angular (2) Vue.JSIs a Framework? × � � � �Virtual DOM × � × × �Classic HTML/CSS � × � � �CLI for Build × (�)1 × � �Flat Learning Curve � × × × �Complexity low high high high low/mediumPerformance slow fast medium fast fastTypeScript Support × � × �2 �Native rendering × � × × (�)3

1 React.JS offers a CLI project generator with several limitations [81].2 Angular (2) itself was written in TypeScript [11].3 There is an active development of a native implementation of Vue.JS called ”Weex” [81].

Table 2.1: Comparison between web frameworks and a library [8][9][46][66][72][79][81]

2.2.2 Progressive Web App

After the bursting of the dot-com bubble in 2001, many people thought, the web wasoverhyped [63]. In O’Reilly’s opinion, the bursting was turning point of the web andcreated the new term Web 2.0 at a conference [63].

This term was very vague, because it did not describe a new technology, but rather a setof multiple, newly emerged technologies [63]. One major technology which was part of theWeb 2.0 was Ajax [12]. Furthermore, there were a lot of new concepts attributed to the

2.2. WEB FRONT-END TECHNOLOGIES 9

term Web 2.0. Examples for this were the introduced interactivity of a website visitor,which could be communicating with other visitors of a website [49]. One famous exampleis Wikipedia [49].

In regards of being a buzzword, the term Web 2.0 has similarly evolved as the termProgressive Web App or PWA. The term Progressive Web App describes the newesttechnology to build an application which runs in the web browser, but includes elementswhich were formerly only known from native mobile applications [12]. The goal of aprogressive web app is to have an application that is fast, reliable and engaging [40] andtherefore decreases the differences between a native and a web application. Google furtherdescribes these main properties of a progressive web application as follows [40]:

”An application should be responding quickly to user interactions with silkysmooth animations and no janky scrolling. It should load instantly and showa downasaur, even in uncertain network conditions.” An application can belaunched from the user’s home screen, service worker’s enable a PWA to loadinstantly, regardless of the network state (offline modus). ”An applicationshould feel like a natural app on the device, with an immersive user experience.”This means, that a PWA can be installed on the user’s home screen and open inan immersive full screen. It can notify the user with web push notifications [40].

This description can be broken down to a list of main features, as discussed by TalAter [12]:

Availability Regardless of ConnectionProgressive web apps should not be depending on a constant network connec-tion [12], similar to how native apps work: Native apps can be installed and arethen available for a usage later on. When a user enters a progressive web app, aservice worker is registered automatically [12]. This service worker adopts the con-nection management and downloads the static resources of the application (readmore about service workers at the end of this section). This offers the user thepossibility to not bother about the connection: An action is just made after theconnection is reestablished again [12].

Fast loading timesBy using service workers, the static resources of the application are downloadedonce. From then on, the application is ready to be used on the client’s device, nomatter what connection the user is currently having [12]. Reopening the applicationis then very fast [12].

Push NotificationsPush notifications can be sent by the progressive web app even days after the uservisited the app [12]. This behavior was only known from native applications before.

Home Screen ShortcutAfter the user visited the progressive web app twice in his browser, an installationrequest appears in the browser [41]. If the user decides to install the application, anapplication shortcut is put to the Home screen.


Native LookWhen adding an application shortcut to the Home screen, the application can belaunched in a full-screen standalone manner [12]. The browser and phone UI can behidden, so that a user is unaware, that the PWA is running with the browser enginebehind the scene [12].

A web app at least needs to support the following features in order to be qualified as aprogressive web app. As soon as all the requirements are met, Google Chrome for Androidwill prompt the user to install the application on the home screen [41].

• Having a valid web app manifest

• Being served over HTTPS

• Having a valid service worker registered

• Website being visited twice, within > 5min

Web Apps Compared to Native Apps

The core benefit of using a web application compared to a native application is, that auser does not need to download and install an application from an app store. A user hasto be convinced to download the application:

”Users need to find out about your site (through traditional online advertising,or on your website). They then have to visit your page on the app store.Then they need to click install. They need to agree to give the app differentpermissions. Then they need to wait for the app to download and install.Finally, they need to actually launch the app at least once and maybe even useit.” [12]

The hurdle to do all of the above steps for installing an application is very high. Cer-tain companies are trying to convince a user with aggressive marketing strategies, as forexample LinkedIn [12]: LinkedIn presents the users of their mobile web site a full screenmodal with the request to download the native application [12]. A user has to activelyrefuse the download of the native application and to continue on the mobile web site.

Native application do need to be updated regularly via the app store [74]. The user hasto either activate automatic app store updates or manually update an application. A webapplication can be refreshed by reloading the page. Depending on the service worker, anew version of the web application is fetched or not.

Web applications can easily be discovered via a web search engine. The application thenautomatically asks the user on the second visit if the application should be added to thehome screen. Native apps cannot directly be found on a website, but only a link to theapp store can be provided [74].

2.3. SYSTEM USABILITY SCALE (SUS) 11

The main benefit of native applications is the full access to a device’s hardware sensors.Currently the Web Bluetooth API [30], as well as the Web NFC API [32] are not fullyimplemented. Therefore, there is no option to access these sensors. A native applicationhas established APIs for these sensors [4][5].

Service Workers

A service worker is a script, which is running in the background and is installed into thebrowser by a web application [70]. Service workers enable features like push notificationsand background syncing [70]. They work in a separate thread as a web worker, and donot have direct access to the Document Object Model (DOM) [70]. A service worker is aprogrammable network proxy [70]. Every request from a user on a web application goesthrough this web proxy and the handling of those requests can be managed [70].

Installing a service worker is initiated by the web application developer by simply pro-viding a special JavaScript script [70]. A very common scenario is, to initially downloadsome static resources during the installation [70]. If the download of any of these filesfails, the installation is aborted and the next time, the user visits the web application,it will be retried again [70]. The service worker is only activated when the user leavesthe page after the installation and returns [70]. From then on, it will be in charge of allnetwork requests made from a web application.

Because of the major impact of interfering all network requests, an HTTPS connectionis required [70]. Possible attack vectors include hijacking a connection or fabricatingor manipulating responses with man-in-the-middle attacks [70]. For the development,localhost is also allowed to be used with a service worker [70].

Lighthouse

Lighthouse is a tool, developed by Google, for evaluating web apps in regards of theirquality [51] which collects performance metrics and insights [52]. It can be run as anextension within Google Chrome or directly being installed into the Google Chrome Dev-Tools. In an analysis of a web page, several audits are run. The quality is then measuredin four categories: Progressive Web App, Performance, Accessability and Best Practices.Lighthouse calculates a single score between 0 and 100 for each of those four categories.It can be used as a verification tool for the Progressive Web App requirements.

2.3 System Usability Scale (SUS)

A usability evaluation should use measures which cover effectiveness (”the ability of usersto complete tasks using the system, and the quality of the output of those tasks”), effi-ciency (”the level of resource consumed in performing tasks”) and satisfaction (”users’subjective reactions to using the system”)[29].


The System Usability Scale SUS is a standardized usability evaluation questionnaire,developed by Brooke [29]. SUS approached these measures by implementing a simple,ten-item scale [29]. It is based on a Likert scale, which basically gives a statement and aparticipant has to indicate how much he agrees with the statement [29].

The statements of the ten-item based questionnaire were carefully selected to provokeextreme expressions of the attitude being captured [29]. Brooke evaluated 50 potentialquestions. Half of the selected questions indicated strong agreement and the other halfindicated strong disagreement. The items leading to the most extreme responses thenfinally were selected for the system usability scale [29]. The final questions are listed inTable 2.2.

1. I think that I would like to use this system frequently.2. I found the system unnecessarily complex.3. I thought the system was easy to use.4. I think that I would need the support of a technical person to be

able to use this system.5. I found the various functions in this system were well integrated.6. I thought there was too much inconsistency in this system.7. I would imagine that most people would learn to use this system

very quickly8. I found the system very cumbersome to use.9. I felt very confident using the system.

10. I needed to learn a lot of things before I could get going with thissystem.

Table 2.2: The SUS questionnaire by Brooke [29].

When using the SUS evaluation questionnaire, it is required to first define the target groupof the system which is being evaluated [29]. The respondents should have the opportunityto use the system and immediately afterwards respond to the 10 questions [29]. Eachquestion has to be answered by the participants.

2.3.1 SUS Score Calculation

When evaluating the answers, one SUS score number results for each participant. TheSUS score is, according to Brooke [29], calculated as follows:

1. The score contribution of each question is handled differently depending on if thequestion number is odd or even:

(a) The score contribution of question 1, 3, 5, 7 and 9 is the answered scale positionminus 1. For example, the score contribution of an answer of 4 is 4− 1 = 3.

(b) The score contribution of question 2, 4, 6, 8 and 10 is 5 minus the answeredscale position. For example, the score contribution of an answer of 4 is 5−4 = 1

2. The sum of all score contributions is then multiplied by the factor of 2.5. Thisresults in the SUS score of one participant.

Chapter 3

Design

This chapter discusses the design of the web application. First, the requirements of theCoinblesk web application are described. Then, the architectural decisions and theirimpact on the required trust of a Coinblesk user are discussed. After the presentation ofthe developed components and their functionality, the two transfer scenarios of sendingBitcoins to an e-mail or Bitcoin address are described. Next, the possibility of device-independent payments by using a synchronization is introduced. Eventually, the chapterconcludes with a section about progressive web apps.

3.1 Requirements

The goal of the web application is to provide an easy accessible interface to the Coinbleskapplication. It should be usable for both desktop and mobile users. Moreover, it shouldpresent Apple iOS users a viable alternative to the Android application. Depending onthe user role, there are different requirements:

An administrator should be able to monitor the application. Namely, all user accounts andBitcoin addresses should be manageable. Basic management tasks include viewing anddeleting user accounts, listing all addresses with their balances or a list of events occurredinside the server. Since the integration of virtual payments and channel transactions, itis also important to track the server balance. The server balance constitutes the equalityof the sum of all channel transactions and the sum of all virtual payments [76]. Lastly, anadministrator should be able to monitor the buffering amount of Bitcoins on the serverto fund payouts of virtual payments.

A user has different needs: He wants to be able to use the web application similar tothe Android application. This means that a user should be able to make payments toanother user and to another Bitcoin address. Because typing of the Bitcoin address iscumbersome, the Android application, for that reason, has multiple hardware interfacesto read the address from another device (NFC, Bluetooth, etc.). The web application,however, should allow a user to enter an e-mail address as recipient or scan a QR code

13

14 CHAPTER 3. DESIGN

with an e-mail/Bitcoin address to make payment transfers. Payments should be able tobe done in either Bitcoin or a converted FIAT (non-crypto) currency.

Furthermore, a user wants to be able to manage his own funds. This means that he wantsto see all his addresses with their corresponding balance. Every address should have agenerated QR code next to it. The payment channel as well as the virtual balance [76]need to be depicted too, so that a user can transparently see his funds and the pendingtransaction of the payment channel. A user should also have the possibility to payout hisfunds from the virtual balance to an actual Bitcoin address. Equally important is that theuser can transfer his funds from previous, now unlocked addresses to the current lockedaddress. Unlocked addresses cannot be used by Coinblesk to make a payment. If the locktime of all addresses have expired, a user should be able to generate a new address.

The following section discusses the architectural decisions taken during the design andimplementation of the web application in the context of the previously introduced re-quirements and based on the already existing Coinblesk application.

3.2 Architecture and Trust

The existing architecture of Coinblesk comprises a server and an Android client. Theserver, but also every Android client, runs a Bitcoin node. This node is useful to fetchinformation about the current balance and previous transactions directly from the Bitcoinnetwork. The client can completely rely on this data because there is no intermediatethird-party which may interfere and maliciously manipulate the data.

The unspent funds of a client are always in the possession of the client, since the client’sprivate key is only stored on the client’s device. By making a Coinblesk payment, however,the user must entrust the Coinblesk server with his payed funds. A Bitcoin transactionnormally takes ∼60 minutes to be confirmed, depending on the numbers of expectedconfirmations [23]. To speed up these transactions i.e. to reduce the confirmation timeto less than a second, Coinblesk takes the position of an intermediary. The transaction isbroadcasted immediately, whereas the recipient gets the confirmation that the paymentis successful. This can be achieved by locking the user’s funds, as to ensure that thetransaction will pass.

By introducing channel transactions and virtual payments [76], the trust level betweenthe server and the client was further increased. The client and the recipient do not onlytrust the server to broadcast the transaction, but in a micro payment, the recipient of theactual Bitcoin transaction is the server’s Bitcoin address. The actual recipient does notget the funds transferred to a Bitcoin address, but gets it instead as a virtual balance.This virtual balance can then be used to make virtual payments to other Coinblesk users.The sender expects the server to transfer the amount to the recipient later in a separatepayout Bitcoin transaction. A user can request a payout of his funds to an actual Bitcoinaddress.

The increased trust of having the server as a recipient of a micro channel transaction is,however, limited by an upper bound threshold. Currently, the total sum of the channel

3.2. ARCHITECTURE AND TRUST 15

transaction cannot exceed a limit of 100 US-Dollar (equivalent of 100 US-Dollar in Bitcoinswith the current exchange rate). Payments above this threshold do not profit from themicro payments in Coinblesk and are directly addressed to the recipients Bitcoin address.

In this master thesis, a web application was introduced into the existing setting describedabove. Several issues occurred during the planning of the architecture:

1. A web application cannot run a Bitcoin node, although there is an interestingproof-of-concept project which is trying to achieve exactly that [15][16]. Neverthe-less, there are several libraries supporting the creation of transactions and otherpure cryptographic functionalities, without connecting to the Bitcoin network. Byusing such a library, a web application needs to connect to a Bitcoin node, to fetchor broadcast data from the Bitcoin network.

2. The private key is stored locally in the Coinblesk Android application data. It is notbeing synchronized to keep the funds always in the possession of the user. A user ofthe web application can therefore not access the funds of his Android application.Therefore, some sort of synchronization is required to offer the same functionalityon multiple devices.

3. Requests to the Coinblesk server are signed by the Android client with the same keyas a transaction would be signed. This behavior allows for maximal pseudonymity,because the main features can be used without providing any additional information(i.e. no user credentials). Web authentication, providing a common web interfacefor users and administrators as well as convenience methods like sending Bitcoins toan e-mail address, however, required further information about the user. Therefore,a user is required to provide an e-mail address and a password as login credentialsfor the web application.

A solution to the first mentioned point is to have a server which provides the necessary in-formation from the Bitcoin network directly to the clients. As described above, the serveralways broadcasts the Bitcoin transaction itself. Therefore, omitting the Bitcoin node onthe client does only affect the information of the current balance of each address. Addinga link to a publicly accessible blockchain explorer like blockchain.info [26] mitigates thistrust diminishment: The user is still able to verify the balance online, on an independentBitcoin website.

The second point can be solved by using a synchronization between the various devices.The Android client needs to share the key to another device, either by sending it over theinternet or a hardware device. Another option would be to store the private key on theserver. This would obviously allow the server to access the funds, therefore an encryptionof the key is necessary. In Section 3.5.1 Synchronization, the synchronization options arediscussed in more detail.

The last point describes the need of having additional information stored on the serverabout the user. This data diminishes the anonymity of the user as it links the Bitcoinaccount to the user’s e-mail address. One can maybe draw some conclusion out of this link,because the e-mail address may contain the user’s real name. There is a trade-off between


the convenience improvements of sending Bitcoins to an e-mail address and logging in tothe application by using an e-mail address. However, the improvement for the user, touse his own e-mail address, prevails the concerns about the privacy. A user can generatean e-mail address on any free hoster with a random (or non-informative) local-part of theaddress.

The aforementioned solution approaches present an architecture, where the server controlsthe Bitcoin node of every web application user. The Android users remain with their ownBitcoin node. A user of the web application can use the application on his desktop ormobile device at the same time. The private key is synchronized automatically over thevarious devices. An administrator can access the same web application and configureand monitor the state of Coinblesk. This relationship of the stakeholders is depicted inFigure 3.1.

A web application user needs to be authenticated with his e-mail address, as discussedabove. This requires the application to support an authentication mechanism, as well asan authorization mechanism for the distinction between the administrator and a regularuser. The following section discusses the corresponding architecture.

3.2.1 Authentication and Authorization

The Coinblesk web application consists of an unauthenticated area and an authenticatedarea. An unauthenticated user has solely access to the main Home page, the Forex page(current market trends of Bitcoin) and the user management pages (i.e. Login, Registra-tion, Activation and Password Forgotten). Every user has direct access to these pageswithout any authentication. Any other page requires the user to provide an authentica-tion token. This token will be provided by the back-end after a successful login. It is thenstored in a local database in the user’s browser, as long as the user is logged in.

A user can be authenticated with either one of the following two user roles: ROLE_USER

or ROLE_ADMIN. The role model does not intend the roles to be inherited from each other.This means that an administrator does not have access to pages annotated with the roleROLE_USER and vice versa an ordinary user does not have access to pages annotated withthe role ROLE_USER. The user role of any user can only be set by an administrator.

3.3 Overview of the Components

After the registration and a successful login, a regular user has access to the page whichdepicts their funds and a page to send funds to a recipient. An administrator, however,does only have access to monitoring and configuring pages.

3.3. OVERVIEW OF THE COMPONENTS 17

Android App User iOS/WebApp User Administrator

Coinblesk Server Bitcoin Network

TRANSACTIONS

TRANSACTIONS

BALANCES,

BLOCKS

BA

LA

NC

ES,

BLO

CK

S

USE

R A

CC

OU

NT

MA

NA

GE

ME

NT

DA

TA

Figure 3.1: Architecture diagram (image source: Flaticon [37])


3.3.1 User Account Management

As described in Section 3.2.1, it is necessary to have an authentication mechanism inCoinblesk to provide user and administration features. First, a user has to be able to pro-vide credentials and to register himself. This functionality is provided on the Registrationpage. After a successful registration, the user needs to activate his account by clicking anactivation link, to be able to finally log in.

RegistrationThe registration is a core element of the Coinblesk web application. After a success-ful registration, both a user account as well as a Bitcoin account, linked to a timelocked address, is created.

First, the user needs to provide a valid e-mail address together with a passwordand accept the terms and conditions of Coinblesk. The provided information isinstantly validated. In a second step, a Bitcoin key pair is generated. This keypair is essential for the further usage of Coinblesk. The generated private key willlater be used to sign every transaction made from the user’s Coinblesk account. Tosupport multiple devices, but still keeping the client in full possession of his funds(see Section 3.5 for more information), the private key will be shared with the serverin an encrypted form. However, during the registration, the user needs to provide apass phrase to encrypt the private key. This protects the user’s private key from aserver access. The strength of the pass phrase is evaluated during the registration(see Section 3.5 for further information). If the provided information is valid, theencrypted private key, its corresponding public key, the e-mail address, and the useraccount password is sent to the server to create a new account. In Figure 3.2 bothsteps of the registration are depicted.

The sever additionally validates the provided information. Then, it creates a newuser account with a new Bitcoin account and a linked time locked address. Theuser still needs to activate the account by using the activation token he receives viae-mail.

Account ActivationTo verify a user’s e-mail address, an account needs to be activated before a usercan log in. After a successful registration, a user receives an e-mail with an URLto the Coinblesk activation page. The URL contains a token and the user’s e-mailaddress. A click onto the URL opens the activation page, verifies the given token(see Figure 3.3, on the left). The token can also be entered manually by the user, ifhe likes to access the activation page without a token parameter. After a successfulverification, the user account is activated and the user is now able to log in.

LoginThe login page (see Figure 3.3 on the right) requires the user to provide his creden-tials, consisting of the e-mail address and the user account password. If a user wasdeleted by an administrator or has a special unregistered token (see Section 3.4.1for further information), the login is denied with a message indicating this prob-lem. Otherwise, the credentials are checked against the database. If the credentials


Figure 3.2: Both steps of the Registration, including the generation of the Bitcoin keypair and the pass phrase strength validation.

Figure 3.3: A user can manually activate his account by entering the activation tokenfrom the e-mail. Afterwards he needs to provide his credentials to log in.


match the database entries, the user receives an authentication token, which willthen be stored locally by the browser. This token is necessary for accessing anysecured page, as well as for any back-end server request via REST interface.

If a user has forgotten his password, he is able to reset it on the Password Forgottenpage.

Password Forgotten and VerificationA user can request a link to reset his password. The password forgotten pageprovides a simple input field for the e-mail address of the user (see Figure 3.4). Ifthe e-mail address exists in a Coinblesk user account, the user will receive an e-mailcontaining a link with a secret token. Together with this token, a user is able toreset his password. After a successful change of the password, the user is redirectedto the login page, where he can try to log in again.

Figure 3.4: A user can request a token to reset his password.


3.3.2 Common Area

The user account management is only accessible, if a user has not yet authenticatedhimself. If an authentication token is set, the access to these pages is denied. Instead,every user, independent of its role, has now access to the pages of the common area. Thecommon area comprises the Home, Forex and the Profile page.

HomeThe Home page is the starting page of the Coinblesk web application. This page ismainly needed as an introductory page, but also as a fallback page. For example,after a successful registration, the user is linked to the Home page, as he is requiredto activate his account first via the provided link in the e-mail. The user is alsoredirected to the Home page, if there is a routing error. Figure 3.5 depicts theHome page together with the navigational side bar.

Figure 3.5: The Home page together with the navigational side bar

ForexBitcoin has a very high volatility and trades for different prices on different ex-changes [28]. Therefore, it is necessary for a Coinblesk user to know the currentexchange rate of Bitcoin, before transferring an amount to another user.

The page Forex covers this need as it depicts the current and historic exchangerate of Bitcoin. The user is able to choose between two different exchange sources,namely Bitstamp [25] and CoinDesk [33]. They are also able to select three differentcurrencies to change to: USD, EUR, CHF. CoinDesk provides historic data over thelast 30 days. The historic dataset is used to build a line chart, showing the markettrend of the last month.

The Forex page is accessible by everyone, an authentication is not required. If auser is authenticated, this page is still accessible, no matter to what role the user isattached to.


In Figure 3.6, the Forex page is depicted. It shows a CoinDesk dataset from the28th July, 2017 with current and historic data.

Figure 3.6: The Forex page shows the current and historic market trend of Bitcoin.Screenshot made on the 28th July, 2017.

ProfileThe profile page allows the authenticated user to change his password and preferredlanguage. The preferred language is directly stored locally in the browser. Thelanguage switch takes place immediately. A user can choose between German andEnglish.

Furthermore, the user can set a new user account password. The input fields containvalidation. The user account password is necessary to log in to the Coinblesk webapplication. It mustn’t be confused with the pass phrase, which is also set duringthe registration. The pass phrase is used to encrypt the private key and is onlyneeded when the user wants to transfer his funds to another user or Bitcoin address.The pass phrase cannot be changed anymore afterwards.

Figure 3.7 depicts the Profile page.


Figure 3.7: The Profile page allows the user to change his password and select his preferredlanguage (German or English).

3.3.3 User Area

The user area contains of two separate pages: The Funds and the Transfer page. TheFunds page allows the user to manage his funds and his time locked addresses whereasthe Transfer page allows the user to transfer amounts of Bitcoins to another Bitcoin ore-mail address.

FundsThe page Funds contains a table of all time locked addresses, generated for theuser with his key pair. Every address displays the current balance together withadditional information (creation date, locked date, unlocked state and a QR code).In Figure 3.8 you can see a depiction of this page.

To be able to spend funds, Coinblesk requires the user to provide a time lockedaddress. The funds on this address can then be accessed by the server togetherwith a signature of the client. By default, a 3-month valid time locked address isgenerated during the registration. After 3 months pass, the user must generate anew address on the Funds page. If he wants to use the funds of the previous, nowunlocked address, he must transfer the funds to a new address. Funds on unlockedaddresses can directly be transferred with their total amount to the current lockedtime locked address.

Coinblesk always tries to reduce the number of actual Bitcoin transactions by usingchannel transactions and virtual payments (see Transaction Fee Reduction in Coin-blesk [76] for more information). To handle this, a virtual balance is necessary forevery account. The sum of all time locked addresses (locked and unlocked) togetherwith the virtual balance deducting a possible channel transaction amount results in


Figure 3.8: The Funds page shows a table with the current time locked addresses, theirfunds and the virtual balance. A possible channel transaction is also listed here.

the total funds available on Coinblesk. This total number is shown on the upperright on the Funds page. The virtual balance and a possible channel transactionamount is added as a separate row in the time locked address table.

All actions on the Funds page require the user to decrypt the encrypted private key,which is stored on the Coinblesk server. The key is requested by the web applicationand a modal is showing up to decrypt the key. Every action can only succeed if thekey is decrypted.

The Funds page depicts the funds available. If there are funds to spend (funds ona locked address or funds in the virtual balance), a user can switch to the TransferFunds page to spend his funds.

Transfer FundsThe core feature of Coinblesk is the fast transfer of funds from one user to another.The Transfer Funds page, or Transfer Bitcoins page, allows a user to send fundsfrom his locked Bitcoin address and his virtual balance to another user or Bitcoinaddress.

The page comprises of a simple form which contains an address field and an amountfield (see Figure 3.9). Both fields are being validated on submit. A user is allowedto enter either an e-mail address or a Base58 Bitcoin address. To simplify the inputof the address, the form supports the scanning of a QR code. The QR code mustcontain either an e-mail or a Bitcoin address. A click onto the camera icon opensthe camera – directly in the browser. While the camera is shown, it searches for aQR code. If a QR is read by the camera, the value is passed into the input fieldand the camera is closed. See Figure 3.10 for a depiction of the camera modaland Section 4.7 for further information about the implementation details of the QRscanning feature.

Additionally, there is a box showing the maximal amount of which the user is cur-rently allowed to transfer. The maximum spending value is depending on wherethe funds rely and to what type of address the user wants to send it. A user


can only spend funds of either the virtual balance or the locked address. See Sec-tion 3.4 Transferring to Bitcoin and E-Mail Addresses for further information.

Furthermore, there is a checkbox to proclaim if the user wants to subtract or add thefees from the inserted amount. If the payment can be done with a virtual payment(see the requirements in Section 3.4), no fees are added. Otherwise, the currentaverage Bitcoin transaction fees are included in the transaction.

After submitting the form, the user is asked to enter the pass phrase to decrypt hisprivate key (see Section 3.5.2 Pass Phrase Strength Evaluation for more informa-tion). If the pass phrase is valid and the form is submitted, the payment will beexecuted.

Figure 3.9: Sending funds to another user or Bitcoin address can be easily made on thepage Transfer Bitcoins.


Figure 3.10: The QR code scanner helps typing a recipient’s e-mail or Bitcoin address onthe Send Funds page.

Figure 3.11: After entering the recipients address and the amount to send, the user needsto decrypt the private key to finally create the transaction.


3.3.4 Administration

The administration contains multiple pages to manage the Coinblesk server. Namely, alluser accounts and Bitcoin addresses should be manageable. Furthermore, the administra-tor needs to have access to the server balance, a page which displays the financial stateof the server itself. Finally, an administrator needs to have access to the events page.

User AccountsThe user accounts page (see Figure 3.12) displays a paged table, listing all users ofCoinblesk. The user table contains the most important values of the user, but thereis also a link to a details page next to every user row.

The details page (see Figure 3.13) shows all detail information, including the datawhich was missing on the overview page. On the details page, the administrator isalso able to delete a user account or to switch the role of a user from ROLE_USER

to ROLE_ADMIN and vice versa. The table does also list a link to a user’s Bitcoinaccount. User accounts are automatically linked to a Bitcoin account during theregistration.

AccountsAn account contains information like the public key of the client, the virtual balance,or the channel transaction. Linked to an account are all the generated time lockedaddresses of a certain user.

The accounts page is similarly constructed as the user accounts page, because ithas also an overview page and a details page. The overview page contains a table,listing all accounts with a small set of information. Every row contains a Detailsbutton, which leads to the details page of the accounts.

On the details page, the administrator can display all information of one specificBitcoin account. This comprises the various balances, all available keys, but alsothe channel transaction is also parsed and presented. The time locked addresses,which are linked to this account, are also shown in a table on the bottom of theDetails page. Figure 3.14 shows the overview page and Figure 3.15 the details page.

Server BalanceChannel transactions and virtual payments were recently introduced in Coinblesk [76].A user expects the server to increase the virtual balance of a recipient with the sameamount he pays to the server in a channel transaction. The channel transaction iskept open to combine multiple smaller payments. The sum of all channel transac-tions needs to be equal to the sum of all virtual payments.

The recipient can pay out his virtual balance to an actual Bitcoin address. Theserver needs to fund this payment with a so-called server pot, which acts as a bufferbetween the two participant. This buffer value needs to have a certain amount ofBitcoins ready to pay out the virtual balance. When the server pays out a virtualbalance but did not yet broadcast a channel transaction to fund this payment, theequilibrium between the total amounts available in the channel transaction and thetotal amounts in virtual balances gets out of sync.


Figure 3.12: The user account overview displays a list of all users together with somebasic information and a link to the details page.

Figure 3.13: The user accounts detail page shows all relevant information about a useraccount. The administrator is also able to delete a user and switch the roles.


Figure 3.14: The account overview page displays a list of all Bitcoin accounts, registeredin Coinblesk.

Figure 3.15: The accounts detail page shows all information available about a user’sBitcoin account on Coinblesk. This comprises of all balances, time locked addresses andmore.


It might also be the case, that a channel transaction is already closed and the amountof Bitcoins is transferred to the server, but the virtual balance is not yet payed out.Thus, the server balance needs to include the current server pot value and the initialvalue of the server pot (server pot baseline).

Adding additional Bitcoins to the server pot address immediately leads to an imbal-ance of the sever balance. Every time, the buffering amount is externally changed,the change needs to be reflected to the server pot baseline. The server balance pageoffers a form to adapt the server baseline (see Figure 3.17).

The calculated equilibrium is shown on the Server Balance page (see Figure 3.16).The page shows the aforementioned situation in an equation.

The following equation (3.1) depicts the server balance calculation in detail:∑Channel Transactions

!=

∑V irtual Balances

+ Server Pot Baseline

− Current Server Pot

(3.1)

Let’s take the following scenario as an example: The server baseline is set to 10BTC. Now, Bob transfers 1 BTC to Alice and creates a micro channel. Alice’svirtual balance increases to 1 BTC. The equation (3.2) depicts this scenario.

1 B!

= 1 B + 10 B− 10 B (3.2)

Let’s now assume, that Alice makes a payout of her virtual balance to, for example,make a payment to a regular Bitcoin address. The payout leads to a transactionfrom the server to Alice with the amount of 1 BTC. Equation (3.3) depicts thisscenario.

1 B!

= 0 B + 10 B− 9 B (3.3)

Shortly before the time locked address gets unlocked, the server distributes thetransaction into the Bitcoin network. The payment channel to Bob is closed andthe transaction is done. Now, there are no more open payment channels, there is noamount on a virtual balance and the server received his funds back. Equation (3.4)depicts this scenario.

0 B!

= 0 B + 10 B− 10 B (3.4)

EventsThe events page shows server events, which occurred on the Coinblesk server. Theseevents are grouped into several categories: FATAL, ERROR, WARN, INFO and DEBUG.Depending on the severity of the event, the event is classified and separately shownon the events page. The events are grouped by severity but, in every group, docontain events of a higher severity class. This means that events of the selectedgroup ERROR automatically do also contains events with the severity FATAL. Formore information about the events, please refer to the Section 4.8.3, which explainsthe implementation of the events.


Figure 3.16: The server balance shows an equation which depicts the equilibrium betweenchannel transaction, virtual balances and the server pot.

Figure 3.17: The server pot baseline is the server pot buffer amount of Bitcoins. Theserver baseline can be adapted to add or withdraw buffering funds.


3.4 Transferring to Bitcoin and E-Mail Addresses

Depending on the address type and the fund distribution of the sender, the maximalamount as well as the transaction type may differ. The following list distinguishes betweenthe possible scenarios.

1. The user wants to send to a Bitcoin address.

(a) The maximal amount allowed to transfer is the amount on the locked address.If the user has only enough funds on an unlocked address, he must transfer itfirst to the locked address on the Funds page. If the user only has enough fundson the virtual balance, the user must payout his funds first. Furthermore, fundsources cannot be mixed for a single payment.

2. The user wants to send to an e-mail address.

(a) If the amount is lower than the virtual balance of the sender, the funds aredirectly transferred to the recipient. This virtual payment does not requirepayment fees, because the transaction is solely made in the database of Coin-blesk.

(b) If the amount is higher than the virtual balance of the sender, the funds cannotvirtually be transferred to a recipient. If the funds on the unlocked address arehigh enough, an actual Bitcoin transaction can be made. If the funds on theunlocked address are lower than the amount, the user is not allowed to makea payment.

It needs to be evaluated if the maximal micro payment (a Bitcoin transactionto the server, combined with increasing the virtual balance of the recipient) of100 US-Dollar is exceeded with this payment.

i. If the maximal micro payment threshold is not yet exceeded by sendingthe amount over a micro channel, a transaction is prepared. The receiverin the Bitcoin transaction is the server pot address. The e-mail addressof the actual receiver is then sent to the server together with the builttransaction.

ii. If the transfer via micro payment would exceed the threshold, the amountis directly transferred to a recipient’s Bitcoin address. In this case, onlyregistered users can receive funds. Unregistered users do not yet have avalid Bitcoin address connected to their user account.The locked Bitcoin address of the recipient is then requested from theserver with the recipient’s e-mail address. If the user is registered, a pay-ment is possible. A conventional Bitcoin transaction is created from thesender’s Bitcoin address to the receiver’s Bitcoin address. Regular Bitcoinfees occur, as well as the usual Bitcoin confirmation delay of around 60minutes [23].

3.5. DEVICE-INDEPENDENT PAYMENTS 33

3.4.1 Transferring to Unknown E-Mail Addresses

If the e-mail address of the recipient is not yet in the system, micro payments are stillpossible. The received amount is stored as a virtual balance in the Coinblesk database.A sender has however a limit of 100 US-Dollar when sending funds over a micro paymentchannel. An unregistered user does not yet have a Bitcoin address connected to hisaccount. This address is initially created after the registration of the user. This processcannot be done earlier, because the private key of the user cannot be generated on theserver but must be generated during the registration inside the user’s web browser.

If a micro or virtual payment is made to an unregistered user, a new account is createdfor him. If the payment is successful, the user receives a notification via e-mail. The no-tification contains a special URL which links to the registration form. The URL containsa registration token, which is necessary for the user to register. After a successful regis-tration, the user must access his virtual funds directly like a regular user. From then on,he is also able to receive external Bitcoin payments, not only micro payments, or virtualpayments.

3.5 Device-Independent Payments

Previously, an Android app contained a full Bitcoin node to create transactions with thelocally stored private key. This concept, however, limits the usability. A user is only ableto make a transaction with the same device.

In case of a theft or an irreversible crash of the storage, there was no access to the fundson Coinblesk anymore. Furthermore, there was no web access or any other form of accessto the funds. The user was always required to use his Android phone, whereas iOS userswhere debarred from the begin with. A desktop user did not have access to his funds atall. The benefit of this concept is its simplicity: There are neither synchronization issuesnor security impacts. Another benefit is, that there is a Bitcoin node running in theAndroid device, which can directly check if the funds are received or not, which increasesthe credibility of the server: The client checks by itself, if a transaction was made or not.

With the introduction of payment channels and virtual payments [76], the dependency tothe server has been increased. Up to a certain amount, funds are administrated by theserver. A Bitcoin transaction is made from the client to server, and kept back by the server,instead of making a direct transaction from one user to another. This concept greatlydecreases the transaction fees, but creates a lack of transparency: The user cannot see onthe Bitcoin blockchain if a transaction was made and confirmed and the recipient receivedhis funds. He must trust the server instead. The server on his side keeps transactionsback up to a certain amount to combine all payments, where it only increases a virtualbalance of the recipient.

As the transactions cannot be tracked as expected, the need to have a Bitcoin node onthe client itself therefore decreases. The added security to have full possession over allnot yet spent funds with multi-signing is however essential. This opens a new possibility:


A web application with a safe, cryptographic Bitcoin library covers this requirement butstill offers features like multi-device support or the access from previously unsupportedmobile (iOS) and desktop devices.

3.5.1 Synchronization

To be able to access to Coinblesk on multiple devices, a synchronization is necessary.Holding on to the multi-signing feature is essential for keeping the funds in the possessionof the user. Therefore, the user needs to be able to sign a transaction on all his devices.This can only be achieved, if he the private key of his funds is synchronized to everydevice, he wants to be able to make transactions from.

Sharing the key over InternetOne way to achieve this, is to create a sharing function for the private key. TheAndroid application could be using the default Android sharing feature [6] and sendthe private key to another device. Depending on the medium he chooses to send thekey over with, this might lead to a critical security breach. If the user e.g. uses anon-secure e-mail to send the key to an e-mail address of his own, the communicationwould not be safe.

Sharing the key by handAnother option with increased security would be to just to copy the key by hand,character by character. This option would be safe, but very inconvenient for theuser. An inexperience user would probably not understand we he had to copy it byhand instead of just sending it over the Internet.

Sharing the key with a QR codeThe abovementioned option could be enhanced by using a QR code. Using sucha code would increase the usability very much and it would keep the high securityrequirements of the transfer. The main drawback of this option, however, is, thatthe receiving device requires to have a camera and a QR barcode scanner in it.Whereas mobile devices, such as tablets or smartphones usually have a camera,desktop devices such as computers do not always have one. Furthermore, a userneeds to physically have those two devices next to each other to share the privatekey. This diminishes the gained advantage through QR codes, because desktopdevices are a main target of the multi-device usage of Coinblesk.

Storing the key on the serverAnother possibility is to store the key on the server. Storing the client’s private keyon the server reduces the concept of multi-signing to absurdity. The server will beable to access the funds by using the key of the client and the key of the server,which would both be stored on the server.

Cryptographic methods are meanwhile largely supported by modern web browsers [31].Thus, Bitcoin transaction signing in web browsers is possible. Additionally, it allows theusage of standard encryption/decryption algorithms like AES.

3.5. DEVICE-INDEPENDENT PAYMENTS 35

Encryption solves this problem by storing the private key on the server in an encryptedform. The private key can locally be encrypted with JavaScript and then be submittedto server. As soon as the client requires the key, it will be transferred over an encryptedSSL/TLS connection. The client is able to decrypt the key with his secure pass phrase.The decrypted private key can then be used to create Bitcoin transactions and access thefunds.

The main drawback of this method is, that the user may use a pass phrase which is tooweak. A weak pass phrase increases the vulnerability of the account. A malicious servercould try to encrypt the pass phrase. To prevent this, a strong pass phrase evaluation canbe made when encrypting the private key, i.e. before submitting it to the server the firsttime. The pass phrase is required in the registration and cannot be changed afterwardsanymore. Therefore a pass phrase strength evaluation takes place, before allowing theuser to register (see 3.5.2 Pass Phrase Strength Evaluation).

The option to store the client’s strongly encrypted private key on the server was selectedas the best options to resolve the synchronization problem.

3.5.2 Pass Phrase Strength Evaluation

When storing the client’s private key on the server, the pass phrase is the only encryptionwhich protects the funds from being accessed by a malicious server. Therefore, there wasa need to create a strength evaluation for the user’s pass phrase.

The authors of paper published on 2012 IEEE Symposium on Security and Privacy [48]compared several password restriction conditions against each other. They found, thatis much more efficient to have longer passwords, than to have smaller ones with strongconditions (uppercase/lowercase, special characters etc.). Furthermore, they found, that”basic16 provides the greatest security against a powerful attacker”. basic16 describes thecondition of having at least 16 characters but no further restrictions [48].

Considering the findings of the aforementioned paper, the pass phrase evaluation im-plemented in Coinblesk requires the user to enter at least 16 characters (with at leastone letter). Pass phrases with less characters are not accepted. To further increase thedifficulty of maliciously decrypting the private key, the following indicators were added.They provide additional information for the user: The presence of numbers, the pres-ence of special characters and the presence of upper- and lowercase characters. Satisfyingthese optional conditions increases the strength of the pass phrase even further becauseit enlarges the domain of possible characters [48].


3.6 Progressive Web App

The web application was designed to be compatible to the requirements of a progres-sive web application (see Section 2.2.2 for further information about a progressive webapplication). This means that Coinblesk can be installed as stand-alone ”Home screen”application, which is running no matter if there is Internet or not (offline mode). Anindicator message displays to the user, that he is currently offline and cannot use allfunctionality.

All the styles have been adapted, so that the application is completely responsive. Everypage can be opened on a smartphone, a tablet as well as on a desktop device. The sidebarhides behind a Hamburger icon (see Glossary), if the width of the screen is not highenough. The Hamburger icon can also be seen on the right side of Figure 3.18. Everytable, with a large width got a scroll bar below and is therefore also viewable on a smallscreen device.

In Figure 3.18 you can see Coinblesk as a Home screen application and Coinblesk runningin the offline mode on a smartphone. In Figure 3.19 you can see a Coinblesk page invarious resolutions, depicting the responsive designs.

3.6. PROGRESSIVE WEB APP 37

Figure 3.18: On the left side you can see the Coinblesk web application installed as aHome screen application on an Android smartphone. On the right side, you can see theapplication running in the offline mode.


Figure 3.19: The administration page User Accounts is depicted on various screen size todemonstrate the responsive behavior of the web application (raw image source: [50])

Chapter 4

Implementation

This chapter discusses the implementation of the previously in Chapter 3 described designof the web application. It starts with the architecture of the front-end and the buildprocess with Webpack. It goes on with the implementation details about the servercommunication, the state management and the routing. Then, the introduction of theconcepts of a progressive web app are described. Due to the fact, that Bitcoin transactionsare required to be created in the front-end, transaction-building in JavaScript is discussed.Coinblesk offers a QR code to share and scan Bitcoin and e-mail addresses. Details aboutthis, are discussed in Section 4.7. Finally, an overview on the refactorings of the existingCoinblesk application is given.

4.1 Front-End Architecture

The web application is based on the official boilerplate template of Vue.JS with Web-pack [82]. This basic template contains only a single web component. The folder architec-ture was then adapted and several Vue.JS plugins were added to match the requirementsof a multi-page web application with a separate configuration and services (see the sub-sequent sections for more detailed information about added plugins). In Figure 4.1 theadapted folder structure is depicted.

The build process is created with Webpack, which bundles JavaScript and other front-endresources. It is based on the Vue.JS Webpack template [82]. This default build processsupports multiple loaders: For example, a newer version of JavaScript, ECMAScript2015,is supported and then transpiled to a JavaScript version understood by most browsers(ECMAScript5 ). Furthermore, there is a Sass loader, which allows to write style sheetsin Sass/SCSS instead of CSS. Depending on their file size, fonts and images are includedinto the style sheet as Base64 or are created as file resources. Finally, when building forproduction, JavaScript and CSS resources are minified and uglified. A content hash isadded to the file name of every built file to prevent caching issues.

Components are created using the single-file-component pattern of Vue.JS. This patterncombines the HTML, JavaScript and Styles of one component into a single .vue file [84].

39

40 CHAPTER 4. IMPLEMENTATION

|- src

|- assets # static resources → will be compressed and hashed

|- fonts # static font files, extracted from Google Fonts

|- components # main components

|- auth # components with authorization

|- config # app configuration (e.g. routing, Vuex, etc.)

|- services # outsourced logical code

|- styles # Sass styles

|- static # static resources, copied 1:1 (e.g. manifest.json)

|- dist # productive build folder → generated files

|- node_modules # build dependencies

|- build # building configuration

Figure 4.1: Front-End Folder Architecture

The styles inside this component can be scoped. Vue.JS then generates unique HTMLattributes for the template and the styles (e.g. data-v-2dbcea38). This allows the usageof simple CSS selectors without any side effects.

The templates are being designed to support multiple languages. Every translatable stringinside the templates is replaced with a key like this: {{ $t(’demo.greeting’) }}. Thelanguage artifacts can then be specified globally or locally in the component inside the<i18n/> tag. The language of the application can easily be switched. Changing a languageimmediately replaces every key with the selected language values. The complete Coinbleskweb application is available in English and German. More common keys are translatedglobally in a single file whereas more specific keys are translated inside a component.

An example of a Vue.JS component, how it is used in Coinblesk, is provided in Figure 4.2.

4.2 Server Communication

The web application is built with a server-client architecture and a RESTful interface in-between. The client-server communication uses the JSON format. Further, the authenti-cation and authorization between of a client is done with a JSON Web Token (JWT) [47].

A JSON Web Token contains a payload, which is used to provide the user role to thefront-end web application. Furthermore, it contains a signature, which signs the payload.The full token is necessary to communicate with the server’s /auth interfaces.

There are three /auth interfaces: One for the administrator, one for the regular user andone for common functionality. This is necessary, because the user roles do not inheritfrom each other: An administrator does not have access to REST interfaces of a regularuser (see Section 3.2.1 for further information).

The interfaces either return the expected response or deny the request by throwing anexception. The exception is always marked and therefore not visible by the front-end. A

4.2. SERVER COMMUNICATION 41

<template>

<div class="main">

<p>{{ $t('demo.greeting') }} {{ name }}!</p>

</div>

</template>

<script>

export default {

data: function () {

return {

name: 'Sebastian'}

},

mounted: function () {

console.log('Component is mounted');}

};

</script>

<style lang="scss" scoped>

@import '../styles/variables';

.main p {

color: $blueish-color;

}

</style>

<i18n>

{

"en": {

"demo": {

"greeting": "Hi"

}

},

"de": {

"demo": {

"greeting": "Hallo"

}

}

}

</i18n>

Figure 4.2: An example of a Vue.JS component using the single file pattern, includingscoped SCSS styles and local i18n translations.


valid JSON is always returned as the payload of a request. When a custom exception,which was created with a Spring @ResponseStatus annotation, is thrown, the status codeand reason of this annotation is used to generate the JSON response. A list of non-customexceptions is mapped to certain status codes and reasons. If an exception does not meetany of these requirements, an internal error is returned. Depending on the environment(e.g. PROD vs. DEV), the attribute ”exception” and the attribute ”message” is hidden. Thedefault format is depicted in Figure 4.3.

{

"timestamp": 1502794636817,

"status": 400,

"error": "Bad Request",

"exception": "InvalidAddressException",

"message": "An invalid address was provided.",

"method": "GET",

"path": "/auth/user/payment/utxo"

}

Figure 4.3: The server response when an unhandled server exception occurred.

The exceptions are handled by the web application automatically. There are HTTP com-munication interceptors implemented, which catch an error and handle it. The followingsubsection will discuss the implementation of the HTTP interceptors.

4.2.1 Interceptors

The web application utilizes many HTTP requests to server. Those requests are listed inthe HttpService. Depending on the interface, server denials or exceptions are expected.An example for such an interface is the /login. This interface might respond with anerror, because the user provides false credentials which cannot be checked on the client-side. Therefore, a doNotIntercept hook was implemented, to suppress an automaticserver error handling in certain cases.

In most cases, however, the requests from the front-end are validated before the actualcall to the back-end is made. In those cases, global error management is beneficial. Forthis reason, an HTTP interceptor was created. All HTTP requests and responses first gothrough this interceptor.

First, a possible available authorization token, which was received during a login, is addedto the request header. This is necessary to authenticate a request. Unauthorized sessionsare skipping this step. Moreover, the response is evaluated. The evaluation is basicallymade via the returning status code:

4.3. STATE MANAGEMENT 43

Status code 0:The application is offline. A message is presented, that this call is not possible atthe moment. Usually offline calls should be prevented by the component logic: Acomponent which is offline available should check the offline status first before doinga server call. See the Section 4.5.2 about offline-mode for further information.

Status code 2xx:The request is successful and no error handling is triggered.

Status code 401:If the user is logged in and still receives a 401, the session is expired and the user islogged out. In any case, the user is redirected to the /login page.

Status code 400:A message is shown to the user, that the data could not be loaded and that an erroroccurred.

Status code 403:A message is shown to the user, that the necessary permissions are not given.

Any other status code:It is assumed, that an internal error occurred. A red message shows the user, thatsuch an error occurred and the page is reloaded after 3 seconds.

4.3 State Management

The state management of the web application is based on a Vuex [85] Store. Vuex isa ”state mangement pattern and library” of Vue.JS [85]. It provides a centralized storefor all the Vue.JS components [85]. The state can then only be changed in a predictablefashion over an API [85]. When changes are made to the Vuex Store, all the componentsusing the changed attribute are informed and updated [85].

In the Coinblesk web application, Vuex is used to store the JSON web token (see Sec-tion 4.2), the extracted role and additional information about the user and his currentBitcoin balance. Furthermore, the preferred language and the online/offline state of theapplication are part of the Coinblesk Vuex store. All those properties can be accessed andupdated from the components.

The access and setting of the properties is done via mutations and actions [85]. Thedifference between those two types is the way they operate: A mutation is an immediate,synchronous change of a property. An action, however, is asynchronous and returns apromise. In an action, it is therefore possible to make asynchronous calls without resolvingthe promise until the asynchronous call is done. In Coinblesk, mutations were only usedwithin the store, but all public methods were actions. The benefit of this concept isthat there is always the same interface for changing a property and asynchronous callsare possible. An example of an asynchronous store method would be updateUser: Thismethod updates the Vuex Store with the newest data from the server. The server request is


obviously asynchronous, but the caller of this method can still catch the resolved promise,of when the action is actually finished.

The Vuex Store is created on page load like all JavaScript components in the Coinbleskweb application. All the data of the store would be lost after a page refresh. This mightnot be a problem for the current user data, which can be fetched again from the server,but the user role and the authentication token would also be lost. This would meanthat a reload of a page would immediately log out the user. To prevent this behavior,the vuex-persistedstate [86] plugin is used to persist the store to a local in-browserdatabase. vuex-persistedstate stringifies the data and persists it on every change intothe LocalStorage [53]. On reload of the page, this plugin automatically restores the VuexStore from the storage and the user won’t be logged out.

4.4 Routing

The Coinblesk web application is built as a single page application (SPA). A single pageapplication does not reload the web browser during the whole session and can be thoughtof as a ”fat client that is loaded from a web server” [58]. To link through the components ofthe page, a routing mechanism is necessary. The Coinblesk web application offers variousdifferent pages (see Section 3.3) and therefore routing was required.

Vue.JS provides an official package for routing through the components: vue-router [83].All components which should have their own URL need to be registered in the vue-routerconfiguration. The resulting URL of a components can also have parameters. The pathsneed to be provided as a path-to-regexp [64] path. path-to-regexp is a library whichis internally used by vuex-router and which parses the given paths and makes the stringsusable for routing.

Not every route should be accessible by any user: Some routes require an authentica-tion, some an authentication and a specific role. The authentication and authorization ishandled directly before a user enters a route. vue-router offers a method beforeEnter,which can be used to make the required checks. If any of the checks fail, the user isautomatically redirected to another site – before even entering the path’s component.

In Figure 4.4 a simplified example of such a routing definition, where it is required to haveadministration permissions (i.e. the role ROLE_ADMIN), is depicted.

The routing concept was then extended to also allow offline routing. See more aboutoffline routing in the subsequent Section 4.5.2.

4.4. ROUTING 45

// configuration

{

path: '/auth/admin/accounts',name: 'admin-accounts',component: AdminAccounts,

beforeEnter: requireAuthAndAdmin

}

// beforeEnter check

function requireAuthAndAdmin(to, from, next) {

if(!Store.state.auth.authenticated) {

// show unauthorized warning

// redirect to login

next({ name: 'login' });

} else if (Store.state.auth.role !== 'ROLE_ADMIN') {

// show forbidden warning

if(from && from.path) {

// return to previous page

next(from.path);

} else {

// return to home page if no previous page available

next({ name: 'home' });

}

} else {

// just continue

next();

}

}

Figure 4.4: A simplified example of a routing requirement as an administrator.


4.5 Progressive Web App (PWA)

Building a progressive web app (PWA) requires at least two main functionalities on topof a regular web application: Offering the user a shortcut to the application, which allowsit to run stand-alone and providing an offline experience. A responsive web design andother functionalities introduced with Web 2.0 are a precondition, because they are alreadynecessary to build a regular web application. How the two main functionalities of aprogressive web app are implemented in Coinblesk is described in the following two sections4.5.1 Standalone Application and 4.5.2 Offline Mode.

4.5.1 Standalone Application

To create a stand-alone application, a manifest.json has to be defined. This manifest in-cludes meta-data about the Coinblesk application. Figure 4.5 depicts the manifest.json

of the Coinblesk web application.

{

"name": "Coinblesk",

"short_name": "Coinblesk",

"icons": [

{

"src": "/static/img/icons/android-chrome-192x192.png",

"sizes": "192x192",

"type": "image/png"

}, {

"src": "/static/img/icons/android-chrome-512x512.png",

"sizes": "512x512",

"type": "image/png"

}

],

"start_url": "/index.html",

"display": "standalone",

"background_color": "#353535",

"theme_color": "#c6ff00"

}

Figure 4.5: The Coinblesk web application manifest.

The manifest includes the application name and a short_name which is then used belowthe Android home screen application icon of Coinblesk. The home screen icon itself isdefined in the manifest as the icon with the size 192x192 (see Figure 3.18 for a screenshotof such a home screen application with the 192x192 icon and the short_name).

When opening the application from the home screen, a loading screen is shown. This load-ing screen consists of the large icon (512x512), the application name and the background

4.5. PROGRESSIVE WEB APP (PWA) 47

color which is also defined in the manifest. The theme_color is used as an indicator color:When the application is opened, the Android status bar gets colored with the theme color.The start_url defines the HTML page to where the user is sent to when he opens theweb application over the home screen shortcut.

Finally, there is the display option, which makes the application look like a native ap-plication. By using the value standalone, the browser navigation bar gets hidden. Theapplication is running in a full-screen mode, only showing the system status bar on top.

Running the application with the current setup via home screen does only work, if theuser is connected to the Internet. If a user is offline, a browser error message (”Page NotFound”) is shown inside the full screen application. To prevent this, an offline mode needsto be implemented.

4.5.2 Offline Mode

A main part of building a progressive web app (PWA) is supporting an offline mode.Multiple parts of the application need to support the offline mode. For example, duringthe process of the routing, it needs to be decided, if a component can be accessed ornot. Then, when a user is offline, the communication with the server is not possible. Allcalls made automatically or deliberately need to first check, if a connection is possible.To support a true offline behavior, the data from previous calls need to be cached. Andfinally, the build process needs to be adapted to serve a service worker with a list of filenames together with their content hashes.

Offline Routing

To accomplish an offline routing behavior, a router path needs to be defined as offlineroutable or not. For example, the Forex page is offline routable whereas the TransferFunds cannot be made offline routable. Trying to access such a page should immediatelybe denied and the user should be redirected to the Home page.

To achieve such a behavior, every offline-routable component needs to be defined as such:The most convenient way to do this, is to introduce an additional component attributecalled ”offline”. The decision, if the component is offline routable or not, lies thendirectly inside the component itself. This value can be used during the routing process.In Section 4.4 the beforeEnter method was introduced. This method can be extended tosupport an offline behavior. In Figure 4.6, this process is depicted in a simplified manner.

The offline attribute of a component can also be used in the navigation bar. When a useris offline, not every page is accessible. There is, however, an indicator in the navigationbar which displays the non-accessible pages grayed out. This is done automatically: If thecomponent’s offline flag changes after some time, the navigation bar automatically reactsto this new behavior. This allows to develop a component without knowing anythingabout the navigation bar or the routing.


// Forex component definition

export default {

name: 'Forex',offline: true, // ← flag as offline available

data: function () {

selectedCurrency: 'USD',[...]

}

[...]

}

// beforeEnter routing check (no authentication)

function noAuth(to, from, next) {

if(!Store.state.offline) {

if(component.offline) {

next();

} else {

// show offline warning

next({ name: 'home' });

}

} else {

next();

}

}

Figure 4.6: ”offline” attribute definition in the Forex component to allow routing to thispage when the user is offline.

Data Caching

To provide a true offline experience, not only the static files (see the subsequent sub-section), but also the dynamic data needs to be cached. For example, the Forex pagedisplays the current and historic market trend of Bitcoin vs. a fiat currency. This datais immediately loaded when a user accesses the page. When a user is offline, this datacannot be retrieved. To circumvent this, there are two different approaches:

1. After the login, all necessary data, which can be found anywhere in the applicationis initially loaded. Then, the client communicates from time to time with the serverand asks for new data. All the data is stored in a local database.

2. Data which is loaded from the back-end while going through the application in theonline mode is cached in a local database. Every call is stored and provided witha timestamp. If a user enters the same page again in the offline mode, the cacheddata is retrieved from the local database.

4.5. PROGRESSIVE WEB APP (PWA) 49

Choosing the first option leads to a large amount of data being loaded after the login.During this time, the user needs to wait for the data, which leads to a worse user expe-rience. Furthermore, the loaded dataset largely increases the requested amount of datafrom the server. The requested data, however, is most often not used, because most usersdo not visit every single page. Finally, the data requests of the whole application need tobe centralized in the login component. This splits the code which belongs together intotwo separate places.

The second approach, however, offers a larger flexibility: The logic is concentrated insidea component. The data is loaded, when it is necessary, but is still available after the userwent offline. The main drawback of this approach is, that the user needs to first visitevery page, if he wants to have a full offline application.

In Coinblesk, the second approach was chosen. After loading the data in offline-accessiblecomponents, the data is additionally stored in an IndexedDB1. When the user returnsin the offline-mode, the previous data is retrieved from the IndexedDB and presentedtogether with their retrieval date.

Requests to the back-end with the main purpose of providing data to the server cannoteasily be cached. An example for this would be the Transfer Funds page. A transactioncannot be built with old Bitcoin transaction inputs, which could have already been usedon another device. Therefore, online access is necessary for certain pages.

Service Worker

To create an offline web application, a service worker is required. A service worker actsas a proxy between the server and the client and provides for example cached files to thefront-end (see Section 2.2.2 for further information about service workers). In Coinblesk,all static resources like fonts, images, JavaScript files etc. are cached and provided by theservice worker.

Every time the web application is loaded, it checks for an update of the service-

worker.js file. If there is a change in this file, all the static content is loaded againin the background. On the next page refresh, it will use the new content.

When creating a service worker, it is of upmost importance to make sure, that the filescan be updated when a new version of them is deployed. This can be done by addinga hash of the file content to each file name as a parameter. Changing a file results in achange of its hash, what finally results in a file change of the service-worker.js. Thebrowser detects this change and refreshes the static content in the background.

The service worker has to be generated during the build process to add the static files withtheir hashes. Vue.JS offers a build process template package which extends the regularWebpack build (described in Section 4.1) [82]. The service worker is then automaticallygenerated. It can only be run with a prod build to prevent caching during the development.A script is provided to test the productive build on localhost (see Appendix A.1).

1An IndexedDB is a ”low-level API for client-side storage of significant amounts of structured dataincluding files and blobs” [43]


4.6 Building Bitcoin Transactions with JavaScript

The core of Coinblesk is the transfer of Bitcoins from one person to another. As discussedin Chapter 3, there are multiple benefits when the client creates a transaction by himselfon the client device. Making transactions on the server on the other hand transfers thepossession of the funds to the server, increases the trust and is therefore not a viablesolution.

Creating the transaction on the client in a web application means that the transactionneeds to be built and signed in JavaScript. There is an undocumented but well-maintainedlibrary called Bitcoin.JS [19] which supports the cryptographic procedure to create andsign a transaction. The library does also support advanced features like multi-sig or HDwallets [19].

To create a transaction, first the transaction fee has to be calculated. The fee is providedby the Coinblesk server in the unit Byte/Satoshi. To find out, how large the fee in totalSatoshis is, the number of Bytes of this transaction needs to calculated. The transactionsize heavily depends on the number of inputs: The more inputs there are, the moresignatures have to be provided. The most simple way of calculating the Byte numberis to create a temporary transaction and sign all inputs. Bitcoin.JS then provides thenumber of Bytes. Because a second signature will be added eventually by the server, anassumed value of 75 Bytes/input is added on top of the calculated transaction size.

Then, to create the actual transaction, every input transaction needs to be added togetherwith its corresponding output number (the output index of the transaction which is used).The outputs are usually the server pot (when using micro-payments) and the sender’saddress for the change. The change is calculated as the Total Input Amount minus theSending Amount minus the Fee. Finally, every input needs to be signed with the CLTVredeem script, which is provided by the server. Bitcoin.JS, however, did not supportCLTV redeem scripts.

4.6.1 Supporting CLTV Redeem Scripts

Unfortunately, Bitcoin.JS does not support 2-of-2 multi-signature redeem scripts with atime lock which is how they are used in Coinblesk (see Section 2.1 for further information).The script is created by the server according to the definition of a two-factor wallet witha time lock, specified in BIP0065 [18].

The redeem script is composed of the following structure (see also Figure 4.7 for a formalrepresentation of the redeem script). It first requires a signature of the server. If theserver’s signature is not valid, it checks, if the lock time is expired. Only if one of theseconditions are met, the client’s signature is checked. In any case, the client’s signaturehas to be valid. Such redeem scripts are also labelled as CLTV, because of the introducedCHECKLOCKTIMEVERIFY opcode in BIP0065.

The Bitcoin.JS library was then extended to support BIP0065. When a CLTV redeemscript is detected, the already available multi-sig feature of Bitcoin.JS is used to create

4.7. QR CODE – SCANNING AND DISPLAYING 51

IF

<server pubkey> CHECKSIGVERIFY

ELSE

<expiry time> CHECKLOCKTIMEVERIFY DROP

ENDIF

<user pubkey> CHECKSIG

Figure 4.7: CLTV redeem script according to its definition in BIP0065.

and sign the transaction. In a second step, the server parses the transaction and extractsthe client’s signature chunk of every input. This chunk is the only relevant chunk, becausethe server signature is only added after the submission on the server-side. Therefore, allother input chunks, which are provided because of the multi-sig feature of Bitcoin.JS, areomitted. The server is able to finish the transaction with the user’s signature of eachinput.

4.7 QR Code – Scanning and Displaying

A Bitcoin address contains 26-35 alphanumeric characters [22]. It is therefore cumbersometo share such an address by hand from one person to another. Thus, QR codes wereestablished to share Bitcoin addresses [20].

The Bitcoin QR Code format was specified in the approved Bitcoin proposal BIP0021 [17].This proposal defines an URI format for a Bitcoin address with additional options. Theresulting scheme is then encoded into a QR code. Figure 4.8 depicts an example of suchan address format with its corresponding QR code.

bitcoin:1HVnjExerLUsahcyZ4aRVfd9wPKGY4T6Bp?amount=10&label=Schrepfer

&message=Master%Thesis↪→

Figure 4.8: An example Bitcoin URI scheme compliant with BIP0021 and its correspond-ing generated QR code.


Such QR codes are also useful in Coinblesk: If a user wants to send funds to anotherperson, he needs to provide the recipient’s Bitcoin or e-mail address (see Section 3.4 forfurther information about how to send funds as a Coinblesk user). It is very convenientto be able to scan QR codes of another Coinblesk user or of an external Bitcoin address.It is especially cumbersome on mobile devices, since a user has to completely switch fromthe Coinblesk web application app to another app to copy an address.

Coinblesk therefore provides a QR code for every Bitcoin address on the Funds page (seeFigure 3.8 for a depiction of this page). It further provides a QR code of the e-mailaddress for a virtual payment inside of Coinblesk. The QR codes are generated with asimple library called qr-code-generator [65].

During a payment, the address can be scanned with a QR scanner. The Transfer Fundspage offers a camera modal, which is able to parse the QR code. For further informationabout this page, see Section 3.3.3; Transfer Funds. The parsed QR code content thenneeds to be evaluated. If the address contains a valid pattern according to BIP0021, theinput fields on this page are filled with the address and possibly the requested amount. Ifthe content does not match the pattern, it is just put into the address field. The submitvalidation then requires the field value to be a valid e-mail or Bitcoin address.

4.8 Refactorings

Several refactorings were made on the Coinblesk server during the course of this thesis. Adebug page was developed to simplify the first steps of new developers. The REST APIwas refactored and visualized. Finally, events were introduced to prevent an excessiveautomatic e-mail sending to the administrator.

4.8.1 Debug Page

The server application was refactored to always respond with a valid JSON – eitherthe expected response or an error JSON (see Section 4.2 for further information). Tosimplify the first steps of a new Coinblesk developer, a Debug page was created. Thispage lists often used tools like e.g. the H2 console, the development database interfaceor the Swagger UI interface. The debug page is only accessible if the Spring developmentprofile dev is active and excluded in production. See Figure 4.9 for a depiction of thedebug page.

4.8.2 Swagger UI and API Refactoring

Swagger UI [77] is a tool to ”visualize and interact with the API’s resources withouthaving any of the implementation logic in place”. Springfox’s Swagger [73] integratesseveral REST interfaces into the Spring-based application which can then be accessedby the Swagger UI to represent the full API in the browser. The REST interfaces of

4.8. REFACTORINGS 53

Figure 4.9: The debug page.

the server are listed together with the expected DTO structure of every single interface.Furthermore, calls to the API can directly be made inside the browser with custom data.

The Coinblesk API interfaces for authorized users are only accessible when a valid JSONWeb Token is given (see Section 4.2 for further information about a JWT authenticationand authorization). The Swagger UI can be configured to support an additional header.The JWT authorization token can therefore be copied to the Swagger UI configurationand it will support authorized requests to the Coinblesk server.

Most interfaces of Coinblesk were available both in a regular notation (e.g. /user/login)and in multiple short forms (e.g. /u/l and /user/l). This short form was previouslyintroduced as a handy method for manually typing the URI. By using Swagger UI, therewas no need for short forms anymore. The API was therefore simplified and all the shortforms were removed. The API has been substantially narrowed down by removing theshort forms. Figure 4.10 shows the Swagger UI representation of the Coinblesk API afterthe refactoring.

4.8.3 Events

In the previous Coinblesk version, several critical events in the server application led tothe sending of an e-mail to the administrator. With the introduction of a server adminis-tration, these events could also be displayed inside this administration (see Section 3.3.4;Events for further information about the event listings in the server administration).

Occurring events are saved in the database by type and severity. Additionally, a descrip-tion is added to each event to describe the context of the event. Possible event severitiesare FATAL, ERROR, WARN, INFO and DEBUG. Depending on the severity of an event, there isa configurable setting which periodically sends out an e-mail to the administrator if thethreshold is exceeded.


The thresholds are checked every 10 minutes. They are defined as follows: An e-mail issent when at least one of the following conditions is met.

• At least 1 FATAL event occurred in the last 10 minutes.

• At least 5 ERROR events occurred in the last 10 minutes.

• At least 20 WARN events occurred in the last 10 minutes.

INFO and DEBUG events never provoke the sending of an e-mail.

Using this algorithm prevents the sending of too many e-mails to the administrator. FATALevents like ”Server Balance Not In Sync”, however, always lead to the sending of an e-mailto the administrator.

Figure 4.10: The Swagger UI representation of the Coinblesk API after the refactoring.

Chapter 5

Evaluation

This chapter discusses the evaluation of the Coinblesk web application. Two differentapproaches were made. The chapter starts with a usability evaluation, which was madewith the System Usability Scale questionnaire. Finally, the automatic analysis of theprogressive web app with Lighthouse is discussed in Section 5.2.

5.1 SUS Usability Evaluation

The usability of the Coinblesk web application was evaluated with a System Usability Scale(SUS) which was introduced in Section 2.3. The questionnaire contains ten standardizedquestions with a scale from 1 to 5.

In the beginning of the questionnaire, a short introduction was given about what Coin-blesk’s goal and idea is. The text explained the reason for using Coinblesk over regularBitcoin transactions and explained the purpose of having a Coinblesk server as an inter-mediary between the users. Furthermore, it described the idea of the web application.See Appendix B for the full text of this introduction.

Then, there was an explanation of how a participant could test the Coinblesk web applica-tion. Four test user accounts were listed to log into the Coinblesk web application. Threeof them had the the role ROLE_USER and were provided with enough funds to test the pro-cess of making a Coinblesk transaction. Another user account with the role ROLE_ADMIN

was given to test the features of the administration. The server application was linked tothe Bitcoin testnet1, so the participants could freely test the making of transactions withtestnet Bitcoins.

Then, the 10 standardized SUS questions [29] were asked. At the end of the questionnaire,two additional questions were added to evaluate the skill-set of a participant. The first

1”The testnet is an alternative Bitcoin block chain, to be used for testing. Testnet coins are separateand distinct from actual bitcoins, and are never supposed to have any value. This allows applicationdevelopers or bitcoin testers to experiment, without having to use real bitcoins or worrying about breakingthe main bitcoin chain.” [21]

55

56 CHAPTER 5. EVALUATION

question generally asked about the IT skills and the second one asked about the knowledgeof the participants about crypto currencies. These question were mainly asked, becauseCoinblesk’s main target group are people with knowledge about IT and crypto currencies.These two questions were the basis for second mean SUS score caluclation containing onlypeople of a target group. Finally, the user could optionally add his name and a commentbefore submitting.

The questionnaire was conducted online using Google Forms [39]. Altogether, 23 peoplewere invited via email to participate in the questionnaire.

The questionnaire with its introductory text and the answers with the calculations arelisted in Appendix B.

5.1.1 Results

13 people evaluated the Coinblesk web application and participated in the questionnaire.This is a response rate of 56.5%. The calculated SUS score of the answers was onaverage 80.962 with a standard deviation of 10.216. A SUS score of at least 70 is viewedas acceptable [13]. The SUS score can also be mapped to an adjective. Bangor et al.created a list of SUS scores together with their appropriate adjective [13]. The adjectivesare listed in Table 5.1. According to this adjective list, the Coinblesk web application isclassified between ”Good” and ”Excellent”.

SUS Score Adjective100 Best imaginable85.58 Excellent72.75 Good52.01 OK39.17 Poor25.00 Worst imaginable

Table 5.1: The SUS scores mapped to a list of adjectives [13].

The actual distribution of the measured SUS scores is depicted in Figure 5.1. Mostof the answers given by the participants were above the acceptable threshold of 70. Oneparticipant had a score below 70 with 57.50. However, this answer can be relativized: Thisparticipant responded to the additional question about the IT skills with 4/10 and theknowledge about crypto currencies with the lowest number of 1 out of 10. The Coinbleskweb application requires the user to have certain knowledge about crypto currencies ingeneral. The participant is therefore not part of the target group.

If only target group participants are considered (knowledge about crypto currencies > 5),the number of participant drops down to 7. The SUS score, however, increases to 83.214with a standard deviation of 7.759. Hence, knowledge about crypto currencies is relevantto use the Coinblesk web application.

5.2. LIGHTHOUSE EVALUATION 57

The optional comment field was often used to add positive and negative critics about theCoinblesk Web Application. Selected ideas of these comments are discussed in 6.2 FurtherWork.

0

1

2

3

4

5

6

7

0-10 10-20 20-30 30-40 40-50 50-60 60-70 70-80 80-90 90-100

NU

MB

ER

OF P

AR

TIC

IPA

NT

S

SUS SCORE

Figure 5.1: The distribution of the SUS score results.

5.2 Lighthouse Evaluation

As described in Section 2.2.2, Lighthouse is a tool to measure the quality of a web appli-cation in the four categories: Progressive Web App, Performance, Accessibility and BestPractices.

The analysis of the Coinblesk web application was made using the same URL as in theSUS questionnaire from Section 5.1. Lighthouse does not follow any links to sub-pagesand therefore the Home page has been analyzed.

The Coinblesk web application reached the following scores (also depicted in Figure 5.2).Every requirement of the Progressive Web App category was completely fulfilled and thescore was 100%. The same score has been awarded for the accessibility category. TheBest Practices were not completely fulfilled with a score of 92%. A deduction was givensince Coinblesk was deployed on a test server environment without support for HTTP2. Abest practice would be to serve all content over the improved HTTP2 protocol. This issuecould easily be resolved using a newer version of Apache on the server.

The largest deduction was given in the Performance analysis with a score of only 50%.The main issue was the loading time of the ”first meaningful paint”. Reasons for that aremainly the large JavaScript codebase of Coinblesk (2.81MB) and the large-scale image onthe Home page. The instascan library alone, which is used to scan a QR code, makes up

58 CHAPTER 5. EVALUATION

for about 53% of the JavaScript code (1.49MB). Using another QR code scanner mightdecrease the filesize and therefore increase the performance score.

Figure 5.2: The Lighthouse analysis scores of the Coinblesk web application

Besides the large JavaScript file, Lighthouse presented further reasons for the increasedloading time: Images should be provided in the WebP format instead of the PNG or JPEG for-mat, as it provides ”better lossy and lossless compression than PNG or JPEG”. Furthermore,the provided Coinblesk logo inside the sidebar was not appropriately sized.

Chapter 6

Discussion

Digital payments at a Point-of-Sale (POS) are nowadays made with payment terminals andfollow a complex payment process. This process is designed for traditional transactionsin FIAT money (e.g. USD, CHF). Introducing Bitcoins into this process could representa way to establish crypto currencies in daily life payments.

Section 6.1 discusses the opportunities to introduce Bitcoin payments with Coinbleskinto POS payment terminals. Section 6.2 then discusses the possibilities of improvingCoinblesk in the future.

6.1 Coinblesk Integration into Payment Terminals

Coinblesk, as described in Section 2.1, was introduced in a canteen of the University ofZurich. Payments in this system were made with the Coinblesk application connectingto a custom NFC terminal. This terminal was connected to a computer, which thencommunicated with the Coinblesk server.

This way of an integration, however, had one large disadvantage: it did not scale verywell. Raising the number of merchants accepting Bitcoins over Coinblesk could only workif new custom NFC devices (similar to the aforementioned device) were deployed at themerchants payment locations (checkouts). Furthermore, the custom payment terminalswould always need to communicate with the merchant’s cash system. This system needsto provide at least an identifier of the merchant, and the amount to pay to, to the NFC ter-minal. Additionally, it needs success or failure messages after the transaction. Integratinga new custom payment device on a large-scale basis is therefore cumbersome.

Another integration approach could comprise the reuse of existing, well-established pay-ment terminals. Several acquirers in Switzerland, like Aduno [2] or SIX [71] providepayment terminals which are equipped with NFC sensors. Combining the Coinblesk ap-plication with established payment terminals and providing converted Bitcoins to themerchant over the NFC protocol would decrease the aforementioned scalability problemsof Coinblesk.

59

60 CHAPTER 6. DISCUSSION

6.1.1 Current Situation: Stakeholders

In the current digital payment process, which includes a payment terminal, there aremultiple stakeholder involved: A payer receives a payment card from the issuer. Then,he wants to pay at a merchant. The payment terminal, issued by the acquirer (which islicensed by a scheme), initiates the payment and checks the account balance of the payerat the issuer. In case of a success validation, the payment is accepted at the terminal [75].The stakeholders and roles involved in this process are described subsequently in moredetail.

PayerA payer is the owner of a payment account, and allows a transaction to be madefrom this account or, if there is no such account, a person which places a paymentorder. Traditionally, the payer is the owner of a payment card [75].

MerchantA merchant is the accepting person or legal entity of a transaction and the finalreceiver of a payment [75].

AcquirerAn acquirer processes payments between a payer and a merchant technically andprocedurally [75]. An acquirer provides the physical payment terminals at the pointof sale [1]. An acquirer is in Switzerland not a finance intermediary [75]. An examplewould be Aduno [1].

IssuerAn issuer provides payment cards to natural persons and legal entities [75]. Theissuer combines the role of account management with issuing physical and virtualcards [75]. In Switzerland, an issuer is a finance intermediary. An example of anissuer is Viseca [1].

SchemeA scheme runs a payment system. It takes the role of a licenser and of a paymentnetwork. In Switzerland, the most wide-spread schemes are MasterCard with amarket share of 45-55% and VISA with a market share of 35-45% [75].

6.1.2 Integration of Coinblesk via Virtual Debit Cards

Using established, already deployed payment terminals instead of custom NFC terminalstogether with Coinblesk could establish Bitcoin payments in the non-virtual area. Byusing a convenient Android client like Coinblesk, the user could buy a croissant in thestore of his choice and pay for it with Bitcoins at a credit card terminal which is supportingNFC. Major issues arising from how the Bitcoin network works, such as the problem ofhaving to wait for a block confirmation for up to an hour, as well as the problem ofhaving way too high transaction fees for a small transaction (see Section 2.1 for furtherinformation) would already be handled and be solved by Coinblesk.

6.1. COINBLESK INTEGRATION INTO PAYMENT TERMINALS 61

Multiple acquirers like Aduno or or SIX already provide such terminals which supportsupport near field communication [2][71]. A theoretical integration path enable paymentsfrom Coinblesk to a regular payment terminal by using a virtual debit card number. Thisdebit card number could then be transmitted via NFC interface to the payment terminal.Subsequently, the envisioned steps of a transaction:

1. The Coinblesk user/payer has enough funds on his time locked address or in hisvirtual balance and wants to pay an amount to a merchant. The payer goes into astore of a merchant and wants to spent a certain amount to the merchant.

2. The payer enters the amount he wants to spend into the Coinblesk application(in a local currency). The application then sends the amount to the Coinbleskserver. The Coinblesk server communicates with a virtual debit card provider (e.g. aprovider similar to Coinizy [34]). This debit card provider generates a one-time debitcard number and preloads this card with the amount the Coinblesk user requested.Buffering funds are already accessible by the debit card provider, as a certain amountis stored as a buffer on site. The debit card number, loaded with the exact amount,is returned to the Coinblesk Android application.

3. The Coinblesk Android application provides the debit card number in an appropriateformat over the NFC interface to the payment terminal. The debit card transactionis then successfully made.

4. After the transaction was successful, the following things happen within Coinblesk:

(a) A Bitcoin transaction is made from the requesting user to a special Coinbleskaccount, reserved for debit card payments. The amount of this transactionis calculated by converting the requested amount in the local currency intoBitcoin. A fee is added to the converted value to stabilize currency fluctuations.Such a transaction behaves like a regular Coinblesk transaction from a user toanother user.

(b) On a regular basis, the special account requests a payout to its Bitcoin address,similar to how a user can request a payout. After the payout is successful, theBitcoins are transferred to an exchange and are being sold for USD or CHF. Thesold amount is then withdrawn from the exchange and transferred over a banktransaction to the debit card provider.

During an analysis of the aforementioned integration approach, several problems discov-ered. The next section goes into detail about the problems and pushbacks which occurred.


6.1.3 Pushbacks and Problems

The aforementioned concept relies on the communication between an Android applicationrunning the Coinblesk application and an established payment terminal of an acquirer.The idea was to transmit a debit card number from the Android smartphone to theterminal. Unfortunately, it is not sufficient to provide a card number over NFC to apayment terminal.

A transfer of the card number without authentication or using dynamic features is pos-sible [75]. This form of transfer is mainly used when telling the number via telephone,to e.g. make a Hotel reservation or when sending the credit card number via post ore-mail to somebody (so-called ”mail-phone-order-transactions”) [75]. This transfer is veryinsecure and is not possible when using payment terminals.

Nowadays, a transaction at a payment terminal is made with the standardized EMVchip (Europay, MasterCard, Visa) inside the payment card [75]. The payment terminalcommunicates with the EMV chip and first makes an offline data authentication [75]. Anoffline data authentication generates at least a dynamic one-time key for every transactionbut may even combine this key with a session key for the communication between the cardand the terminal [75]. Afterwards, the terminal decides if it makes an offline transaction(a transaction certification is requested, but there is direct clearing and no authorization)or first an online-authorization by connecting to the card issuer [75]. This online/offlineauthorization concludes the transaction process [75].

A transaction at a payment terminal over NFC works very similar as described above withthe EMV standard [75]. The single difference is that there is no possibility for the issuer tochange any data in the virtual chip after an online authorization [75]. The authenticationprocess however takes also place over NFC [75].

Contact-less payments at physical terminals with a smartphone are called cloud-basedpayments [75]. In contrast to payments with a physical EMV chip, the smartphone isalways connecting to a centralized server of the issuer (cloud) or a third-party during apayment [75]. Over an encrypted interface, a cryptogram from the cloud is requested [75].As soon as the smartphone receives the cryptogram, it is transferred over NFC to thepayment terminal [75]. Furthermore, many smartphones save their initial, encryptedtoken (based on a real debit/credit card number) on a special place of their storage (specialencrypted chip Embedded Secure Element, SIM card or within the operating system) [75].This token is necessary to even request the cryptogram from the cloud [75].

6.1.4 Consequences

The complex nature of the payment process makes it impossible to use a payment terminaltogether with Coinblesk as proposed in Section 6.1.2. The goal was to send a debit cardnumber over NFC to a payment terminal to make a transaction. However, the cardnumber cannot just be transmitted to the terminal to make a payment.

6.2. FURTHER WORK 63

When using a smartphone, the card number needs to be encrypted to a token (during thesetup) [75]. Then, during the payment, a request is made to an issuer-hosted cloud [75].The returned cryptogram can then be used to transmit via NFC to the payment termi-nal [75]. Such special wallet applications, which are to be able to communicate with thecloud service operate in narrow technical, contractual and procedural collaboration withthe issuers and schemes [75]. There are yet wallets by Google, Apple and Samsung whichare able to communicate with these services [75].

To implement the proposed concept it is essential to be able to make NFC payments onterminals with Coinblesk. Therefore, this idea had to be dismissed.

A possible solution could be to take over the part of the issuer and issue a separate deb-it/credit card of an existing scheme. An issuer always takes the role of the account man-agement too, as described in Section 6.1.1. This makes it possible to control the paymentsfrom both sides. The start-up company TenX [78] is currently working on an implemen-tation of this concept. They are issuing their own virtual and physical debit cards andallow an instant payment in a local currency funded by various crypto-currencies.

6.2 Further Work

Several ideas and features came up during this thesis which were out of scope and havebeen left for future work. These ideas are outlined below.

The current work flow of sending funds to another user could be improved. Currently,there is no possibility of combinind virtual payments with actual Bitcoin transfers. Ifa user, who holds 5 BTC in virtual money and 5 BTC on his locked address, wants tosend funds of 7 BTC to another user, the transaction is currently denied. The maximalspending amount on the User Funds page currently indicates that the maximal spendableamount is either the virtual balance or the funds on the time locked address, dependingon which of these is higher. If the user wants to spend all his funds, he is required to firstmake a payout of his virtual balance to his locked address. Then, the maximal spendableamount is the amount on the locked address which should be the sum of the previousbalances.

A possibility to circumvent this drawback is to use the payout functionality to makea payout not to the user himself but to the recipient. The recipient then receives twopayments: One from the server and another from the time locked address. This could behandled by creating two transactions on the User Funds page.

Furthermore, there seems to be a need to display previous transactions made with Coin-blesk. Such an overview should contain virtual and actual Bitcoin transactions. Becauseof the combination of multiple virtual payments to a single Bitcoin transaction and evenusing payouts to another user as described in the paragraph above, this could make thetransaction overview non-trivial to implement. This idea was also proposed in the ques-tionnaire of the SUS evaluation. Using virtual balances without a transaction historymight also lead to legal problems because of its potential of money laundering.


A transaction history could help repeating a transaction. The amount and the recipient’saddress could be stored and an option to carry over this data to Transfer Funds pagecould be offered. An address could also be labelled as a contact: When sending Bitcoinsto an e-mail or Bitcoin address, the user could be asked for a name of this contact. Usingcontacts would certainly increase the simplicity of the system.

Furthermore, automated repeating payments (i.e. standing orders) could be established,as proposed by a participant in the SUS questionnaire. The participant also proposed aninteresting idea of adapting the style and behavior of the Coinblesk web application to ane-banking solution. Adapting the styles of Coinblesk to a professional banking solutionwould improve the usability and the trust of a user into Coinblesk.

Another interesting approach to increase the security of Coinblesk is to use a multi-factor authentication. A multi-factor authentication requires the user to provide morethan one verification method [59]. Usually the user name and password are combinedwith biometrical data or by an access to a trusted device (e.g. a generated number ona phone, an short message, etc.). In the case of Coinblesk, Google Authenticator [38]could be used together with the combination of user name and password to form a two-factor authentication. An automated session timeout would also increase the security ofCoinblesk, as one SUS questionnaire participant responded.

Another participant of the questionnaire mentioned, that it may help to offer a sectionwith Frequently Asked Questions (FAQ). This would help understand features, which maynot be self-explanatory. One participant for example did not understand the lock statusof a time locked address. With a section about the process in Coinblesk a user wouldprobably understand the process even better.

The web application currently offers an offline mode which only grants access to the Forexpage. Other pages like the Funds Overview or the Transfer Funds page are not accessiblein the offline mode. Especially the Transfer Funds page could be made offline by cachingthe data and annotating the page with the timestamp of the dataset.

The access to Bluetooth and NFC sensors on mobile devices via web is under developmentby major browser vendors [30][32]. In the future, it will be possible to access those sensorsvia a Web API. This opens up interesting new possibilities: The application could rely one.g. a payment terminals internet connection to fetch some data before paying directly viainternet-less connection (Bluetooth, NFC). Existing features of the Android applicationcould also be ported to the web application.

The micro payment threshold is currently fixed at 100 US-Dollar. No later than when thisthreshold is reached, the channel transaction is broadcasted. There is currently no wayto change this threshold in the administration of the web application. The next versionof Coinblesk could address this issue.

In the current version of the Coinblesk web application, a Bitcoin transaction is created inthe browser of a user. By making a micro payment transaction, the server pot’s addressneeds to be known because it is the recipient of the micro payment. Therefore, the userhas the possibility to fetch the address from the server application. A malicious user withknowledge about the internal process of Coinblesk could then make a Bitcoin transfer of 1

6.2. FURTHER WORK 65

Satoshi to this address from outside of Coinblesk. This would immediately raise a FATAL

event and send e-mails out to the administrator every 10 minutes because Server Balancewould become out of balance. In a future version of Coinblesk, this problem could alsobe addressed.

Smaller improvements comprise of the display of the private and public key of the user inthe profile. This information is currently only visible during the registration. Further, thepass phrase can only be set once, during the registration, and cannot be changed anymore.Resetting the pass phrase would improve the usability. Furthermore, the current, sent e-mails do only provide the necessary information in a single sentence in a non-HTMLmanner. More elegant e-mails could also constitute a usability improvement for a futurework.

To conclude with, Coinblesk currently only supports the crypto currency Bitcoin. Asof the 22nd August 2017, Bitcoin has the largest market capitalization of all crypto cur-rencies [36]. The total market share of Bitcoin in the context of market capitalization(dominance) is 45.3%. However, the dominance is vigorously decreasing since March2017, where the dominance was at ∼85%. Ethereum, Bitcoin Cash and Ripple are contin-uously growing their shares of the total market capitalization. To address this change ofthe market, other crypto currencies could be supported in Coinblesk in the future.

Chapter 7

Summary and Conclusions

The main result of this thesis is the Coinblesk progressive web application which interactswith the existing Coinblesk application. The web application provides a simple interfacefor an administrator to manage the application and for a regular user to transfer andmanage his own funds in a trustworthy way.

Funds can be transferred to another user simply by using the e-mail address of the recip-ient. A user can scan a Bitcoin QR code to immediately send funds. He can also providethe QR code of his address to another user to request funds. An administrator on theother hand is able to manage the Coinblesk server within the web application. User ac-counts and Bitcoin accounts can be listed and adapted. The server balance between micropayment channels and virtual balances is monitored and the administrator can configurea higher baseline server pot directly inside the web application.

The web application is based on current technologies like the concept of progressive webapps with its offline, standalone app-like character. All Bitcoin transactions are createdand signed inside a user’s browser. The private key, which is necessary for signing theBitcoin transaction is shared over multiple devices without granting the server access tothe funds: It is encrypted on the user’s device with a strong, predefined pass phrase.

The application was evaluated with a questionnaire and the results indicate a SUS Scorebetween Good and Excellent. To increase this value even further, multiple proposals werediscussed for future work.

Finally, there is a discussion about payment terminals and a possible integration of Coin-blesk and payments with Bitcoins. Unfortunately, it is not possible to use an existingpayment terminal to transfer converted Bitcoins with a generated virtual credit cardnumber.

67

Bibliography

[1] Aduno group: Geschaftsbereich payment. https://www.aduno-gruppe.ch/de/

gruppe/geschaeftsbereiche/payment/. Online, accessed 2017-08-06.

[2] Aduno: Zahlterminals, passend fur jeden einsatz. https://www.aduno.ch/

kartenzahlung-kartenlesegerate/zahlterminals. Online, accessed 2017-08-06.

[3] Glossary of loosely coupled: Ajax. http://www.looselycoupled.com/glossary/

AJAX. Online, accessed 2017-08-05.

[4] android.bluetooth: Bluetooth API for android. https://developer.android.com/

reference/android/bluetooth/package-summary.html. Online, accessed 2017-08-22.

[5] android.nfc: NFC API for android. https://developer.android.com/reference/android/nfc/package-summary.html. Online, accessed 2017-08-22.

[6] Android: Adding an easy share action. https://developer.android.com/

training/sharing/shareaction.html. Online, accessed 2017-08-05.

[7] Github issues: Core angular developer denies the integration of jsx into angular.https://github.com/angular/angular/issues/5131#issuecomment-318751190.Online, accessed 2017-08-12.

[8] Codementor: React vs. angular 2. https://www.codementor.io/codementorteam/react-vs-angular-2-comparison-beginners-guide-lvz5710ha. Online, ac-cessed 2017-08-12.

[9] Angularjs: What is angularjs? https://docs.angularjs.org/guide/

introduction. Online, accessed 2017-08-12.

[10] Angularjs: Github changelog. https://github.com/angular/angular.js/blob/

master/CHANGELOG.md. Online, accessed 2017-08-12.

[11] Angular: Why typescript? https://vsavkin.com/

writing-angular-2-in-typescript-1fa77c78d8e8. Online, accessed 2017-08-12.

[12] Tal Ater. Building Progressive Web Apps, 1st Edition. O’Reilly Media, Inc., August2017.

69

https://www.aduno-gruppe.ch/de/gruppe/geschaeftsbereiche/payment/

https://www.aduno-gruppe.ch/de/gruppe/geschaeftsbereiche/payment/

https://www.aduno.ch/kartenzahlung-kartenlesegerate/zahlterminals

https://www.aduno.ch/kartenzahlung-kartenlesegerate/zahlterminals

http://www.looselycoupled.com/glossary/AJAX

http://www.looselycoupled.com/glossary/AJAX

https://developer.android.com/reference/android/bluetooth/package-summary.html

https://developer.android.com/reference/android/bluetooth/package-summary.html

https://developer.android.com/reference/android/nfc/package-summary.html

https://developer.android.com/reference/android/nfc/package-summary.html

https://developer.android.com/training/sharing/shareaction.html

https://developer.android.com/training/sharing/shareaction.html

https://github.com/angular/angular/issues/5131#issuecomment-318751190

https://www.codementor.io/codementorteam/react-vs-angular-2-comparison-beginners-guide-lvz5710ha

https://www.codementor.io/codementorteam/react-vs-angular-2-comparison-beginners-guide-lvz5710ha

https://docs.angularjs.org/guide/introduction

https://docs.angularjs.org/guide/introduction

https://github.com/angular/angular.js/blob/master/CHANGELOG.md

https://github.com/angular/angular.js/blob/master/CHANGELOG.md

https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8

https://vsavkin.com/writing-angular-2-in-typescript-1fa77c78d8e8

70 BIBLIOGRAPHY

[13] Aaron Bangor, Philip T Kortum, and James T Miller. An empirical evaluation of thesystem usability scale. Intl. Journal of Human–Computer Interaction, 24(6):574–594,2008.

[14] Base58 definition. https://www.hotspotshield.com/glossary/base58/. Online,accessed 2017-08-04.

[15] BCoin for the browser. http://bcoin.io/browser.html. Online, accessed 2017-08-05.

[16] Bcoin, reddit topic. https://www.reddit.com/r/Bitcoin/comments/4mrg9r/a_

segnet4_full_node_in_your_browser/. Online, accessed 2017-08-05.

[17] Bitcoin bip0021. https://github.com/bitcoin/bips/blob/master/bip-0021.

mediawiki. Online, accessed 2017-08-17.

[18] Bitcoin bip0065. https://github.com/bitcoin/bips/blob/master/bip-0065.

mediawiki. Online, accessed 2017-08-17.

[19] Bitcoin.js. https://bitcoinjs.org/. Online, accessed 2017-08-17.

[20] Bitcoin wiki: How to accept bitcoin, for small businesses. https:

//en.bitcoin.it/wiki/How_to_accept_Bitcoin,_for_small_businesses#

Smart_Phone_or_Tablet. Online, accessed 2017-08-17.

[21] Bitcoin wiki: Testnet. https://en.bitcoin.it/wiki/Testnet. Online, accessed2017-08-23.

[22] Bitcoin wiki: Address. https://en.bitcoin.it/wiki/Address. Online, accessed2017-08-17.

[23] Bitcoin wiki: Confirmations. https://en.bitcoin.it/wiki/Confirmation. On-line, accessed 2017-08-05.

[24] Bitcoinfees21: Predicting bitcoin fees for transactions. https://bitcoinfees.21.

co/api/v1/fees/recommended. Online, accessed 2017-08-13.

[25] Bitstamp API. https://www.bitstamp.net/api. Online, accessed 2017-07-28.

[26] Blockchain.info: Bitcoin block explorer. https://blockchain.info. Online, ac-cessed 2017-08-03.

[27] Bootstrap: Modal. https://v4-alpha.getbootstrap.com/components/modal/.Online, accessed 2017-08-04.

[28] Marie Briere, Kim Oosterlinck, and Ariane Szafarz. Virtual currency, tangible return:Portfolio diversification with bitcoin. Journal of Asset Management, 16(6):365–373,2015.

[29] John Brooke et al. Sus-a quick and dirty usability scale. Usability evaluation inindustry, 189(194):4–7, 1996.

https://www.hotspotshield.com/glossary/base58/

http://bcoin.io/browser.html

https://www.reddit.com/r/Bitcoin/comments/4mrg9r/a_segnet4_full_node_in_your_browser/

https://www.reddit.com/r/Bitcoin/comments/4mrg9r/a_segnet4_full_node_in_your_browser/

https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki




https://bitcoinjs.org/

https://en.bitcoin.it/wiki/How_to_accept_Bitcoin,_for_small_businesses#Smart_Phone_or_Tablet



https://en.bitcoin.it/wiki/Testnet

https://en.bitcoin.it/wiki/Address

https://en.bitcoin.it/wiki/Confirmation

https://bitcoinfees.21.co/api/v1/fees/recommended

https://bitcoinfees.21.co/api/v1/fees/recommended

https://www.bitstamp.net/api

https://blockchain.info

https://v4-alpha.getbootstrap.com/components/modal/

BIBLIOGRAPHY 71

[30] Can I use: Web bluetooth. http://caniuse.com/#feat=web-bluetooth. Online,accessed 2017-08-04.

[31] Can I use: Web cryptography. http://caniuse.com/#feat=cryptography. Online,accessed 2017-07-30.

[32] W3C: Web NFC. https://w3c.github.io/web-nfc/. Online, accessed 2017-08-04.

[33] CoinDesk API. https://www.coindesk.com/api. Online, accessed 2017-07-28.

[34] Coinizy: Online shopping for everyone. https://www.coinizy.com/. Online, ac-cessed 2017-08-06.

[35] Coinmarketcap. https://coinmarketcap.com. Online, accessed 2017-08-23.

[36] Coinmarketcap: Bitcoin dominance. https://coinmarketcap.com/charts/

#dominance-percentage. Online, accessed 2017-08-22.

[37] Flaticon, icons designed by ’madebyoliver’, ’pixel buddha’, ’eucalyp’, ’freepik’ and’dinosoftlabs’. https://www.flaticon.com. Online, accessed 2017-08-03.

[38] Install Google Authenticator. https://support.google.com/accounts/answer/

1066447?co=GENIE.Platform%3DAndroid&hl=en. Online, accessed 2017-08-19.

[39] Google forms. https://www.google.com/forms/about/. Online, accessed 2017-08-12.

[40] Google: Progressive web apps. https://developers.google.com/web/

progressive-web-apps/. Online, accessed 2017-08-04.

[41] Google: Progressive web app requirements for showing the ”add to homescreen” banner. https://developers.google.com/web/updates/2015/12/

getting-started-pwa?hl=en#add_to_home_screen_banner. Online, accessed2017-08-04.

[42] Computerhope: What is a hamburger menu? https://www.computerhope.com/

jargon/h/hamburger-menu.htm. Online, accessed 2017-08-05.

[43] Mdn web docs: Indexed db api. https://developer.mozilla.org/en-US/docs/

web/API/IndexedDB_API. Online, accessed 2017-08-15.

[44] Simon Kaeser Jeton Memeti, Mehmet Ali Bekooglu. Master project: Bitcoin inpractice, 03 2014.

[45] Number of stackoverflow questions of jquery, angularjs and react.js compared. https://keithhenry.github.io/jsmeetup-jquery-rise-fall/#/trends. Online, ac-cessed 2017-08-12.

[46] React: Introducing jsx. https://facebook.github.io/react/docs/

introducing-jsx.html. Online, accessed 2017-08-12.

[47] Json web tokens. https://jwt.io. Online, accessed 2017-08-15.

http://caniuse.com/#feat=web-bluetooth

http://caniuse.com/#feat=cryptography

https://w3c.github.io/web-nfc/

https://www.coindesk.com/api

https://www.coinizy.com/

https://coinmarketcap.com

https://coinmarketcap.com/charts/#dominance-percentage

https://coinmarketcap.com/charts/#dominance-percentage

https://www.flaticon.com

https://support.google.com/accounts/answer/1066447?co=GENIE.Platform%3DAndroid&hl=en

https://support.google.com/accounts/answer/1066447?co=GENIE.Platform%3DAndroid&hl=en

https://www.google.com/forms/about/

https://developers.google.com/web/progressive-web-apps/

https://developers.google.com/web/progressive-web-apps/

https://developers.google.com/web/updates/2015/12/getting-started-pwa?hl=en#add_to_home_screen_banner

https://developers.google.com/web/updates/2015/12/getting-started-pwa?hl=en#add_to_home_screen_banner

https://www.computerhope.com/jargon/h/hamburger-menu.htm

https://www.computerhope.com/jargon/h/hamburger-menu.htm

https://developer.mozilla.org/en-US/docs/web/API/IndexedDB_API

https://developer.mozilla.org/en-US/docs/web/API/IndexedDB_API

https://keithhenry.github.io/jsmeetup-jquery-rise-fall/#/trends

https://keithhenry.github.io/jsmeetup-jquery-rise-fall/#/trends

https://facebook.github.io/react/docs/introducing-jsx.html

https://facebook.github.io/react/docs/introducing-jsx.html

https://jwt.io

72 BIBLIOGRAPHY

[48] Patrick Gage Kelley, Saranga Komanduri, Michelle L Mazurek, Richard Shay, Timo-thy Vidas, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Julio Lopez. Guessagain (and again and again): Measuring password strength by simulating password-cracking algorithms. In Security and Privacy (SP), 2012 IEEE Symposium on, pages523–537. IEEE, 2012.

[49] Thomas Kilian, Berthold H Hass, and Gianfranco Walsh. Grundlagen des web 2.0.In Web 2.0, pages 3–21. Springer, 2008.

[50] Free stock graphics: Technology age. https://www.

freestockgraphics.com/free-images/technology-images/

free-objects-stock-graphics-technology-age/. Online, accessed 2017-08-05.

[51] Google developers: Lighthouse. https://developers.google.com/web/tools/

lighthouse/. Online, accessed 2017-08-22.

[52] Github: Lighthouse. https://github.com/GoogleChrome/lighthouse. Online, ac-cessed 2017-08-22.

[53] Mdn web docs: Window.localStorage. https://developer.mozilla.org/de/docs/Web/API/Window/localStorage. Online, accessed 2017-08-22.

[54] Project lombok. https://projectlombok.org/. Online, accessed 2017-08-07.

[55] Merriam webster dictionary: Fiat money. https://www.merriam-webster.com/

dictionary/fiat%20money. Online, accessed 2017-08-04.

[56] Merriam webster dictionary: Pseudonym. https://www.merriam-webster.com/

dictionary/pseudonym. Online, accessed 2017-08-04.

[57] Merriam webster dictionary: Pseudonymity. https://www.merriam-webster.com/

dictionary/pseudonymity. Online, accessed 2017-08-04.

[58] Michael S Mikowski and Josh C Powell. Single page web applications. B and W,2013.

[59] What is azure multi-factor authentication? https://docs.microsoft.com/en-us/

azure/multi-factor-authentication/multi-factor-authentication. Online,accessed 2017-08-19.

[60] Node.js, the official website. https://nodejs.org/en/. Online, accessed 2017-08-05.

[61] Bitcoin.org glossary: Opcode. https://bitcoin.org/en/glossary/op-code. On-line, accessed 2017-08-17.

[62] Oracle java jdk 8. http://www.oracle.com/technetwork/java/javase/

downloads/jdk8-downloads-2133151.html. Online, accessed 2017-08-05.

[63] Tim O’Reilly. What Is Web 2.0: Design Patterns and Business Models for the NextGeneration of Software. ”O’Reilly Media, Inc.”, 2009.

https://www.freestockgraphics.com/free-images/technology-images/free-objects-stock-graphics-technology-age/



https://developers.google.com/web/tools/lighthouse/

https://developers.google.com/web/tools/lighthouse/

https://github.com/GoogleChrome/lighthouse

https://developer.mozilla.org/de/docs/Web/API/Window/localStorage

https://developer.mozilla.org/de/docs/Web/API/Window/localStorage

https://projectlombok.org/

https://www.merriam-webster.com/dictionary/fiat%20money

https://www.merriam-webster.com/dictionary/fiat%20money

https://www.merriam-webster.com/dictionary/pseudonym

https://www.merriam-webster.com/dictionary/pseudonym

https://www.merriam-webster.com/dictionary/pseudonymity

https://www.merriam-webster.com/dictionary/pseudonymity

https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication

https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication

https://nodejs.org/en/

https://bitcoin.org/en/glossary/op-code

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

BIBLIOGRAPHY 73

[64] Path-to-regexp. https://github.com/pillarjs/path-to-regexp. Online, ac-cessed 2017-08-15.

[65] Qr code generator by kazuhikoarase. https://github.com/kazuhikoarase/

qrcode-generator/tree/master/js. Online, accessed 2017-08-17.

[66] React native. https://facebook.github.io/react-native/. Online, accessed2017-08-12.

[67] Bitcoin.org glossary: Redeem script. https://bitcoin.org/en/glossary/

redeem-script. Online, accessed 2017-08-17.

[68] Bitcoin.org glossary: Satoshis. https://bitcoin.org/en/glossary/

denominations. Online, accessed 2017-08-17.

[69] Search security definition: Ssl. http://searchsecurity.techtarget.com/

definition/Secure-Sockets-Layer-SSL. Online, accessed 2017-08-04.

[70] Google: Service workers, an introduction. https://developers.google.com/web/

fundamentals/getting-started/primers/service-workers. Online, accessed2017-08-04.

[71] Six group: Die terminals von six payment services. https:

//www.six-payment-services.com/de/shared/offering/products/

payment-terminals.html. Online, accessed 2017-08-06.

[72] Rendering speed & performance challenge with famous front-end framework. https://medium.com/thothzocial-engineering/

rendering-speed-performance-challenge-with-famous-front-end-framework-196c876a68af.Online, accessed 2017-08-12.

[73] Springfox: Swagger. https://springfox.io. Online, accessed 2017-08-18.

[74] Stackoverflow: Comparison between native apps and progressive web apps. https:

//stackoverflow.com/a/39027789/3233827. Online, accessed 2017-08-04.

[75] C. Stengel and T. Weber. Digitale und mobile Zahlungssysteme : Technologie,Vertrage und Regulation von Kreditkarten, Wallets und E-Geld. Schulthess, 2016.

[76] Sebastian Stephan. Transaction fee reduction in coinblesk. Master’s thesis, Universityof Zurich, May 2017.

[77] Swagger ui. https://swagger.io/swagger-ui. Online, accessed 2017-08-17.

[78] TenX: Making cryptocurrencies spendable anytime anywhere. https://www.tenx.

tech/. Online, accessed 2017-08-07.

[79] React: The virtual dom. https://www.codecademy.com/articles/

react-virtual-dom. Online, accessed 2017-08-12.

[80] Raphael Voellmy. Coinblesk, a mobile nfc bitcoin payment system. Bachelor Thesis,Univ. Zurich, Communication Systems Group, Department of Informatics, Zurich,Switzerland, 2015.

https://github.com/pillarjs/path-to-regexp

https://github.com/kazuhikoarase/qrcode-generator/tree/master/js

https://github.com/kazuhikoarase/qrcode-generator/tree/master/js

https://facebook.github.io/react-native/

https://bitcoin.org/en/glossary/redeem-script

https://bitcoin.org/en/glossary/redeem-script

https://bitcoin.org/en/glossary/denominations

https://bitcoin.org/en/glossary/denominations

http://searchsecurity.techtarget.com/definition/Secure-Sockets-Layer-SSL

http://searchsecurity.techtarget.com/definition/Secure-Sockets-Layer-SSL

https://developers.google.com/web/fundamentals/getting-started/primers/service-workers

https://developers.google.com/web/fundamentals/getting-started/primers/service-workers

https://www.six-payment-services.com/de/shared/offering/products/payment-terminals.html



https://medium.com/thothzocial-engineering/rendering-speed-performance-challenge-with-famous-front-end-framework-196c876a68af

https://medium.com/thothzocial-engineering/rendering-speed-performance-challenge-with-famous-front-end-framework-196c876a68af

https://springfox.io

https://stackoverflow.com/a/39027789/3233827

https://stackoverflow.com/a/39027789/3233827

https://swagger.io/swagger-ui

https://www.tenx.tech/

https://www.tenx.tech/

https://www.codecademy.com/articles/react-virtual-dom

https://www.codecademy.com/articles/react-virtual-dom

74 BIBLIOGRAPHY

[81] Vue: Comparison with other frameworks. https://vuejs.org/v2/guide/

comparison.html. Online, accessed 2017-08-12.

[82] Vue.js PWA: A full featured pwa template with webpack. https://github.com/

vuejs-templates/pwa. Online, accessed 2017-08-16.

[83] Vue.js: Router. https://router.vuejs.org/en/. Online, accessed 2017-08-15.

[84] Vue.js: Single file components. https://vuejs.org/v2/guide/

single-file-components.html. Online, accessed 2017-08-16.

[85] Vuex. https://vuex.vuejs.org/en/. Online, accessed 2017-08-15.

[86] Persist vuex state with localstorage. https://github.com/robinvdvleuten/

vuex-persistedstate. Online, accessed 2017-08-15.

[87] W3c: What is the document object model? https://www.w3.org/TR/

DOM-Level-3-Core/introduction.html. Online, accessed 2017-08-05.

https://vuejs.org/v2/guide/comparison.html

https://vuejs.org/v2/guide/comparison.html

https://github.com/vuejs-templates/pwa

https://github.com/vuejs-templates/pwa

https://router.vuejs.org/en/

https://vuejs.org/v2/guide/single-file-components.html

https://vuejs.org/v2/guide/single-file-components.html

https://vuex.vuejs.org/en/

https://github.com/robinvdvleuten/vuex-persistedstate

https://github.com/robinvdvleuten/vuex-persistedstate

https://www.w3.org/TR/DOM-Level-3-Core/introduction.html

https://www.w3.org/TR/DOM-Level-3-Core/introduction.html

Abbreviations

API Application Programming InterfaceBIP Bitcoin Improvement ProposalBTC Currency: BitcoinCHF Currency: Swiss FrancCLTV Check Lock Time Verify (Bitcoin Opcode)DOM Document Object ModelDTO Data Transfer ObjectEMV Europay, MasterCard, VisaEUR Currency: EuroHTTPS HyperText Transfer Protocol SecureIEEE Institute of Electrical and Electronics EngineerIfI Institute of Informatics, University of ZurichJSON JavaScript Object NotationJWT JSON Web TokenMBPS Mobile Bitcoin Payment System, previous name of CoinbleskNFC Near Field CommunicationP2SH Pay to Script HashPWA Progressive Web AppQR Code Quick Response CodeREST Representational State TransferSIM Subscriber Identity Module (SIM card)SSL/TLS Secure Socket Layer/Transport Layer SecurityUI User InterfaceURI Uniform Resource IdentifierURL Uniform Resource LocatorUSD Currency: US-Dollar

75

Glossary

Ajax ”AJAX (Asynchronous Javascript And Xml) is the term coined in February 2005to describe a collection of technologies used to automatically update and manipulatethe information on a web page while it is being viewed in a browser (i.e. withoutthe user having to manually refresh the page). This allows developers to create moresophisticated web pages and applications without having to add to the native capa-bilities of the browser. A key component is the use of XMLHttpRequest, a functionoriginally added to browsers by Microsoft, to exchange data in the background withone or more web servers.” [3]

Authentication Authentication is the identification of a user against a web server. Usu-ally a password or another form of a secret information is needed to grant access.

Authorization Authorization is the decision whether an entity is allowed to perform aparticular action or not, e.g. whether a user is allowed to access a dataset or not.

Base58 ”Base58 is a scheme that aims to represent large integers (numbers) as alphanu-meric text. The scheme uses Binary text encoding, but it differs from Base64 asit avoids the use of non-alphanumeric characters which makes it easier for humaninterpretation and data entry. Characters that are omitted are O (Capital O) and0 (Zero), I (Capital i) and l (lower case l) and + and / -

”All of these characters can easily be confused with other letters and numbers.Base58 is suited for encoding large integers, but is not suitable for encoding sec-tions of binary data. Applications of base58 include creating different addressessuch as Bitcoin and Ripple addresses.” [14]

DOM ”The Document Object Model (DOM) is an application programming interface(API) for valid HTML and well-formed XML documents. It defines the logicalstructure of documents and the way a document is accessed and manipulated. In theDOM specification, the term ”document” is used in the broad sense.” [87]

FIAT money ”Fiat money refers to any currency lacking intrinsic value that is declaredlegal tender by a government. As valid currency solely by virtue of a governmentdeclaration, fiat money is not backed by any commodity, such as gold, but only bythe faith of the bearer. In this respect, unlike currencies backed by gold or silver,fiat money does not have any intrinsic value (e.g., paper money and much coinage).The U.S. dollar is an example of fiat money.” [55] Crypto currencies, like Bitcoinare by contrast not FIAT money.

77

78 GLOSSARY

Hamburger icon ”The hamburger menu or hamburger icon is a name given to the menuicon found in newer programs and websites that hides the traditional File menu.Alternatively referred to as the hotdog menu or three-line menu, using the hamburgermenu makes it easier to view program options on mobile devices. The icon gets itsname because it looks like a hamburger or a top and bottom bun with a meat pattyin between the buns.” [42]

LocalStorage ”The read-only localStorage property allows you to access a Storage

object for the Document’s origin; the stored data is saved across browser sessions.localStorage is similar to sessionStorage, except that while data stored in lo-

calStorage has no expiration time, data stored in sessionStorage gets clearedwhen the page session ends – that is, when the page is closed.” [53]

Modal ”Modals are streamlined, but flexible dialog prompts powered by JavaScript. Theysupport a number of use cases from user notification to completely custom contentand feature a handful of helpful subcomponents, sizes, and more.” [27]

Opcode ”Operation codes from the Bitcoin Script language which push data or performfunctions within a pubkey script or signature script.” [61]

Pseudonymity ”The use of a pseudonym; also: The fact or state of being signed witha pseudonym.” [57], A pseudonym is a fictitious name [56]. Bitcoin addresses arepseudonym because the address is not random but fixed and everybody can see whatis on an address. The address is the pseudonym of the person behind.

Redeem Script ”A script similar in function to a pubkey script. One copy of it ishashed to create a P2SH address (used in an actual pubkey script) and another copyis placed in the spending signature script to enforce its conditions.” [67]

Satoshi ”Denominations of Bitcoin value, usually measured in fractions of a bitcoinbut sometimes measured in multiples of a satoshi. One bitcoin equals 100,000,000satoshis.” [68]

SSL/TLS ”Secure Sockets Layer (SSL) is a computer networking protocol for securingconnections between network application clients and servers over an insecure net-work, such as the internet. The TLS protocol evolved from SSL and has officiallysuperseded it, although the terms SSL or SSL/TLS are still commonly used to referto the protocol used to secure web/internet traffic.” [69]

Time Locked Address A time locked address in Coinblesk is a Bitcoin address gener-ated with a Bitcoin script. Funds transferred to this address can only be access withboth the server and the client’s signature. After a certain time period (after the locktime expires), the funds are being unlocked and the client’s signature is sufficient toaccess the funds.

List of Figures

3.1 Architecture diagram (image source: Flaticon [37]) . . . . . . . . . . . . . 17

3.2 Both steps of the Registration, including the generation of the Bitcoin keypair and the pass phrase strength validation. . . . . . . . . . . . . . . . . . 19

3.3 A user can manually activate his account by entering the activation tokenfrom the e-mail. Afterwards he needs to provide his credentials to log in. . 19

3.4 A user can request a token to reset his password. . . . . . . . . . . . . . . 20

3.5 The Home page together with the navigational side bar . . . . . . . . . . . 21

3.6 The Forex page shows the current and historic market trend of Bitcoin.Screenshot made on the 28th July, 2017. . . . . . . . . . . . . . . . . . . . 22

3.7 The Profile page allows the user to change his password and select hispreferred language (German or English). . . . . . . . . . . . . . . . . . . . 23

3.8 The Funds page shows a table with the current time locked addresses, theirfunds and the virtual balance. A possible channel transaction is also listedhere. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.9 Sending funds to another user or Bitcoin address can be easily made on thepage Transfer Bitcoins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.10 The QR code scanner helps typing a recipient’s e-mail or Bitcoin addresson the Send Funds page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.11 After entering the recipients address and the amount to send, the user needsto decrypt the private key to finally create the transaction. . . . . . . . . . 26

3.12 The user account overview displays a list of all users together with somebasic information and a link to the details page. . . . . . . . . . . . . . . . 28

3.13 The user accounts detail page shows all relevant information about a useraccount. The administrator is also able to delete a user and switch the roles. 28

3.14 The account overview page displays a list of all Bitcoin accounts, registeredin Coinblesk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

79

80 LIST OF FIGURES

3.15 The accounts detail page shows all information available about a user’sBitcoin account on Coinblesk. This comprises of all balances, time lockedaddresses and more. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.16 The server balance shows an equation which depicts the equilibrium be-tween channel transaction, virtual balances and the server pot. . . . . . . . 31

3.17 The server pot baseline is the server pot buffer amount of Bitcoins. Theserver baseline can be adapted to add or withdraw buffering funds. . . . . 31

3.18 On the left side you can see the Coinblesk web application installed as aHome screen application on an Android smartphone. On the right side,you can see the application running in the offline mode. . . . . . . . . . . . 37

3.19 The administration page User Accounts is depicted on various screen sizeto demonstrate the responsive behavior of the web application (raw imagesource: [50]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1 Front-End Folder Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 An example of a Vue.JS component using the single file pattern, includingscoped SCSS styles and local i18n translations. . . . . . . . . . . . . . . . . 41

4.3 The server response when an unhandled server exception occurred. . . . . . 42

4.4 A simplified example of a routing requirement as an administrator. . . . . 45

4.5 The Coinblesk web application manifest. . . . . . . . . . . . . . . . . . . . 46

4.6 ”offline” attribute definition in the Forex component to allow routing tothis page when the user is offline. . . . . . . . . . . . . . . . . . . . . . . . 48

4.7 CLTV redeem script according to its definition in BIP0065. . . . . . . . . . 51

4.8 An example Bitcoin URI scheme compliant with BIP0021 and its corre-sponding generated QR code. . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.9 The debug page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.10 The Swagger UI representation of the Coinblesk API after the refactoring. 54

5.1 The distribution of the SUS score results. . . . . . . . . . . . . . . . . . . . 57

5.2 The Lighthouse analysis scores of the Coinblesk web application . . . . . . 58

B.1 The given answers of the participants with the calculations made based onSUS [29]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

List of Tables

2.1 Comparison between web frameworks and a library [8][9][46][66][72][79][81] 8

2.2 The SUS questionnaire by Brooke [29]. . . . . . . . . . . . . . . . . . . . . 12

5.1 The SUS scores mapped to a list of adjectives [13]. . . . . . . . . . . . . . 56

81

Appendix A

Installation Guidelines

To run the Coinblesk web application, the server and the front-end application need tobe started. To do this, you should follow the subsequent steps.

A.1 Installation and Building

1. Setup: Make sure to have the following three packages ready: coinblesk-shared-resources, coinblesk-server and coinblesk-frontend. For the subsequent in-structions, it is expected, that these three projects are in one folder.

2. Install Node.js by downloading it from the official web site [60].

3. Install the Java JDK by downloading it from the official web site [62].

4. Back-End Building: Run the following commands to build and install the coinblesk-shared-resources:

$ cd coinblesk-shared-resources

$ ./gradlew install

5. Run the following commands to build the coinblesk-server:

$ cd coinblesk-server

$ ./gradlew build

6. Front-End Building: Install Yarn from the command line. This is optional, but itis recommended to use it intead of NPM. Otherwise, the following commands haveto be adapted.

$ npm install -g yarn

83

84 APPENDIX A. INSTALLATION GUIDELINES

7. Install the project dependencies of the front-end project:

$ cd coinblesk-frontend

$ yarn install

A.2 Running in development

Back-EndRun the following command to start the coinblesk-server. The service is thenavailable at http://localhost:8080. You can go to the /debug page (http://localhost:8080/debug) to access the H2-console, the Swagger API and a scriptto generate accounts and time locked addresses.


$ ./gradlew run

# Open now http://localhost:8080/debug

Front-EndRun the following command sto start the coinblesk-frontend. The service is thenavailable at http://localhost:9090. It communicates with the back-end server onport :8080. Therefore, the front-end cannot run on its own. Every change to a lineof code of the front-end leads to an immediate injecting reload into the browser.


$ yarn run dev

# Open now http://localhost:9090

Testing the Service WorkerThe service worker cannot be tested with the development mode of webpack. There-fore, you need to build the files for production (see Section A.3). The producedfiles can then be served with the provided script coinblesk-frontend/start-

server.js. This script starts an express Node.js server, serving the static contentfrom the \dist folder on the URL http://localhost:7070. The service workerwill be installed, even though the files are not served over HTTPS, because local-

host is allowed for development. It won’t work however, if you are trying to accessthe website from a device in your local network.


$ yarn run build

$ node ./start-server.js

# Open now http://localhost:7070

http://localhost:8080

http://localhost:8080/debug

http://localhost:8080/debug



A.3. BUILDING FOR DEPLOYMENT 85

A.3 Building for deployment

Back-EndThe coinblesk-server can be built with the following commands. The result-ing .jar file is on the path coinblesk-server/build/libs/coinblesk-server-

2.1.SNAPSHOT.jar, where the version number may vary.


$ ./gradlew assemble

Front-EndThe front-end can be build with the following commands. The resulting final staticresource files are on the path coinblesk-frontend/dist.


$ yarn run build

Make sure to check the properties, before you create a production build!The properties are stored stored in the file coinblesk-frontend/src/properties.jsand contains two configurations: the type of the Bitcoin network (testnet or main-net) and the URL of the back-end (the default is the current URL plus another port:the port :8080).

A.4 Hints for Eclipse

If you want to run the Coinblesk server respectively build the coinblesk-shared-resourcesin Eclipse, you need to follow the following steps:

1. Close Eclipse and install Lombok into your local Eclipse instance: Download it fromthe official website [54] and run the .jar file as an executable. Select the Eclipseinstallation path and run the script. Restart Eclipse.

2. Install the Buildship Gradle Integration 2.0 from the Eclipse Marketspace.

3. Right click onto the project → Configure → Add Gradle Nature

4. Click in the menu on Window → Show View → Other... → Gradle Tasks

5. Run other/install in the coinblesk-shared-resources project

6. Run build/build in the coinblesk-server project

7. Add -spring.profiles.active=dev to the Run Configuration of the coinblesk-

server

86 APPENDIX A. INSTALLATION GUIDELINES

If "tools.jar" is missing during the gradle build, you are probably either running on aJRE instead of a JDK or your system environment variable JAVA_HOME is not set to yourJDK directory. If setting the environment variable is not helping, try setting the VMmanually in eclipse.ini: http://stackoverflow.com/a/37455965/3233827

http://stackoverflow.com/a/37455965/3233827

Appendix B

System Usability Scale:Evaluation Material

B.1 The full questionnaire

The questionnaire begins with an introductory text. Then, the actual questions werebeing asked. This section depicts the full questionnaire as follows:

Master Thesis: Usability Evaluation

Thank you for participating in the usability evaluation of the Coinblesk webapplication! It will be very much appreciated :)

First, you will get some information about Coinblesk and Bitcoin. Then,you will be asked to use the web application either on your desktop or mobiledevice. Finally, you will be asked ten very simple questions about the usability.

Introduction

Please take some time to carefully read the following text:

Coinblesk is a Bitcoin application which improves several drawbacks of theBitcoin network by introducing an intermediary server application. This ap-plication buffers transactions between users, which allows for a faster paymentrate. A regular Bitcoin transaction takes up to one hour to be confirmed. WithCoinblesk, a payment from one user to another can be done within a secondthrough virtual payments whilst keeping actual Bitcoin transactions of thesender on hold. This further allows to minimize transaction fees (up to 2US-Dollar per transaction), because the server application is able to combinemultiple payments.

Coinblesk was initially developed exclusively as an Android application. Dur-ing this thesis, a progressive web application was created to reach also desktop

87

88 APPENDIX B. SYSTEM USABILITY SCALE: EVALUATION MATERIAL

and iOS users. Furthermore, the application can now be used on multiple de-vices at the same time. These new features were introduced without increasingthe user’s required trust in the server application: unspent funds will alwaysstay in the singular possession of the corresponding user (the private key toaccess the funds is only synchronized via the server in an encrypted form). ABitcoin transaction is then built in the user’s web browser.

Another introduced feature comprises of the sending of Bitcoins to an e-mailaddress. This is done by inviting unregistered users and holding the funds onthe server. To keep the the amount of funds on the server at a minimum, thiswill only work up to a threshold of 100 US-Dollar. This means that one canonly transfer a Bitcoin amount worth 100 US-Dollar to an unknown user. Apre-known user automatically has a Bitcoin address connected to his accountand the funds are directly sent to the respective Bitcoin address.

The Coinblesk web application also comprises of a server administration. Theserver administration shows all user accounts, Bitcoin accounts and serverevents. Furthermore, it depicts a server balance: Keeping transactions backand increasing a virtual balance of a user needs to be always in sync.

Using Coinblesk

Coinblesk is currently being deployed using the Bitcoin testnet. This meansthat all Bitcoins in this network have no real value and its sole purpose is totest the system. Therefore, you can test the application without any risk (i.e.don’t worry if you spend some coins by mistake).

After the registration, you won’t have any coins yet, but there are severalwebsites (so-called faucets) which send you some test Bitcoins for free. Justenter the Bitcoin address you’ll receive after the registration into the faucet andyou’ll get some free Bitcoins. Keep in mind, that actual Bitcoin transactions(e.g. from a faucet to Coinblesk) first need to be confirmed in a block. Thismeans, you will have to wait at least 10 min before you can begin spendingyour new funds in Coinblesk. Alternatively, you can just use an account frombelow!

You can test the following functionality in Coinblesk:

• Registration/Activation/Login

• View your funds and Bitcoin address

• Send funds to another address

• Login as Administrator and view the administration (please don’t changeanything ;)

• (Receive funds from a faucet to your Bitcoin address)

If you don’t want to use a faucet, you can also use one of the following accounts.These accounts should have enough spendable funds on it (please don’t spendeverything, leave some funds for other survey participants)

B.1. THE FULL QUESTIONNAIRE 89

E-Mail Password Pass PhraseAdmin: [email protected] this-is-my-master-thesis —User B: [email protected] this-is-my-master-thesis this-is-my-master-thesisUser C: [email protected] this-is-my-master-thesis this-is-my-master-thesisUser D: [email protected] this-is-my-master-thesis this-is-my-master-thesis

Faucet: https: // testnet. manu. backend. hamburg/ faucet

—

So, let’s start. Here is the Coinblesk link: https://bitcoin2-test.csg.

uzh.ch

Please continue this survey after having evaluated the Coinblesk web applica-tion.

Questionnaire

Please answer the following questions bearing in mind that the target group ofthis system is familiar with Bitcoin and the problems of the Bitcoin network.

1. I think that I would like to use this system frequently.2. I found the system unnecessarily complex.3. I thought the system was easy to use.4. I think that I would need the support of a technical person to be able

to use this system.5. I found the various functions in this system were well integrated.6. I thought there was too much inconsistency in this system.7. I would imagine that most people would learn to use this system very

quickly.8. I found the system very cumbersome to use.

Hint: According to http://dict.cc, cumbersome means: schwerfallig,muhselig, umstandlich, muhsam.

9. I felt very confident using the system.10. I needed to learn a lot of things before I could get going with this

system.

i. How would you estimate your IT skills?ii. How would you estimate your knowledge about crypto-currencies?iii. What is your name? (optional)iv. Would you like to leave a comment? (optional)

https://testnet.manu.backend.hamburg/faucet

https://bitcoin2-test.csg.uzh.ch

https://bitcoin2-test.csg.uzh.ch

90 APPENDIX B. SYSTEM USABILITY SCALE: EVALUATION MATERIAL

B.2 SUS Score calculation

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

Q10

Q1

Q2

Q3

Q4

Q5

Q6

Q7

Q8

Q9

Q10

Sum

SU

S S

core

IT S

kills

Cry

pto

-Curr

ency

Skills

CC-S

kills ≥

5

P1

32

51

33

51

33

23

44

22

44

22

2972.50

8 /

10

P2

41

41

41

31

53

34

34

34

24

42

3382.50

8 /

10

8 /

10

TR

UE

P3

41

51

42

41

52

34

44

33

34

43

3587.5

08 /

10

2 / 1

0FA

LSE

P4

41

51

41

51

51

34

44

34

44

44

3895.0

08 /

10

3 / 1

0FA

LSE

P5

41

21

42

32

41

34

14

33

23

34

3075.0

05 /

10

4 / 1

0FA

LSE

P6

54

53

51

42

32

41

42

44

33

23

3075.0

07 /

10

5 /

10

TR

UE

P7

51

51

51

51

51

44

44

44

44

44

40100.0

09 /

10

8 /

10

TR

UE

P8

31

41

41

41

42

24

34

34

34

33

3382.50

9 /

10

5 /

10

TR

UE

P9

44

52

51

52

52

31

43

44

43

43

3382.50

10 /

10

6 /

10

TR

UE

P10

42

51

51

31

42

33

44

44

24

33

3485.0

08 /

10

6 /

10

TR

UE

P11

22

33

51

54

24

13

22

44

41

11

2357.5

04

/ 1

01 /

10

FA

LSE

P12

42

43

41

21

52

33

32

34

14

43

3075.0

07 /

10

8 /

10

TR

UE

P13

43

41

42

51

41

32

34

33

44

34

3382.50

7 /

10

3 / 1

0FA

LSE

Ø 8

0.9

62

Ø 8

3.21

4

δ 10.216

δ 7.7

59

Measu

red v

alu

es

(5-s

cale

)Calcula

ted S

core

Contr

ibuti

on

Fig

ure

B.1

:T

he

give

nan

swer

sof

the

par

tici

pan

tsw

ith

the

calc

ula

tion

sm

ade

bas

edon

SU

S[2

9].

Appendix C

Contents of the CD

• The LATEX source of this thesis

• The PDF document of this thesis

• Source code of the Coinblesk Front-End application (including the source code ofthe adapted Bitcoin.JS library and the adapted Instascan library)

• Source code of the Coinblesk Server application

• The abstract in two .txt files for both the German and the English version

91

Documents

A Progressive Web Application for Coinblesk · web application o ers similar functionalities as does the native Android client with the bene t of having secure device-independent