@MartinOpde , you provided an account private key when you started the proxy. It means that you don't have enough ETH on it - you need at least
10**8 WEI . See the webui-related instructions from https://github.com/raiden-network/microraiden#quick-start
@Timvdv , to make sure we are on the same page: when you want to send an off-chain transaction between two accounts, there are some requirements:
- a channel needs to exist between the accounts
- the account in the
receiverrole needs to run the uRaiden Python proxy server and it has to be online, otherwise it cannot receive offchain payments.
Now, for thesenderto use the web interface, see the link to the Readme quick start from above regarding the webui. You can run the proxy examples shown here: http://microraiden.readthedocs.io/en/docs-develop/applications/pyserver/usage.html (wikipaydia, demo_proxy) to see the paywall web interface.
Thanks for the quick response, the proxy is up and running. I connected 2 accounts via the uraiden openChannel function and added some balance to open the channel. the channel block is the same for both accounts. This means they're in the same channel right?
I don't really understand the sender/receiver part. A sender can also be a receiver right? I created a image to clear things up.
Mhh, Thats not really readable, try this link: http://cloud.tvdv.me/2X0C1E3t280U/o
@Timvdv the channel is unidirectional. You can only send tokens from the
So with uRaiden, the only way you could send A<->B is to have two channels. But this means that both A and B have to run the uRaiden Python proxy.
Note that uRaiden is efficient when you need to do frequent payments, ideally unidirectional (think users paying for a service that they use frequently or apps using a paid API)
sender (e.g. A) to a receiver (e.g.) B, so : A -> B. Raiden Network has bidirectional channels and you can send A <-> B (even if you don't have a channel opened directly between A and B).So with uRaiden, the only way you could send A<->B is to have two channels. But this means that both A and B have to run the uRaiden Python proxy.
Note that uRaiden is efficient when you need to do frequent payments, ideally unidirectional (think users paying for a service that they use frequently or apps using a paid API)
Aha, okay makes sense! Thanks for the explanation. I'm creating an IOT Dashboard, from here you can add different devices. a smart lightbulb for example. I think this is the correct use case for uraiden, I want to open a channel once, and then send the commands on/off regularly. I created a new diagram. This should work right? http://cloud.tvdv.me/3h212X3U0i1B
I have one more question, if we use the example in my diagram. How can the user find the IOT device and open the initial channel
@Timvdv , the new diagram is correct with a single nitpicky mention -> the Parity Server should be uRaiden proxy + Ethereum chain. For the users to find an IoT device, you have to store the available IoT device addresses - this is a Dapp related issue, not a uRaiden one, if I understand the question correctly.
The whole is here: https://www.reddit.com/r/ethereum/comments/84u6ip/ethereum_developer_community_please_help_raiden/ and there is 2 comments according them EIP712 is not important:
" But just merging an EIP doesn't do anything. This EIP doesn't require a hard fork. It just proposes a convention.
You have to convince client developers to implement the proposed convention.
+
"Actually those extremely well funded projects could develop from scratch their own clients. There’s lots of space for improvement in the client space. An elegant way to say the clients we have today barely work."
Some other guys in reddit raiden told us that basicly Microraiden is ready and it await only EIP 712. Now it looks like EIP 712 is not needed, but it is needed some changes in client. Who is correct?
"conclusion
microraiden - docs and waiting for EIP 712" from https://www.reddit.com/r/raidennetwork/comments/81x9xl/git_weekly_update_7/
@another1001bit_twitter eip712 is a standard/protocol for client implementation. It'll allow the client to sign the data he's seeing, instead of an opaque hash. The later doesn't actually need any changes for the client, and was a preliminary implementation in µRaiden. But we can't ask for "faith" from the user when signing a micropayment, that's why EIP712 is needed (also why you see the amount of ETH you are asked to transfer in Metamask, instead of a dialog asking to sign some big hex string)
it's not strictly required for µraiden (it's already released, and on Mainnet), but essential for a trustless µpayment system
@another1001bit_twitter As Andre said it's required for a secure and trustless version of microraiden. You can still use microraiden today -- just the deployed version does not have the usability guarantees we want until EIP712 is cleared and all the security issues are addressed.
Thanks a lot /\
Most important would be to get feedback by people in order to clear out the last few issues that have surfaced in the EIP.
i run a token mining pool and i'm curious to use microraiden for token payouts instead of sending them on chain, we've been starting to develop our own protocol, but if this one is complete and more secure...
But Ether can very easily be ERC20-tokenized.
would it be possible to store microraiden signatures on chain in a public testnet or other private network? This would allow a fully featured microraiden client to only know how to do IO with ethereum networks. Related, in the python server, how is the state stored? Are Channel objects stored on disk? in memory? https://github.com/raiden-network/microraiden/blob/master/microraiden/client/channel.py
(ty for making this in python and not node)
ah cool thanks - do you think it would be feasible to modify this file to store microraiden sigs on a sidechain? https://github.com/raiden-network/microraiden/blob/master/microraiden/channel_manager/state.py does that make sense? can these signatures be decentralized/public?
@mseiler1_twitter , can you clarify what you mean by
Also, the main component is the microraiden proxy-server, which receives the off-chain payment = the signed balance proof. So, the microraiden client can be implemented as you would like - if you want a custom way of providing the input (signed balance proof). We do have 2 microraiden client implementations (python, typescript) that can serve as example.
microraiden signatures and store microraiden signatures on chain?Also, the main component is the microraiden proxy-server, which receives the off-chain payment = the signed balance proof. So, the microraiden client can be implemented as you would like - if you want a custom way of providing the input (signed balance proof). We do have 2 microraiden client implementations (python, typescript) that can serve as example.
i mean storing the signed balance proof on a public ledger
let me try to write up the back ground of why this is interesting
there's a second motivation for creating a side chain