Pages:
Author

Topic: Solidcoin's design choices (Read 2709 times)

legendary
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
August 22, 2011, 03:07:37 PM
#25
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.

The bitcoin changes must be tested somewhere too
The people of multicoin also has test networks and they change parameters.
There's no need to trade the new currency for bitcoins for testing it.


Yet people have been trading them for the past two weeks now.  Grin

Somehow I keep ending up with those bitcoins at the end of the day.
hero member
Activity: 938
Merit: 1002
August 22, 2011, 03:02:59 PM
#24
There's no need to trade the new currency for bitcoins for testing it.
I was going to write something like that as a reply to doublec. Well, I can't claim to know that there is no need, but creating a new currency to test features may not be so optimal. For starters, you need a few years for the currency to mature and come to a level of ATMs, banks, snack machines and whatnot to actually say if it scales or not. Of course it will never come to that, and we'll still need to build models and make predictions about the system's scalability and act on them. Now, if you already have made these simulations, and came to a conclusion that it is plausible, but there is no way to know other than testing it in real life, then I'd say go for it.

Not to say that there is nothing useful we can learn from this endeavour of course... Smiley
legendary
Activity: 1372
Merit: 1002
August 22, 2011, 02:15:53 PM
#23
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.


Just because someone posts something on a forum doesn't necessarily make it true.... (ironic eh Smiley )

Found it.
Tell me what you think.
legendary
Activity: 1372
Merit: 1002
August 22, 2011, 02:00:34 PM
#22
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.

The bitcoin changes must be tested somewhere too
The people of multicoin also has test networks and they change parameters.
There's no need to trade the new currency for bitcoins for testing it.
sr. member
Activity: 252
Merit: 251
August 22, 2011, 09:54:22 AM
#21
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.


Just because someone posts something on a forum doesn't necessarily make it true.... (ironic eh Smiley )

Firstly to understand how long a block takes to propagate you have to look at
A) The size of the block
B) The nodes capacity sending and receiving
C) The size of the network


In bitcoin (A) is an average of about 25KB right now. B) is quite unknown but if you consider the prevalence of broadband around the world and the minimum connection having at least a 16+KB/sec up and 32KB/sec down speed, which is a fairly conservative estimate. The size of the network, going by my rough estimations is around 3000-5000 nodes or so. Now when a miner sends out a winning block how long would it take given all these factors? Seconds.

If people on dialup need 5 minutes to receive a block then they shouldn't be running a full node in my opinion. They have alternatives, such as ewallets. Also with something like SolidCoin in the future which will have a method for so called "thin clients" to be able to confirm transactions without needing all blocks.

Should everyone be allowed to run a full node? Sure, if they can. Should the network cater to the lowest common denominator? In my opinion no. Like I said, people get stuck thinking about todays problems and not realizing where that path is actually taking them. You need a clear path to your destination if you want to succeed, so firstly you need to know where you want to go. Is your path 90 minute single confirmations?
member
Activity: 61
Merit: 10
August 22, 2011, 09:45:22 AM
#20
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.
legendary
Activity: 1372
Merit: 1002
August 22, 2011, 08:00:13 AM
#19
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.
legendary
Activity: 1078
Merit: 1005
August 22, 2011, 07:48:53 AM
#18
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.
legendary
Activity: 1372
Merit: 1002
August 22, 2011, 07:19:25 AM
#17
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?
sr. member
Activity: 252
Merit: 251
August 22, 2011, 04:56:21 AM
#16
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.
member
Activity: 61
Merit: 10
August 22, 2011, 02:50:40 AM
#15
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.
hero member
Activity: 742
Merit: 500
August 22, 2011, 12:49:37 AM
#14
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"
member
Activity: 61
Merit: 10
August 22, 2011, 12:38:08 AM
#13
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.
hero member
Activity: 742
Merit: 500
August 22, 2011, 12:23:48 AM
#12
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.
full member
Activity: 126
Merit: 100
August 22, 2011, 12:16:39 AM
#11
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.
member
Activity: 61
Merit: 10
August 22, 2011, 12:12:42 AM
#10
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?
hero member
Activity: 742
Merit: 500
August 21, 2011, 11:17:51 PM
#9
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.
legendary
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
August 21, 2011, 10:17:21 PM
#8
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.
hero member
Activity: 938
Merit: 1002
August 21, 2011, 09:16:45 PM
#7
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.
full member
Activity: 154
Merit: 100
August 21, 2011, 09:00:57 PM
#6
It's just a matter of time before the PerfectCoin solves all the flaws of the venerable Bitcoin. Smiley
Pages:
Jump to: