Request new RPC methods.

[monsterbitar]

Currently, there are three subscribe methods that provide data that might be desirable to have, but is not available without subscribing for future updates:

• blockchain.headers.subscribe
• blockchain.scripthash.subscribe
• blockchain.address.subscribe

I would like to have the same functionality available without needing to subscribe to future events, but for now I only need the chaintip data, so:

blockchain.headers.chaintip

Returns the block height and hash for the current chaintip.

Signature

blockchain.headers.chaintip()

Result

The header of the current block chain tip. The result is a dictionary with two members:

• hex

The binary header as a hexadecimal string.

• height

The height of the header, an integer.

Example Result

{
  "height": 520481,
  "hex": "00000020890208a0ae3a3892aa047c5468725846577cfcd9b512b50000000000000000005dc2b02f2d297a9064ee103036c14d678f9afc7e3d9409cf53fd58b82e938e8ecbeca05a2d2103188ce804c4"
}

[monsterbitar]

The address and scripthash variations should be simple as well, returning the status. They're much less likely to be used by anyone (since status purpose is to compare for changes, so subscription makes a lot of sense).

[dagurval]

I support this addition. I have multiple times written scripts where I poll the tip by calling blockchain.headers.subscribe and blockchain.headers.unsubscribe.

The chain in the name chaintip is somewhat redundant, as it already has the blockchain prefix. Just tip would work better IMHO.

I looked through existing issues and found that we also discussed this feature in #9. I'm marking that as duplicate of this one, as this one is better defined.

[monsterbitar]

It has been a significant amount of time since #9, it might be a good idea to verify with @cculianu before completing this, just in case there's any new information or use cases that could impact what the best design of this is.

Also, I don't mind the shorter name of just .tip rather than .chaintip.

[cculianu]

Isn't this completely redundant with blockchain.headers.subscribe? Why not just use that? it notifies you on change asynchronously.

Can you walk me through a use case or rationale why this would be needed as opposed to that?

[cculianu]

@monsterbitar Jonathan -- you realize you can just keep calling blockchain.headers.subscribe multiple times, right, and it in effect does what this method does (except you also get notified -- but you can easily ignore the notifications).

[monsterbitar]

@monsterbitar Jonathan -- you realize you can just keep calling blockchain.headers.subscribe multiple times, right, and it in effect does what this method does (except you also get notified -- but you can easily ignore the notifications).

Yes, but shouldn't this be considered abuse?

If I just want to, for example, show on a website upon load what the current chaintip is - why would I subscribe?

I know I can subscribe and then promptly unsubscribe, but that's poor design, prone to human error.

Furthermore, if someone wants to start using electrum they might skip over all subscribe functions while looking for the feature they want, and then dismiss electrum as an option because they can't find the feature they are looking for.

At scale, this also becomes a problem - while the electrum backend probably don't care much if a handful of people subscribe to things they don't intend to use, if something with a million users would subscribe over the course of a week, compared with the same number of users would request once over the same time, the impact on resource usage is significant.

[cculianu]

As it stands right now: Subscribing to headers at least in Fulcrum is not really that heavy. There is only ever 1 "latest header" and whenever it changes (every ~10 mins) you iterate over a set. It's far far less impactful than say, subscribing to 20,000 addresses which is something that happens.. a lot.

And you never have 1 million people connected simultaneously. If we get to that "problem" we are in a good place. It means we won. I have about 200 maybe 300 clients connected at most ever.

It's not really abuse, no. It's weird, yes.

You don't need to unsubscribe. Just subscribe and keep subscribing. It is what it is.

Yes, I guess if that irks your sensibilities, perhaps a simple "query" function could be added....

Note also there are some functions called "subscribe" that don't.. actually.. subscribe. So aesthetically speaking this API is far from harmoniously divine.

[monsterbitar]

Note also there are some functions called "subscribe" that don't.. actually.. subscribe. So aesthetically speaking this API is far from harmoniously divine.

For bitcoin cash versions of electrum, we've already deviated, so perhaps this is something that should be addressed. The protocol is already versioned, so that makes it somewhat easier, and backend servers can depreciate old protocol version over time.

[monsterbitar]

Yes, I guess if that irks your sensibilities, perhaps a simple "query" function could be added....

I've had times when I've wanted to use this as a simple query, but I suspect the value gained from adding this is less about what I need/want, and more about having new developers come into the space and instead of seeing a big mess, see a quality protocol they want to use.

[cculianu]

That’s very subjective. It’s also some sort of argument based on fear. Haven’t we had enough of that in 2020 with COVID? Do we really need to represent the zeitgeist of our times as echoes of our minds here as well?

On that subjective note I consider apis with 1000 methods that all do almost the same thing a cognitive burden. It might be easier just to add a Boolean flag to the existing method (to, say, not really subscribe).

Note that already this API is imperfect and inconsistent with its own conventions and naming.

There are already methods named “subscribe” that dont even subscribe...

[monsterbitar]

It might be easier just to add a Boolean flag to the existing method (to, say, not really subscribe).

That to me sounds like a cleaner solution that having a separate subscribe to begin with. It would be inconsistent with current structure though, which is a clear negative.

[cculianu]

inconsistent with current structure

HA! May I introduce you to server.peers.subscribe ?