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
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
main.js file for the webUI, it contains a nice walkthrough of the steps needed
- 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)')
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
@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
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)
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
verifyProof
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
@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.jscarefully, 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.
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
settleChannel. You're always able to load the channel as much times as needed. loadChannelFromBlockchain is just a helper (as I said), which do some smart checks to avoid you loading a channel which is inside the settle timeout (as you can't do anything with it anyway), allowing you to e.g. open a new channel and interact with it. If you forget the new channel and call this function again after settle timeout expires, it'll pick the old, to-be-settled channel again so you can settle it
"server won't accept this channel.
Please, close+settle+forget, and open a new channel"
this message is displayed on both chrome and firefox with metamask on the ropsten test network while accessing demo https://wikidemo.micro.raiden.network/wiki/Main_Page . it appears after depositing the TKN tokens and trying to sign them. Please suggest.