raiden-network / microraiden Goto Github PK

The javascript code of the webUI currently comes from the server, so the client must trust it. We also don't use SSL, and this opens a possibility for a MITM attack.

It should be possible to query runtime state of the proxy server via the REST interface.

• closing/settlement of an open channel by the server
• state of an open channel (balance...)
• maybe some stats

Use cases where a payment must come with some signed extra data?

Footage of server log, Browser, TXs on Etherscan

Now, if the user is not logged in with MetaMask, we show all the UI components used in the app.

It'd be probably better to set modes to 600 - I am not sure if there is currently any security issue caused by letting others know current balance proof, but it won't hurt to enforce it.

The mode should be also checked for private key files and app must refuse to start if the file is readable by others.

Opening a channel costs gas. This is always payed by the sender.
Closing a channel also costs gas. Let's look at the incentives to cooperate.

Receiver wants to settle

Reasons of doing so would be,

• channel ran out of funds and the sender is not expected to top-up, i.e. sender is not expected to pay for the closing cost
• sender became inactive, receiver wants to settle

Receiver can always settle a channel with a single transaction.

Sender wants to settle

If he has agreed with the receiver on closing the channel and received a sender signed proof of agreement on the last balance, then the sender can settle the channel with a single transaction.

Receiver perspective

If the sender does not cooperate, the client can close with a wrong balance which the receiver needs to challenge. In order to not having to pay for a tx, the receiver is incentivised to cooperate when the client requests an agreement on closing the channel.

Sender perspective

Requesting closing of a channel is more expensive (additional storage allocated) than then directly settling it. Also the party settling the channel will get a gas refund from the freeing the storage. Also settlement is not deferred by a challenging period. Therefore the client will try to settle the channel with one transaction based on a signed closing agreement from the receiver.

• after clicking close, dialog should switch status of a channel to "closed" and hide other buttons
• the same with forget button
• when displaying "open channel" dialog, the deposit button is disabled by default and enables only after changing token amount of the spinner box.
• if I close the channel, reload, then forget the channel, channel status changes back to an 'opened' state (all buttons are visible and status is "opened"), clicking sign and close buttons will cause an error
• if a tx for opening of a new channel is rejected in MM/Parity, webui displays spinwheel and a dialog "The transactions are being processed.
  Please authorize with your Ethereum client.". How about setting a timer and if within 60 seconds tx doesn't appear, then the webui will display an error.

buttons in the webUI should be displayed depending on the channel state - i.e. it doesn't make sense to display 'sign' button if the channel is closed, or 'settle' if channel is still open and we expect user to 'close' the channel first.

Title.
Non showstopper, as current message works, just aren't nicely shown to the user on signing interface.

Solution

Agree on a new message format without linebreaks, maybe simply replacing them with spaces.
Implement it in getBalanceMessage method.

When trying to get the content, server will reply with E500 - Internal server error.

How to reproduce:

1. delete cookies from the browser & the server state rm ~/.raiden/*pkl -f
2. start the server and let it sync
3. in a browser, navigate to a resource, do usual steps with deposit and signing
4. after the deposit, the content is unavailable and server will reply with E500

Server log:

  File "/home/xoza/src/micropay/lib/python3.4/site-packages/flask/app.py", line 1612, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/xoza/src/micropay/lib/python3.4/site-packages/flask/app.py", line 1598, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/xoza/src/micropay/lib/python3.4/site-packages/flask_restful/__init__.py", line 480, in wrapper
    resp = resource(*args, **kwargs)
  File "/home/xoza/src/micropay/lib/python3.4/site-packages/flask/views.py", line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/home/xoza/src/micropay/lib/python3.4/site-packages/flask_restful/__init__.py", line 595, in dispatch_request
    resp = meth(*args, **kwargs)
  File "/home/xoza/src/micropay/raiden-micropayment-service/raiden_mps/raiden_mps/proxy/resources/expensive.py", line 131, in get
    data.balance_signature)
  File "/home/xoza/src/micropay/raiden-micropayment-service/raiden_mps/raiden_mps/channel_manager.py", line 413, in register_payment
    c = self.verify_balance_proof(receiver, open_block_number, balance, signature)
  File "/home/xoza/src/micropay/raiden-micropayment-service/raiden_mps/raiden_mps/channel_manager.py", line 400, in verify_balance_proof
    self.contract_proxy.address
  File "/home/xoza/src/micropay/raiden-micropayment-service/raiden_mps/raiden_mps/crypto.py", line 104, in verify_balance_proof
    return addr_from_sig(balance_sig, msg)
  File "/home/xoza/src/micropay/raiden-micropayment-service/raiden_mps/raiden_mps/crypto.py", line 27, in addr_from_sig
    receiver_pubkey = PublicKey.from_signature_and_message(sig, msg, hasher=None)
  File "/home/xoza/src/micropay/lib/python3.4/site-packages/coincurve/keys.py", line 244, in from_signature_and_message
    deserialize_recoverable(serialized_sig, context=context),
  File "/home/xoza/src/micropay/lib/python3.4/site-packages/coincurve/ecdsa.py", line 64, in deserialize_recoverable
    raise ValueError("Invalid recovery id.")
ValueError: Invalid recovery id.

Get rid of approve/transferFrom pattern, to be more user friendly and save gas.
Requires changes in all components.

https://github.com/Dexaran/ERC23-tokens
ethereum/EIPs#223

• Allows contract developers to handle incoming token transactions.
• ERC223 transfer to contract consumes 2 times less gas than ERC20 approve and transferFrom at receiver contract.
• Allows to deposit tokens into contract with a single transaction. Prevents extra blockchain bloating.

• open a new channel with Token.transfer

• topUp channel with Token.transfer

Describe receiver and sender setup.
IPython repl demo video for receiver (if feasible) and client.

Client requests, pays and buffers chunks of data.

https://asciinema.org/a/3132
https://github.com/asciinema/asciinema/blob/master/asciinema/player.py

Add a high level description of MicroRaiden.

Maybe with main differences & similarities between MicroRaiden and Raiden, so that people won't confuse them.

Smart Contract

Messages (off-chain)

HTTP Request and Response Headers

Proxy Resources

Setup a lab M2M Demo, open channel, do 100K requests and payments, close channel, calculate & report avg. fee, latency and throughput.

There should be a nice README.md that describes the project and shows a basic setup of the paywall. It will also contain links to tutorials, once they are ready.

From Rocket.Chat:

jannik 14:07
tester doesn't support getLogs but I don't know if that's the only issue
replacing getLogs with newFilter and getFilterChanges should be quite straightforward, but we'd have to support both options because Infura doesn't like the latter one.

Configuration parameters should be configurable by having a config file or command line options.

• contract address
• token address
• private key
• html/js files used when displaying a paywall

sometimes channel manager misses a block, and in this case an event may be skipped.

Client requests a resource. Receives a 402 reply, so it will proceed to create a new channel.

127.0.0.1 - - [2017-08-16 12:13:18] "GET /doggo.jpg HTTP/1.1" 402 4106 0.000996
DEBUG:raiden_mps.channel_manager:filtering for events u:3221846-latest c:3221845-3221845 @3221846

Another attempt to get the resource, client receives another 402 because ChannelCreate is not confirmed

127.0.0.1 - - [2017-08-16 12:13:25] "GET /doggo.jpg HTTP/1.1" 402 280 0.051550
DEBUG:raiden_mps.channel_manager:filtering for events u:3221847-latest c:3221846-3221846 @3221847

channel manager registers a ChannelOpened event in a block ...1847

DEBUG:raiden_mps.channel_manager:received unconfirmed ChannelOpened event (sender 0x0052d7b657553e7f47239d8c4431fef001a7f99c, block number 3221847)
INFO:channel_manager:unconfirmed channel event received  

Note that next filter is at block ...1849. CM skips check for confirmed events in block ...1847.

DEBUG:raiden_mps.channel_manager:filtering for events u:3221849-latest c:3221848-3221848 @3221849
127.0.0.1 - - [2017-08-16 12:13:34] "GET /doggo.jpg HTTP/1.1" 402 280 0.057406
DEBUG:raiden_mps.channel_manager:filtering for events u:3221850-latest c:3221849-3221848 @3221849
127.0.0.1 - - [2017-08-16 12:13:43] "GET /doggo.jpg HTTP/1.1" 402 280 0.051625
DEBUG:raiden_mps.channel_manager:filtering for events u:3221850-latest c:3221849-3221849 @3221850
DEBUG:raiden_mps.channel_manager:filtering for events u:3221852-latest c:3221851-3221851 @3221852

Channel is not confirmed and thus the server can't provide this resource to the client.

127.0.0.1 - - [2017-08-16 12:13:52] "GET /doggo.jpg HTTP/1.1" 402 280 0.053337
DEBUG:raiden_mps.channel_manager:filtering for events u:3221853-latest c:3221852-3221852 @3221853
DEBUG:raiden_mps.channel_manager:filtering for events u:3221854-latest c:3221853-3221854 @3221855
127.0.0.1 - - [2017-08-16 12:14:01] "GET /doggo.jpg HTTP/1.1" 402 280 0.056821

Server should first save the state into a tempfile and only then overwrite the state file to prevent corruption of the data.

Proxy should be capable of using HTTPS.

WebUI now displays balance as a sum of spent tokens. It should also display how much of the funds is left for future payments.

Proxy should send UI response only if the client sets the Accept: text/html header.

Anyone who manages to create/replace our channel manager state created by pickle may execute arbitary code.

See:
https://www.smartfile.com/blog/python-pickle-security-problems-and-solutions/

Many clients use different algorithms for their message signing.

There are two main issues we should decide on:

• Whether or not to use the v += 27 value (we currently don't)
• Whether to use Parity's way of signing a message (hex-encode message with leading 0x and eth_sign that message) or Metamask way (expect 32 byte msg + raw sign that).

It seems like using eth_sign is supposed to become the standard but Metamask explicitly reverted from that after it broke a lot of apps: MetaMask/metamask-extension#1104 (comment)
So we probably need to support both signatures, at least on verification.

Current verify_X functions in the contract code and crypto.py return the recovered signer address. This is not possible anymore if there are two potential signature algorithms like we have now. Options are:

1. Add an optional argument that determines the recovery type (raw sign or eth_sign), defaulting to the old one.
2. Have the function return true/false instead of an address and take an additional expected_address and check both algorithms against it. Return false it neither matches. This would require the contract's non-cooperative close function to take an additional _sender address in order to retrieve the sender if the receiver calls the function.
3. Have the function return both addresses and let the calling code check against both.

I personally prefer option 2). We should definitely adopt the new "standard" way of signing in the client code though. This means:

• Take raw balance proof message (without hashing)
• Convert to 0x-prefixed hex string
• Sign with eth_sign (I added an eth_sign implementation to crypto.py)

These changes would need to be implemented in crypto.py, the web client, and the contract + tests.

Mention in the docs that two clients using a same channels may not work when using webUI.

For some applications bidirectional channels could be useful.

Bidirectional channels are composed of two simple channels. But the logic during settlement and validating payment capacity is changed such that the spendable amount is deposit-balance of the sender->receiver channel plus the balance of the receiver->sender channel.

This might require, that we allow to create the second channel using the same opening_block.

Old format:

• sign(privkey_receiver, (balance_signature))
• with balance_signature being the balance proof message (receiver_address, open_block_number, balance) signed by the sender

New format:

• same as sender-signed balance proof, except it's signed by the receiver.
• that is: sign(privkey_receiver, (sender_address, open_block_number, balance))

Pros:

• produces a human-readable signature message
• doesn't include the sender signature in the signing message (user experience)
• doesn't require a sender signature => more flexibility
• balance proof message and closing message only differ in sender/receiver

Cons:

• human-readable signature is harder to verify on-chain (and more costly)

A: Sender
B: Receiver
C: Micropayment Channel Contract

Current: 103

1. Approve: 41

Base:21
Store Approval: 20

2. Open: 36 (actual: 59)

Base:21
Transfer A>C: 5 + 5
Free Approval: -15
Store Channel: 20

3. Close: 26 (actual: 90)

Base:21
Transfer C>A: 5 + 5
Transfer C>B: 5 + 5
Free Channel: -15

Custom: 77

Trusted Contract can deduct w/o approval.
Similar to approveAndCall (which would be 5 more expensive)
Saves one tx (21) and one sstore-srefund (5)

1. Open: 51

Base:21
Transfer A>C: 5 + 5
Store Channel: 20

2. Close: 26

Base:21
Transfer C>A: 5 + 5
Transfer C>B: 5 + 5
Free Channel: -15

When trying to call:

transfer.sendTransaction(
      this.contract.address,
      deposit,
      byte_data,
      {from: account},
      callback)

Possible issues:

• 2 transfer functions - one with 2 inputs, one with 3 inputs (though it works with web3.py)
  • yes, this was the case https://ethereum.stackexchange.com/questions/15385/how-does-web3-js-work-out-the-types-of-the-arguments-you-feed-it (JS does not allow overloading)
• byte_data not what Solidity expects (seems that sending the receiver address should work for the create channel transfer - https://gitter.im/ethereum/web3.js?at=5704150615b4d27b083ef61b )
  • this was also the case, I had to use '0x' + [...receiver_address].map((char, i) => str.charCodeAt(i).toString(16)).join('')

Error:

Uncaught Error: Invalid number of arguments to Solidity function
    at Object.InvalidNumberOfSolidityArgs (inpage.js:8198)
    at c.validateArgs (inpage.js:8198)
    at c.toPayload (inpage.js:8198)
    at c.sendTransaction (inpage.js:8198)
    at RaidenMicropaymentsClient.openChannel (rmp.js:175)
    at HTMLButtonElement.$.click (main.js:83)
    at HTMLButtonElement.dispatch (jquery-3.2.1.js:5206)
    at HTMLButtonElement.elemData.handle (jquery-3.2.1.js:5014)

Add quick start instructions for the default proxy-web Paywall example.

Make it clear that this is customizable and the process is documented.

Currently, if you had multiple clients running on the same machine, they would overwrite each other's balance proofs in the channels.json file.

Deploy on the Rinkeby, Kovan, Ropsten testnets and verify contract with Etherscan. Document addresses.

Problem description

In rare circumstances, the client's channel state may be in a desync with the proxy.
This can happen if client attempts to use a channel that's been for some reason deleted from the proxy.

Solution

The webui must

1. detect presence of a RDN-Nonexisting-Channel header
2. notify user that the proxy will not accept balance signatures of this channel, offering an option of close/settle
3. automatic signature popups and signature button must be disabled

To reproduce

1. Create a new channel from the webui
2. using rest API, delete the channel curl -X delete http://127.0.0.1:5000/api/1/admin -d sender=0x0... -d open_block=12345
3. Access content using webui again

Sometimes there is a channel that's already been closed, but client uses it as if it was open.

Solution:
add an error header to a server reply and handle it properly in the client.

May use the same state file. Prevent this by using a lock file.

Problem:
If webui cached state uses a saved state of a channel that has been closed already, only a server reply "Channel does not exist or has been closed(sender=0x0052d7b657553e7f47239d8c4431fef001a7f99c, open_block_number=3261525)" is displayed.
The message goes away only after deleting the cookies.

Solution:
The webUI should display either a button to forget/settle the channel or forget the saved data automagically.

New error at balance signing in the webUI : {"message": "Internal Server Error"}

Proxy error:

[2017-08-18 09:33:36,267] ERROR in app: Exception on /doggo.jpg [GET] 
Traceback (most recent call last):
  File "/Users/loredana/ETH/raiden-micropayment-service/env/lib/python3.6/site-packages/flask/app.py", line 1612, in full_dispatch_request
    rv = self.dispatch_request()
  File "/Users/loredana/ETH/raiden-micropayment-service/env/lib/python3.6/site-packages/flask/app.py", line 1598, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/Users/loredana/ETH/raiden-micropayment-service/env/lib/python3.6/site-packages/flask_restful/__init__.py", line 480, in wrapper
    resp = resource(*args, **kwargs)
  File "/Users/loredana/ETH/raiden-micropayment-service/env/lib/python3.6/site-packages/flask/views.py", line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "/Users/loredana/ETH/raiden-micropayment-service/env/lib/python3.6/site-packages/flask_restful/__init__.py", line 595, in dispatch_request
    resp = meth(*args, **kwargs)
  File "/Users/loredana/ETH/raiden-micropayment-service/raiden_mps/raiden_mps/proxy/resources/expensive.py", line 131, in get
    data.balance_signature)
  File "/Users/loredana/ETH/raiden-micropayment-service/raiden_mps/raiden_mps/channel_manager.py", line 418, in register_payment
    c = self.verify_balance_proof(receiver, open_block_number, balance, signature)
  File "/Users/loredana/ETH/raiden-micropayment-service/raiden_mps/raiden_mps/channel_manager.py", line 405, in verify_balance_proof
    self.contract_proxy.address
  File "/Users/loredana/ETH/raiden-micropayment-service/raiden_mps/raiden_mps/crypto.py", line 91, in verify_balance_proof
    pubkey = PublicKey.from_signature_and_message(balance_sig, msg, hasher=None)
  File "/Users/loredana/ETH/raiden-micropayment-service/env/lib/python3.6/site-packages/coincurve/keys.py", line 244, in from_signature_and_message
    deserialize_recoverable(serialized_sig, context=context),
  File "/Users/loredana/ETH/raiden-micropayment-service/env/lib/python3.6/site-packages/coincurve/ecdsa.py", line 64, in deserialize_recoverable
    raise ValueError("Invalid recovery id.")
ValueError: Invalid recovery id.

If the webapp fails to create a channel (see i.e. tx 0xc6CeA2fF3e5Aef51a54568a03e8b3ba896115F3b), the client will still display channel info as it has been created, but with zero balance.

The app should display an error message instead, prompting user to reload the page and retry the payment.