raiden-network/raiden-monitoring-service

Raiden monitoring service

raiden-monitoring-service's Issues

Ignore messages for already closed channels

A few questions about monitoring services for a research

Hi guys, I'm researching Lightning Network watchtowers (WTs) and Raiden monitoring services (MSs), and writing a series of articles, explaining why they are essential for scaling, how they work, different types of WTs and MSs, their approximate operating and capital costs, scaling challenges, proposed solutions and their trade-offs, viable business models, etc.

If you can answer a few questions, that will be very helpful and I can link this issue in the article, so interested developers can read your answers, join the discussion and potentially contribute to a project.

1. Does monitoring service know which exact channel it watches?
2. There are at least 2 parties (2 on-chain addresses) in the channel. Does monitoring service know which exact party (on-chain address) it watches?
3. Is this info about channel or address included in the each package sent to a monitoring service?
4. Is it possible to implement a logic that a monitoring service will not know exact channel or address it watches with current protocol?
5. If not, what kind of changes to a protocol will be required?
6. How much time user has to broadcast a penalty transaction in case of uncooperative closure? I've seen 2 hours in some video, if so, then why so low? To increase UX of unilateral closure? But that decreases security.
7. Can the time be easily changed or are there some dependencies that might "break" after that?
8. Can users change this time by mutual agreement upon creation of a channel? Or is it hardcoded on a protocol level?
9. Any approximation on the size (in bytes) of each message (package with latest balance proof) sent to monitoring service after each transaction?
10. Ever growing database of stored messages (packages) can become a bottleneck for scaling. On LN this problem can be solved with eltoo (with privacy trade-offs), which will allow users and watchtowers to store only latest states and thus delete all old states. Is something like this possible on Raiden without any risks of losing funds (e.g. losing multiple pending transfers)?
11. If yes, then does this update/feature has a name? And is it on the roadmap? Any approximate date?
12. Can monitoring services discover the exact values of channel states from received/stored messages? E.g. LN watchtowers don't know the exact state balance, they only know that the state was changed.
13. In case of breaching transaction, do monitoring services broadcast a penalty transaction that moves all channel's funds to a victim's on-chain address, so a cheater can potentially lose some money? Or do monitoring services broadcast a penalty transaction with just latest state, so a cheater doesn't risk anything?
14. Alice and Bob used a channel for awhile. Alice lost her phone with all balance proofs. She has a recovery seed, so she can access on-chain funds, however, she does not have the latest balance proof. Can Alice get/receive/route transfers using an opened channel with Bob, or should she just sit and wait until he closes the channel unilaterally?
15. I think, I saw something about snapshots and ability to recover balance proofs, but what if there were e.g. 10 more transactions after the latest snapshot?
16. Can Alice (lost her phone with all balance proofs, but has recovery seed) close her channels unilaterally without a risk of losing her funds?
17. Can Alice (lost her phone with all balance proofs, but has recovery seed) retrieve all balance proofs from her monitoring service?
18. Do you have any plans to implement collateral as was described in PISA by Patrick McCorry?
19. Any other ideas how to improve accountability of monitoring services?

Additional:
This is how LN watchtowers work in a few words.

• After each channel state update, Alice sends to a watchtower encrypted signatures authorizing the movement of all channel's funds back to Alice.
• The sent package has no info about state's balances.
• Each sent package also contains a "hint" how to find a breaching on-chain transaction.
• Watchtower constantly watches blockchain by checking all new on-chain transactions against its hash table of "hints".
• Once the breaching transaction is found, watchtower is able to decrypt the signatures from Alice's package and reconstruct the penalty transaction that moves all funds back to Alice.

Can you describe how Raiden monitoring services will work in a similar simple way? Or outline the main differences?
Thanks!

P.S. I rarely check my github nowadays, so if you read this from the far future, please consider reaching out via twitter, linkedin, or medium, if you'll have any questions or info to share.

Remove REST API

Currently the MS includes a REST API. I don't see a point in that currently and would argue that we should remove it and all related code and tests.

Message format

Which metadata should envelope contain?

some ideas:

• encryption type
• compression

MS listens to channel closing events

Description

As Josh I want the MS to be able to

find out that a monitored channel was closed

So that it can

update the channel state in the smart contract

Acceptance Criteria

• MS listens to ChannelClosed events on the blockchain for monitored channels
• MS listens only to monitored channels
• New BlockChainListener ensures in-order processing

Related story / issue

• #39
• In-order blockchain events: #47

Reviewer

Handle transport disconnects

If Matrix server goes down, client should reconnect and MS must still react on blockchain events.

Use BlockchainListener from Raiden-libs

Integrate changes in Raiden SCs

After merge of raiden-network/spec#54 SC calls and messages will require an update.

Make disabling of SSL for requests library optional

Certificate check is disabled because BB hosted Matrix servers use self-signed certificate. In production, it should be enabled by default, and only command line option should override it.

check network invariants

• network id
• contract existence

Recoverability: Store BPs in a database

Although submitted BPs can be obtained from the matrix channel, it'd be better to store them in a database
Reasons are:

• Matrix transport might be unavailable
• migration of MS to a new Matrix channel where BPs are broadcasted
• there can be a BP submitted via other channels (i.e. REST)

Make sure all channel related events arrive in order

We had problems with the current BlockchainListener because it queries events per event name. This means that events are served out-of-order when multiple events are queried, which can lead to hard to debug problems.

In the PFS we already switched to a new design which listenes to all events for token networks at the same time.

THis PR integrates this BlockchainListener into the MS codebase.

Part of #38

Monitor requests get overwritten if both parties submit MRs

The database table has a primary key on channel_id (see https://github.com/raiden-network/raiden-monitoring-service/blob/master/monitoring_service/state_db/queries.py#L18) and uses INSERT OR REPLACE to update the monitor request in the db. This means that only the latest MR for a channel survives. The desired behaviour is to keep one MR per (channel_id, signer) pair.

Split MS into two processes

As suggested in https://github.com/raiden-network/raiden-monitoring-service/issues/37#issuecomment-452704814, splitting the MS into two processes makes DOS attacks on the MS harder. I also expect it to lead to clearer code and better separation of concerns.

The following parts should be moved out of the main MS into a Request Collector:

• all matrix communication
• validation of incoming MRs
• storage of MRs into the database

Then the MS has to only interface with the blockchain and the database.

update SPEC

SPEC should slowly iterate towards more technical document, including details on i.e. message format and interfaces used.