Electrum's wallet protocol isn't rich enough?

[NotATether]

While having a discussion on Reddit about whether a managed full node service is a profitable business, someone told me that there's a need for better electrum servers, which I believe would have a greater number of wallet API functions.

Naturally, the API is provided by the electrum server you're connecting to, which is usually running ElectrumX. It's possible to fork it to make an API that's not 100% compatible with ElectrumX which would be the plan here, along with a plugin that utilizes these methods for the GUI.

This is ElectrumX's protocol documentation: https://electrumx.readthedocs.io/en/latest/protocol-methods.html I don't use the console too much so I am not really sure what people are missing from this API, but what would be methods you guys want to see in an ElectrumX clone?

[NeuroticFish]

I don't know if the restrictions are in ElectrumX or Electrum itself (I didn't use ElectrumX directly) but two things may be:
1. Afaik, if an address has a large number of transactions, they are not retrieved. In some rare cases it may be good to "lift" the restriction or at least return the last few and the current balance.
2. Well.. read this thread about OP_RETURN in Electrum console/RPC

However, I don't need them myself, but maybe they give you or others some ideas.

[ranochigo]

I don't know if the restrictions are in ElectrumX or Electrum itself (I didn't use ElectrumX directly) but two things may be:
1. Afaik, if an address has a large number of transactions, they are not retrieved. In some rare cases it may be good to "lift" the restriction or at least return the last few and the current balance.

The Electrum server. It is done intentionally to avoid overloading them by including a cap on the addresses that can be queried by individual servers.

2. Well.. read this thread about OP_RETURN in Electrum console/RPC

There is currently a PR to include scripts in payto/paytomany RPC.

[HCP]

1. Afaik, if an address has a large number of transactions, they are not retrieved. In some rare cases it may be good to "lift" the restriction or at least return the last few and the current balance.

It's possible to work around that restriction based on the configuration of the ElectrumX server... it's basically a "protection" to prevent servers from being DDoS'd (accidentally?) by requesting huge amounts of data. Refer: https://electrumx-spesmilo.readthedocs.io/en/latest/environment.html#resource-usage-limits

As for only returning partial data... I don't think that is a very wise decision. You should return "all" or "none"... giving a partial result could result in all sorts of issues and would likely result in the end user getting very confused.

Or... if the return set is so massive because a particular address has hundreds/thousands of addresses and it would cause issues, the server should really generate a "paged" result set and allow the client to request specific pages or subsets in smaller blocks.

[NeuroticFish]

the server should really generate a "paged" result set and allow the client to request specific pages or subsets in smaller blocks.

Hmm.. you're right! This sounds a lot better, just unfortunately for some reason this idea didn't cross my mind yesterday 

[ABCbits]

Electrum protocol is rich enough for regular user. But for advance user, API which return statistic data would be useful. Few example,
1. Average block time within last X blocks (such as 36, 144 or 2016).
2. Total transaction size on mempool.

[NotATether]

1. Afaik, if an address has a large number of transactions, they are not retrieved. In some rare cases it may be good to "lift" the restriction or at least return the last few and the current balance.

Raising limitations isn't really what I'm looking for, then you'll just have a ton of transactions that you have to data-mine. And paid block explorer APIs can fetch addresses with several transactions without problems.

Electrum protocol is rich enough for regular user. But for advance user, API which return statistic data would be useful. Few example,
1. Average block time within last X blocks (such as 36, 144 or 2016).
2. Total transaction size on mempool.

Yeah this is exactly what I mean. Normal users who just want to send and receive money don't need any of the more advanced queries that power users and businesses could use for building services on top of them.