We are proud to support FC Bayern, Germany’s leading soccer club on their Hackathon:
Thinking of fan experiences and services in a new way. Testing and applying innovative and new technologies within and outside the stadium. Bringing the emotional connection of our club to life even more through technology and digital infrastructure. Learning from each other and creating new things together.
For the first time, FC Bayern Munich will host, together with its fans, partners, leading experts, start-ups and students from all over the world, the #FCBayernHackDays to learn together, face new challenges and to research new innovative possibilities.
We’ve stirred much interest in the issuance of our XSC token at the IOTA hackathon in Gdansk. We therefore decided to prolong our rewards campaign for IOTA developers for 1 week:
If you’re a developer who committed code to advance the IOTA network during the month of November, you’ll be eligible. If you think you’re eligible you can request up to 250 XSC until Friday, 1 December 2017.
For more information on the CSC Blockchain Evolution Incentive Scheme, click here and here.
This is the second installment outlining the experiences of the winning team “PlugInBaby” during the IOTA Hackathon. In the first post (found here), we describe the idea generation process. In this post, team member Rebecca Johnson goes into more detail with regards to how the team built the project and what exactly it accomplishes.
Our PoC decentralizes and democratizes access to a network of electric vehicle chargers by allowing the chargers to costlessly broadcast their status (offline, occupied, available) via 0 value transactions on the tangle. Next, using a mobile app, users searching for a charging station can query the tangle using 0 value transactions to search for tags of available stations. They can reserve a charging spot and book micro transactions necessary to pay for electricity, all using IOTA.
Using the tangle as a database makes the solution quite elegant. The protocol for sending data and value are essentially the same which removes the need for a centralized payment processing layer and allows for the DIY ethic to extend all the way to the end-user.
This approach is also flexible enough to leave room for participation by utilities and other stakeholders since the hardware and software are open-source. Improvements are welcome and anyone is free to implement the idea. The code can be found here.
Requirements & Assumptions
We restricted ourselves to using only IOTA for implementing the database functionality. This carries the theoretical advantages of future scalability, full decentralization and zero transaction costs for messages sent to and from the tangle as well as a mechanism for machine to machine electricity purchases.
We assumed that the API and the interaction between the charger and the car app are out of scope for the hackathon.
Charging station vendors need to send status messages for their stations (free, in-use, offline) using 0 balance transactions to the tangle. Our back-end provides this capability via terminal inputs. Since this is just a PoC we didn’t build out an API or UI for this portion.
A web-based front-end, a back-end connection to the tangle and an API for communication between the two needed to be built. Given this, the team split into two groups of 3-4 developers each.
The experience of the PlugInBaby team was similar to that of the Freedom Pass team. We started out by following this tutorial from Baltic Data Science and gained speed by utilizing some of the resources from the Q&A with Chris Dukakis of IOTA. After that, we connected to a testnet node and started issuing transactions.
Like the Freedom Pass team, we also considered using a mainnet node but the issue of how to connect with neighbors was eventually a knockout criterion. This was actually due to security concerns. One of our team members had a Java Runtime Environment setup on a remote virtual machine and we considered setting up an instance of the IRI. In the end, however, we weren’t comfortable with the security risks that connecting with unknown nodes presented.
Our team member Lukasz Zmudzinski has written a great blog post on his site which outlines which Python methods we used to read and write to the tangle in greater detail. We used the Tornado web framework and asynchronous networking library for this project and wrote our own API to communicate with the front end.
Users can query the tangle for the transactions of vendors with free stations and also read dynamic pricing information. The search mechanism uses information written to tags while the state information about the charging station and the station latitude/longitude are written in the message. This information is then passed via API calls to the front-end for interpretation in the UI.
The user uses a smartphone app to query the tangle for available charging stations.
The user selects a charging station from the map. Each station has dynamic pricing which is shown in real-time along with the map pin when selecting the station.
The user drives to the station and lets the station know that they have arrived by sending a message to the tangle.
The charging station tells the app that the car is fully charged.
The user’s IOTA wallet is debited and the transaction is signed by the seed stored in the app.
The charger resets its status to available on the tangle and all the transactions/messages are available for verification.
What We Learned:
The PlugInBaby PoC demonstrates the feasibility of an IOTA-based search and payment app for IOTA-based DIY chargers but it is far from ready-for-use outside of the lab/hackathon. A number of issues came up which will need to be solved before this system would be appropriate for public use.
Tags only allow for 27 characters which wouldn’t be enough to store latitude and longitude data plus a transaction ID without truncation. The team ended up using the message field to store data (location + charger status) while the tags were used to store a searchable charger identifier.
Speed is quite limited on the testnet. Specifically, we found that the testnet confirmation times were quite long late at night (2-3 minutes) when fewer users were online running test applications. This is due to the fact that each new transaction must approve two other transactions. This approach scales well but also requires many active nodes to submit and approve transactions. As both the testnet and the mainnet grow this problem should be mitigated.
Transaction caching was required to make the demo useable within the alloted three minute presentation time.
While the support from the IOTA team was excellent, we noticed that the documentation, particularly regarding the phython libraries, is quite lacking. This makes development a slow trial and error process.
Security and privacy are generally open questions within the IOTA ecosystem. The team assumed these issues to be outside the scope of this PoC. That said we raised privacy concerns regarding the possibility of API misuse and the lack of privacy often during the development process. Improved documentation and more descriptive error messages would go a long way towards making these issues easier to handle.
Masked Authenticated Messaging (MAM), the planned Private Transaction layer, and the integration of zero-knowledge-proofs into the IOTA ecosystem are exciting areas for new research given the current limitations of IOTA in the area of security and privacy.
To sum up, the team learned a lot about the implementation of an exciting use case that really makes sense for IOTA. Is this the only way to build such a system? No. There are many other ways to find, navigate to and pay for electric vehicle charging. Many market-ready centralized systems are already up an running. Our PoC demonstrates, however, that it’s possible to solve this use case using IOTA alone which allows for the possibility of a scalable decentralized approach. This, in turn, could open up the field to many more players and provide a common system for various entities to build upon.
Here is an overview of all reports on the IOTA Hackathon’s projects:
The IOTA Hackathon took place from Nov 17 to Nov 19 in Gdansk, Poland. Software developers from all over Europe came together to put to test the IOTA Platform with various use cases. The event was sponsored by IOTA, Baltic Data Science (blockchain and big data service), Datarella (blockchain and big data consultancy) and Bright Inventions (mobile app development). Four teams of developers and software experts formed around various use cases and competed for 4,200 IOTA in prize money.
The team was joined by Bogdan Vacusta, who brought a real-life challenge from the London Council to the IOTA Hackathon. London Councils issue “Freedom Passes” to disabled residents which allow them to use public transport within the city free of charge. Prior to the issuance of a Freedom Pass, one must obtain a doctor’s certificate to prove disability.
Unfortunately, scammers have successfully been photoshopping doctor’s certificates for perfectly healthy London residents. No one knows for sure how many Freedom Passes have been issued under false pretenses but the number is likely in the thousands. London Councils have no procedure in place to verify if a certificate has been faked. A simple alert, when one doctor has issued an unusually high number of certificates would be a huge step in successfully detecting fraud. This step alone could save the public tens of millions of Pounds per year with the help of IOTA.
The team’s task was to build a Proof of Concept (PoC) to prevent fraud. So, how can IOTA be used for fraud detection?
2. The Solution
The team decided to create a transaction from the doctor to the applicant, thus certifying the disability of the applicant on the IOTA Tangle. If an anomaly in the number of issued certificates of a doctor occurs, the system alerts the London Councils.
In an ideal scenario, the doctor would issue this digital certification from an app (mobile or web based), signing the transaction with her private key (this measure would actually help prevent fraud). Given the short timeframe at the IOTA Hackathon (less than 24h), the team chose to create sample data and to carry out the transaction on the doctor’s behalf for the PoC. A local database would be fed the details of the doctor and the applicant, as to identify them. So, the system for the PoC was to include the following components:
An input form for doctor and applicant data
An interface to the IOTA Tangle
A database with doctor and applicant data
A backend which analyses the data
A frontend for the London Councils with a list of alerts
3. The Process
Here’s is how it works:
1. Entering the data
The data is written to the local database. Simultaneously a transaction – symbolizing the disability certificate – from the doctor to the applicant is immutably written to the IOTA Tangle. The transaction ID is, in turn, written to the local database adding the ability to prove that the certification has taken place.
3. Analysis & Reporting
The backend analyses the data and alerts the officials in case of any anomalies. ie. (If one doctor has issued unusually many certificates within a certain time frame.)
What we learned
We completed our goal within the timeframe despite running into issues due to working with an immature system along the way. In the end, we managed to create a Proof of Concept perfectly suitable for the setting of the IOTA Hackathon.
We did run into a few issues along the way which must be addressed by the IOTA team in order to improve the system and make it fit for future use cases:
Speed of transactions: On the IOTA testnet we experienced long wait times when confirming transactions. Submitted transactions confirmed in ~1 minute, reading transactions took circa ~3-5 minutes or more depending on the amount of data. This may be a testnet issue independent of the mainnet.
The Documentation was not up to date, there was missing information and what documentation existed was somtimes misleading (i.e. Properties marked as optional are actually required, not obvious that a replayTransaction function creates a completely new transaction, sending a message instead of a transaction the sender is not documented on the tangle …)
Releases are not scheduled in advance, if an update is run during development, developers must adapt quickly to accommodate changes. A roadmap by IOTA for releases would be very helpful.
Node.js SDK is based on “callbacks” (an old technology standard), not on “promises” (current technology standard).
The API can easily be misused. Values and properties that shouldn’t be passed can go through without any error message. The API is missing descriptive error messages, leaving developers in the dark when it comes to hunting down bugs.
So, why IOTA?
Frist off, one might argue that this task could have been done with a regular database entirely. While this is true, a database is a lot easier to attack by hackers than a blockchain or tangle. Also, this kind of system could have been set up on a blockchain system s.a. Ethereum, why use IOTA? Well, the challenges blockchain systems are struggling to overcome are performance and scalability. Due to block sizes, transaction times constantly increase – thus making the systems less usable for scenarios in which transactions must happen near instantly.
IOTA helps to solve the problems of performance and speed of transactions. The team is in agreement that the IOTA Tangle and similar “non-block” chain approaches are likely to be most feasible to enable scalability in future. Also, an application using IOTA can quite easily be transferred to related use cases.
Would the team recommend using IOTA for fraud prevention?
The answer is Yes, if the long term goal is to further develop IOTA in general. The answer is No, if the system should be used in a productive environment at this point, since it is still immature. Alternative systems which currently are more mature and could be used for the task include Hyperledger Fabric, Sovrin and Ethereum. These blockchain systems pose scalability issues in the future, whereas development here is also ongoing.
The IOTA application “Freedom Pass” is very well scalable and transferable to related use cases. However, IOTA must undertake massive improvements regarding performance s.a. speed and documentation as well as for the API and SDK/node.js. If the above issues are continuously improved, the team recommends IOTA for further developing this kind of system for the public. IOTA promises future potential for the public for reconciliation of data, reduction of duplication, auditability, authentication.
This is the second installment in our posts about the experiences of the “Freedom Pass” team during the IOTA Hackathon. In the first post (found here), Kira set the stage and explained the current issues of the London Freedom Pass. In this post, we’ll get a bit more detailed with regards to how we built the project.
DISCLAIMER: Even though the project is called “Fraud Detection” the technological focus is very much on IOTA and not at all on machine learning-methodologies or data science, as one would commonly associate with fraud detection and prevention.
After we’d narrowed the scope down sufficiently to what we thought would be achievable during a hackathon, we started getting familiar with the IOTA tangle. We followed this tutorial for making a simple transaction, written only a few weeks earlier but already with some modifications required. After having gotten ourselves familiar with the general concepts of the Tangle (much accelerated by a presentation and Q&A by ChrisDukakis of IOTA) we connected to a testnet node and started issuing transactions.
Before we get into the details of the project, I’ll make a short comment about the decision whether to run a full node, the IOTA Reference Implementation (IRI) or to connect to pre-existing nodes. In short, to run the IRI, one needs a complete Java Runtime Environment, which is one of the reasons why IOTA can’t be run on an IoT device at this point. Each node connected to the tangle exposes an HTTP API through which transactions can be issued. To set up an instance of the IRI, one has to acquire the addresses of the already connected nodes in the tangle. The recommended way to do this is by asking people in the slack-channel #nodesharing. Because of the above restrictions and our requirements in time, we didn’t think it would be necessary to run our own node.
Register Doctor as a seed on the tangle
Register Applicant as a seed on the tangle
Perform a transaction for each certificate between the issuing Doctor to the Applicant.
Verify that a certificate was registered on the tangle given a Doctor and an Applicant
Read information off of the tangle about outgoing transactions from all Doctors
Given the above functionality, how could we leverage the existing IOTA library in the best way possible? Well, since smart contracts or most types of advanced transactions aren’t really possible on IOTA (yet), we will need some off-tangle processing, storage and UI.
For this, we implemented a backend and some wrapping to process the information from the applications. The server-side was written using Node.JS and the express-framework. To model the logic and structure of the database, we used MongoDB and mongoose. The MongoDB contained a simple key-value store, saving relevant applicant information. One could imagine that is could be upgraded to a graph-model to better mirror the tangle structure and to be able to more efficiently analyse connections between Doctors and Applicants, however, that was out-of-scope during the ~24h of coding we had.
In order for the user to interact with the tangle in an easy way, we built a small web-frontend. It allows the user to enter information about an application such as the national insurance number of an Applicant, postal code of the Doctor and Applicant, phone numbers, etc. At this stage, four things need to happen:
The information is saved in the MongoDB-collection,
seeds for the Applicant and Doctor are created based on an aggregate of identifying information,
new test tokens are generated and sent to the Doctor’s account and
an IOTA transaction is issued from the Doctor to the Applicant.
To save the information into a MongoDB-collection a controller instantiates and returns a new model containing the just entered data. It passes it on to the server.jswho handles the HTTP-requests from the client.
There is no dedicated IOTA API-call for generating seeds, but they do supply a command line command for generating a random seed. We made our seeds relatable to the private information by concatenating the private key with the national insurance number for the Applicants and the Doctor’s ID for the Doctors. After the seed was generated, a fresh address is created for each new transaction.
To make the functions from the iota.lib.js a bit more usable, we wrapped the existing callbacks-based structure in Promises. This allowed our code to become a bit more asynchronous than it is ‘out-of-the-box’.
Here is an overview of the architecture:
Once the data and the transactions were issued, the next step was to provide a way of viewing the existing applications and certificates. So we created a second page of the UI for listing all applications with relevant information read from the MongoDB-collection.
This doesn’t, however, provide such a great way of finding the main type of fraud that we were considering, namely Applicants reusing information about Doctors. This makes it look like a single Doctor issued an unreasonable amount of certificates. A pretty easy case to catch, one would think, but considering it is a completely analog process done by on paper in different boroughs by different administrators, it sums up to quite a large amount of faked applications. This is the type of fraud we focussed on in our processing.
So how can we in a user-friendly way flag cases that should be investigated? We chose the simplest option and created a second view of the UI where each Doctor in the system is listed along with the number of certificates they’ve, supposedly, issued. The list is sorted by the number of certificates issued. Here one could imagine making it a bit smarter by including the date the certificate was issued and creating a more differentiated metric of certificates per time unit, but it wasn’t in scope this time around. If a Doctor issued more than 10 certificates, they were highlighted in red. A very simple but potentially efficient way of communicating to the user that something needs to be investigated. Of course, the number 10 was completely arbitrary and could have been chosen differently. In fact, to decide that number, one would have to, first of all, analyze historical data.
To sum up, Team Freedom had a lot of fun and learned tons about IOTA, ideation, cooperation, and creation in a short time-frame. We managed to build a functioning Proof of Concept for how IOTA can be used for the secure issuing of medical certificates in order to prevent and detect fraud. The application to the Freedom Pass was done so that it would be easier to understand what was being done and why. But that does in no way mean that the base structure cannot be used for other purposes, in fact, it was written specifically to be general enough that it is also interesting in other areas.
Is this the only way that the problem could have been solved? No. Was it the easiest way of solving it? Absolutely not. However, we believe that only by experimenting and utilizing one of the few scalable and future-resistant distributed ledger solutions can we achieve applicability. There is, generally speaking, almost no distributed ledger application that could not have been done without the use of a distributed ledger, but it would have incurred great financial, organizational or trust costs. IOTA is a very cost-effective and scalable solution, but with the caveat that it is still in its infancy.
Here is an overview of all reports on the IOTA Hackathon’s projects:
The blockchain tech sphere in the fall of 2017 looks totally different than in the same period of 2016. Then, many people heard about blockchain for the very first time, now there are several dedicated blockchain platforms for specific applications. In the field of Industry 4.0, beside supply chain and robotics, IoT applications provide a hotbed for highly scalable blockchains, such as IOTA, NEO, or QTUM.
For and with one of these IoT-specific blockchains, IOTA, we will organize a hackathon, a week-end full of code, co-creation and ideas.
BUILD THE FUTURE WITH US!
Today is blockchain, tomorrow is industry 4.0 and the internet of everything. Autonomous cars, sensors and intelligent factories are the future but how will they communicate and transact among one another on a worldwide scale? IOTA is a blockless ledger system which enables scalable autonomous machine to machine micro-transactions without fees. Want to get your hands dirty and take part in building the future?
WHAT’S THE IOTA HACKATHON ALL ABOUT?
Developing services or products for the internet of things
Gaining experience with IOTA’s blockless ledger system for cutting-edge machine to machine transactions
Keynote speeches by key players in the industry
Networking, fun, free food and friendly competition
THREADS TO BE PURSUED
IoT Based Business Plans
Hardware Connectivity Layer: Bluetooth, Z-wave, ZigBee or LoRa
Application Layer: MQTT, XMPP
Fog, Mist & Edge Computing for IoT
IoT Maintenance & Lifecycle Management
Identity of Things (IDoT)
WHO CAN PARTICIPATE?
Business Practitioners & Economists
FRIDAY 17 NOV 18:00 – 19:00
Reception and Networking: Get comfortable and get to know one another
19:00 – 21:30
Keynote Presentations: Introductions and food for thought
– Jörg Blumtritt (Datarella)
– Dominik Schiener (IOTA)
SATURDAY 18 NOV 9:00 – 9:30
Breakfast and Coffee: Fuel up for the Hackathon
9:30 – 10:15
Individual Introductions: Barcamp style three keywords per person
30 Second Elevator Pitches: Explain your idea, build a team that can execute it!
10:15 – 11:00
Team Building: Chat with team leaders of interest & decide which team you want to hack with.
11:00 – 12:00
Speakers round: Getting started with IOTA: Dev Tools & Resources from Baltic Data Science
12:30 – 13:30
Lunch Break: Enjoy some delicious food and get ready
13:30 – 16:30
Time to Hack: Build, Test, Iterate
16:30 – 16:45
Movement Break: Get your blood pumping!
16:45 – 19:30
Time to Hack: Build, Test, Iterate
19:30 – 20:30
Dinner Break: Take some time to nourish the body and get ready for the all nighter to come!
20:30 – Late
Hack Till Your Heart’s Content: It’s up to you. The accelerator is open all night. Code till you drop.
SUNDAY 19 NOV 9:00 – 9:30
Breakfast and Coffee: Fuel up for the final day
9:30 – 12:30
Hacking and Presentation Prep: Get your demos running!
12:30 – 13:30
Lunch Break: Nutrition for the final stretch
13:30 – 14:00
One Last Check: Audio Visual and Tech Check for Demos
14:00 – 16:30
Demo Presentations: Show us what you’re made of!
16:30 – 17:30
Jury Session: Enjoy some refreshments while the jury deliberates
17:30 – 20:30
Awards Ceremony: Celebrate with the winners, network and celebrate
To apply for the IOTA HACKATHON 2017 register now!
Don’t wait for too long – the number of participants is limited.
Today, we would like to announce something special. Something we can’t wait to take place and until mid June it’s going to be tough to sit tight. Please, feel invited to our Wearable Data Hack Munich 2015!
The Wearable Data Hack Munich 2015 is the first hack day on wearable tech applications and data. It will take place right after the launch of Apple Watch – the gadget we expect to rise the tide for all wearables. Withe the Wearable Data Hack Munich 2105, we aim to kick-off app development for the emerging smartwatch and wearable tech market. During this weekend you will have the first occasion to share your views and ideas and jointly gather experience with the new data realm.
Apple calls the Apple Watch “Our most personal device ever”. And with good cause: The data from wearable tech, smartphones and smartwatches are really the most personal data ever. Our mobile devices accompany every step we take, every move we make. A plentitude of sensors on the devices draw a multidimensional picture of our daily lives. Applications of wearable data range from fitness to retail, from automotive to health. There is hardly an industry that cannot make direct use of it. And yet, wearable apps still are in their childhood. The Apple Watch will be hitting the street in April and will get the ball rolling.
THREADS TO BE PURSUED
Developers, data geeks and artists will pursue one or more of these threads:
– Data-driven business models for wearables – Data-driven wearables – Smartphone app (Stand alone / combined with smartphone) – User Experience – API – Open Data – mHealth / Medical Data
So let’s explore what we can do with this data! Let’s play with the possibilities of our wearable gadgets and mobile sensors.
To apply for the Wearable Data Hack Munich 2015, please send us an email with
– your name
– your profession
– your take on wearable data
– 3 tags describing yourself best.
Don’t wait for too long – the number of participants is limited.
For more information, please have a look here! See you at Wearable Data Hack Munich 2015!