Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPV with multi server validation #64

Closed
RCasatta opened this issue Oct 26, 2020 · 2 comments
Closed

SPV with multi server validation #64

RCasatta opened this issue Oct 26, 2020 · 2 comments

Comments

@RCasatta
Copy link
Contributor

The SPV with multi-server mechanism at a library level should allow:

  • to enable/disable spv verification. By default is disabled. Flag spv_enabled in network_parameters.cpp, configurable via the connect method
  • to configure the primary electrum server. (which will be the only one which downloads the tx proof leaking most the privacy). It points by default to esplora blockstream.info:995. It will never switch automatically. Field electrum_url and flag tls in network_parameters.cpp, configurable via the connect method
  • to enable/disable the multi server cross validation. If a user points to his own electrum server he may want to not connect to others servers (even if he is leaking only his ip (if not tor) and his chain height and he is not asking tx proof to secondary servers). By default is enabled. Flag spv_cross_validation in network_parameters.cpp (not exist at the moment, to be added), configurable via the connect method.
  • to provide electrum cross validation URLs or use hardcoded ones. The server urls for multivalidation are hardcoded and must be taken from network_parameters field spv_cross_validation_electrum_urls, could be overwritable from connect. URLs could be initialized from electrum github and eventually updated on releases.

Apps are getting the result of SPV validation directly from the list_transactions in the spv_verified field which can assume the following values:

  • in_progress
  • verified
  • not_verified
  • disabled

Native rust could handle the population of the field with the internal store populated with the Headers thread, while the external API at the moment is triggered directly from the list_transactions call, to avoid to be too slow the result is cached and only one in_progress is allowed (see impl details)

The external API cache could potentially leak information of wallet txs, because of this an encryption_key must be passed to the spv_verify_tx, this field should be added to the get_transactions call.

@shesek
Copy link
Contributor

shesek commented Nov 1, 2020

Some thoughts/questions:

  • Since the cross validation failure state is not transaction specific, perhaps it makes more sense to expose it as a global (per-network) flag of some sort?

    I think that also at the GUI level, this should be displayed somewhere prominently and not just at the individual transaction level. Perhaps it even warrants a notification of some sort. Treating this as a global state could make that easier.

    Update: I made the global cross-validation status overwrite the validation status of individual txs retrieved via get_transactions. Should consult with someone using this from the app side regarding a global flag. Implemented in 5570e0f

  • Would you suggest to run this in the existing spv headers validation thread, or in a new one? The secondary servers could be slow or unresponsive, so it probably makes more sense to get this out of the way of communicating with the primary one?

    A related consideration is that we need to make sure that rust-electrum-client uses reasonable timeouts. It seems like we currently have to manually initialize the SslConnector and TcpStream to configure this, maybe I'll send a PR to make that easier.

    Update: Decided on IM to use the same thread after all, because of mobile environment considerations (especially iOS). But the number/frequency of cross-validation checks being performed will be limited, something like 1 server every 30 seconds. Implemented in f91b18d.

  • Should a notification be sent through NativeNotif to the app layer when cross validation fails, or it is good enough to wait for the next time the it polls for the validation status?

    Update: A transaction notification is now sent out to trigger a refresh of the transaction list. Implemented in 7e7aab0

@LeoComandini
Copy link
Contributor

Implemented in #59, the points that need further discussion, will be discussed in separate issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants