Coinblesk: Payments &
Administration in a Web
Application

Master Thesis: Final Presentation

by Sebastian Schrepfer

live slides

Overview

1. Introduction​

2. Web Application

   • Architecture

   • Business Logic

   • Progressive Web App

3. Evaluation

4. Conclusion & Demonstration

5. Discussion

goo.gl/6Ty8Wx

Introduction

1

Coinblesk: Previous Work (1/2)

• Mobile Bitcoin Payment System

• Initially designed to make payments at a point-of-sale

• Now, general-purpose Bitcoin wallet with instant payment confirmations

  • Intermediary server confirms payments between users instantly

• In the first version, the funds were moved to the Coinblesk server and virtual payments between the user were made

• Introduction of Time Locked Addresses (CLTV) moved the possession of the funds to user

  • User & Server signs a transaction, private key of the user not available on the server

Coinblesk: Previous Work (2/2)

• To decrease Bitcoin transaction fees (~3.61$ for one small Coinblesk transaction, as of 20.08.2017), micro payment channels and virtual payments were introduced

• Micro Payment Channel:

  • Open payment transaction to the server, who can be sure, that it is not spent yet (time locked address) → broadcasted later

  • New transaction is combined with old one (replaced)

  • The payment goes to the server instead of the actual recipient. The actual recipient gets virtual funds

  • Only up to 100 US-Dollar, because of the increased trust to server

• Virtual Payments:
  • The virtual funds can directly be spent between the users without having to pay fees (database operations) → server owns the funds

Motivation

• Coinblesk is only available as an Android application

  • iOS, desktop users etc. cannot participate

• The private key to access the funds is only available on one device

  • In case of a theft or a system crash, the funds are gone

• There is no administration to monitor the application and add/subtract funds to/from the system (buffering funds)

• The micro payment channel has not yet tested in an application
  (not yet implemented on Android)
   

→ Building a web application addresses these issues. The idea is to create a device-independent payment platform for Coinblesk users and administrators.

Web Application

2

Architecture: Main issues

1. A web application cannot run a Bitcoin node

2. Private key of the funds is stored locally on Android device and should not be shared with the server

Bitcoin network connection

• Running a Bitcoin node with a web worker is possible but experimental and space-consuming (ported Node.js solution)
• Information retrieved by the Android app comprises only of the current balances
• Transactions are always broad casted over the server
• The current balances can also be provided by the server
• A link to an external blockchain explorer can be given (to verify to data by the server)

"A web application cannot run a Bitcoin node"

iOS/WebApp User

Synchronization

"Private key stored locally; should not be shared with the server"

• Multiple devices need to synchronize the key to access the funds
• Synchronization is possible over several media:
  • Sharing over Internet (e.g. e-mail)
  • Sharing by hand (typing)
  • Sharing by QR code
  • Sharing the key with the server, but encrypted
• Last option most convenient & secure, because
  • Server has no access to the key, if the encryption is strong enough
    • Encryption must use a strong pass phrase to keep key save
  • Synchronization is made automatically between the devices

Business Logic  User

• Transfer Funds

  • Transfer of funds to Bitcoin & e-mail addresses

  • Scanning of QR codes

  • Currency conversion

• View Funds

  • View of all Bitcoin addresses & virtual balance (incl. QR code)

  • Payout of virtual funds to the current locked address

  • Creation of new time locked addresses

Business logic  Administrator

• User Account management (deletion, user-role switch)

• Account management (actual Bitcoin addresses)

• Event handling

  • ​Gather log events and send administration e-mail if threshold of critical events is exceeded

• ​Server Balance

  • Determines, if the the micro payments are not in balance (critical)

  • ∑ all virtual payments ≠ ∑ all transactions → ☠ bad state

  • Creates a critical event which leads to an automatic e-mail notification (admin)

Implementation

• Token-based authentication (Local Storage)

• User State handling with Vuex

• Routing with Vue.js → Automatic error handling on wrong link or missing permissions/authentication

• Login, Registration, Password forgotten, Activation

• HTTP interceptors for unexpected error handling

• Global Message Handling (Toasts)

• i18n, English/German with global & local translations

Progressive Web App

• Provides an app experience on a mobile device:
  • App icon on the home screen; loading screen with large app image and configured theme colors
  • Full-screen mode: The web app is opened in full-screen with the system header bar or completely in full-screen
  • Offline mode: the main specified request always returns a 2xx status code and delivers content no matter if offline or online
  • Possibility to send native notifications
  • Everything from Web 2.0 (responsive designs, etc.)

PWA: Implementation

• Manifest to make it standalone and provide graphical information (icon, large icon, theme colors on startup etc.)
• Service Worker
  • Proxy between web app and server: caches static files
  • Lists all static cached files and downloads these in another thread (web worker). On the next page load, the service worker is active
  • Requires the JavaScript build process to support PWA
    • The hash of content of each file must be added to a static file during the build.
    • If neglected, the page might be using old resources indefinitely on some clients.
    • The service-worker.js is checked every time for updates
• HTTPS required (mainly because of the service worker)
• Responsive styles

Evaluation

3

Usability Evaluation

• System Usability Scale

  • 10 simple questions (positive/negative alternating)
  • SUS Score (0-100) can be calculated for each participant the provided algorithm
  • According to a study, a SUS score above 70 is acceptable

• Results

  • The mean SUS score of all participant is 80.962 with a standard deviation of 10.216

  • According to the same study as above, adjectives can be mapped to a SUS score. The Coinblesk web application is between "good" and "excellent"
  • If only the participants are considered with a crypto-currency skill of >= 5/10 (additional question), the mean SUS score is 83.2

Usability Evaluation

• Results

  • If only the participants are considered with a crypto-currency skill of ≥ 5/10 (additional question), the mean SUS score is higher: 83.2

  • The lowest SUS score was submitted by a participant with the  knowledge of crypto currencies of 1/10

Conclusion

4

Conclusion

• The Progressive Web Application offers device-independent access for all users, independent of the system

• Multiple devices have simultaneously access to Coinblesk because of the synchronization of the encrypted private ke

• There is an administration to monitor the application and add/subtract funds to/from the system (buffering funds)

• Micro payment channel transactions & virtual payments can be made with the web application

Demonstration

click here

will only work on the presenter's laptop

Discussion

5