How practical is it to have a light Blockstack node which runs on an average mobile phone?
Let me define light node as “A minimal node that gathers bitcoin transactions and builds the latest trusted consensus hash”. Doesn’t need to store any other state or zonefiles or anything.
There is no such implementation of this at the moment (I believe). Is it due to lack of use-cases/incentive or some other issue?
If you had a trusted consensus hash (or the txid of a transaction that contained one), you could build a SNV client right now using the Python 2 library (see blockstack/lib/snv.py). No one really asks about it though.
The 2.0 software will instead rely on MARF proofs for specific name/key bindings, and will have a way for clients to deduce the longest chain by inspecting bitcoin headers and Stacks 2.0 headers.
If you had a trusted consensus hash (or the txid of a transaction that contained one), you could build a SNV client right now using the Python 2 library (see
blockstack/lib/snv.py). No one really asks about it though.
I’m talking about building a light client that can gather a trusted consensus hash. Because without a trusted consensus hash it becomes a recursive problem 
We can use BIP37 bloom filtering to get BTC peers to filter all possible Blockstack transactions. Then we can apply BNS rules on top, like a normal full BNS node.
Should work right?
Some possible concerns -
SPV attack vectors are inherited, and will have broader implications for a state management system based on BTC transactions like BNS.
The way Blockstack transactions are structured today, they cannot be bloom filtered.
#2 can be fixed by adding another OP_RETURN output to Blockstack transactions - a static ‘tag’ that can be filtered using BIP37 rules.
#1 can be fixed with a trade-off by limiting source of block headers to a set of semi-trusted BTC nodes. Although this is debatable but this is a better than having no source of trusted consensus hash.
One way we’ve tried to solve this in the past is to just run a full Blockstack node at home, and have it upload consensus hashes to your Gaia hub. Then, your light clients can just fetch them from there.
#2 isn’t really viable, as far as I know – Bitcoin transactions with multiple OP_RETURNs are not standard, and are unlikely to be mined.