Blockchain Engineering 2023 - Offline Token Money II

[synctext]

Team issue for 10 weeks of blockchain engineering course at Delft University of Technology

Offline token money. Your task is to create easy payments using tokens, without Internet. Giving and receiving tokens should be easy and effortless. Special requirement is that it should also work in an emergency: when the Internet is down. Probably you need to use QR-codes scanning to move Tiktok Tokens between devices. The hard scientific task is to address the double spending risk. Required background reading from Delft: Double spending prevention of digital Euros using a web-of-trust.

• Discussed: 20 and 21 April (week 10) final meeting.
• {tentative} final project goal. Create token. Transfer token to another device. Some measure for double spending mitigation.
• Prior work around Euro token transactions:
  • digital Euro engine {thesis work, nearly finished, https://github.com/KoningR/eurotoken }
  • Another digital Euro in trustchain-superapp
  • Github details of previous team: code, links, context, and comments
• You can assume a central authority in the form of a "ECB Digital Euro Public Key", hardcoded public key. Not a central trusted server.
• First sprint goal: Create unique coin EURO 000001, signed by yourself, Show QR code, scan QR code (all this is already operational inside Superapp), copy inside trustchain data structure.
  • feel free to build upon the work already done: https://github.com/Tribler/trustchain-superapp/pull/129

[Ne184]

The team went through the double spending paper and noticed that it should be the receiver the one who needs to get the warning message and the trust-score of the sender, since he is the one who is expecting to receive money.

Everyone also looked at the Trustchain paper to get acquaint how Trustchain is working and be able to reason about the double spending issue in an offline scenario.

QR scanner was developed, but need to be integrated with DetToks. QR code was also successfully produced

[synctext]

Great find! Receiver is taking the risk :police_officer: did not notice this problem earlier. The flow does not match typical trading situations! Figure 3. Screen capture of a transaction showing a trust score of the offline Euro paper shows the Send Money screen with scores. Please propose a better flow. Could just be clarification at the receiver side. For instance, a clear 3 x warning beep when scanning low-trust QR codes. A very loooong beep for QR code owner who got caught double spending and refusal to process the QR code. Idea of a collateral is also great to explore. Related (crypto) work from China: https://link.springer.com/chapter/10.1007/978-3-031-17551-0_30 Key concept: Post-incident accountability.

Limiting the scope, can't be solved in the general case. scenario: pay for water at the local supermarket you visit every week in an emergency. {nobody has any money. avoid the disaster after the disaster} quote: people leaving their phone numbers and promising to come back and settle their debts once the situation stabilises.

{repeating from first meeting} First sprint goal: Create unique coin EURO 000001, signed by yourself, Show QR code, scan QR code (all this is already operational inside Superapp), copy inside trustchain data structure.

At week 5: good to have running code of some mechanism.

[julio1998]

We discussed that our main focus should be on improving the trustscore by including more factors than just the number of transactions. Furthermore, we came up with a mechanism that could possibly detect double spending. What will be included in the final product is still open to discussion but it’s good to think these scenario’s out.

Improving score: the score should be dependent on the trustscore (number of transactions), the number of detected double spendings and the time you have been online for the last time. The last dependency is included to detect double spending (as described in next section).

Detecting double sending: detect double spending by reducing the comparisons of chains to a subset of parties a user has pre-defined before going offline. The idea is that if a user wants to pay offline he/she must first add the parties it wants to spend its money to to a list. The parties that receive the token only need to compare its chain with the chains that were part of the list. When you come online you compare your chain only to the users that were pre-defined in the list.

"It is not trivial for two random strangers to detect that they were defrauded by the same person. The proposed solution tries to reduce the number of people to compare a users chain to so that two random strangers can indeed detect fraud in a feasible amount of time."

For example, user A wants to spend money at company B, C and D. User A spends his offline token at company B. Company B now only needs to compare its chain with companies C and D to be sure there was no double spending. This reduces the comparison of chains to a reasonable subset instead of a large amount of total users in the network.

Verify tokens: a token is verified if the transaction of the token has been compared to the chains of the parties in the list of the sender. This reduces the risk of double spending. A token can only be spend after it has been verified (i.e. a token that has been received offline can not be respend before the user has been online).

Other ideas:

1. Block an account after double spending has been detected. The user may use his account after a fine has been paid.
2. Block an account for a finite amount of time.
3. Synchronize transactions with connected people so your chain can be accessed even if you are offline again.

Progress so far:

1. Choose amount and generate request
2. Encode requested amount and public key and QR
3. Scan QR code and add transaction to block

Link to branch

[synctext]

• Target next week {week 6} have a somewhat working .APK on your issue.
• Offline Euro is coming: https://ec.europa.eu/commission/presscorner/detail/en/SPEECH_23_1547
• Idea: include an address book type of list of well known counterparties. These can be selected by the attacker: what if they all collude to steal money by double spending?
  • this means everything needs to be included inside a single QR code
  • solution: concept of a transaction wallet
  • you give away the private key of a wallet containing money
  • transaction wallet: coin, owner public key, and private key of Tx wallet
• Cardinal design principle: keep it as simple as possible! Thus no offline interaction, bi-directional communication. receiver is unknown. you can see it, you can steal it. No key exchange rounds.
• Just a more basic token: https://github.com/KoningR/eurotoken/blob/main/src/main/kotlin/Token.kt#L27
  • coin minting " EURO 000001 Value: 2 Euro {signature by ECB}
  • enteral growing list of owners
  • give this coin away by adding new signature. No transaction recording, different paradigm
  • See latest offline digital Euro thesis
• or only use Trustchain when online and revert to "unsigned halfblocks"???.
• this commit picked up some other code changes: https://github.com/Tribler/trustchain-superapp/commit/3387dd4b1c7f72e21dc968c4ac122b514f80df7c
• Focus for wrapping up this course. Please pick by next week
  • detecting double spending frauded strangers?
  • this includes your idea of simple signed addressbooks, synced when online
  • or improve web-of-trust trustscore calculations

[julio1998]

Based on the meeting of last week we revised our flow and reduced the task to a viable MVP.

Score: the score should be dependent on the size of the EuroToken. The more transactions in the token, the larger the token. This is because by a change of owners a block is added to the token.

Verification: two ideas 1) Verify each user in the chain of owners, checking that they had the token and checking with every user in their "address book". 2) Add transaction to TrustChain. The transaction will be between the initiator and final owner of the EuroToken. If the transaction is added, it is considered valid. Double spending should be detected by comparison of chains in the TrustChain network. We will focus on the last one.

Our MVP can be divided in the following tasks:

• Create and store EuroToken
• Verify EuroToken
• Encode and create QR for EuroToken
• Verify EuroToken with transaction on TrustChain
• [OPTIONAL] Detect double spending on TrustChain

Each task has its corresponding UI.

What we've done since the last meeting:

• Added a new page to create tokens and show it on the screen (Ali)
• Add the functionality for adding a friend in the list of friends, add list to the wallet (update the encoding of the QR code to encode token which is also assigned the new owner) and save list in db (Nevana & Vyshnavi)
• Setup TrustChain Community inside the DeToks app. Experienced some difficulties during creation, should be running by Wednesday (Julio)

[synctext]

• Brief chat with European Central Bank in Amsterdam about our offline Euro work/offline token research
  • Program Director Digital Euro, European Central Bank
  • Event: https://toekomstbetalingsverkeer.nl/sprekers/
• Readme.Markdown documentation
  • example: https://github.com/Tribler/trustchain-superapp/blob/master/eurotoken/README.MD
  • Explain basic design, attack, and your solution: case of not fulfilling its promise to send funds
  • Please not a huge 120 page babbling report, sharp, short, efficient, and effective technical documentation
  • More depth than Euro Token example
  • @alikahawa Document the "3rd key is only thing you need" simplified design option
• Real world scenario
  • City with millions of user in China has severe floods
  • subways are flooded
  • people are hungry, shops are still having food
  • Your focus: How to pay at the semi-flooded supermarket?
• Requirement:
  • instant settlement
  • one-shot, no bi-directional communication
  • Trustchain is not a requirement
  • In real solution: QR codes are not a requirement.
  • Euro zone can dictate new "swipe-to-pay"
  • Device wakeup, no need to open an app
  • Significant boost to usability and frictionless payments
  • Display Euro amount on a cash payment terminal. Swiping means paying this amount
  • offline received money can also be spend offline (no talking to server needed)
  • Allowed to "cheat", redefine double spending as debt buildup.
  • However, how to deal with stolen smartphone, bad actor does double spend (document or even solve).
  • Offline biometrics (e.g. passport-level photo, compare face with actual person holding smartphone)
    • This could be a new scientific direction: offline biometric to protect money.
    • Open source and transparent, share hashes of biometrics
  • Or lock the wallet locally with biometric unlock {make that mandatory, to prevent the theft scenario largely}
    • encrypted storage. unlock with you fingerprint or facial features.
    • No recovery upon loss of fingerprints.
• Week 6: decide if you will call it offline Euro or Decentral Tiktok token. Replace all existing Euro code in the superapp?
• "One-time identity" idea. For each offline transaction you share the private key of a wallet with tokens in it. So a single QR has: public key, private key, and numerous coins (2 Euro x 40, 1 Euro x 3 and .5 x 7 = 86.50 Euro)
  • eternal growing chain of past owners and present owner
  • Assumption: when online you can always ask for a short fresh coin. Always ask the central bank to "break a 2 Euro coin" into anything of equal value
  • Assumption: infinite QR codes
• Please use standard Euro coin denominations in an initial GUI (.05, .1 Euro, .5 Euro, 1, and 2 Euro)

[julio1998]

We finalised our final product to the following:

• The coin will be called EuroToken and include a timestamp
• The coin will be minted and verified by a central authority. The solution will therefore not be de-centralised
• A token is valid for a limited amount of time (say a month). After a month a token must be verified before being able to re-spend it. The token will be restamped with a new timestamp.

Our application will now also include a special admin page that mimics the central authority. The admin page will be able to verify the token and re stamp it with a new timestamp.

[synctext]

• After a month a token must be verified
  • please elaborate a bit more the attacker model (calamity, double spending)
  • plus: design, and detailed solution
  • Format: https://github.com/Tribler/trustchain-superapp/blob/master/eurotoken/README.MD
• {repeating} Target next week {week 6} have a somewhat working .APK on your issue.
  • running code for passing grade
  • Make a PR!!! :exclamation:
  • Transfer Euros between us
• is add friend really the term to use for supermarket payment?
• :warning: Bit of a concern. Not as much progress as needed by Week 7.

[julio1998]

We have been working on creating a working APK. Unfortunately we have run into some issues that slowed down our progress. Up until this point we have a working QR code scanner and are able to add and retrieve the wallet of the user. We are not able to display this in the app. We also experienced issues with generating a proper APK.

TODO's:

• Display tokens from user wallet
• Display tokens in admin wallet
• Make money transfer between two users
• Verify token from user by admin

Current branch: branch

Screenshots:

Admin screen

Token List

[synctext]

• :warning: concern about the progress. Not as much progress as needed by Week 8.
• {repeating 2} Target next week {week 6} have a somewhat working .APK on your issue.
  • running code for passing grade
  • Make a PR!!! :exclamation:
  • Transfer Euros between us
  • Try to scan a QR code 10 times, what happens? (double spending?)
• for debug purposes (admin): ability to mint new Euro tokens
• [ ] Document your double spending solution
  • your URL: https://github.com/Tribler/trustchain-superapp#offline-digital-euro
• [ ] Required: add 1-section of documentation in readme.md format as with all Superapp PR projects by students:
  • https://github.com/Tribler/trustchain-superapp#peerchat
  • https://github.com/Tribler/trustchain-superapp#digital-euro
  • https://github.com/Tribler/trustchain-superapp#ai-trading-bot
  • https://github.com/Tribler/trustchain-superapp#luxury-socialism
  • https://github.com/Tribler/trustchain-superapp#freedom-of-computing-app
  • Optional very detailed documentation example (linked from main readme, located in subdirectory): https://github.com/Tribler/trustchain-superapp/blob/master/trustchain-voter/README.md
• [ ] Add animated .GIF to your readme.md documentation (with a visible QR code)

[VyshnaviMN]

Updated README.md

We also prevent the same coin from being scanned by two people, hence preventing double spending of the same coin

GIF - https://drive.google.com/file/d/1Om2BhDseR2K3bHnyacP2KV7krysMa7cg/view?usp=sharing

APK - https://drive.google.com/file/d/1MH3qiH1NXBtPdBbfjCnsNqvs3r8FT5Wg/view?usp=sharing

[Ne184]

Decentralised TikTok skeleton app for the CS4160 Blockchain Engineering (2022/23) course.

Detoks - Offline Token 2 An easy payment application that makes sending and receiving tokens easy. A user can choose the amount to be received and create a request which can be paid by a preadded contact. The payment can then be done by scanning the generated QR code and a transaction is then made. A Eurotoken is minted and verified by a central authority.

GIF - https://drive.google.com/file/d/1Om2BhDseR2K3bHnyacP2KV7krysMa7cg/view?usp=sharing

APK - https://drive.google.com/file/d/1MH3qiH1NXBtPdBbfjCnsNqvs3r8FT5Wg/view?usp=sharing

Use case The application can be used for the following use cases:

Create and store EuroToken (add screenshot) Encode and create QR for EuroToken (screenshot) Send and receive EuroToken between contacts Add new contact Double spending To mitigate double spending, contacts are to be added before users can send or receive EuroTokens. This makes it easier for admins to track double-spend EuroToken and give users warnings when trying to add malicious users. Another important concept is used to make sure that the detection of double spending is relatively on time. After receiving a new token, the token is valid for a limited amount of time (a month). After that month a token must be verified before being able to re-spend it. The token will be restamped with a new timestamp which makes it a valid euro token.

Future work To detect the double spending, two ideas were discussed which can be implemented in the future:

Using the verifivation mechanism, double spending can be easily detected when two users try to verify the same token. The authority will be able to direcly detect the double spender. To prevent double spending in offline transactions, a given precentage of the user tokens is preserved and cannot be used to make payments until the user comes online.

[synctext]

• For first time the .APK installs!
• Observed crashes
• Coins expire in 3 minutes (develop setting enabled)
• Quick look at the code. not ideal, hard delay(1000L).
• added the same QR code for another named friend gives a nice error: duplicate.
• scanning money for another public key: nice error "this token is not for you".
• Found Readme: https://github.com/Ne184/trustchain-superapp#detoks---offline-token-2
• Not as much content in Readme as would like, for instance, see token engine team
• No technical documentation on either the friendship QR code or the actual QR token transfer. It is said to contain the transfer history of all past owners. This atomic approach is obviously difficult to scale.
• {repeating} "Please use standard Euro coin denominations in an initial GUI (.05, .1 Euro, .5 Euro, 1, and 2 Euro)"
  • only basic support for 1 coin
  • no support for fractions or arbitrary sums of money
• Public key for live demo

[VyshnaviMN]

Public key

[Ne184]

Token to Vyshnavi, only Vyshnavi can receive it

[Ne184]

[VyshnaviMN]

Sending token to Prof

[VyshnaviMN]

1. Updated README.MD https://github.com/Ne184/trustchain-superapp/blob/master/README.md#detoks---offline-token-2

2. Latest APK: https://drive.google.com/file/d/1r2p7AvBQ-pumPTApD-cKcR0m7v0g8q1D/view?usp=share_link

3. Added Standard Euro Denominations (.5 Euro, .05 Euro, 1 Euro, 2 Euro, 5 Euro)

   • Supports fraction sums
   • Can send more than 1 coin at a time

4. Made Draft Pull Request: https://github.com/Tribler/trustchain-superapp/pull/158

5. For Demo:

Add public keys for a smooth transaction process:

• Public Key of Vyshnavi:

• Public Key of Nevena:

7. Code Link - https://github.com/Ne184/trustchain-superapp/

8. Sending Token to Professor:

   

[synctext]

• An offline payment application that makes sending and receiving tokens easily. Please note that developers probably do not understand that this app is exclusively offline. No usage of the IPv8 networking stack is made, not for the token transfer and neither for the `Add Friend feature. suggestion to add to readme.md
• Readme is not in the same format as others, two levels. First level is short in the main superapp readme, second level is within the detoks subdirectory
• Friendship is a requirement for sending money to a public key. This is explained in section III of docs, but not in 1. Send Money.
• Concept of expiration of tokens is explained, but not the current setting of 3 minutes. Also no pointer to the exact code and expiration setting. Another important concept is used to make sure that the detection of double spending is relatively on time. After receiving a new token, the token is valid for a limited amount of time (a month). After that month a token must be verified before being able to re-spend it. The token will be restamped with a new timestamp which makes it a valid euro token.
• no pointer to the underlying Kotlin code within readme.md