Brainstorming/feature: lightweight version of bitcoin-Qt #1191

I am wondering, how easy would it be to make a lightweight version of bitcoin-Qt. The difference being that it won't store the blockchain locally but instead query connected nodes instead for the needed information.

If it's able to establish enough connections, and connect to the network in the same way as a full-node, but behaving much in the same way as a node that's not yet downloaded the blockchain, and there was a small modification made to the protocol that allowed the necessary queries - perhaps an extension to the protocol rather than a change to it, and full-nodes can choose whether to opt-in to help provide this service or not.

I'm not very familiar with how other lightweight clients do it so far, to see how this idea compares. Also, people could configure their lightweight bitcoin-qt's to specify which full-nodes to consult, thereby allowing people to configure how much they can trust it. I see the main miners being good souces for such co-operating nodes, and already my full-node obtains most of it's blocks from one of the significant mining pools.

Open issues on blue skys ideas is not likely to create progress on its on. It's very easy to spout ideas, much harder to actually make progress on them.

I think there is probably general consensus that we'd at some point like to have wallet / backend separation— and some of the restructuring that has gone on in the last year makes that a bit easier... but there is still a lot of work ahead.

@gmaxwell. Yes, wallet / backend sepatation does seem to be where this idea would fit in. Protocol-wise, do you think it should involve a BIP, or be an independent network? I'm inclined to think it could fit in easily to the existing network (via BIP). Although I think the current version system advertised amongst peers is not ideal for future feature expansion. I think something in the form of flags would be better. The number 60000 takes up 16 bits of information. I wonder whether a new version/flag system implemented, via the BIP process, where each bit could correspond to a function of that peer, might offer better expansion abilities.

I don't think the communication between clients and a trusted blockchain backend server needs to use the same protocol. There is almost no overlap (it doesn't need peer exchange, block/tx distribution, ... but it does require knowledge about things like addresses and balances which don't exist at the bitcoin protocol level). Also, several proposals and implementations already exist: Electrum, BCCAPI, bitcoin-js, and maybe even bitcoind's RPC protocol.

Also, when new node-specific features are added to the protocol, they can use the nServices flag. As this is information propogated along with peer exchange, it is much more useful to potential peers. No need to put that in the version number.

As I've asked you on the mailing list already: Why do you not take a look at the existing lightweight clients? You are re-hashing ideas that were already proposed on the forum and mailing list more than a year ago. Some people are working very hard on those. I don't see it necessary to duplicate their effort. There's enough to do to make the perfect and stable full node, which is IMO what the Satoshi client should be focusing on.

Design-wise a bitcoin client can be split into three components:

1 frontend <-> 2 wallet <-> 3 P2P blockchain client 

Electrum is a client with just the frontend and the wallet, and has the P2P blockchain client in so-called supernodes (which AFAIK run Satoshi client). It doesn't use the P2P protocol for the communication from wallet to blockchain client, but something called Stratum (see https://bitcointalk.org/index.php?topic=55842.0). It makes sense to use different protocols for different concerns.

Next time, please only file a "blue sky idea" issue if it is really considered an issue (after discussion on the maling list, for example), or you are committing to implementing it yourself. Sorry if this sounds harsh, but to me it feels like bitcoin's issue list is turning into a discussion forum lately.

@laanwj Apologies for the re-hashing of ideas. I wasn't aware that they were old ideas (although I'm not surprised). I did do a search of the github issue database first before raising this though, which I thought would be the first place to look for whether it had previously been suggested.

From my perspective, github issue list seems the ideal place to discuss things, as with the mailing list, I can only see what is discussed since I joined the list, which isn't much, and I'm not aware of any mailing list archives, nor how to easily search them.

Can someone please advise how I can get post/reply ability on bitcointalk.org please? It would be nice to be able to discuss such things on there instead of here, if that is the overall preference.

Github issue tracker is for everything directly related to bitcoind / Bitcoin-Qt, not more, not less ... IMHO!

@rebroad: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development