feature: blockchain.scriptpubkey.* endpoints

[Davidson-Souza]

I would like to get some feedback on a new endpoint for the Electrum Protocol that takes scriptpubkeys instead of script hashes.

Rationale

I'm working on a project that has an integrated Electrum Server, but doesn't index all addresses. It's meant for single users that want a server for their wallet, and only their wallet and to find older transactions, we use BIP-0158 Compact Block Filters, but those filters don't index script hashes, only scriptpubkeys. For this reason, I need to ask the user to provide the wallet xpub or output descriptor before being able to use Floresta. This is a bad UX, I would prefer everything to work out-of-the box with no extra configuration.

It gets even harder when you consider second layer protocols, like Lightning. Where we can't have something easy like output descriptors; the addresses we need to follow depend on the peer's public keys, which we don't know until we open a channel, and is unique per channel. If we can give the scriptpubkey it doesn't matter that those addresses aren't HD, simply use the filters to find any historical transactions.

Spec

I thought about mirroring the endpoints in blockchain.scripthash, but with scriptpubkeys. This won't have the same problem as the older blockchain.address. Scripts are general, and don't depend on the address type, so they are future-proof for new soft-forks. In fact, if those endpoints use the same data as blockchain.scripthash, so if any soft-fork breaks those new endpoints, it also breaks the old ones.

Talking with @SomberNight back in Prague, we've decided it would be better to limit the script sizes for DoS prevention. The Bitcoin consensus limits scriptpubkeys to 10,000 bytes (anything above that is unspendable), but this is way above the needed. If we assume that users will only care about standard addresses type, 200 bytes cover all of them. (*)

• n-of-3 bare multisig: If we use uncompressed pks (65 bytes) we have <t> OP_PUSH65 <pk1> OP_PUSH65 <pk1> OP_PUSH65 <pk1> 3 OP_CHECKMULTISIG (198 bytes)
• pay to pubkey: again, using uncompressed pk: OP_PUSH65 <pk> OP_CHECKMULTISIG (67 bytes)
• pay to pk hash: OP_DUP OP_HASH160 OP_PUSH20 <hash> OP_EQUALVERIFY OP_CHECKSIG (25 bytes)
• pay to script hash: OP_HASH160 OP_PUSHBYTES_20 <hash> OP_EQUAL (23 bytes)
• pay to witness script hash: OP_0 OP_PUSHBYTES32 <hash> (34 bytes)
• pay to witness pk hash: OP_0 OP_PUSHBYTES20 <hash> (22 bytes)
• pay to tr: OP_1 OP_PUSHBYTES32 <hash> (34 bytes)
• OP_RETURN: OP_RETURN OP_PUSHDATA1 <bytes> <thing>

If we were to limit it to 200 bytes, we would cover them. But we can assume that users of things like Floresta or EPS are just using a common address scheme like pkh or one of the segwit addresses. So 64 bytes are more than enough. If the user wants something more fancy, just use the old blockchain.scripthash endpoints.

Implementation

It should be trivial to implement this with the current indexers, you just need to hash the spk passed as parameter and lookup as usual. No re-indexing is required here. There's also no need to change wallets that don't want to implement these, as the old ones are still there. But if you'd like to, it's trivial to swap endpoints.

(*) someone please check this math, I did this from the top of my head and might be wrong by a few bytes.