Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Peter Holzer
    @PeHo89

    @andrevmatos I loaded the channel which was created by the echo service demo application in typescript app and want to close it. I always get an 'unknown account' error. But i see correct (?) channel state. Code is here: https://gist.github.com/PeHo89/1a998e89d7fb77d6c7a3a53f9a6b9e38. Here is the output:

    Application started!
    { account: '0x4f171ad9568e295998182d09a3dbc5db03a19750',
    receiver: '0x58a08b28dada672f04a20d22e9faf4097cc7e322',
    block: 3769554,
    proof: { balance: BigNumber { s: 1, e: 0, c: [Array] } } }
    Closing channel. Cooperative = undefined
    Error: unknown account
    at Object.InvalidResponse (/home/peter/Downloads/microraiden-master/microraiden/webui/microraiden/node_modules/web3/lib/web3/errors.js:38:16)
    at /home/peter/Downloads/microraiden-master/microraiden/webui/microraiden/node_modules/web3/lib/web3/requestmanager.js:86:36
    at XMLHttpRequest.request.onreadystatechange (/home/peter/Downloads/microraiden-master/microraiden/webui/microraiden/node_modules/web3/lib/web3/httpprovider.js:129:7)
    at XMLHttpRequestEventTarget.dispatchEvent (/home/peter/Downloads/microraiden-master/microraiden/webui/microraiden/node_modules/xhr2-cookies/dist/xml-http-request-event-target.js:34:22)
    at XMLHttpRequest._setReadyState (/home/peter/Downloads/microraiden-master/microraiden/webui/microraiden/node_modules/xhr2-cookies/dist/xml-http-request.js:208:14)
    at XMLHttpRequest._onHttpResponseEnd (/home/peter/Downloads/microraiden-master/microraiden/webui/microraiden/node_modules/xhr2-cookies/dist/xml-http-request.js:318:14)
    at IncomingMessage.<anonymous> (/home/peter/Downloads/microraiden-master/microraiden/webui/microraiden/node_modules/xhr2-cookies/dist/xml-http-request.js:289:61)
    at IncomingMessage.emit (events.js:185:15)
    at endReadableNT (_stream_readable.js:1106:12)
    at process._tickCallback (internal/process/next_tick.js:178:19)

    Unfortunately I also can not create a new channel between a new sender and an existing receiver. Same error message. What is missing or what I am doing wrong here?
    André Vitor de Lima Matos
    @andrevmatos
    @pkafei tokens are actually distributed back on settle, which is done immediatelly on cooperative close and when receiver is closing the channel, or after timeout blocks, then the sender can settle it and get its tokens back (if the receiver went offline, for example). On uncooperative close, receiver will also settle the channel (inside timeout period) if it detects a wrong close attempt by the sender
    @PeHo89 The TypeScript library currently implements only the client/sender logic. If I'm not mistaken, SmartMesh was working on a Java or JS implementation of the server logic, but you could do it too, it should not be that much code and will give you a complete overview of the internals. Feel free to contribute it back to the community, we'll be glad to review and possibly make it official ;)
    About your error, keep in mind JS/TS client/sender uses eth-node signing of the transactions, so your ETH node/web3 provider (MetaMask, Geth, Parity, etc) needs to have the Private Key of the account you're trying to use on its keystore. This erros specifically means that you tried to sign a transaction with an account addres which the node knows nothing about. If you're not doing that on browser, there's some ethereum js libraries that may help you load and sign transactions on client too, as we do in the Python client, but that is unsafe in browser environments, that's why it was left off for now.
    Peter Holzer
    @PeHo89
    @andrevmatos many thanks for your input, i will have a look ;)
    Peter Holzer
    @PeHo89
    @andrevmatos Implementing the server / receiver logic in ts / js would be very interesting. I have to clarify this.
    did you mean I have to add the accounts in geth (i am using geth) or in my application somewhere? I can not image how / where to do this. I thought the basic workflow is somehow opening a channel, sending and receiving token und closing it, right? Signing transactions has to do with sending and receiving token in my imagination. Anyway adding the accounts to geth didn't solve the problem. Do you have other / further hints? By the way its very cool from you that you are helping me! Thanks again! :)
    Peter Holzer
    @PeHo89
    @andrevmatos Maybe I try to explain my problem a little better. I created 2 accounts with metamask: one for the sender and one for the receiver. I run the python echo service with that 2 accounts. Then I played a little bit arround with the typescript library. I wanted to open, load, close channels und I wanted to send some token via a channel. When I try to load the created channel via the python app, I receive some information. When I try to load a channel with doesn't exist (between a new sender account and the old receiver account) of course it doesn't find a channel. When I try to open a new channel (new sender and old receiver) I get the error 'Error: unknown account' but my local geth node knows all 3 accounts ('geth account list' shows all 3). What else could be the reason for this? Do you have any idea? Further I can not close the open channel (old sender and old receiver created by the echo service). The error massage 'Closing channel. Cooperative = undefined. Error: unknown account'. What could be the reason for this? Many many thanks!
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 Is this error being thrown in client/sender? Through the webUI/Metamask, or something else?
    Peter Holzer
    @PeHo89
    @andrevmatos Yes, through using the sender typescript logic in my own 'application'. I am playing a little bit with the library. I also can't open a new channel between 2 completely new accounts.
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 Yes == webui/Metamask/browser ?
    Peter Holzer
    @PeHo89
    @andrevmatos No, typescript compiled to JavaScript and executed by node. But the ethereum node knows all 4 accounts. I figured out one new thing: between sender and receiver 5 channels exits (maybe caused by errors on bringing the application up at my very beginning?) If I send a get request to /api/1/stats I get "open_channels": 5 back and when I am request 'api/1/channels' I get one sender address and 5 block numbers back. But when I am trying to close this 5 channels with a delete request to 'api/1/channel/<sender_address>/<block_number>' I everytime receive an internal server error (NoBalanceProofReceived('Payment has not been registered.') exception). What could be the problem? But the other thing is that I am not able to open a completely new channel for 2 completely new accounts.
    Peter Holzer
    @PeHo89
    @andrevmatos And regarding implementing the server / receiver logic in tyescript: Yes, I will do this! What do you suggest here? Inspecting the python code and implement it in typescript? or do you have further documentation?
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 Hmm, that is a problem, there's a limitation on using geth directly by the client now with eth-node side signing (which is what is done in ths TS client lib)
    µRaiden uses an early implementation of EIP712's eth_signTypedData, which is only supported by Metamask. The python client works because it does the signing locally (i.e. it opens the private key by itself). The TS client library rely on the eth node (e.g. Geth, Metamask) to do the signing, and geth doesn't support it directly
    You may either look on how to implement a middleware to do the signing on this format locally (there's an implementaton on the test folder for the microraiden js/ts client library), or wait until last eip712 version is implemented on major clients and we update our implementation (which we plan to do as soon as metamask, geth and parity implements the accepted draft)
    Peter Holzer
    @PeHo89
    @andrevmatos To be honest I am not sure if I can follow you. The problem is the signing of messages / requests to the ethereum node, right? In your web ui application this is done by MetaMask and in your echo service it is done within the application, right? So I have to implement this part in TS within my 'app' too, right? Oh, yeah, I just found this part too, okay.
    André Vitor de Lima Matos
    @andrevmatos
    Yes. Both python client and server open their private keys directly, and then they can sign any data they want, in whatever format they want, and at the time we went with this early eth_signTypedData format proposed by Metamask, since the webUI client was the only one which didn't have much choice. As this early signature format isn't supported directly by geth, and being deprecated in Metamask, you may either wait for the final draft to be implemented in the clients, or right now follow the python implementations, open the key by yourself and implement the signature method by yourself (as the link above does for tests/ganache-cli)
    Peter Holzer
    @PeHo89
    @andrevmatos Okay, than I think I got it. Thanks in the meanwhile. Regarding implementing the server / receiver logic in TS: After I got the things running I will try to do this. What do you suggest here? Inspecting the python code and implement it in typescript? or do you have further documentation?
    Ghost
    @ghost~59777aeed73408ce4f6eb81d
    Hi guys, my name is Victor. I recently found out about microraiden and am trying to get it up and running on my ILP connector (interledger.org) I looked at the docs but it seems I'm going to have to run my own node. Any way to easily connect to the Raiden network and send payments through microraiden channels without having to do all the set-up?
    All I'm trying to do is lock up a bunch of ETH in a smart contract and open a payment channel for IOUs or something similar.
    Peter Holzer
    @PeHo89
    @andrevmatos Unfortunately I didn't get it running so that I can open / close channels in my client implementation. Do you have some further informations which can guide me through the single steps I need to do? I totally got stuck here.
    André Vitor de Lima Matos
    @andrevmatos
    @PeHo89 I'd need a little bit more information. Where exactly are you stuck?
    Peter Holzer
    @PeHo89
    @andrevmatos I would like to implement the client logic in TS for the echo service and I got stuck on how to sign messages as you mentioned last time. As I am completely new to this field I don't even know the steps that have to be done one by one. It would be very great if you can provide some guide or more Infos to me on how to proceed from scratch. Many thanks!
    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.