 I think we can get started now. I was supposed to be the interesting talk, but 20 minutes ago, plan A demo didn't work, plan B demo didn't work, plan C demo didn't work, because of poor internet connection. I have to run a full, OK, I'll try to speak louder. So I have to run a full chain for the demos to work, so that's why I'm not sure that I can, I will be able to actually show you something. So I am Laura Dana. I have been working with BrainBot developing microraden, so I am one of the developers. Now, how many of you have heard about Raden Network or microraden? OK, that's good. How many of you have heard about state channels or payment channels? OK. So both Raden Network and microraden use payment channels as a scaling solution. The difference between them is that microraden is a framework for off-chain payment channels but unidirectional from many to one, as opposed to Raden Network, which is many to many. So Raden Network is more complex in the sense that it needs routing. It needs fees to incentivize nodes in the system so they can route payments without having to always open channels between the sender and receiver. So that's why microraden is actually free, offers free off-chain transactions because you open a channel and it's only you and the receiver, you sending tokens to the receiver, so that doesn't cost anything. Microraden is available now on the mainnet and the testnet, Robshten, Ringby and Coven. The version is 0.2, and it's another bug bounty release. So after we see what happens now, please, if you want to look at the contracts and we actually had a very successful bug bounty release of version 0.1 and we actually changed some of the code that we didn't find any important bugs, but there were some advices that we took into consideration. So please have a look. As use cases, you can have paywalled content, so pay per use. This is one of the main use cases and I can actually show you a demo now, hopefully. Okay, so I have my microraden server working here and this is the Robshten chain syncing. And we have a paywall here that wants us to open a channel. We have MetaMask connected and we already have 39 tokens as a deposit here. We can deposit nine tokens. This will take a bit because this is an on-chain transaction, so opening a channel happens on-chain and we can follow the transaction. We'll have to wait a bit. We can see that the microraden server already received the create channel event, but we are waiting for some confirmations first. It has seen that the channel is open. We're still waiting a bit here. Okay, and now we can make our first off-chain micro payment. This is actually... So the token that we use has 18 decimals, so that's why it's so large here. And now we have our content. If we refresh the page again, we are prompted to sign to pay another time for the resource and this is how the paywall content works. If we want to... We can also tap up the channel if one will remain out of tokens, but let's close the channel for now. This again is an off-chain transaction. So opening a channel, topping it up with tokens, closing the channel, and we have also added a withdrawal function. So now the receivers can withdraw their tokens from the open channels. So that's why these channels will be long-lived because the service providers can actually withdraw tokens. Yes? We need to Wi-Fi. Doesn't automatically close and then stay open? While the server, the micro-aided server is closed, the receiver or the service provider needs to keep this micro-aided server opened. If it's closed, it cannot receive payments. It cannot receive events. So the senders or the clients cannot access the resources. So switching after you have paid for the resource? After opening the channel content? After opening the channel on-chain, you just come back and you see your channel. It's not closed. Yes, yes, yes. Yes, for example, even at this point, we store the temporary channel data in the local storage of the browser. But we can also retrieve the channels from the blockchain because opening the channel, topping up, has events on-chain. So we can look at those events and retrieve that channel data. And we can query, I'll get to this later bit when I actually explain how it works. The receiver always has the last balance proof of the client. So the client, if somehow loses the channel data, it can get even the last balance proof from the receiver. So this is the channel closing and we can see that the two tokens have went to the receiver. The two tokens that we have spent and the rest have come back to us in our account. We can forget the channel and then redo the process. Going back a bit to the presentation. So one use case is the paywall content and another one is machine-to-machine services. APIs for whatever you would think. For example, we have a video demo online and we have an example of querying the Ether price and US dollars and we do this constantly and we can see that we're sending payments. These sending new balance proof is the actual payment and yes, you can look at that. I also prepared or wanted to show you a more interesting demo today. Not sure if this will happen, just a moment. And then I'll show you the code that you need to actually do this demo because the nice thing is that you don't need a lot of code if you know how to control the drone. That was actually the harder part. So up here we have the micro-ident server for the drone. So the drone has an Ethereum account and there has been a bit of activity before. I almost forgot. I have to connect to the wifi of the drone. So we have to wait a bit until I can see it. Okay, try this again. Okay, if this time it doesn't work, we'll just... So the idea is that we already have an open channel with the drone and now these commands just are done. I mean, you actually pay a fee for each command and then you can fly the drone however you want. Hopefully next time, I'll actually have a nice interface for this. Yeah, these are, here we can see that. We are sending the requested price and then, yeah, it's alive. Unfortunately, I didn't prepare it for this room. Yes. Yeah. It would have been more interesting to actually pay for each request, but I have to be honest, I didn't have enough time to do it like that. And we actually have, it should have made some snapshots of the room. So we can also make it... I mean, we can also pay for each picture. But now for the code. So there's a lot of code here, but it's something else, so don't worry about it. This is the micro-raden server that was used. So we import some helper classes from the server and then this is the resource for which we pay and I just put in all the commands here. So it would have been nicer to separate the commands and do separate APIs for them. But I just wanted you to see how easy it is to actually set up a machine-to-machine server and client for this type of use. And then the client... Yeah, we'll probably have this online so you can actually look more. Okay. And this is the client. So with just two files, we made this. Okay, yeah, I should have shown you this before. So we have the repository. It's open source at Radon Network Micro Radon. I told you about the off-chain payments. So the channel data contains the receiver address and the sender's address, the block number at which the channel has been opened and the last balance because the balance is always increasing so we keep the last value. And the receiver keep the channel data. The receiver also has the last balance proof received from the sender. This data is signed by the sender and this is the actual balance proof. We use now signed type data as a standard which is still in work so that's why we are not able to actually have a stable release because we are also waiting a bit for the standard to be implemented. And the nice thing about it is you saw when we are actually signing the balance proof that we actually see text so we can see how many tokens we are paying to whom, what's the contract address and so on. Until now this wasn't really that nice when signing messages. So the sender sends all of this data to the receiver and then he gets the resource. We also support the ERC-20 and ERC-223 tokens up until this point. I know there are some more standards coming out. Why we decided for ERC-223? Mainly because of lower gas cost because we only do one transaction for opening and topping up channels instead of two transactions. So we only do a transfer and the same transaction opens the channel. The ERC-20, you have to approve the tokens first and then you can create the channel and it's the same for topping up. About closing the channels, so what happens? The best case scenario is when the sender and the receiver actually agree about what amount of tokens is owed. So the sender queries the receiver and sends him his balance proof and then the receiver signs the same balance so the receiver sends his own signature to the sender and then the sender can close the channel for both of them and that's instantly. There are two more cases when the receiver, let's say he's not online or for whatever reason he doesn't want to sign. The sender can close the channel and then there's a challenge period in which the receiver with the last balance proof that he has stored, he can close the channel himself or after the challenge period has finished then the sender can settle the channel himself and that transaction is also instant. Next time we may have maybe a demo where you can play with the drone yourselves. Just being optimistic here. So yes, you can find the code and please participate in the bug bounty we have given tokens in the previous one. That's it.