theymos' full node and lite node write up got me thinking. There are two problems here that we are trying to solve: - The scalability of broadcast messages. - The resources required to sync and verify the block chain.
I see three distinct groups of clients: - Miners (dedicated servers & desktops) - Full (desktops) - Lite (mobile devices) To address scalability of broadcasting, there could be three separate modes of operation (or client types). Mining nodes would retain the complete block chain, and share all messages between other mining nodes. Full nodes would retain the complete block chain, receive new block information from mining nodes, and share block data between each other. Lite clients would not contain the block chain, or any broadcast messages, and would query against a full client for all actions. Mining nodes would handle the brunt of the barrage of messages. All block and transaction messages would have to be broadcast across all mining nodes. This would be essentially the same as all clients currently operate today. A full client would be one step down from a mining client. They only need new block data, and new transactions that pertain to them (for instant notification). All other broadcast data is irrelevant to them. They would get new block data from connections to mining nodes, or from other peer nodes. The transaction submission could be sent directly to a connected mining node, or bounced through other connected full nodes, with a random number hops. This would disassociate the IP from the transaction, similarly to Tor. To address the need for instant transaction notification, without broadcasting to to everyone, notification messages would be sent directly from one full client to the other. This is where aliases come in. When an alias is resolved, it includes both a Bitcoin address, and a list of IPs to notify of the transaction. This reveals the IP of the sender and receiver to each other. If the sender or receiver wishes to remain anonymous, then they could opt out of notification, and wait for the transaction to appear in the block chain. A lite client would connect to a "trusted" full client over an encrypted connection. This would essentially function as a remote control to a full client, and allow a user to send, receive, and confirm normally, but without the overhead. A full client could reside on the home computer or server, which is owned by the user. A hosted wallet could also be used just as easily. I don't like the idea of a header only client, unless this is just an interim action until the full block chain is downloaded in the background. Development of these types of clients is probably inevitable, but I believe that this breaks the most fundamental aspects of Bitcoin's security model. If a client has only headers, it cannot do full verification, and it is trusting the data from random anonymous peers. ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
