ghost43

> instead of multisig payment 2 multisig payment 2 that's not what it says. it says `multisig payment; multisig payment 2`. i.e. it considers both transactions to relate to both...

This can indeed result in annoying behaviour... :/ E.g. imagine a user paying your accountant, on-chain, once a month. Let's say the accountant gives to the user bip21 URIs including...

>> Another way is to add a method to this protocol which does nothing but notify the server about what address will be later requested in blockchain.outpoint.subscribe. Call it something...

> from wallet point of view what we really need is to get the most recent history > it only needs to fetch the most recent 3 transactions(including unconfirmed) from...

> Although already I believe with the changes in 1.5 it should be possible now retrieve a partial history towards the "end" now.. right? Yes. You can call `blockchain.scripthash.get_history` with...

> In most our usage scenarios, including wallets and explorers, servers are generally trusted > applications don't try to remember transaction history it has downloaded from server I see. Indeed...

I've cherry-picked doc changes from https://github.com/spesmilo/electrumx/pull/109 re > :func:`blockchain.block.headers` now returns headers as a list, instead of a single concatenated hex string. Also, I've made minor changes as per comments...

> Aside from reorg — Can rbf shenanigans also lead to potentially many notifications as well? Oh right, definitely. That too; and other mempool quirks, such as tx eviction. So...

Ok, I've added some examples in https://github.com/spesmilo/electrumx/pull/90/commits/e3f95c760ed5eb6640e0264e064ae63ded3bc802.

FWIW ElectrumX does not listen while it is indexing the blockchain or when processing the mempool (can take up to several minutes). I mean re initial sync - so e.g....