QUICKCOIN - 1 block per second!

[SgtSpike]

Ok, so I don't have anything created or compiled or made, but I think it would be extremely interesting to see how a bitcoin-clone with blocks confirming every second would actually work.  Sure, confirmations would get reversed all the time, then rebuilt, then reversed again, but eventually, a transaction would make its way into a generally accepted longest chain.  And, it might take a lot less time than it does to get 1 solid confirmation from Bitcoin.

It's been theorized to be a terrible idea, but is it so terrible in practice?  Let's try it for fun anyway!

[Revalin]

I'm for it.  The orphan rate will be jaw-dropping, and if nothing else that will give us great insight into how the protocol behaves when pushed hard.  I suspect it'd work.

One per second is perhaps too extreme, but it might have an interesting positive effect: pools would be unnecessary for a very long time since anyone could jump in and reasonably expect to strike coins several times a day even on a Bitcoin-scale network.

[ercolinux]

1 second is really to low: latency of the network is in some case comparable to that. But a 30second block can teoretically works.

It can fill the gap that makes bitcoin not so usable in brick and mortar shop: 20 or 30 minutes of wait in bitcoin network to have a couple of confirm of the payment will be too long to wait  but in quickcoin is faster than POS payment in a lot of case.

[sron]

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://bitcointalk.org/index.php?topic=114336.0

[killerstorm]

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

[DeLorean]

Wouldn't this be extremely network intensive?

[killerstorm]

It would be definitely more wasteful in the long term.

[tacotime]

Geistgeld 2: The Geistening

[markm]

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-

[SgtSpike]

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).

[markm]

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-

[SgtSpike]

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-

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.

[bitpop]

Cool

[markm]

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.

[killerstorm]

By the way:

P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target.

[pyra-proxy]

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

[markm]

By the way:

P2Pool creates a new block chain in which the difficulty is adjusted so a new block is found every 10 seconds. The blocks that get into the P2Pool block chain (called the "share chain") are the same blocks that would get into the Bitcoin block chain, only they have a lower difficulty target.

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-

[gmaxwell]

Ok, so I don't have anything created or compiled or made, but I think it would be extremely interesting to see how a bitcoin-clone with blocks confirming every second would actually work.  Sure, confirmations would get reversed all the time, then rebuilt, then reversed again, but eventually, a transaction would make its way into a generally accepted longest chain. 

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!

[SgtSpike]

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

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.

Ok, so I don't have anything created or compiled or made, but I think it would be extremely interesting to see how a bitcoin-clone with blocks confirming every second would actually work.  Sure, confirmations would get reversed all the time, then rebuilt, then reversed again, but eventually, a transaction would make its way into a generally accepted longest chain. 

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!

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

[pyra-proxy]

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?

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!