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

Notify if wallet balance could be incomplete due to utxo limit or backlog history #1930

Open
gits7r opened this issue Sep 18, 2016 · 10 comments
Labels

Comments

@gits7r
Copy link

gits7r commented Sep 18, 2016

The server side part of this problem is logged in electrum-server as 169, but we need to adjust something at the client as well.

When an user tries to query an address with a big backlog history or utxo set bigger than the server limit, the server should return a specific error code that the client will interpret by displaying a warning to the user such as: "One or some of your addresses contain more transactions than the server can process - your balance and transaction history might be incomplete. Use a full node wallet in order to use such addresses." Also this should make the wallet unusable at all for clear reasons, go offline and don't try to connect to that server or other server.

In electrum server we have a limit of 1000 utxo's per address, introduced in commit: d1501bfe0c278304d2bd7d90967a333935044b16 (and we log it after commit: 5e51f038c6e2ab43b22e94912a0f97e083fde321)

I don't know exactly how to handle this for the Sweep function. Is there any way we can spend all utxos of an address for the private key being swept without querying its entire backlog? If we can't sweep it because the utxo set size we should display an error message as well.

@ecdsa
Copy link
Member

ecdsa commented Sep 21, 2016

can you share with me an address that causes this issue?

@gits7r
Copy link
Author

gits7r commented Sep 22, 2016

@ecdsa Any address that has either too large UTXO set (unspent transactions) either too large spent TXO history. Any popular address would do, for example: 1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp - shouldn't we code the client to interpret a certain error code sent by the server either for the utxo set or spent txo set being overlimit?

@ecdsa
Copy link
Member

ecdsa commented Sep 24, 2016

I imported 1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp in a wallet.
len(listunspent()) returns 871, so the limit is not reached.
the balance displayed is the same as on blockchain.info

@gits7r
Copy link
Author

gits7r commented Sep 24, 2016

But does it show the entire history of 3195776 transactions?I am not saying the wallet handles these kind of addresses incorrectly, just that it's not explicit to warn / notify the user by displaying a message if:

  • history (spent TXO's list) is not complete due to the configurable server limit (100 or 10000);
  • current balance (UTXO set) is not complete due to the server hardcoded limit (1000);

Also, how do we treat the dust UTXO's of an address in both current wallet and sweep function? Might document this to be explicit to the user as well.

@ecdsa
Copy link
Member

ecdsa commented Sep 24, 2016

I agree it would be better to handle these cases explicitly.
There's no explicit warning currently, because the protocol was designed before limits were added.

@gits7r
Copy link
Author

gits7r commented Oct 4, 2016

Right - sorry if I've written this confusing. I guess (low priority) we could adjust 2.7.x to get some error codes from the server (when one of the limits [spent TXOs or UTXOs] is reached, disconnect and warn the user that either the balance either the history backlog is incomplete and should use a full node to properly handle it since it's not possible with our limitations.

Thanks.

@bauerj
Copy link
Collaborator

bauerj commented Jan 15, 2018

I just tested with the address above.

The wallet just stays on "Synchronizing" forever.

It outputs

[Synchronizer] response error: {'jsonrpc': '2.0', 'id': 73, 'error': {'message': 'response too large (at least 1020631 bytes)', 'code': -32600}, 'method': 'blockchain.scripthash.get_history', 'params': ['1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp']}
[helicarrier.bauerj.eu] connection closed remotely

We should add some kind of error message in this case like proposed by @gits7r

@helpau
Copy link

helpau commented Oct 15, 2023

Windows 10, Electrum 4.4.6, 1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp looks empty, no errors or warnings returned.
image
image
Related bug #2044

@SomberNight
Copy link
Member

the most relevant issue is #4315

What server are you testing with @helpau?
I cannot reproduce what you are seeing.
The expected behaviour is that the client gets stuck syncing and will display it is in "synchronizing" state. If you get to the "green orb" state, that is likely a server issue.

@helpau
Copy link

helpau commented Oct 17, 2023

bitcoin.threshold.p2p.org:50002 Fulcrum 1.9.1 server []
tardis.bauerj.eu:50002 ElectrumX 1.10.0 BestEffortRequestFailed
eai.coincited.net:50002 ElectrumX 1.16.0 UntrustedServerReturnedError
22jumpstreet.mooo.com:50002 ElectrumX 1.16.0 []

By the way, quite interesting repro steps:

  1. Create empty wallet
  2. Turn on Select server automatically
  3. Add address 1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp
  4. Go to Console
  5. Turn off Select server automatically
  6. Select a server which returned error
  7. Turn on Select server automatically
  8. Look at server rotation and console/logs messages

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

No branches or pull requests

5 participants