Topic: Solidcoin's design choices - page 2. (Read 2709 times)
I would say of all the forks so far I like this one the best, because I felt the confirmation time/difficulty changes is the biggest weakness of bitcoin, so will be interesting to see what problems might arise. I do like how these forks allow us to test "what if" scenarios...
one thing you can say for sure about these alternative bitcoins, is that they DO provide valuable data and a valuable learning experience for the future coins.
Yeah they may be jokes, get rich quick schemes, or just gambling apps, but they still provide some unique incite into the whole idea of crypto-currencies.
Yeah they may be jokes, get rich quick schemes, or just gambling apps, but they still provide some unique incite into the whole idea of crypto-currencies.
+1 It's like trying different flavors of ice cream. Bring on more flavors!
one thing you can say for sure about these alternative bitcoins, is that they DO provide valuable data and a valuable learning experience for the future coins.
Yeah they may be jokes, get rich quick schemes, or just gambling apps, but they still provide some unique incite into the whole idea of crypto-currencies.
Yeah they may be jokes, get rich quick schemes, or just gambling apps, but they still provide some unique incite into the whole idea of crypto-currencies.
I actually just wrote the exact same thing in the main thread but I'll repeat it here.
If we learned anything from the I0Coin startup (which was quite the fiasco) it's that faster block generation drastically increases the likelihood that two or more miners will find conflicting block solutions and that one or more of them will be orphaned. I haven't done any real tests just yet, but it's my suspicion that faster block generation times will be directly proportional to the number of orphaned blocks. This makes sense considering that block generation is the only time when a block can become orphaned and SC's ~3.3x faster block generation speeds mean that transactions are subjected to the possibility of being orphaned ~3.3x as often.
I plan on testing this thoroughly but it will take some time. First I have to mine a reasonable number of testnet coins on both networks, then I'll bash out a script that sends one tiny transaction on each network ever 15 minutes or so and let it run for... well... quite a long time to gather enough data to be statistically meaningful. It's basically a monte carlo simulation that I'm forced to run in realtime. If anyone has a better way, do let me know.
Edit: It suddenly occurs to me that certain people or companies already HAVE wallets with thousands or millions of transactions in them. If MagicalTux, for example, could do a "bitcoind listtransactions" it would be a trivial matter to go through the JSON and count the number of orphans vs the number of total transactions and it would save me a lot of time and effort on the BTC side. It would also answer one of my two questions quite quickly and I can fill in the rest with SC testing. We could also combine the counts of a large number of people. For SC tests, perhaps DoubleC could do the same with the SC exchange's wallet after a while?
After I've gathered several thousand data points I'll come back and post my results. This should also be useful for merchants since it'll finally answer the question "how often will a 0/unconfirmed transaction actually be orphaned" and we can finally decide if that number is lower than the percent of credit card transactions merchants expect to see reversed. I've long suspected that it is, but without data that's just my optimism speaking.
If we learned anything from the I0Coin startup (which was quite the fiasco) it's that faster block generation drastically increases the likelihood that two or more miners will find conflicting block solutions and that one or more of them will be orphaned. I haven't done any real tests just yet, but it's my suspicion that faster block generation times will be directly proportional to the number of orphaned blocks. This makes sense considering that block generation is the only time when a block can become orphaned and SC's ~3.3x faster block generation speeds mean that transactions are subjected to the possibility of being orphaned ~3.3x as often.
I plan on testing this thoroughly but it will take some time. First I have to mine a reasonable number of testnet coins on both networks, then I'll bash out a script that sends one tiny transaction on each network ever 15 minutes or so and let it run for... well... quite a long time to gather enough data to be statistically meaningful. It's basically a monte carlo simulation that I'm forced to run in realtime. If anyone has a better way, do let me know.
Edit: It suddenly occurs to me that certain people or companies already HAVE wallets with thousands or millions of transactions in them. If MagicalTux, for example, could do a "bitcoind listtransactions" it would be a trivial matter to go through the JSON and count the number of orphans vs the number of total transactions and it would save me a lot of time and effort on the BTC side. It would also answer one of my two questions quite quickly and I can fill in the rest with SC testing. We could also combine the counts of a large number of people. For SC tests, perhaps DoubleC could do the same with the SC exchange's wallet after a while?
After I've gathered several thousand data points I'll come back and post my results. This should also be useful for merchants since it'll finally answer the question "how often will a 0/unconfirmed transaction actually be orphaned" and we can finally decide if that number is lower than the percent of credit card transactions merchants expect to see reversed. I've long suspected that it is, but without data that's just my optimism speaking.
Made a new thread because there's too much noise in the announcement thread.
I've heard that increasing the block generation and retarget rates would produce blockchain forks too often because of latency problems. Don't you think this will be an issue with blocks every 3 minutes and retargets every 240 blocks or is the problem being exaggerated?
Also, assuming that the max capacity of blocks remains 1 mb, is there any worry that the blockchain could grow too big too fast from spam attacks?
I've heard that increasing the block generation and retarget rates would produce blockchain forks too often because of latency problems. Don't you think this will be an issue with blocks every 3 minutes and retargets every 240 blocks or is the problem being exaggerated?
Also, assuming that the max capacity of blocks remains 1 mb, is there any worry that the blockchain could grow too big too fast from spam attacks?
Jump to: