Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 well, the client logic is already implemented in TS. The only thing missing is for the client to be able to run on node environment, and to achieve it, you need only to implement private key opening and local signing with eth_signTypedData Metamask early draft, as I pointed is already done/injected in the tests (you need only to do the same with actual keys/environment). The echo node has nothing to do with client, but with server. If you want to implement it in TS, then it'd need to be done from scratch, using the python server files as base for the algorithm. The echo server is actually a tiny data logic surrounded by the µRaiden flask-restapi decorators and classes, so you'd need to implement it in TS (probably as an express middleware), and then it can be used on express endpoints, e.g. an endpoint which implements the echo node logic (basically, give back some request parameter/data upon payment, kinda useless, but good for testing)
    Peter Holzer
    @PeHo89
    @andrevmatos Many thanks for your input. I think I manged it. I can open, load, close and settle channels via TS library. But I can not increment balances. What are the steps needed to be done? loadChannelFromBlockchain/openChannel -> incrementBalanceAndSign -> confirmPayment right? I can see the incremented balance right after confirmPayment but it is not persisted. What could be the reason for that? Do you need more information on this?
    Nick Savers
    @nicksavers
    @brainbot Any plans to integrate with BitRefill?
    Peter Holzer
    @PeHo89
    image.png
    image.png
    @andrevmatos I figured out another strange thing: When I load a channel via API from python server I get the info that a channel have balance of 10 token, but when I load the same channel via TS library it have a balance of 0. What I am doing wrong here?
    Nicholas von Holtermann
    @nickvonh

    Hello, I had a general question about security.

    Considering all records of the offchain transactions are held by the receiver in a centralized server – what protects the sender from any foul play? or if the data is lost?

    where would the sender get their latest signature from – if they had to challenge a proof?
    are they expected to keep track of their own balance updates?
    Nicholas von Holtermann
    @nickvonh
    @andrevmatos any chance of getting an answer here?
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 confirmPayment sets the next balance proof as the current one, and setChannel then persists it in localStorage (if present). If you're on node, you may need to provide a localStorage-compliant object to store the proofs. The webUI demo does not do this, instead it loads the balance proof that comes in the cookies for the next server response (the server sends it whenever it detects a valid/signed but outdated proof, e.g. when you load from blockchain, you sign a 0 token balance proof, which will validate yourself with the server and trigger it into sending you your latest balance proof), validating it with verifyProof and setting the up-to-date channel state locally. That should be the balance you're seeing when you load the channel with the the TS library.
    So, you have 2 options: 1. store and load the channel info locally everytime, with localStorage or alike, or 2. sign a zero-proof, load latest from server, verifyProof it and proceed from there.
    1. is safer, as you only store BPs you've verified were delivered, but may leave you in a out-of-sync state with the server, requiring updating it manually or closing+settling the channel and opening a new one; 2. has better UX, will always use server's view which won't get out-of-sync, of course validating your own signature, but the server may get your BP, and instead of sending the resource you paid for, updating the cookies and sending a new payment request, and then you may need to pay again or go on-chain (that's kind of the case with credit card payments anyway, you could pay and the server get your money and require a new payment, it's up to the user to pay attention on it)
    André Vitor de Lima Matos
    @andrevmatos
    @nickvonh the beauty of µRaiden is that it's uni-directional, the sender/client doesn't need to challenge anything, the server can only claim the tokens the client sent a payment/signed balance proof, and it's in its interest to always use the latest/biggest one (they're increasing only). The client can't be foul-played here then. The only case where it cares is if it wants to retrieve the tokens it have locked on the channel and not paid the server, so it either: 1. do a cooperativeClose if the server is available, by requiring a closing signature which states it agrees on a given paid amount, and acknowledges the channel isn't valid and won't accept payments in it anymore; 2. if the server isn't available anymore, the client then can do an uncooperativeClose, presenting some balance proof on-chain, which will start a settle timeout, when the server (which is required to keep watching the blockchain) can challenge with its latest BP, or lose the already paid tokens if offline, but not locking forever the user's tokens
    the sender only depends on the latest signature to make a new payment (over it), which it can either store locally, or request from the server (as I answered above), and verifying its own signature on it before proceeding
    PS: The server/receiver can always immediately close the channel, as it is the only one which have something to lose, as it can only do it with last/some BP from the client
    Vadim N.
    @watercolourqq_twitter
    Hi everyone?
    Do you have an atomicity of the payment? And how does it work?
    Peter Holzer
    @PeHo89
    @andrevmatos Thank you for your response. To be honest, I don't fully understand the procedure. Just to remind you what I am trying to do: I would like to interact with the python echo service server application via an own TypeScript / JavaScript application, which I am executing locally with NodeJS (without a browser). I am using the MicroRaiden library from the WebUI demo. My target is to request the charged resource from the python echo service server. I thought, the process is as follows: Starting geth and the python echo server application on my machine and then doing these steps in my TS application: load a channel (MicroRaiden#loadChannelFromBlockchain) or open a new channel (MicroRaiden#openChannel) between the sender and receiver address (of course the python echo server application is started with this receiver address), increment channel (MicroRaiden#incrementBalanceAndSign) with the from the charged resource required amount of token and send a http get request to the charged resource with some http header and respective data (RDN-Sender-Address, RDN-Open-Block, RDN-Sender-Balance, RDN-Balance-Signature, RDN-Receiver-Address, RDN-Contract-Address and RDN-Payment). The python echo service server will prove the data sent by http headers in his own instance of MicroRaiden and if everything is valid he will respond with the charged resource. Is this perception correct?
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 Yes, that's correct. My comment was about the step after incrementBalanceAndSign: you need to "persist" this signature locally in your client, through confirmPayment or simply validate server response on next request, which should also contain the payment info you did (so, it's persisted on the server and validated on the client). Everything else seems to be in place
    @watercolourqq_twitter µRaiden payments are atomic, as they come in the http request and are fully validated before returning the paid resource. Raiden payments are kind of atomic too, as to be completed off-chain, they need the secret to be shared between payer and payee (and from there, cascade between mediators until arriving back in the payer). If it's not, to unlock the payment requires the secret to be revealed on-chain, on a SecretRegistry contract, which is then listened by all participants, and then they can unlock the payment
    Peter Holzer
    @PeHo89
    @andrevmatos Ok, I understand, many thanks! But, I did this 2 steps: MicroRaiden#incrementBalanceAndSign and after that MicroRaiden#confirmPayment. I print out the balance before the increment, which is 0, and after the increment, which is 5 (I increment by 5). Everything looks okay. But if I start the application again, it also prints 0 before the incremention and 5 after. But I would expect 5 before the incremention and 10 after. So it seems that the transaction is not persisted. But why? By the way I print out the balance with uRaiden.channel.proof.balance where uRaiden is my instance of MicroRaiden. So, maybe I am doeing something wrong here?
    Peter Holzer
    @PeHo89
    @andrevmatos Oh, wait, of course the transaction gets lost because it is off chain, right? Before exiting my application and therefore destroying my instance of MicroRaiden, I have to settle the channel, to get the transaction on chain, right? Or should the transaction still exist within the MicroRaiden network? Mhm..I am confused now :)
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 No, you should only settle on the end of the lifetime of your channel (when you don't need it anymore and want to recover the still locked tokens there, not accross restarts). Your balance is being reset after restart, and that's intended. As I said, usually you should configure a localStorage instance (there's several implementations, e.g.) on the global context of your client to allow it to save and restore the channel info. When doing this, you shouldn't use loadChannelFromBlockchain, but instead loadStoredChannel at the startup of your app.
    Alternatively, you may rely on the last payment sent to you by the server. To trigger the server to sent it to you, you should loadChannelFromBlockchain, which will load a 0-balance proof, request the resource to the server, and when the server detects it isn't enough (because its zero), it'll send your last BP, and then you verifyProof it, and then your client channel will be properly initialized. That's what webUI client does, to avoid relying on localStorage, which may get cleaned
    Peter Holzer
    @PeHo89
    image.png
    @andrevmatos But how do I request the resource at the server to trigger it to send me the latest balance proof? I do it this way but get the error that the payment must be an integer (in my opinion it is). Http code is 409.
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 sending a request with the zero-balance proof (the one on your channel state after loadChannelFromBlockchain, or actually any outdated balance) should trigger this. Not sure about your error, you may need to check the server's logs
    Look into the main.js file for the webUI, it contains a nice walkthrough of the steps needed
    Peter Holzer
    @PeHo89
    @andrevmatos Ok, so you think I am doing this correct here from a conceptional point of view? Ok, I will have a look.
    André Vitor de Lima Matos
    @andrevmatos
    Yes, in the concept, you got it, from what I know, just need to get the implementation right now =)
    Peter Holzer
    @PeHo89
    Ok, good to now anyway :) Many thanks!
    Peter Holzer
    @PeHo89
    Mhm, unfortunately I don't get it. I had a look into the main.js file. The steps I do are similar to that. Acutally I have to problems:
    • I can not request the python resourse with all of the RDN-* header (I get the error that the payment must be an integer, in my opinion it is)
    • I can not increment the channel balance permanently (loadChannelFromBlockchain -> incrementBalanceAndSign(0) -> verifyProof(proof object returned from 'incrementBalanceAndSign(0)') -> incrementBalanceAndSign(5) -> confirmPayment(proof object returned from 'incrementBalanceAndSign(5)')
    Peter Holzer
    @PeHo89
    @andrevmatos Do you have any further hints for me? I am sorry to demand you permanently but I would really like to get it running so that I can proceed with my project for university and because I am really interested in this topic.
    André Vitor de Lima Matos
    @andrevmatos
    loadChannelFromBlockchain will do the sign of the 0-balance proof, no need to incrementBalanceAndSign it. verifyProofshouldn't be run on the proof returned by incrmenetBalanceAndSign, but on the one composed by data returned by the server. You said you did read main.js, but I'd ask you to give a closer look
    Peter Holzer
    @PeHo89
    @andrevmatos Unfortunately I don't get it. Other question: I have this channel on the blockchain. Let's focus on my client app. I don't start the python echo server application. Shouldn't it be possible to load the channel from the blockchain and increment the balance? Why do I need a balance proof from the python echo server there? In my imagination I don't need the python echo server. I load the channel and increment it's balance. This should be independent from any service except the micro raiden and geth instance, right? So I would like to increment the balance on the channel but can not persist this. Everytime I load the channel it has 0 balance. Then I increment by 5. Then it has 5 balance. If I run the application it has again 0 balance but I expect it to have 5 and after my application run through it should have 10. But why this is not the case? This python echo server application is simply an demo. It has nothing to do with administrating the micro raiden network, right? So I absolutely don't get the application flow, I am sorry.
    Peter Holzer
    @PeHo89
    In my imagination the flow is the following: I have one service (in my case the python echo service server) where I would like to request a resource from. It responses with 402 and some important information within the eaders (price for the resource, addresses and so on). So next I can load a channel between my address and the address specified in the header (the address of the server) or create one if no one exists. Then I incrementAndSign the price and send this information within headers to the resource I want to have Infos from. The server takes this Infos and proves it in his own micro raiden instance. If everything is correct, it sends me the data provided by the resource.
    So If I simply would like to send someone money, I should be able to do so without requesting him, right? I only have to know its address. So why I am not able to do this in my application? Is there something wrong from the conceptional point of view?
    André Vitor de Lima Matos
    @andrevmatos

    @PeHo89 Conceptually, it's correct. You're not getting the implementation details and the constraints on web dapps: you can't be sure you'll always have the information available, as browser storage comes and goes easily (clear cache, opening it in a private tab, another device, etc).
    So, I'll walk you through the default case, assuming you can trust the local storage (the place where your client will save the channel data, as it can't put it on the blockchain): 1. open a channel, or loadStoredChannel from localStorage or a json file, wherever you saved it, 2. incrementBalanceAndSign, 3. set headers/cookies, redo request, 4. confirmPaymenton channel.next_proof once you're sure you got the resource you paid for, it'll save back the data to localStorage for the next run, 5. repeat from 2 as many times as you want, 5. close the channel once you don't intend to make other off-chain payments on it

    That was the "happy" case.
    But what happens if you don't have localStorage (as you don't in your node instance)? You have 2 sources for each part of the channel info: 1. the blockchain, so you know the channel details, but outdated (without balance proofs, i.e. balance=0), 2. the server, as it also stores your last payment data, which you where supposed to persist but didn't, but to get it to sent it for you, you need to "authorize" with it, through an outdated balance (even if it's a zero-balance proof, the initial/pristine/fromBlockchain one). So you don't need the server for incrementing the balance, but if you didn't persist the data with localStorage or any other mean, you need to beg the server to update you with what it knows about you. This workflow replaces the loadStoredChannel+confirmPayment (as there's nowhere to store it) withloadChannelFromBlockchain (which will give you the 0-balance channel) + redoing the request to get the data from the server, and verifyProof it to be sure you're not being fooled into signing a higher amount than you should

    So, you have two options: either setup a localStorage compatible instance in your node storage and do the first workflow, or do the 2nd one, asking the server for the info you're not storing (webui does the 2nd for the reasons presented before, web app storage isn't reliable)
    Peter Holzer
    @PeHo89
    @andrevmatos Thank you for your extensive answer! So incrementAndSign doesn't affect anything within the raiden network? Is this right? And how do I request the server to send me the information I am not storing?
    André Vitor de Lima Matos
    @andrevmatos
    No, it just increment the last balance proof (which, if you didn't load one from storage or from the server, will be 0) by the amount you provide it, sign and set it on channel.next_proof (to be persited with confirmPayment or replaced by verifyProof on the next server load). On µRaiden, there's no "raiden network", there's only your local state and the server state
    You request it by signing the zero-balance proof and doing the request, it'll then reply with a 402 response, with your last balance proof on headers/cookies, which you then (in the 2nd case) is supposed to load and verifyProof
    Please, read main.js carefully, the whole workflow is there, although somehow wrapped in some jQuery callbacks to keep the UI consistent, but with some jquery knowledge/homework, you can follow it there
    Peter Holzer
    @PeHo89

    @andrevmatos

    You request it by signing the zero-balance proof and doing the request, it'll then reply with a 402 response, with your last balance proof on headers/cookies, which you then (in the 2nd case) is supposed to load and verifyProof

    My problem is to trigger the server to send me the latest balance proof. So from the very beginning I do this steps: loadChannelFromBlockchain and then request the resource? Requesting the server with which data? With all the 7 RDN-* header? Which value has the RDN-Payment header to have? If I send a number there I get 500 internal server error back with this message in the body "Payment must be an integer". I do not receive my latets balance proof within headers or cookies. Mybe because I never did a persistent transaction between this two parties?

    Please, read main.js carefully, the whole workflow is there, although somehow wrapped in some jQuery callbacks to keep the UI consistent, but with some jquery knowledge/homework, you can follow it there

    I will try this again. Reading code unfortunately isn't the best way for me learning and understanding new technology. Documentation would be much easier for me.

    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 Yes, all fields are required. Please, try using cookies instead of headers (the names are the same), maybe some specifics on your server libraries is preventing the integer in the header to be recognized as such
    Peter Holzer
    @PeHo89
    Ok, I will do so. And the payment field is 0, right?
    André Vitor de Lima Matos
    @andrevmatos
    Yes for the "load" request. After that, you should verify the proof received in the 402 response to load it, increment and sign, re-fill the cookies and re-do the request
    Peter Holzer
    @PeHo89
    Ok, and the balance signature is undefined after loadChannelFromBlockchain, right?
    André Vitor de Lima Matos
    @andrevmatos
    Yes, you need to sign the 0-balance proof (e.g. with incrementBalanceAndSign(0))
    main.js is demo code, so it's part of the documentation. Nonetheless, these details are in all the extensive µRaiden documentation, both the server, m2m client, microraiden-js lib and demo documentation, but of course we're always open to PRs to improve it
    Peter Holzer
    @PeHo89
    @andrevmatos I got the 'hello' the first time! Cool! Thank you very very much! :) But I have the next problem: Trying it again I get the error "TypeError: this.channel.proof.balance.plus is not a function". This comes from the function incrementBalanceAndSign within the TS library. Do you know whats the point here?
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 You should be providing it with a number. microraiden-ts uses BigNumber, you need to populate the balances with BigNumbers, instead of standard number. There're some helper functions to convert a number of wei tokens to bignumber and back
    Peter Holzer
    @PeHo89
    Yeesss! That hint solved it! Great!! THANKS!
    Peter Holzer
    @PeHo89
    @andrevmatos What if I close the channel after some transactions without a closing signature and without settling it before? I have to settle it right after closing it, right? But I can't load it anymore, so how can I do this?
    André Vitor de Lima Matos
    @andrevmatos
    settling is always done at the same time of closing (if cooperative close or the receiver is the one closing) or after settle timeout expired (when uncooperative close by the sender), if the receiver didn't challenge during this timeout