As I said, the block time needs to be more than several times the maximum end-to-end propagation delay.  This is needed to prevent competing nodes from generating blocks at the same time and convincing large parts of the network that their respective block is the winning block.  If competing nodes can convince large parts of the network that their respective block is the winning block, you risk fragmentation of the blockchain.  Having the block time be at least several times the maximum end-to-end propagation delays helps prevent competing nodes from convincing large parts of the network that their respective block is the winning block.

Really?  WorldCoin has proven this?  Which other coin has had an entire mining pool mining on an orphan blockchain for more than 300 consecutive blocks?

Really?  WorldCoin has proven this?  Which other coin has had an entire mining pool mining on an orphan blockchain for more than 300 consecutive blocks?


With Bitcoins you will encounter an occasional orphan, not 300 orphans consecutively.

If you want instant, then decentralized is not the solution.

The problem is when the orphan chain ends up being the main chain.  Now, you have real transactions taking place on the orphan chain -- someone is going to lose their coins.

The network is connected enough so that there is multiple ways to route messages between each pair of nodes.  If a node dies on a route between two nodes, messages are redirected across other routes that don't involve the dead node.

What exactly did the developer do to prevent these issues?  Note that the issues I present only become apparent once the distributed network becomes large enough.  Low orphan rates now doesn't necessarily prove anything, it likely just means that the network hasn't grown large enough for these problems to become apparent yet.

DigitalCoin won't succeed for a different reason.  The chosen block time is actually too short.  I write about why that's a bad thing here: https://bitcointalk.org/index.php?topic=211535.0

For all cryptocurrencies based off the Bitcoin protocol, the block time needs to be chosen carefully in order to guarantee that nearly every node in the distributed network maintains the same view of the blockchain.  The block time needs to be, at the very least, several times larger than the maximum end-to-end propagation delay across the distributed network.

Choosing a very short block time demonstrates a lack of understanding of this requirement.  If you make block times very short, then nodes will generate blocks faster than it would take for notifications to reach nodes on the opposite end of the distributed network.  This will cause nodes within the distributed network to have inconsistent views of the blockchain.

What does this mean?  1) Lots of orphans.  2) Very long orphan blockchains.  3) Significantly reduced security for the network.

Earlier today, one of the WorldCoin mining pools (http://wdc.dontmine.me) was on an orphan blockchain for more than 300 blocks.  That would never happen for any competently designed coin.

Altcoins with very short block times have no real future.  Once they reach a certain critical mass, they will inherently self-destruct due to the large percentage of inconsistency within the distributed network.  Imagine the blockchain accidentally forking into two separate blockchains.  With very short block times, that's a real possibility.  Or imagine having a transaction confirmed, only to realize hours later that the transaction was confirmed in an orphan blockchain and needs to be rolled back and reconfirmed.  No one would realistically support such an altcoin.

If you're going to release an altcoin, do the community a favor and at least release something that appears competently designed.

This is absolutely a valid argument.  For anyone who thinks this can't happen, it happened with GameCoin.  Someone (presumably the developer) was able to override the mined blockchain with an even longer blockchain, giving all of the rewards to that one person.

Er, those values are preceded by a right-shift operator.  By changing the amount of right-shift from 20 to 1000000, he actually is making the value of bnProofOfWorkLimit smaller, not larger.  In fact, because uint256 doesn't actually have 1000000 bits, by setting the amount of right-shift to 1000000, he's basically setting the value of bnProofOfWorkLimit to 0.

I support all of your other posts, but this one isn't technically accurate.

LOL, I wonder if you actually know programming.

It was shifted right. Bitops. SHIFTING IT RIGHT DOES NOT INCREASE IT, IT DECREASES IT.

Devianttwo, pool is so messy I can't even understand what's the right host:port. Could you please clarify?

Luke-jr may be wrong on Litecoins but you should all respect him and not badmouth him (Radacoin). Have you read the #bitcoin-dev log from the March 11/March 12 hardfork event?? Luke-jr was the guy taking the lead on the solution. He is the reason that you are still wealthy if any of you were smart enough to buy BTC at low prices! A thank you would be in order.

http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12