Solidcoin's design choices

[JohnDoe]

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?

[1713558911]

1713558911

[1713558911]

1713558911

[1713558911]

1713558911

[1713558911]

1713558911

[1713558911]

1713558911

[enmaku]

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.

[joulesbeef]

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.

[smoothie]

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.

+1 It's like trying different flavors of ice cream. Bring on more flavors!

[bansal]

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

[huayra.agera]

It's just a matter of time before the PerfectCoin solves all the flaws of the venerable Bitcoin.

[memvola]

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

Well, for using in snack machines, block chain / miner approach will never be fast enough. So I don't think any bitcoin fork will fix this weakness. On the other hand, conventional instant or near-instant payment methods (cards, SMS, bills, etc.) do solve it and as a plus, keep the block chain much much smaller. Now, 10 minutes is, I think, pretty optimal. Retargets every two weeks? Maybe it would be better if it was shorter, but we don't need a fork to fix this.

[smoothie]

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

Well, for using in snack machines, block chain / miner approach will never be fast enough. So I don't think any bitcoin fork will fix this weakness. On the other hand, conventional instant or near-instant payment methods (cards, SMS, bills, etc.) do solve it and as a plus, keep the block chain much much smaller. Now, 10 minutes is, I think, pretty optimal. Retargets every two weeks? Maybe it would be better if it was shorter, but we don't need a fork to fix this.

We do need a fork to test it though. Changes need testing.

[enmaku]

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

The true "confirmation time" is NOT changeable. 6 confirmations was not arbitrarily chosen, it was chosen because it represents about an hour of the entire network crunching away at blocks after the initial transaction. For the same level of security you need the same amount of TIME regardless of how fast the blocks are solved within that time. Faster blocks simply increase the chance of orphans. If you need faster transactions than the hour required for 6 confirmations, just accept transactions at 1/unconfirmed or 0/unconfirmed - it's EXACTLY the same as speeding up the block times since TIME equals security, regardless of the number of blocks generated in that time.

Think of it this way - if I have a team of elite soldiers who are about to blow up an enemy installation and they need to be 2 miles away to be safe, it doesn't matter if they drive that 2 miles at 10 MPH or 60 MPH, they STILL won't be safe until they're 2 miles away. If they drive super fast for too little time and they're only 1 mile away they're still dead - it's the miles that count not the speed. Making confirmations take 3 minutes instead of 10 and still accepting transactions at 6 confirmations is like driving 60 instead of 10 but only driving 0.6 miles away before setting off the charge - you need at least 20 confirmations at 3 minutes each to meet the same security requirements as the original 6 at 10 minutes each.

Faster block times without longer confirmation requirements equals LESS security. That might be perfectly acceptable to a lot of people, and so it's still a valid change for the fork, but it needs to be duly noted that a SolidCoin transaction is NOT as secure as a bitcoin transaction until it has 20 confirmations.

[bansal]

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

The true "confirmation time" is NOT changeable. 6 confirmations was not arbitrarily chosen, it was chosen because it represents about an hour of the entire network crunching away at blocks after the initial transaction. For the same level of security you need the same amount of TIME regardless of how fast the blocks are solved within that time. Faster blocks simply increase the chance of orphans. If you need faster transactions than the hour required for 6 confirmations, just accept transactions at 1/unconfirmed or 0/unconfirmed - it's EXACTLY the same as speeding up the block times since TIME equals security, regardless of the number of blocks generated in that time.

Think of it this way - if I have a team of elite soldiers who are about to blow up an enemy installation and they need to be 2 miles away to be safe, it doesn't matter if they drive that 2 miles at 10 MPH or 60 MPH, they STILL won't be safe until they're 2 miles away. If they drive super fast for too little time and they're only 1 mile away they're still dead - it's the miles that count not the speed. Making confirmations take 3 minutes instead of 10 and still accepting transactions at 6 confirmations is like driving 60 instead of 10 but only driving 0.6 miles away before setting off the charge - you need at least 20 confirmations at 3 minutes each to meet the same security requirements as the original 6 at 10 minutes each.

Faster block times without longer confirmation requirements equals LESS security. That might be perfectly acceptable to a lot of people, and so it's still a valid change for the fork, but it needs to be duly noted that a SolidCoin transaction is NOT as secure as a bitcoin transaction until it has 20 confirmations.

Why does it need to be an hour of network computing time?  I can understand the issue of a single confirmation being orphaned, but what are the odds of a transaction being invalid after it has been confirmed in 6 consecutive blocks that make it into the block chain?

I have a business and mostly sell over the internet (I am working on integrating bitcoins).  Since I can wait an hour for an internet transaction this isn't a problem, but what if someone were to walk in my office and buy $1000 worth of stuff (pretty typical for the items I sell), am I supposed to wait an hour before letting the customer walk out the door, if I want to be absolutely sure I'm going to get paid, which I would want to be at that dollar amount?

[gw4tt]

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

The true "confirmation time" is NOT changeable. 6 confirmations was not arbitrarily chosen, it was chosen because it represents about an hour of the entire network crunching away at blocks after the initial transaction. For the same level of security you need the same amount of TIME regardless of how fast the blocks are solved within that time. Faster blocks simply increase the chance of orphans. If you need faster transactions than the hour required for 6 confirmations, just accept transactions at 1/unconfirmed or 0/unconfirmed - it's EXACTLY the same as speeding up the block times since TIME equals security, regardless of the number of blocks generated in that time.

Think of it this way - if I have a team of elite soldiers who are about to blow up an enemy installation and they need to be 2 miles away to be safe, it doesn't matter if they drive that 2 miles at 10 MPH or 60 MPH, they STILL won't be safe until they're 2 miles away. If they drive super fast for too little time and they're only 1 mile away they're still dead - it's the miles that count not the speed. Making confirmations take 3 minutes instead of 10 and still accepting transactions at 6 confirmations is like driving 60 instead of 10 but only driving 0.6 miles away before setting off the charge - you need at least 20 confirmations at 3 minutes each to meet the same security requirements as the original 6 at 10 minutes each.

Faster block times without longer confirmation requirements equals LESS security. That might be perfectly acceptable to a lot of people, and so it's still a valid change for the fork, but it needs to be duly noted that a SolidCoin transaction is NOT as secure as a bitcoin transaction until it has 20 confirmations.

Why does it need to be an hour of network computing time?  I can understand the issue of a single confirmation being orphaned, but what are the odds of a transaction being invalid after it has been confirmed in 6 consecutive blocks that make it into the block chain?

I have a business and mostly sell over the internet (I am working on integrating bitcoins).  Since I can wait an hour for an internet transaction this isn't a problem, but what if someone were to walk in my office and buy $1000 worth of stuff (pretty typical for the items I sell), am I supposed to wait an hour before letting the customer walk out the door, if I want to be absolutely sure I'm going to get paid, which I would want to be at that dollar amount?

Bitcoin banks or transfer services will make bitcoin transfers instant.

[enmaku]

Why does it need to be an hour of network computing time?  I can understand the issue of a single confirmation being orphaned, but what are the odds of a transaction being invalid after it has been confirmed in 6 consecutive blocks that make it into the block chain?

I have a business and mostly sell over the internet (I am working on integrating bitcoins).  Since I can wait an hour for an internet transaction this isn't a problem, but what if someone were to walk in my office and buy $1000 worth of stuff (pretty typical for the items I sell), am I supposed to wait an hour before letting the customer walk out the door, if I want to be absolutely sure I'm going to get paid, which I would want to be at that dollar amount?

OK, to be a little clearer, 6 confirmations was not an arbitrarily chosen value, but an hour was. Any amount of confirmations (even zero) can be acceptable, depending on the level of risk you're willing to accept. As an example, let me share a personal experience: I was part of the i0coin launch, and was solo mining when difficulty was still something like 16. I found something like six blocks back-to-back and within two minutes every last one of them was orphaned. This is sort of an exaggerated example, the real problem being that i0coin was being so heavily mined at such low difficulty that the whole network was claiming and arguing over blocks several times per second, but the thing to take away was that in the two minutes or so those transactions were valid for, they gathered 20 or 30 confirmations and then still got orphaned. The number of confirmations is meaningless to the chances of rejection, the amount of time, among other factors, is far more important.

For in-person transactions you have little choice but to accept a transaction at 0/unconfirmed or perhaps 1/unconfirmed if your customer is patient enough. It is worthwhile to note that, while I have no data to back this up, I suspect that the number of transactions seen at 0/unconfirmed that become orphaned is SUBSTANTIALLY less than the number of transactions you would expect to see reversed in traditional credit card processing. I hope to have data to back up that claim soon.

[bansal]

Why does it need to be an hour of network computing time?  I can understand the issue of a single confirmation being orphaned, but what are the odds of a transaction being invalid after it has been confirmed in 6 consecutive blocks that make it into the block chain?

I have a business and mostly sell over the internet (I am working on integrating bitcoins).  Since I can wait an hour for an internet transaction this isn't a problem, but what if someone were to walk in my office and buy $1000 worth of stuff (pretty typical for the items I sell), am I supposed to wait an hour before letting the customer walk out the door, if I want to be absolutely sure I'm going to get paid, which I would want to be at that dollar amount?

OK, to be a little clearer, 6 confirmations was not an arbitrarily chosen value, but an hour was. Any amount of confirmations (even zero) can be acceptable, depending on the level of risk you're willing to accept. As an example, let me share a personal experience: I was part of the i0coin launch, and was solo mining when difficulty was still something like 16. I found something like six blocks back-to-back and within two minutes every last one of them was orphaned. This is sort of an exaggerated example, the real problem being that i0coin was being so heavily mined at such low difficulty that the whole network was claiming and arguing over blocks several times per second, but the thing to take away was that in the two minutes or so those transactions were valid for, they gathered 20 or 30 confirmations and then still got orphaned. The number of confirmations is meaningless to the chances of rejection, the amount of time, among other factors, is far more important.

For in-person transactions you have little choice but to accept a transaction at 0/unconfirmed or perhaps 1/unconfirmed if your customer is patient enough. It is worthwhile to note that, while I have no data to back this up, I suspect that the number of transactions seen at 0/unconfirmed that become orphaned is SUBSTANTIALLY less than the number of transactions you would expect to see reversed in traditional credit card processing. I hope to have data to back up that claim soon.

With credit cards you know you will get paid.  Once a transaction is authorized the funds are held on the customer's credit card and they can't spend it for a certain number of days (varies depending on the bank that issued the card) until the authorization drops off, and once you capture the transaction the funds will be transferred to you.  The big issue with credit cards is chargebacks due to stolen card numbers.  If you accept credit cards over the internet you have to be constantly vigilant about this, I get several attempts a month.  I have become an expert in spotting fraudulent transactions, but I do get burned occasionally.  Contrary to popular belief it is the merchant who gets burned when a stolen card is used, Visa, Mastercard, etc. don't pay a dime.  They simply take the money out of your account and give it back to the person whose card was stolen, and they even charge you a $20 chargeback fee on top of that (varies), even though this wasn't your fault at all.  This is why I love the concept of bitcoins, and it is perfect for transacting over the internet.  But it needs to be made clear what the risks are for accepting these in person.

Also I think you are confused, you solved 20-30 blocks in a row and them orphaned, this is not the same as receiving 6 confirmations on a transaction.  Your orphaned blocks were each at the tip of the block chain, not part of consecutive confirmations, someone can correct me if I'm misunderstanding something.

[enmaku]

Also I think you are confused, you solved 20-30 blocks in a row and them orphaned, this is not the same as receiving 6 confirmations on a transaction.  Your orphaned blocks were each at the tip of the block chain, not part of consecutive confirmations, someone can correct me if I'm misunderstanding something.

It's a terminology thing. Transactions aren't orphaned, whole blocks are and the blocks contain the transactions. My particular blocks only contained the "generated" transactions which were my reward for mining them, but they just as easily could have contained actual transactions which would have been orphaned along with the block that contained them.

Edit: Oh and for the record, your 0/unconfirmed transactions are also "at the tip of the block chain"

[bansal]

Also I think you are confused, you solved 20-30 blocks in a row and them orphaned, this is not the same as receiving 6 confirmations on a transaction.  Your orphaned blocks were each at the tip of the block chain, not part of consecutive confirmations, someone can correct me if I'm misunderstanding something.

It's a terminology thing. Transactions aren't orphaned, whole blocks are and the blocks contain the transactions. My particular blocks only contained the "generated" transactions which were my reward for mining them, but they just as easily could have contained actual transactions which would have been orphaned along with the block that contained them.

Edit: Oh and for the record, your 0/unconfirmed transactions are also "at the tip of the block chain"

Yes of course 0/unconfirmed would be at the tip.  Ok let's look at this a different way, let's say you had two computers with identical wallets with x BTC in them, and you send all x of those BTC to two different addresses from each wallet.  There is a chance that they would each receive 1 confirmation from different nodes, but what happens at the second confirmation?  At this point both blocks will compete to to try to be the longest and make onto the block chain.  So either one will have a second block build on top of it (i.e. second confirmation) while the other won't and will be orphaned.  The orphaned transaction will be invalid.  Now there is a chance that both of those initial blocks could at the same time receive a second block and then still be of equal length, but is not very likely, and becomes increasingly unlikely as time goes on and more blocks are added.  The number of transactions that have been confirmed on the longest block is important, not how long it took to up with a confirmed 6 extra blocks on the chain.  6 is a fairly arbitrary number for this, and I think you could even be reasonably confident after just two in most cases.  This risks would be higher at lower difficulties when it is easier to solve blocks, and get progressively lower with higher difficulty.

[CoinHunter]

I've heard that increasing the block generation and retarget rates would produce blockchain forks too often because of latency problems.

No it won't.

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?

It's being exaggerated. For instance ixcoin/i0coin and now SolidCoin all prove the p2p protocol works fine with blocks going by in the second(s) range. Now second(s) range isn't ideal, especially as transactions grow, however it shows that "block speed" being 10 minutes is mostly some magic number satoshi used which ended up not being the most optimal. Yes a few miners will get some orphans, a little percentage more than BTC, but that is fine, they are trying to win something. No one said that was going to be easy.

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?

A block every 3 minutes means less transactions per block on average given the same transaction load. When we start getting to the 1MB block limit we will need to redesign the network such that people (likely miners) will get paid more for processing transactions at great speeds. ie Unless you have a gigabit connection to the internet you won't be mining. I can go into this topic at another stage when I have more time.

A lot of people have this issue where they think about "current problems" too much and how something is running fine under the "current problems". I'm sorry to say that Bitcoin as it is will not survive if it becomes too much more successful, the network is going to clog and as we have seen recently with some BTC blocks taking upwards of 90 minutes, no business is going to want to rely on something which is so unstable.

Yes BTC was first, yes it has a lot more users, yes it's hard to get people to change. But whether SolidCoin surpasses it, or Bitcoin adopts some similar changes, is irrelevant, because in the end the user will win with a better network and more reliable cryptobanking.

[jtimon]

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?

It's being exaggerated. For instance ixcoin/i0coin and now SolidCoin all prove the p2p protocol works fine with blocks going by in the second(s) range. Now second(s) range isn't ideal, especially as transactions grow, however it shows that "block speed" being 10 minutes is mostly some magic number satoshi used which ended up not being the most optimal. Yes a few miners will get some orphans, a little percentage more than BTC, but that is fine, they are trying to win something. No one said that was going to be easy.
ause in the end the user will win with a better network and more reliable cryptobanking.

3 minutes is probably not scalable. When the network becomes bigger many more blocks will become orphan and, worse, many more forks will appear. 10 minutes is the time for the new block to reach the whole network. Maybe it can be lowered a bit, but not as much as 7 minutes less. And for POS payments you will have to wait the same. If you waited for 3 blocks of "10 minutes difficulty" you'll have to wait for 6 blocks of "5 minutes difficulty".
1 confirmation with 5 min blocks is more easily reversible.

And again, why not use merged mining?
Why compete against bitcoin for computing power?

[doublec]

3 minutes is probably not scalable. When the network becomes bigger many more blocks will become orphan and, worse, many more forks will appear. 10 minutes is the time for the new block to reach the whole network. Maybe it can be lowered a bit, but not as much as 7 minutes less.

How do you know this? Do you have data to support the claim? These alternative chains like SolidCoin are trying these ideas giving everyone the opportunity to gather that data. At some point someone can examine the success or failure and see what the effect the changes have.

[jtimon]

3 minutes is probably not scalable. When the network becomes bigger many more blocks will become orphan and, worse, many more forks will appear. 10 minutes is the time for the new block to reach the whole network. Maybe it can be lowered a bit, but not as much as 7 minutes less.

How do you know this? Do you have data to support the claim? These alternative chains like SolidCoin are trying these ideas giving everyone the opportunity to gather that data. At some point someone can examine the success or failure and see what the effect the changes have.

I've read it somewhere in the forum. I think people try these things in testnet to arrive to those conclusions.
And it's a fact that the shorter that constant the more forks/races will be. If there's orphan blocks with the current bitcoin protocol, it must (with the same size of the network) be more forks if that constant is smaller.
I don't know where it is, but I know that because I really wanted to know the reason for the 10 minutes.
And of course, reducing the 10 minutes does nothing for POS payments.

[bansal]

3 minutes is probably not scalable. When the network becomes bigger many more blocks will become orphan and, worse, many more forks will appear. 10 minutes is the time for the new block to reach the whole network. Maybe it can be lowered a bit, but not as much as 7 minutes less.

How do you know this? Do you have data to support the claim? These alternative chains like SolidCoin are trying these ideas giving everyone the opportunity to gather that data. At some point someone can examine the success or failure and see what the effect the changes have.

I've read it somewhere in the forum. I think people try these things in testnet to arrive to those conclusions.

Testnet is is used to generate some coins on an alternate block chain so that you can test your applications to see if they work without risking real bitcoins, it doesn't change any of the rules that govern bitcoin.