python -m microraiden.examples.demo_proxy --private-key <private_key_file> start
$HOME/.local/share/io.parity.ethereum/keys has an Ethereum folder but the object inside is just empty
@Timvdv on the server, your key doesn't need to be in the eth node (e.g. parity). If you create one through parity's interface, for example, it'll be in the folder you listed, but if you didn't, the eth node will still launch and work. In the µRaiden server side, it doesn't care from where does your key come from, as far as it can access it. If it's on the parity's default path, you can point it directly there, with
--private-key, or copy if from there to another path. The key is read directly, and the eth node is used only to talk with the network. So, you can launch parity without a key, and generate one with Metamask and put it directly in µRaiden server, and it'll work.
Traceback (most recent call last):
File "/Users/Deep/Documents/OneDrive/Documents/BlockChain/Paid API/WD/proxy-server.py", line 102, in <module>
main()
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/click/core.py", line 722, in call
return self.main(args, kwargs)
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, ctx.params)
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/click/core.py", line 535, in invoke
return callback(args, **kwargs)
File "/Users/Deep/Documents/OneDrive/Documents/BlockChain/Paid API/WD/proxy-server.py", line 49, in main
run(private_key)
File "/Users/Deep/Documents/OneDrive/Documents/BlockChain/Paid API/WD/proxy-server.py", line 74, in run
web3
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/microraiden/make_helpers.py", line 58, in make_channel_manager
token_address = channel_manager_contract.call().token()
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/web3/contract.py", line 794, in call_contract_function
output_data = decode_abi(output_types, return_data)
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/eth_abi/abi.py", line 58, in decode_abi
raise TypeError("The
TypeError: The
File "/Users/Deep/Documents/OneDrive/Documents/BlockChain/Paid API/WD/proxy-server.py", line 102, in <module>
main()
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/click/core.py", line 722, in call
return self.main(args, kwargs)
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, ctx.params)
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/click/core.py", line 535, in invoke
return callback(args, **kwargs)
File "/Users/Deep/Documents/OneDrive/Documents/BlockChain/Paid API/WD/proxy-server.py", line 49, in main
run(private_key)
File "/Users/Deep/Documents/OneDrive/Documents/BlockChain/Paid API/WD/proxy-server.py", line 74, in run
web3
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/microraiden/make_helpers.py", line 58, in make_channel_manager
token_address = channel_manager_contract.call().token()
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/web3/contract.py", line 794, in call_contract_function
output_data = decode_abi(output_types, return_data)
File "/Users/Deep/anaconda/envs/raiden/lib/python3.5/site-packages/eth_abi/abi.py", line 58, in decode_abi
raise TypeError("The
data value must be of bytes type. Got {0}".format(type(data)))TypeError: The
data value must be of bytes type. Got <class 'str'>
@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.
