Topic: QUICKCOIN - 1 block per second! (Read 2293 times)

Ok, I can agree with you on that.

No one uses geistgeld because it is a resource hog and the blocks are too fast. Why do another experiment? There have been 2, geistgeld and liquidcoin, and both are unusable for the main reason of the exact property you are trying to add. Heck, litecoin is having problems due to its block propogation speed. I know how you coin will turn out (unusable) because i've tried it and it doesn't work. What are you going to do differently to fix the problem? Nothing, you're going to make it even worse. Good luck with that.

I am still unconvinced that lots of splits are a bad thing.  The only thing that would be "seen" is the longest chain.  That's all that matters.  Splits can be thrown away as soon as they are detected.

I agree that it would be somewhat inefficient compared to existing solutions, but don't believe that is a deal-breaker.  It would be the price to pay for as-quick-as-possible confirmation of payments.

2.5GB of space is nothing these days.  It would take 1,200 years to fill up a 3 TB HDD at that rate, and storage is only going to continue getting larger, while that 2.5GB/year minimum requirement would stay the same.

Possibly relating to gmaxwells comment but your coin would quickly look like an irreconcilable tree of data with probably hundreds of branches that sprout new splits as often or more often than shorter branches are pruned.  It would also be likely the most energy/resource inefficient coin system out there since your miners would spend a majority of their time mining on yet to be orphaned chains... but if you have a method to converge the branches instead of pruning them then a majority of those issues go away.... oh and 2.5 gb of data for a chain that essentially did nothing for a year?  Seems kind of high to me or you don't intend it to get any use at all and this is just garage talk... in which case, have at it sounds like a great idea!

Why would splits need to be dealt with?  If two chains are competing with each other, and each has dozens of blocks, and one is finally rejected by all the miners, then.... so what?  Why is that a problem?

I am unconvinced that 1 second blocks would cause too much bloat in the blockchain.  The smallest a Bitcoin block can be (i.e. empty) is 80 bytes.  80 bytes/second for one year = 2.5GB.  It's really not an insurmountable problem.

Can you explain your scenario in more detail?  Why would latency cause the chains to never converge (on average)?

Depends on how you define "eventually".  If there exists a partitioning of miners such that the mean time between blocks is less than the communications and block processing latency for a block to propagate completely is less than the mean time between blocks then the bitcoin algorithm will take infinite time to converge in the average case.

In Bitcoin at current transaction levels we now see propagation times at several minutes sometimes. High orphan rates and lots or reorganizations also slow down convergence, so in practice you probably need to have a block time considerably greater than the latency bound or bad things start happening.

But hey, if you plan on reporting the many coin-generic bugs I'm sure you'll find then it's all good, and might be a fun exercise even if it's doomed to fail. Have fun!

I use p2pool to do my merged-mining, maybe that is why my machine could not handle geistgeld at the same time.

Maybe putting a pool on one machine and the actual chains on another would work.

Whether I put GeistGeld on a second machine or p2pool on a second machine either way I first need to budget electricity for a second machine, which GeistGeld did not seem to be providing.

-MarkM-

The only way I see such a high speed chain really working is if it had a better way of dealing with chain splits, perhaps a new way in which to identify a malicious split whereby in all other cases the splits are all accepted as good once they converge (note: likely needing a chain convergence algorithm instead of just dropping shorter chain splits).  Additionally, blockchain bloat would have to be far superior, perhaps going to the often proposed ledger system instead of the current bitcoin standard.

Edit:  minimum speed should account for reasonable network latency as well, not just a blanket 1s ... perhaps some sort of algo could be used to adjust this dynamically such that the targeted chain speed over the next X blocks is the average latency between miners in the previous X blocks + 1s

By the way:

Well so far is has been learned from GeistGeld that even 10 second blocks is too fast to be practical, I am not the only merged miner who had to drop them from the lineup due to that speed uses too much system resources, interfering with all the other chains.

So probably figure that as number of altchains grows more time between blocks would probably give more chance of being merged mined, faster chains likely being the first to be dropped due to excessive resources use.

-MarkM-

EDIT oops you/somone implied its actually 15 seconds for GeistGeld? However many seconds GeistGeld is, is already too fast to be practical except possibly for larger merged mining operators prepared to fire up extra machine to separate it from other chains, and even that has not been proven to fix the problem the speed causes.

Cool

I have no idea how much hash power it would take, just making the assumption that I don't have enough hashpower because I only have one GPU capable of mining at the moment.

How much hash power would it take to push liquidcoin testnet in a box to one second or faster?

If the problem is your CPU is particularly slow and you have no GPU, maybe you could get someone with a GPU to throw some their GPU's power it it to drive it to such a speed? Or does it take two or three GPUs to achieve such speeds?

Remember that even the old code testnets have 1/16 the difficulty of main-nets, did you make the mistake of using a mainnet in a box instead of a testnet in a box when you discovered you did not have enough hashing power to perform the experiment?

-MarkM-

Geistgold is interesting... but a factor of 15 times slower than QUICKCOIN!™  I am still curious what happens if blocks are generated every second.  That said, it does sound similar in goals to what I am proposing.  So, the question is, why does no one use it?  And more importantly, who came up with that horrible name?  It reminds me of a yeast infection every time I read it.

@ercolinux, I understand that 1 second is slower than network latency/propogation, but why would that really be a problem?  Sure, blocks would be orphaned a lot, and forks would dead-end even after several blocks fairly often, but I don't see either of those as a show-stopper.

@markm - I don't know anything about liquidcoin, and, while it sounds like an interesting experiment as well, I likely do not have the hashpower available to push it to its limit.  Thus, I cannot experiment with such an alt in the way you describe.

You seem to have misunderstood my intent.  This is a call for an experiment - nothing more, nothing less.  It would only be a few lines of code changed from the Bitcoin-QT client to actually see this happen.  I would do it myself if it wasn't for the difficulty in compiling Bitcoin for Windows (and I'm not much of a linux user either).

Liquidcoin.

How well have you found liquidcoin to perform for you?

Geistgeld too as already mentioned, however it tries for ten seconds wheread Liquidcoin can be driven as fast as you wish simply by applying more hash-power, so it possibly more useful a testbed for measuring exactly how much faster than ten seconds one can reasonably go.

So, how hoave those two been performing for you? What are your findings so far from your tests with them that lead you to think one second is the sweet spot and in fact demonstrate it so strongly that it can be considered proven thus the next step is to move on to implementing a geistgeld clone adjusted to strive for this one-second sweet-spot in block timing?

How fast have you been running liquidcoin at, exactly? Does effectiveness/efficiency degrade steeply each side of the one second sweet-spot or is the curve not so drastic, making one second more of a general region than a notable peak or trough on various plots of performance and problems?

How much of what you see in Liquidcoin at such speeds is directly attributable to the speed and how much to the lack of difficulty adjustment as speed increases? For example at how many milliseconds does it appear that adding in difficulty adjustment ought to cause the sweet spot to settle at one second?

How long did you run geistgeld testnet in a box at 10 seconds, 9 seconds, 8 seconds, 7 seconds, 6 seconds, 5 seconds, 4 seconds, 3 seconds, 2 seconds, 1 second, half a second, quarter second etc in measuring the sweetness of each such spot?

Have others also tried similar geistgeld testner in a box timing adjustments and arrived as the same sweet spot determination?

If not, heck, do the darn testnet in a box experiments and get back to us with the results!

-MarkM-

Geistgeld 2: The Geistening

It would be definitely more wasteful in the long term.

Wouldn't this be extremely network intensive?

GeistGeld did something similar: http://www.geistgeld.org/about--faq.html

I'm interested in your idea.

What I'm trying to do is publishing instructions which would make it possible for everyone to create their own crypto currency.

If you want to share your skills and know-how, I would be happy to assist in creating instructions for creating the next bitcoin clone... and the next... and the next...

https://bitcointalksearch.org/topic/how-to-clone-bitcoin-to-create-your-own-crypto-currency-crypto-shares-system-114336