Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM <div class="post">Nicely written gridecon. I completely agree. <br/><br/>I've been considering posting a similar critique but you've laid the issue out clearly. if you don't mind I'll add my thoughts here.<br/><br/>As the minting process and the transaction recording process are one, there is really no reason to separate them. I don't disagree with knightmb's points at all. But I do think that is is really important to point out that all that CPU power and electricity usage is absolutely NOT required for the task at hand.<br/><br/>Generating blocks serves three critical but independent functions in the bitcoin system.<br/><br/>1. It permanently records valid transactions in a roughly chronological order.<br/>2. It creates *consensus* among all nodes on what transactions took place and when, WITHOUT relying on a central authority. That was a hugely clever breakthrough.<br/>3. It trickles bitcoins into circulation at a regularly scheduled rate. (roughtly 50 BTC/10 min) Also a nice motivational trick.<br/><br/><br/>However, all of these required tasks could be done in a much more efficient manner.<br/><br/>Generally in a P2P system, if you add more nodes then the necessary machine resources needed per node decrease. (for a given usage level of the service)<br/>However, if we add more nodes to the bitcoin network the necessary machine resources needed per node increase. This is true of CPU usage and network bandwidth. <br/><br/>Satoshi already pointed out that the goal of this is not to scale to millions of pure P2P nodes. But instead to have thousands of transaction checking peers each having thousands of clients. That means the goal is to create core "central authority" of peer nodes each of which is trusted by some clients, but the core peers do not necessarily need to trust each other. This is a absolutely critical design construct if the current implementation of bitcoin is expected to scale to millions of traders.<br/><br/>However, there are other design possibilities that could meet each of these three critical goals without exponential growth in resources utilization.<br/><br/>Implementing the transaction graph using a redundant distributed hash table comes to mind. This could be done with or without a core of central peers. Another possibility would be just to store the transaction graph in a SQL database and use database replication among the core peers. Either of those satisfies goal 1 and 2 using minimal system resources.<br/><br/>Goal 3 is implementable by simply generating a distributed shared secret, then using that shared secret as a concensus random node to send 50 BTC to.<br/><br/><br/>I agree with gridecon that such an implementation would out compete the current implementation. Even if it otherwise following exactly the same external behavior and transaction validation rules.</div> text/html