What does blockchain.address.listunspent exactly return?

Question

I am building a simple application that allows user to create and broadcast spend transaction by providing a private key to get funds from and a BTC address to send those funds to.

The application first calculates the BTC address of that private key and then performs a request to a electrum server:

{"id": 0, "method":"blockchain.address.listunspent","params":["1addresshere1fk29ka3"]}

The problem is, this only returns a list of [transaction hash, output position, value in satoshis, position in blockchain] for every output. But it doesn't contain the script of that output.

Is it safe to assume that every output script is going to be the standard pay-to-hash '76a914' + addr_hash + '88ac' ??

Or do I have to perform another request asking for the raw of all the provided transaction hashes and check that the specific outputs are actually a standard pay-to-hash?

Will blockchain.address.listunspent only provide outputs with pay-to-hash scripts? Will it provide outputs with other kind of scripts such us multisig? Even if its a 1 of 2 keys and you have 1 of them?

And another question, blockchain.address.getbalance, does this also only give the total balance of pay-to-hash scripts? Or does it also add the multisig scripts?

And a final question, will blockchain.address.listunspent return the ouputs that were spent in an already broadcasted transaction that is not yet added in the blockchain?

Answer 1

Is it safe to assume that every output script is going to be the standard pay-to-hash '76a914' + addr_hash + '88ac' ??

Usually.

For your example the full scriptPubKey looks like OP_DUP OP_HASH160 PUSH_20 0x9C1185A5C5E9FC54612808977EE8F548B2258D31 OP_DUP OP_CHECKSIG, but this can also be encoded non-canonically as OP_DUP OP_HASH160 OP_PUSHDATA1 0x14 0x9C1185A5C5E9FC54612808977EE8F548B2258D31 OP_DUP OP_CHECKSIG using a OP_PUSHDATA1 in place of the direct push opcode. There's no functional difference to this and the script will be longer as a result, but there are outputs like this in the unspent outputs database that fit this pattern.

In total there's 4 valid permutations for each P2PKH script, direct push, OP_PUSHDATA1, OP_PUSHDATA2 and OP_PUSHDATA4. Different software either sees these as valid, or simply ignores, it's undefined exactly what people should be doing with them. They are spendable and technically the same as the most obvious permutation, but it's not clear on the outset that this behavior is even permissible.