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

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

1

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

1

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.

1

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

2

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)

2

"A web application cannot run a Bitcoin node"

2

iOS/WebApp User

Synchronization

2

"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

2

  • 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

2

  • 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

2

  • 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

2

  • 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

2

  • 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

3

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

3

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

4

Demonstration

4

click here

will only work on the presenter's laptop

Discussion

5

Made with Slides.com