Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM@<div class="post">I second the DHT idea for maintaining a client list - we can't have millions of people relying upon an IRC channel, etc.&nbsp; As far as the scaling issue goes, the issue is not at all HDD space, its network bandwidth.&nbsp; Everyone is forgetting, its not bytes_per_transaction*transactions, which is the number everyone is using.&nbsp; That number, as everyone has said, is fully manageable.&nbsp; No, the number we're interested in is bytes_per_transaction * transactions * number_of_clients * total_hops_beyond_first_between_all_clients_combined<br/><br/>THIS is the amount of bandwidth which the protocol for BTC consumes as the network scales.&nbsp; We're not just talking about sending one copy of each transaction to each client - we're talking about multiple clients broadcasting potentially redundant data to one another, and doing it across numerous hops, meaning numerous rebroadcasts.&nbsp; Much larger number, much more difficult to handle.&nbsp; However, it is manageable, just not in the current incarnation of network handling in the client.<br/><br/>Perhaps in the "popular" phase, BTC chains could be broken up by region, similar to the purviews of domain name authorities now - and there could be an alternative protocol for transactions across these regional boundaries?&nbsp; This would help the raw numbers of the problem, and also cut down on latency and related issues.&nbsp; Not that I think this is an excellent solution - but P2P flooding across all active clients is obviously out barring some massive breakthrough in quantum computing or whatnot.</div> text/html