Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM<div class="post">As far as I can tell, it's a completely connected network.&nbsp; And it kind of has to be for the security to work - the main idea is that an attacker needs nearly 50% of the computing power of the entire network to inject false transaction information into (or delete honest transactions from) the network.&nbsp; If there was a propagation system, you'd only need to to have about 50%+ of whatever the lowest rung is, and then the rung would be duped into transmitting your false information, possibly beating out the other lowest rungs to dupe the next higher up rung, and so on.<br/><br/>The bottleneck was my first reaction when I read about bitcoin.&nbsp; For one thing, the way the blocks are currently set up, it takes linear time with respect to the total number of transactions (and I think more than that in memory) to verify one transaction.&nbsp; So after 10 years of bitcoin, you need to either go through all 10 years worth of transactions, or have a snapshot of all the account balances of every user ever and work from there.&nbsp; And since the blocks form a straight chain, all of those 35,000 transactions need to go into the same block (if block generation continues to average one per ten minutes).&nbsp; There's currently no way to split that up and have the network work on 350 blocks with 100 transactions each simultaneously, because each block needs the hash of the previous block.&nbsp; That seems particularly silly with the way bitcoin transactions are verified.&nbsp; If everyone waits for one to three blocks to verify a transaction before spending their bitcoins, that means that none of the 35,000 transactions in one ten minute period can depend on each other, and most shouldn't even depend on the previous block.&nbsp; And as far as I can tell, there's no way for the network to speed up block creation in response to transaction overload - if the network ever hit the point where transactions were being made faster than they were being hashed into blocks, the problem would snowball until enough people quit bitcoin out of frustration that the number of transactions dropped below block creation speed.&nbsp; And if block creation were to speed up (via difficulty decrease) then the reward for hashing a new block would have to go down to maintain the planned rate of bitcoin introduction.&nbsp; The nodes would have to know that during the Great Bitstorm of August 2013 blocks only netted the creator 2.5 bitcoins - and they'd have to figure it out <i>during</i> the Great Bitstorm of August 2013.<br/><br/>Also, there's a potential problem if block creation speed were to exceed the speed of information on the network.&nbsp; Chains could be built faster than they would be distributed to the rest of the network, which could mean that two different network segments could work on two different chains simultaneously.<br/><br/>And of course it's worse than 35,000 transactions / ten minutes - we'd probably see something like 50-60k+ transactions during peak hours (depending on how geographically distributed the network is) and much less during the off hours.&nbsp; There would be a need to dynamically throttle proof-of-work difficulty and coin reward hour-by-hour.&nbsp; Since bitcoin is computer based, there'll probably eventually be a fair number of automated systems buying and selling bitcoins - a sudden sharp fluctuation in stock markets or currency exchange rates could set those off all at once.&nbsp; (Although the verification system might help with this, since you can't do microsecond scale trading with bitcoins.)</div> text/html