@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 /\
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
0xbitcoin is a mineable erc20 token and i'm running a pool that's a node+redis app that's accumulating shares similar to bitcoin and sending transactions to the ethereum main net when a full block is found. We were thinking about implementing a pool purely as a solidity contract on an ethereum testnet or private net and be able to have an event listener that signs an event to the main net when a full block is found. This should make maintaining the pool a lot easier than the node+redis app. The thought then is that payouts could happen through the raiden network or similar, where signatures/signed balance proofs could also be stored and hosted on that side ethereum testnet/privatenet and the miners could commit their signatures to the main ethereum network as often as they wanted to cash out. it's a bit in the early planning stages
I'm David. We are running on the hackathon in Seoul now.
I got error above. Anyone can help me?
I got error above. Anyone can help me?
I'm using private one. how can I change to ropsten?
@loredanacirstea Can I read example or API docs for JS?
If you are using a private chain, you need to deploy the smart contracts there first. For ropsten, please see http://microraiden.readthedocs.io/en/docs-develop/tutorials/blockchain.html
@davidkang200 for JS example see the js webui example from
microraiden/webui/js/main.js and https://github.com/raiden-network/microraiden/tree/master/microraiden/webui/microraiden/docs