[ANNOUNCE] New alternate cryptocurrency - Geist Geld

[coblee]

Thus, 1 is neat, 2 is secure, 3 is verily secure, everything above 3 even more secure to the point of paranoia at 6 and "you should probably buy something on Silk Road" at above 6

You need to run your Geist Gold proxied through Tor to understand why you are wrong. Satoshi was probably over-conservative. You are certainly over-optimistic.

Lolcust, I think you are overly optimistic about this. 6 geist confirmations is definitely not enough to be secure. A common misconception about bitcoin is that the number of confirmations determines how safe your transaction is from a double spend attack. In reality it's how much time since your transaction that determines how safe it is. This is because the amount of time determines how likely an attack will succeed.

For example, if an attacker has 33% of the network hashrate, he has to be twice as lucky than the other miners in order to create more blocks than everyone else. It's much more likely to be twice as lucky for a period of 90 seconds (6 geist confirmations) than it is for a full 1 hour (6 bitcoin confirmations).

[2112]

I guess that could be easily tested by having one of the multi-gigahash dudes trying to mine through TOR and mining for 10 mins, then through I2P's cancerous outproxy and mine for 10 mins, then directly and again 10 mins. We could compare the number of blocks accepted by the net and see if TOR or I2P result in notable loss.

I'm sorry I wasn't clear first time around. I edited my post too late.

The real test of your future coin laundry will involve setting up a Tor's hidden service. The connections "Tor<->clearnet" only test less than half of the Tor's privacy stack. To get a real statistics you'll have to setup your ghetto box behind a hidden service to connect "Tor<->Tor". Only then it will you test the full Tor stack: "hidden service directory resolution" + "connection from you to rendezvous-point" + "rendezvous-point delay" + "from rendezvoud-point to the hidden server".

If you regularly use Tor then please look up Hidden Wiki for the hidden bootstrap nodes for the original Bitcoin and try to resync the normal "bitcoind" through them after a weekend offline. Then you could try the same feat with your variant.

People frequently complain about 10 minute block interval of the original Bitcoin as way too slow. It is slow, but it reliably bootstraps through Tor. With your 15 second block intervals the bootstrap will be realy a feat of networking.

[2112]

TOR is not nice but hey, you see my response right ? So mission accomplished *bush pic*

Well, Theymos and bitcointalk.org crew aren't really hiding. Your coin laundry will have to run hidden.

Yeah, I keep forgetting than when I talk about Tor I should be clear about the full privacy: both for a client and for a server.

[doublec]

Lolcust, I think you are overly optimistic about this. 6 geist confirmations is definitely not enough to be secure.

I'm inclined to agree. The bitparking I0Coin exchange stopped accepting blocks last night when it detected a chain reorg going back 10 blocks, past the 10 confirmations required for a deposit. So even with 90 second blocks, 10 wasn't enough. That chain only has half the hash rate of GG though.

[Lolcust]

Thus, 1 is neat, 2 is secure, 3 is verily secure, everything above 3 even more secure to the point of paranoia at 6 and "you should probably buy something on Silk Road" at above 6

You need to run your Geist Gold proxied through Tor to understand why you are wrong. Satoshi was probably over-conservative. You are certainly over-optimistic.

Lolcust, I think you are overly optimistic about this. 6 geist confirmations is definitely not enough to be secure. A common misconception about bitcoin is that the number of confirmations determines how safe your transaction is from a double spend attack. In reality it's how much time since your transaction that determines how safe it is. This is because the amount of time determines how likely an attack will succeed.

For example, if an attacker has 33% of the network hashrate, he has to be twice as lucky than the other miners in order to create more blocks than everyone else. It's much more likely to be twice as lucky for a period of 90 seconds (6 geist confirmations) than it is for a full 1 hour (6 bitcoin confirmations).

Um, I am no actuarian coblee, but it seems to me that the original bitcoin paper does not state that probability of attacker success is a function of time.

Instead, it says that "Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases"

Again, I might be missing an elephant in the room of theses arcane mathematications, but it appears that probability of attacker's success is claimed to drop off with the number of blocks, not the time spent making them, which would mean that "6 valid blocks" are still "6 valid blocks".

Thus, 1 is neat, 2 is secure, 3 is verily secure, everything above 3 even more secure to the point of paranoia at 6 and "you should probably buy something on Silk Road" at above 6

You need to run your Geist Gold proxied through Tor to understand why you are wrong. Satoshi was probably over-conservative. You are certainly over-optimistic.

Lolcust, I think you are overly optimistic about this. 6 geist confirmations is definitely not enough to be secure. A common misconception about bitcoin is that the number of confirmations determines how safe your transaction is from a double spend attack. In reality it's how much time since your transaction that determines how safe it is. This is because the amount of time determines how likely an attack will succeed.

For example, if an attacker has 33% of the network hashrate, he has to be twice as lucky than the other miners in order to create more blocks than everyone else. It's much more likely to be twice as lucky for a period of 90 seconds (6 geist confirmations) than it is for a full 1 hour (6 bitcoin confirmations).

Um, I am no actuarian coblee, but it seems to me that the original bitcoin paper does not state that probability of attacker success is a function of time.

Instead, it says that "Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases"

Again, I might be missing an elephant in the room of these arcane mathematications, but it appears that probability of attacker's success is claimed to drop off with the number of blocks, not the time spent making them, which would mean that "6 valid blocks in a net running at block per 15 secs" are as hard to overpower as  "6 valid blocks in a net running at 1 block per 10 minutes" (assuming hashrate distributions for attacker and good guys match in both of them, of course).

I guess that could be easily tested by having one of the multi-gigahash dudes trying to mine through TOR and mining for 10 mins, then through I2P's cancerous outproxy and mine for 10 mins, then directly and again 10 mins. We could compare the number of blocks accepted by the net and see if TOR or I2P result in notable loss.

I'm sorry I wasn't clear first time around. I edited my post too late.

The real test of your future coin laundry will involve setting up a Tor's hidden service. The connections "Tor<->clearnet" only test less than half of the Tor's privacy stack. To get a real statistics you'll have to setup your ghetto box behind a hidden service to connect "Tor<->Tor". Only then it will you test the full Tor stack: "hidden service directory resolution" + "connection from you to rendezvous-point" + "rendezvous-point delay" + "from rendezvoud-point to the hidden server".

If you regularly use Tor then please look up Hidden Wiki for the hidden bootstrap nodes for the original Bitcoin and try to resync the normal "bitcoind" through them after a weekend offline. Then you could try the same feat with your variant.

People frequently complain about 10 minute block interval of the original Bitcoin as way too slow. It is slow, but it reliably bootstraps through Tor. With your 15 second block intervals the bootstrap will be realy a feat of networking.

Hm, so basically, it will always lag behind the chain because full hidden server is so damn slow. Quite plausible a problem (I guess Bitcoin would always lag behind on, I dunno, GPRS then).

But as long as Geist can stand its ground on "vanilla nets", that strikes me as a fairly remote problem that might be solved by clever lean client design (whether it really can is another matter)

TOR is not nice but hey, you see my response right ? So mission accomplished *bush pic*

Well, Theymos and bitcointalk.org crew aren't really hiding. Your coin laundry will have to run hidden.

Hm, well, one might hypothetically try to have the laundry proper run "lean" and only have the "consumer-facing front" and associated proxy wallets to run G propper.... Hm. Not a bad idea it seems, I'll run it by a certain someone later...

Lolcust, I think you are overly optimistic about this. 6 geist confirmations is definitely not enough to be secure.

I'm inclined to agree. The bitparking I0Coin exchange stopped accepting blocks last night when it detected a chain reorg going back 10 blocks, past the 10 confirmations required for a deposit. So even with 90 second blocks, 10 wasn't enough. That chain only has half the hash rate of GG though.

Again, I might be failing to note an elephant here, but it seems quite explicitly stated in the Satoshi paper that attack success probability drops off with number of blocks, not time spent making them.

As for poor little i0, for the love of everything good, there are currently merely 29.811 Ghashes on i0coin.

If all people mining Geist right now conspired to overrun i0coin, it is not entirely unlikely that we could   do it (not intended to actually incite anyone towards harming the poor little coin)

[coblee]

Um, I am no actuarian coblee, but it seems to me that the original bitcoin paper does not state that probability of attacker success is a function of time.

Instead, it says that "Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases"

Again, I might be missing an elephant in the room of these arcane mathematications, but it appears that probability of attacker's success is claimed to drop off with the number of blocks, not the time spent making them, which would mean that "6 valid blocks in a net running at block per 15 secs" are as hard to overpower as  "6 valid blocks in a net running at 1 block per 10 minutes" (assuming hashrate distributions for attacker and good guys match in both of them, of course).

Yes, the the original paper does say that, and it's true. 6 GG confirms is much more secure than 5 GG confirms, which is much more secure than 4 GG confirms. But the paper doesn't say anything about comparing the security between 10 min blocks and 15 sec blocks. Given the same block times, each additional confirmations makes the probability of successful attack drop off exponentially. But if you try to compare the 2 chains, 1 BTC confirmation is as secure as 40 GG confirmations.

[Syke]

Um, I am no actuarian coblee, but it seems to me that the original bitcoin paper does not state that probability of attacker success is a function of time.

The paper is considering the probility of successfully completing a single attack. Roughly:

6 bitcoin confirmations = 60 minutes
6 gg confirmations = 1.5 minutes

On the gg chain, you can perform 40 times as many attempted attacks in the same time period. So even if the odds for a single attack are the same, you get 40 times as many attempts, so clearly time does effect the security.

[Lolcust]

Um, I am no actuarian coblee, but it seems to me that the original bitcoin paper does not state that probability of attacker success is a function of time.

Instead, it says that "Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases"

Again, I might be missing an elephant in the room of these arcane mathematications, but it appears that probability of attacker's success is claimed to drop off with the number of blocks, not the time spent making them, which would mean that "6 valid blocks in a net running at block per 15 secs" are as hard to overpower as  "6 valid blocks in a net running at 1 block per 10 minutes" (assuming hashrate distributions for attacker and good guys match in both of them, of course).

Yes, the the original paper does say that, and it's true. 6 GG confirms is much more secure than 5 GG confirms, which is much more secure than 4 GG confirms. But the paper doesn't say anything about comparing the security between 10 min blocks and 15 sec blocks. Given the same block times, each additional confirmations makes the probability of successful attack drop off exponentially. But if you try to compare the 2 chains, 1 BTC confirmation is as secure as 40 GG confirmations.

Hm,  at this point I think additional expert opinion is worth inviting, since is seems to me that time can not directly factor into the gambler's ruin like that.

It is entirely a function of block confirmations, but there is an element of time dealing with split chains.  I would theorize that with increased split chains due to smaller block times (I suspect that happens in GG as well), and the increased likelihood that they can grow longer than in the slower alternate coins such as bitcoin.  You have to account for block confirmations and a little bit of a time element (enough blocks to cover the majority of the lengths of typical chain splits) .... so while you might incur more risk with 6 that BTC you don't have to get obscene and force enough blocks to cover an hour....  I would guess 10 or up to 15 should suffice but that is just a semi-educated guess.

Hm, so basically the issue is that the split chains might get longer... but doesn't the BTC algo define "canonicity" in terms of which has most work, and not most "block count" ?

BTW, studying Geist's (hypothetical?) propensity for growing "longer" side-chains is an interesting prospect in itself...

P.S.:
Started a thread in technical about comparing security of a single validation in different alt chains.

[2112]

Hm, so basically, it will always lag behind the chain because full hidden server is so damn slow. Quite plausible a problem (I guess Bitcoin would always lag behind on, I dunno, GPRS then).

Yeah, something like that. But I always try to stress that it isn't the lag that kills the network protocols, it is the variance of the lag that's deadly. Find a way to buffer the variance and you'll win. I would bet that you could operate your little laundry on a asteroid with a predictable orbit with no problems, but trying to do this over the network with high variance will be extremely difficult.

[2112]

Hm,  at this point I think additional expert opinion is worth inviting, since is seems to me that time can not directly factor into the gambler's ruin like that.

I'm not an expert, but I used to eat lunches with some experts. Here's the main difference between Satoshi's approach and yours:

Satoshi made an assumption of type "assume a spherical cow in a vacuum", or in his case "assume that the interblock period is long enough to consider the underlying network observable." In other words he can neglect the inter-node transmission time and consider the time to be a discrete interblock periods.

You made an assumption of type "assume a fat cow on a muddy field", or in your case "assume that the interblock period is as short as a decent computer can squeeze them through a decent home-style Internet pipe." In other words you cannot neglect network observability, your inter-node transmission time is on the same order as a TCP/IP timeout and a BGP route flap. Thus the time in your security model cannot be discretized to just interblock period. You have to consider other cases, eg. your node is getting flapped between two competing versions of the block-chain that are producing blocks on the even/odd half-periods.

Now, from reading your previous posts I can tell that you posses both skill and attitude to solve this type of problems. Perhaps Geist Gold requires a "block-chain flap dampening patch" the same way as BGP protocol required "route flap dampening"?

Anyway, the true expert would answer: "Do you want me to write a research grant proposal?"

[Lolcust]

Hm, so basically the issue is that the split chains might get longer... but doesn't the BTC algo define "canonicity" in terms of which has most work, and not most "block count" ?

*Not an expert here*  But how I understood it was that splits are just as valid up until they either are overtaken by the "main" or overtake the "main" and become the main line, it doesn't necessarily mean they did anything bad but it is a mild competition for longest chain.... thusly if you hypothetically are getting length 10 splits you have to additionally ensure that your minimum transactions have to take that into account just in case one of the splits really is rogue.

As far as I understand, the splits are managed (and the "boss" chain is selected) based upon how much work went into a chain, with the most "laborious" chain "winning" and overtaking the other.

Hm,  at this point I think additional expert opinion is worth inviting, since is seems to me that time can not directly factor into the gambler's ruin like that.

I'm not an expert, but I used to eat lunches with some experts. Here's the main difference between Satoshi's approach and yours:

Satoshi made an assumption of type "assume a spherical cow in a vacuum", or in his case "assume that the interblock period is long enough to consider the underlying network observable." In other words he can neglect the inter-node transmission time and consider the time to be a discrete interblock periods.

You made an assumption of type "assume a fat cow on a muddy field", or in your case "assume that the interblock period is as short as a decent computer can squeeze them through a decent home-style Internet pipe." In other words you cannot neglect network observability, your inter-node transmission time is on the same order as a TCP/IP timeout and a BGP route flap. Thus the time in your security model cannot be discretized to just interblock period. You have to consider other cases, eg. your node is getting flapped between two competing versions of the block-chain that are producing blocks on the even/odd half-periods.

Now, from reading your previous posts I can tell that you posses both skill and attitude to solve this type of problems. Perhaps Geist Gold requires a "block-chain flap dampening patch" the same way as BGP protocol required "route flap dampening"?

Anyway, the true expert would answer: "Do you want me to write a research grant proposal?"

Well, the issue under discussion was somewhat different, but I find your post fascinating.

However, first and foremost my initial assumption was "hey, wouldn't it be nice to make a chain with really, really fast blocks and see if it dies screaming" (which it so far did not, and is taking it like a trooper so far  ). Now that this is out of the way, I find the issue of low-level protocol effects on Geist fascinating (though somewhat saddening because it's quite above my ability to investigate without significant outside help)

I am, however, somewhat perplexed by the idea that BGP flaps can be smooth and regular enough to repeatedly oscilate poor   Geist between two versions of the chain...

As far as I understand, BGP flap is basically a route dying and un-dying fairly rapidly due to something cute happening in a given ISP's network, which suggests that normally they should be fairly irregular and territorially contained... but the issue is absolutely worth looking into, since it makes Geist a fascinating subject of study irrespective of various "plainly pragmatic" considerations.

I'd give you a research grant but I can only pay an impressive sum either in Belorussian Roubles or in Geists, and I'm reasonably certain that Geist is a more viable form of "sorta-money" (not intended as a claim of monetary viability of Geist Geld )

[3phase]

As far as I understand, BGP flap is basically a route dying and un-dying fairly rapidly due to something cute happening in a given ISP's network, which suggests that normally they should be fairly irregular and territorially contained... but the issue is absolutely worth looking into, since it makes Geist a fascinating subject of study irrespective of various "plainly pragmatic" considerations.

I might be wrong, but I think 2112 was trying to point out the inevitable situation of a transaction transmitted over to a network, and getting lost or terribly delayed (even with the very fast Geist blocks) because there is a high enough probability that it never manages to be included in a block which is not orphaned later. This probability will be amplified as more nodes and miners join the network. It might still be OK now with less than 100 nodes active (assumption, again I might be wrong about this number).

This issue can be caused by BGP route flaps, TCP timeouts, torrent software overloading your line, bad cabling, local Ethernet switch flap or any other issue that can impair a user's connection to the network (the Geist network that is) for 10-30 seconds. These events would be a non-issue with a slower chain and definitely a non-issue with most Internet services (except Real time video/audio conferencing which cannot afford more than 1sec delay).

The number of things that can go wrong, most of them beyond the users' powers is also why few would be willing to go to the trouble to solve these issues (even if they could, as in the example of LAN issues). They would probably first give up on trying to use Geist as a transaction medium.

As far as I have read about Geist, it brings many innovative features, but in my view the fast blocks collide (pun intended) with the innovations.

Still watching to see how this goes.

[Lolcust]

As far as I understand, BGP flap is basically a route dying and un-dying fairly rapidly due to something cute happening in a given ISP's network, which suggests that normally they should be fairly irregular and territorially contained... but the issue is absolutely worth looking into, since it makes Geist a fascinating subject of study irrespective of various "plainly pragmatic" considerations.

I might be wrong, but I think 2112 was trying to point out the inevitable situation of a transaction transmitted over to a network, and getting lost or terribly delayed (even with the very fast Geist blocks) because there is a high enough probability that it never manages to be included in a block which is not orphaned later. This probability will be amplified as more nodes and miners join the network. It might still be OK now with less than 100 nodes active (assumption, again I might be wrong about this number).

This issue can be caused by BGP route flaps, TCP timeouts, torrent software overloading your line, bad cabling, local Ethernet switch flap or any other issue that can impair a user's connection to the network (the Geist network that is) for 10-30 seconds. These events would be a non-issue with a slower chain and definitely a non-issue with most Internet services (except Real time video/audio conferencing which cannot afford more than 1sec delay).

Well, geist obviously is more network-sensitive and there obviously is a blockrate/decentralization tradeoff at work (I think I said that in post one), and point of Geist experiment is, in part, to see exactly how this tradeoff works out on a "live" network that experiences all the live influences.

Geist, however, is quite ready to trade decentralization for blockrates (up to a point of course ), which I also stated in my first post, and what concerns me most is that network effects that impede Geist decentralization will also impede pool operation, thus also impeding the partial centralization and thus making further increase in Geist hashrate problematic at best.

They would probably first give up on trying to use Geist as a transaction medium.

Well, "thin" clients don't download the blockchain proper anyways, so theoretically nothing keeps people from sending their tx to all the well-known "big miner" geist nodes first, then the "plebes", thus maximizing the likelihood of those ending up in a block quite soon, or some other, smarter optimization of the way the net handles transactions (I'm not quite smart enough to come up with those by myself, admittedly ).

Bitcoin will need many of those optimizations too if it grows "huge enough", and this is why it might be worthwhile for the community to play around with Geist, IMHO.

In the end, yes, it is quite possible that "audaciously fast blocks" will cause either insurmountable scaling issues or problems of sustaining a good enough connection to force your tx in even if some optimizations in transaction transmission by "lean" clients are in place.

The point of Geist is 1) try to find that out in a "live" setting 2) try to seek amendments to overcome those issues 3) see if some of those optimizations are also worth implementing in Bitcoin

As far as I have read about Geist, it brings many innovative features, but in my view the fast blocks collide (pun intended) with the innovations.

If worst comes to worst, there's nothing in the nature of Geist that would prevent gearing down the blockrate while adjusting the subsidy and retarget to leave economics intact (or maybe even give folks some temporal single-issue of pseudo deflation if they shall so demand, though I refuse on general principle to set a hard upper limit on number of Geists in existence. "Coin regeneration" FTW ), however such course of events will be a huge blow to Geist's stance and appeal, even despite all the knowledge gained when assessing the causes which could lead to such an unfortunate and radical solution.

Still watching to see how this goes.

Interesting things will happen when pools will start to get deployed.

P.S.:



I am a bit iffy on the deeper intricacies of the "how does pool form" theory, so,  how many pool nodes connected to the bicoin network (as opposed to miners connected to pool, which as far as I understand have no particular reason to even be aware of the blockchain since they only deal with the pool's share anyways) does on average each of the "big fishes" of pool business represent ?

[3phase]

I am a bit iffy on the deeper intricacies of the "how does pool form" theory, so,  how many pool nodes connected to the bicoin network (as opposed to miners connected to pool, which as far as I understand have no particular reason to even be aware of the blockchain since they only deal with the pool's share anyways) does on average each of the "big fishes" of pool business represent ?

Don't really know unless you ask a pool operator willing to disclose that information (difficult) but an example which I think is maybe overdone (except if we're talking VPS machines):

Code:

[localbox1.localdomain ]# nslookup btcguild.com

Non-authoritative answer:
Name:   btcguild.com
Address: 78.46.186.28
Name:   btcguild.com
Address: 78.46.186.29
Name:   btcguild.com
Address: 78.46.186.30
Name:   btcguild.com
Address: 78.46.186.50
Name:   btcguild.com
Address: 78.46.186.51
Name:   btcguild.com
Address: 78.46.186.52
Name:   btcguild.com
Address: 78.46.186.53
Name:   btcguild.com
Address: 78.46.186.54
Name:   btcguild.com
Address: 78.46.186.26
Name:   btcguild.com
Address: 78.46.186.27

10 servers - 10 coin nodes for a big one. Bigger pools probably also use load balancers and/or bigger servers.

On another note I applaud your efforts, and it must be said that they have already brought results.

Cheers.

[coblee]

I've been mining with 6 ghash and just now I saw that I found 5 blocks in a row. Immediately, I realized something is not right. I can't be that lucky. After a few minutes, I saw that these 5 blocks all got orphaned. I assumed that due to network issues, I was disconnected enough to build up my own block chain, which got wiped out when I reconnected.

Unfortunately, I think these problems will get worse as the network grows.

[Cosbycoin]

I've been mining with 6 ghash and just now I saw that I found 5 blocks in a row. Immediately, I realized something is not right. I can't be that lucky. After a few minutes, I saw that these 5 blocks all got orphaned. I assumed that due to network issues, I was disconnected enough to build up my own block chain, which got wiped out when I reconnected.

Unfortunately, I think these problems will get worse as the network grows.

Interesting. I wonder how things will play out as we start hitting 100, 200, 300 GH.

[Lolcust]

I've been mining with 6 ghash and just now I saw that I found 5 blocks in a row. Immediately, I realized something is not right. I can't be that lucky. After a few minutes, I saw that these 5 blocks all got orphaned. I assumed that due to network issues, I was disconnected enough to build up my own block chain, which got wiped out when I reconnected.

Unfortunately, I think these problems will get worse as the network grows.

If you (or anyone else) ever find another "bizzaro streak of blocks", please do a getinfo and see if you have connections, and if so, how many. Because if you have like 6-8 connections and get such a streak, then likely something more that just "connection loss" is afoot.

Having said that, if network issues start causing orphaning of large ammount of blocks, that could be detected when studying the blockchain. According to ArtForz, so far there is no indication that the amount of orphans "on whole" is higher that normal.

P.S.:
coblee, could you PM me the timestamps and txid  on those orphans (should be in listtransactions) ?

[coblee]

I've been mining with 6 ghash and just now I saw that I found 5 blocks in a row. Immediately, I realized something is not right. I can't be that lucky. After a few minutes, I saw that these 5 blocks all got orphaned. I assumed that due to network issues, I was disconnected enough to build up my own block chain, which got wiped out when I reconnected.

Unfortunately, I think these problems will get worse as the network grows.

If you (or anyone else) ever find another "bizzaro streak of blocks", please do a getinfo and see if you have connections, and if so, how many. Because if you have like 6-8 connections and get such a streak, then likely something more that just "connection loss" is afoot.

Having said that, if network issues start causing orphaning of large ammount of blocks, that could be detected when studying the blockchain. According to ArtForz, so far there is no indication that the amount of orphans "on whole" is higher that normal.

P.S.:
coblee, could you PM me the timestamps and txid  on those orphans (should be in listtransactions) ?

I did check. I have 8 connections. Since the blocks were consecutive, it makes me thing I was isolated somehow. I will PM you with timestamps and txids.

[Syke]

I've been mining with 6 ghash and just now I saw that I found 5 blocks in a row. Immediately, I realized something is not right. I can't be that lucky. After a few minutes, I saw that these 5 blocks all got orphaned. I assumed that due to network issues, I was disconnected enough to build up my own block chain, which got wiped out when I reconnected.

Unfortunately, I think these problems will get worse as the network grows.

Interesting. I wonder how things will play out as we start hitting 100, 200, 300 GH.

Won't matter if we have 100 TH. After a few quick blocks, difficulty will adjust, and we'll be right back to 15 second blocks.

[Cosbycoin]

I've been mining with 6 ghash and just now I saw that I found 5 blocks in a row. Immediately, I realized something is not right. I can't be that lucky. After a few minutes, I saw that these 5 blocks all got orphaned. I assumed that due to network issues, I was disconnected enough to build up my own block chain, which got wiped out when I reconnected.

Unfortunately, I think these problems will get worse as the network grows.

Interesting. I wonder how things will play out as we start hitting 100, 200, 300 GH.

Won't matter if we have 100 TH. After a few quick blocks, difficulty will adjust, and we'll be right back to 15 second blocks.

As I suspected there is a threshold in which where you add more GH you don't produce any more blocks than with less GH. I'm curious what that number is.