Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained] - page 135. (Read 1369778 times)
June 30, 2015, 05:27:55 PM
Also before we do fork, can we also look into possible ways to reduce the chance on a standard 51% attack? I get that we are already greatly reducing it by this update. But by making something harder it does not make it unpossible. When this coin does go big, and it will get adopted more and more it will only be harder to force a fork.
June 30, 2015, 04:00:43 PM
Yes I define hashdrift as the amount of timestamps it searches from the current timestamp. So 60 timestamps, I mean a hashdrift of 40.
Also in this conversation I don't know if I mentioned that your client actually automatically adjusts your time to be in sync with the network, well in sync with the median time of your peer pool. So even some out of time synced peers will be perfectly capable of producing accepted stakes. But this adjustedtime, as the code calls is, is also dependent on the size of your peer pool, the more peers the more accurate it should be.
Okay. Do you see any reason why 18 would not work just fine then? See my example above. Also in this conversation I don't know if I mentioned that your client actually automatically adjusts your time to be in sync with the network, well in sync with the median time of your peer pool. So even some out of time synced peers will be perfectly capable of producing accepted stakes. But this adjustedtime, as the code calls is, is also dependent on the size of your peer pool, the more peers the more accurate it should be.
June 30, 2015, 03:54:39 PM
Yes I define hashdrift as the amount of timestamps it searches from the current timestamp. So 60 timestamps, I mean a hashdrift of 40.
Also in this conversation I don't know if I mentioned that your client actually automatically adjusts your time to be in sync with the network, well in sync with the median time of your peer pool. So even some out of time synced peers will be perfectly capable of producing accepted stakes. But this adjustedtime, as the code calls is, is also dependent on the size of your peer pool, the more peers the more accurate it should be.
Also in this conversation I don't know if I mentioned that your client actually automatically adjusts your time to be in sync with the network, well in sync with the median time of your peer pool. So even some out of time synced peers will be perfectly capable of producing accepted stakes. But this adjustedtime, as the code calls is, is also dependent on the size of your peer pool, the more peers the more accurate it should be.
June 30, 2015, 03:00:55 PM
The way I see it, we need to drop the hashdrift to about 18 seconds, and then put the timedrift at about 10 seconds more (to ensure no increase in orphans). This would put the timedrift at 28 seconds which is just under the 30 second block target. So this way, it would ensure that even if you attempt a timewarp attack you cannot lower the difficulty.
What do you think?
What do you think?
June 30, 2015, 02:24:41 PM
That is why I suggested 66 seconds for the timedrift. 6 seconds (10%) extra time above the hashdrift. A small grace period for any lag (not sure how necessary, but I think most timedrifts are a bit longer than the hashdrifts right?)
Are there any negatives to reducing the "hashdrift"?
Not necessarily bad. You just arent searching as large of a group of timestamps at a time.
What are benefits of searching a large group of timestamps at a time? How much would a 20 second drop affect it?
It is supposed to be setup to only search those 60 timestamps and then only search 1 more each second. I have found that it seems to use way too much CPU to do this. I redesigned the kernel for HYP to have two parameter (which are now directly editable by the user via RPC call) hashdrift and hash interval. hashdrift has already been explained and hash interval is the period of time that the client will wait between hashing bursts. So instead of going through the loop every second only to interate one second at a time, I found that hashing 60 seconds at a time, and waiting 30 seconds until you hash another 60 hashes (50% redundancy with that setting) is much better on CPU. Most of the time it sits at 0.3% CPU, when hashing for a fraction of a second it might jump up to 7-10%.
If my reading of the code is correct, leaving mint at the standard kernel that it uses now will not have an impact on cpu, even if changing timedrift and hashdrift.
Are you saying that if we reduce hashdrift to 40 it will search 40 time stamps, initially over 40 seconds, and then continue to search 1 per second?
June 30, 2015, 02:03:43 PM
That is why I suggested 66 seconds for the timedrift. 6 seconds (10%) extra time above the hashdrift. A small grace period for any lag (not sure how necessary, but I think most timedrifts are a bit longer than the hashdrifts right?)
Are there any negatives to reducing the "hashdrift"?
Not necessarily bad. You just arent searching as large of a group of timestamps at a time.
What are benefits of searching a large group of timestamps at a time? How much would a 20 second drop affect it?
It is supposed to be setup to only search those 60 timestamps and then only search 1 more each second. I have found that it seems to use way too much CPU to do this. I redesigned the kernel for HYP to have two parameter (which are now directly editable by the user via RPC call) hashdrift and hash interval. hashdrift has already been explained and hash interval is the period of time that the client will wait between hashing bursts. So instead of going through the loop every second only to interate one second at a time, I found that hashing 60 seconds at a time, and waiting 30 seconds until you hash another 60 hashes (50% redundancy with that setting) is much better on CPU. Most of the time it sits at 0.3% CPU, when hashing for a fraction of a second it might jump up to 7-10%.
If my reading of the code is correct, leaving mint at the standard kernel that it uses now will not have an impact on cpu, even if changing timedrift and hashdrift.
June 30, 2015, 01:50:29 PM
That is why I suggested 66 seconds for the timedrift. 6 seconds (10%) extra time above the hashdrift. A small grace period for any lag (not sure how necessary, but I think most timedrifts are a bit longer than the hashdrifts right?)
Are there any negatives to reducing the "hashdrift"?
Not necessarily bad. You just arent searching as large of a group of timestamps at a time.
What are benefits of searching a large group of timestamps at a time? How much would a 20 second drop affect it?
June 30, 2015, 01:37:01 PM
That is why I suggested 66 seconds for the timedrift. 6 seconds (10%) extra time above the hashdrift. A small grace period for any lag (not sure how necessary, but I think most timedrifts are a bit longer than the hashdrifts right?)
Are there any negatives to reducing the "hashdrift"?
Not necessarily bad. You just arent searching as large of a group of timestamps at a time.
June 30, 2015, 12:12:22 PM
Network weight will mean higher difficulty, and higher difficulty means it will be harder to get it into this type of spiral to begin with.
120 minutes = 7200 possible hashes to try and find a stake (although you could target only the say highest 5000 timestamps)
6 minutes = 360 possible hashes
3 minutes = 180
6 minutes reduces the possibilities by a large amount, but narrowing down to 3 minutes still cuts those chances in half. Is 3 minutes too large? It could be.. MINT's 30 second block time doesnt exactly help in this scenario (I recommended to cryptomommy to also put block time up for vote, but I had longevity of chain syncing in mind not this particular issue). The small block time makes it easier to over shoot. For HyperStake I have used a 60 second time. The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.
The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.120 minutes = 7200 possible hashes to try and find a stake (although you could target only the say highest 5000 timestamps)
6 minutes = 360 possible hashes
3 minutes = 180
6 minutes reduces the possibilities by a large amount, but narrowing down to 3 minutes still cuts those chances in half. Is 3 minutes too large? It could be.. MINT's 30 second block time doesnt exactly help in this scenario (I recommended to cryptomommy to also put block time up for vote, but I had longevity of chain syncing in mind not this particular issue). The small block time makes it easier to over shoot. For HyperStake I have used a 60 second time. The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.
Because of this...It sounds to me, we need to have the timeshift at or above 60 seconds in order to prevent a spike in orphans. My concern is could 45 seconds be too low? What about a 66 second timeshift? That would be 1.1 minutes; which is still even more conservative than the 1.5 minutes presstab recommended. My thinking is, going just over 60 seconds, would eliminate any issue with the default implementation of stake hashing going to 60 seconds.
Thoughts?
At anyrate, if we do a fork, we need to give plenty of time for people to upgrade wallets, before the fork block comes. All exchanges and such need to be on board.
As for sync times, is there any reason we can't do a genesis block from a year ago or so that would reduce the blockchain? Just another thing to think about, if we are going to need to fork it, we might as well keep them to as few as possible.
Yes you are exactly right.
If you go 45 second drift you would want to lower the what I call the hashdrift (how far into the future you hash) to preferably lower than 45 seconds, maybe 30-35 seconds. Or you could leave it as is at 60 seconds, and change timedrift allowance to 75-90 seconds, or whatever you all decide is correct (I am just here to help you all understand the details, not here to tell you what to do).
That is why I suggested 66 seconds for the timedrift. 6 seconds (10%) extra time above the hashdrift. A small grace period for any lag (not sure how necessary, but I think most timedrifts are a bit longer than the hashdrifts right?)
Are there any negatives to reducing the "hashdrift"?
June 30, 2015, 11:38:30 AM
Okay. I think I am for it. Sounds like even at 45 seconds it would't increase orphans by much though. Still should be plenty of time. Still will be a big improvement.
It is my opinion that the root cause of orphans in PoS coins is the rules that calculate chain trust. If you create a proofhash and it has a timestamp 45 seconds into the future, and then someone else creates a proofhash that is 5 seconds less than yours their block will orphan yours. The chaintrust yields to highest difficulty up to 6 blocks downstream (if I recall correctly). If timedrift changes are implemented correctly, there should be no increase or decrease in orphan count.
June 30, 2015, 11:35:01 AM
Network weight will mean higher difficulty, and higher difficulty means it will be harder to get it into this type of spiral to begin with.
120 minutes = 7200 possible hashes to try and find a stake (although you could target only the say highest 5000 timestamps)
6 minutes = 360 possible hashes
3 minutes = 180
6 minutes reduces the possibilities by a large amount, but narrowing down to 3 minutes still cuts those chances in half. Is 3 minutes too large? It could be.. MINT's 30 second block time doesnt exactly help in this scenario (I recommended to cryptomommy to also put block time up for vote, but I had longevity of chain syncing in mind not this particular issue). The small block time makes it easier to over shoot. For HyperStake I have used a 60 second time. The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.
The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.120 minutes = 7200 possible hashes to try and find a stake (although you could target only the say highest 5000 timestamps)
6 minutes = 360 possible hashes
3 minutes = 180
6 minutes reduces the possibilities by a large amount, but narrowing down to 3 minutes still cuts those chances in half. Is 3 minutes too large? It could be.. MINT's 30 second block time doesnt exactly help in this scenario (I recommended to cryptomommy to also put block time up for vote, but I had longevity of chain syncing in mind not this particular issue). The small block time makes it easier to over shoot. For HyperStake I have used a 60 second time. The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.
Because of this...It sounds to me, we need to have the timeshift at or above 60 seconds in order to prevent a spike in orphans. My concern is could 45 seconds be too low? What about a 66 second timeshift? That would be 1.1 minutes; which is still even more conservative than the 1.5 minutes presstab recommended. My thinking is, going just over 60 seconds, would eliminate any issue with the default implementation of stake hashing going to 60 seconds.
Thoughts?
At anyrate, if we do a fork, we need to give plenty of time for people to upgrade wallets, before the fork block comes. All exchanges and such need to be on board.
As for sync times, is there any reason we can't do a genesis block from a year ago or so that would reduce the blockchain? Just another thing to think about, if we are going to need to fork it, we might as well keep them to as few as possible.
Yes you are exactly right.
If you go 45 second drift you would want to lower the what I call the hashdrift (how far into the future you hash) to preferably lower than 45 seconds, maybe 30-35 seconds. Or you could leave it as is at 60 seconds, and change timedrift allowance to 75-90 seconds, or whatever you all decide is correct (I am just here to help you all understand the details, not here to tell you what to do).
June 30, 2015, 10:37:07 AM
Network weight will mean higher difficulty, and higher difficulty means it will be harder to get it into this type of spiral to begin with.
120 minutes = 7200 possible hashes to try and find a stake (although you could target only the say highest 5000 timestamps)
6 minutes = 360 possible hashes
3 minutes = 180
6 minutes reduces the possibilities by a large amount, but narrowing down to 3 minutes still cuts those chances in half. Is 3 minutes too large? It could be.. MINT's 30 second block time doesnt exactly help in this scenario (I recommended to cryptomommy to also put block time up for vote, but I had longevity of chain syncing in mind not this particular issue). The small block time makes it easier to over shoot. For HyperStake I have used a 60 second time. The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.
The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.120 minutes = 7200 possible hashes to try and find a stake (although you could target only the say highest 5000 timestamps)
6 minutes = 360 possible hashes
3 minutes = 180
6 minutes reduces the possibilities by a large amount, but narrowing down to 3 minutes still cuts those chances in half. Is 3 minutes too large? It could be.. MINT's 30 second block time doesnt exactly help in this scenario (I recommended to cryptomommy to also put block time up for vote, but I had longevity of chain syncing in mind not this particular issue). The small block time makes it easier to over shoot. For HyperStake I have used a 60 second time. The only problem I have had so far with it is that the default implementation of PPCs stake hashing goes 60 seconds, so if you clock does not properly read consensus time it is possible to orphan blocks because they minted outside the timedrift window. So even a 1.5 minutes timedrift would probably do the trick.
Because of this...It sounds to me, we need to have the timeshift at or above 60 seconds in order to prevent a spike in orphans. My concern is could 45 seconds be too low? What about a 66 second timeshift? That would be 1.1 minutes; which is still even more conservative than the 1.5 minutes presstab recommended. My thinking is, going just over 60 seconds, would eliminate any issue with the default implementation of stake hashing going to 60 seconds.
Thoughts?
At anyrate, if we do a fork, we need to give plenty of time for people to upgrade wallets, before the fork block comes. All exchanges and such need to be on board.
As for sync times, is there any reason we can't do a genesis block from a year ago or so that would reduce the blockchain? Just another thing to think about, if we are going to need to fork it, we might as well keep them to as few as possible.
June 30, 2015, 10:32:47 AM
If I understand this it sounds like A 30 second block would be safe within a 45 second time drift - would be the most secure. Is this an accurate statement?
I do not believe this needs to be a poll. Everyone who would be concerned about these changes in the community from my social channel management experience is talking about it right now. (that's awesome).
As a large investor of Mintcoin I personally would like to go with the most secure option. If everyone agrees with this I would like to move forward with this implementation.
I have another developer on standby for these changes to be completed to make the other changes I mentioned as well. We can release the wallet with all features it looks like.
I do not believe this needs to be a poll. Everyone who would be concerned about these changes in the community from my social channel management experience is talking about it right now. (that's awesome).
As a large investor of Mintcoin I personally would like to go with the most secure option. If everyone agrees with this I would like to move forward with this implementation.
I have another developer on standby for these changes to be completed to make the other changes I mentioned as well. We can release the wallet with all features it looks like.
Okay. I think I am for it. Sounds like even at 45 seconds it would't increase orphans by much though. Still should be plenty of time. Still will be a big improvement.
Would this help the slow sync times?
I don't believe so but we are looking into making significant improvements on the process of installing / upgrading wallet process as well. In the meantime we have a bootstrap daily backup that cuts the time down to a few hours.
June 30, 2015, 10:13:25 AM
If I understand this it sounds like A 30 second block would be safe within a 45 second time drift - would be the most secure. Is this an accurate statement?
I do not believe this needs to be a poll. Everyone who would be concerned about these changes in the community from my social channel management experience is talking about it right now. (that's awesome).
As a large investor of Mintcoin I personally would like to go with the most secure option. If everyone agrees with this I would like to move forward with this implementation.
I have another developer on standby for these changes to be completed to make the other changes I mentioned as well. We can release the wallet with all features it looks like.
I do not believe this needs to be a poll. Everyone who would be concerned about these changes in the community from my social channel management experience is talking about it right now. (that's awesome).
As a large investor of Mintcoin I personally would like to go with the most secure option. If everyone agrees with this I would like to move forward with this implementation.
I have another developer on standby for these changes to be completed to make the other changes I mentioned as well. We can release the wallet with all features it looks like.
Okay. I think I am for it. Sounds like even at 45 seconds it would't increase orphans by much though. Still should be plenty of time. Still will be a big improvement.
Would this help the slow sync times?
June 30, 2015, 09:59:03 AM
If I understand this it sounds like A 30 second block would be safe within a 45 second time drift - would be the most secure. Is this an accurate statement?
I do not believe this needs to be a poll. Everyone who would be concerned about these changes in the community from my social channel management experience is talking about it right now. (that's awesome).
As a large investor of Mintcoin I personally would like to go with the most secure option. If everyone agrees with this I would like to move forward with this implementation.
I have another developer on standby for these changes to be completed to make the other changes I mentioned as well. We can release the wallet with all features it looks like.
I do not believe this needs to be a poll. Everyone who would be concerned about these changes in the community from my social channel management experience is talking about it right now. (that's awesome).
As a large investor of Mintcoin I personally would like to go with the most secure option. If everyone agrees with this I would like to move forward with this implementation.
I have another developer on standby for these changes to be completed to make the other changes I mentioned as well. We can release the wallet with all features it looks like.
Okay. I think I am for it. Sounds like even at 45 seconds it would't increase orphans by much though. Still should be plenty of time. Still will be a big improvement.
June 30, 2015, 07:24:55 AM
If I understand this it sounds like A 30 second block would be safe within a 45 second time drift - would be the most secure. Is this an accurate statement?
I do not believe this needs to be a poll. Everyone who would be concerned about these changes in the community from my social channel management experience is talking about it right now. (that's awesome).
As a large investor of Mintcoin I personally would like to go with the most secure option. If everyone agrees with this I would like to move forward with this implementation.
I have another developer on standby for these changes to be completed to make the other changes I mentioned as well. We can release the wallet with all features it looks like.
I do not believe this needs to be a poll. Everyone who would be concerned about these changes in the community from my social channel management experience is talking about it right now. (that's awesome).
As a large investor of Mintcoin I personally would like to go with the most secure option. If everyone agrees with this I would like to move forward with this implementation.
I have another developer on standby for these changes to be completed to make the other changes I mentioned as well. We can release the wallet with all features it looks like.
June 30, 2015, 12:59:26 AM
That's strange. Whenever I have looked over the network, it always seemed to me that during the times of highest difficulty, and highest staking rate, the orphans rate spiked down to the fewest orphans.
Regardless; are you talking about trying to sync the wallet from scratch possibly freezing? Or are you talking about a fully synced wallet all of the sudden freezing and not syncing?
At this point, I wouldn't say that orphans are really a "problem" they are still tolerable at this point
Regardless; are you talking about trying to sync the wallet from scratch possibly freezing? Or are you talking about a fully synced wallet all of the sudden freezing and not syncing?
At this point, I wouldn't say that orphans are really a "problem" they are still tolerable at this point
Orphan problem shows up more when trying to sync a wallet for the 1st time,
It goes over the orphan limit and locks up during the sync, until it clears no other blocks are synced.
The only thing keeping it from being noticed more is the low staking rate.
I noticed more orphan errors in the debug log, when more coins are staking than less.
If there is another explanation, would love to hear it so I could test it.
Correct at your current level Orphans are not an issue if you are fully synced, but everyone does not stay fully sync. And lowering the timedrift will increase orphans , PressTab can confirm that from his own experience. And if your staking % goes higher, your orphans should also increase again.
I thought Blackcoin and Clams were on 15 minutes, not 15 seconds.
Nope, changed to 15 seconds timedrifts, you can check their forums.
Sounds to me according to presstab, 1 minute timedrift is working with 1 minute blocks, on Hyper, and usually everyone is within 10 seconds of eachother, so is there any reason not to think that 1 minutes should easily work fine with the 30 second blocks that Mintcoin has? What about 45 seconds?
May work fine, with 30 seconds blocks,
May not, 2 major differences Hyperstake is 60 second block time , plus it's # of coins is less than 250 million.
Mint is over 21 billion, over 84 times the size of hyperstake coins.
More staking coins = more orphans.
A 30 second block would be safe within a 45 second time drift.
A 45 second block should be safe within as large as a 2 minute time drift.
A 60 second block should be safe within as large as a 2½ minute time drift.
Higher the time drift , lower the orphans.
Once everyone is done saying their piece,
Have CM Pick the 3 most preferred choices and then the Mint community can vote on it.
Guess the 4th choice would be No changes and hope no one hits mint with the time warp.
June 29, 2015, 11:33:27 PM
FYI: Mint already has orphan issues, they are just not noticed as much, due to the fact that so few are staking 24x7 . For example at the moment only 3.2% of coin are staking, so your orphan rate is lower.
Your staking rate changes daily and on days where you have over 10% staking your Orphan rate is higher.
Easy test , start a new mint wallet and sync it from scratch when your staking rate is higher, you will notice it freeze up on blocks during the sync, check the debug.log file and you will see the orphan problem.
If your timedrift is set too low for a 30 second block and your staking rate improves to 20 or 30 % , your orphan rate it gonna go sky high, unknown if high enough to block syncing or not.
So a increasing/normal staking rate should be a factor in the final decisions.
Your staking rate changes daily and on days where you have over 10% staking your Orphan rate is higher.
Easy test , start a new mint wallet and sync it from scratch when your staking rate is higher, you will notice it freeze up on blocks during the sync, check the debug.log file and you will see the orphan problem.
If your timedrift is set too low for a 30 second block and your staking rate improves to 20 or 30 % , your orphan rate it gonna go sky high, unknown if high enough to block syncing or not.
So a increasing/normal staking rate should be a factor in the final decisions.
That's strange. Whenever I have looked over the network, it always seemed to me that during the times of highest difficulty, and highest staking rate, the orphans rate spiked down to the fewest orphans.
Regardless; are you talking about trying to sync the wallet from scratch possibly freezing? Or are you talking about a fully synced wallet all of the sudden freezing and not syncing?
At this point, I wouldn't say that orphans are really a "problem" they are still tolerable at this point.
http://blog.codinghorror.com/keeping-time-on-the-pc/
Network freeze is most likely not going to be an issue as blackcoin & clams are on 15 seconds and they get by ok. So anything 2 minutes or more won't be an issue.
Hyperstake works at 1 minute time drift with no issues, but they also run at 60 second blocks instead of 30 seconds.
Biggest concern is orphans and that is unknown and dependent on # of people staking.
And will change on a daily basis, don't personally know of anyway to test this, except by doing it and then monitoring the network.
Crypto Bleeding edge, you won't know for sure until you do it.
Network freeze is most likely not going to be an issue as blackcoin & clams are on 15 seconds and they get by ok. So anything 2 minutes or more won't be an issue.
Hyperstake works at 1 minute time drift with no issues, but they also run at 60 second blocks instead of 30 seconds.
Biggest concern is orphans and that is unknown and dependent on # of people staking.
And will change on a daily basis, don't personally know of anyway to test this, except by doing it and then monitoring the network.
Crypto Bleeding edge, you won't know for sure until you do it.
I thought Blackcoin and Clams were on 15 minutes, not 15 seconds.
Yes I think orphans is the biggest concern. With a 2 minute drift allowance, you would be able to have your machine off by 1 minute and still be within the bounds of the timedrift window if you were to stake a timestamp 60 seconds into the future. With 3 minutes you could be 2 minutes off, etc. If you browse through your debug.log it will show the peers time offset when you connect to them. Usually everyone is within 10 seconds or so from each other.
Sounds to me according to presstab, 1 minute timedrift is working with 1 minute blocks, on Hyper, and usually everyone is within 10 seconds of eachother, so is there any reason not to think that 1 minutes should easily work fine with the 30 second blocks that Mintcoin has? What about 45 seconds?
June 29, 2015, 11:19:34 PM
This is the issue... If you drop the timedrift window down, you increase the risk of a network freeze; and it can thus reduce the "randomness" of who is going to be getting the next block, by excluding some people who's clocks are not accurate.
The thing to find out is how big of an issue is this? Do we know what the average, or median divergance typically is from keeping an accurate time for a large pool of nodes? If 98% are within 2 minutes, then it makes sense to me to do it. But does anyone know this information? How can we know what a good timedrift is? Is there anyway to track this data?
Are there any sort of configuration settings that can be done to improve this, and make it more accurate.
One thing to find out is what % increase in orphans will it cause? If it increases them by a mere 5% or something then it is probably acceptable. Is there anyway this can this be tested?
The thing to find out is how big of an issue is this? Do we know what the average, or median divergance typically is from keeping an accurate time for a large pool of nodes? If 98% are within 2 minutes, then it makes sense to me to do it. But does anyone know this information? How can we know what a good timedrift is? Is there anyway to track this data?
Are there any sort of configuration settings that can be done to improve this, and make it more accurate.
One thing to find out is what % increase in orphans will it cause? If it increases them by a mere 5% or something then it is probably acceptable. Is there anyway this can this be tested?
http://blog.codinghorror.com/keeping-time-on-the-pc/
Network freeze is most likely not going to be an issue as blackcoin & clams are on 15 seconds and they get by ok. So anything 2 minutes or more won't be an issue.
Hyperstake works at 1 minute time drift with no issues, but they also run at 60 second blocks instead of 30 seconds.
Biggest concern is orphans and that is unknown and dependent on # of people staking.
And will change on a daily basis, don't personally know of anyway to test this, except by doing it and then monitoring the network.
Crypto Bleeding edge, you won't know for sure until you do it.
Yes I think orphans is the biggest concern. With a 2 minute drift allowance, you would be able to have your machine off by 1 minute and still be within the bounds of the timedrift window if you were to stake a timestamp 60 seconds into the future. With 3 minutes you could be 2 minutes off, etc. If you browse through your debug.log it will show the peers time offset when you connect to them. Usually everyone is within 10 seconds or so from each other.
June 29, 2015, 10:43:39 PM
This is the issue... If you drop the timedrift window down, you increase the risk of a network freeze; and it can thus reduce the "randomness" of who is going to be getting the next block, by excluding some people who's clocks are not accurate.
The thing to find out is how big of an issue is this? Do we know what the average, or median divergance typically is from keeping an accurate time for a large pool of nodes? If 98% are within 2 minutes, then it makes sense to me to do it. But does anyone know this information? How can we know what a good timedrift is? Is there anyway to track this data?
Are there any sort of configuration settings that can be done to improve this, and make it more accurate.
One thing to find out is what % increase in orphans will it cause? If it increases them by a mere 5% or something then it is probably acceptable. Is there anyway this can this be tested?
The thing to find out is how big of an issue is this? Do we know what the average, or median divergance typically is from keeping an accurate time for a large pool of nodes? If 98% are within 2 minutes, then it makes sense to me to do it. But does anyone know this information? How can we know what a good timedrift is? Is there anyway to track this data?
Are there any sort of configuration settings that can be done to improve this, and make it more accurate.
One thing to find out is what % increase in orphans will it cause? If it increases them by a mere 5% or something then it is probably acceptable. Is there anyway this can this be tested?
http://blog.codinghorror.com/keeping-time-on-the-pc/
Network freeze is most likely not going to be an issue as blackcoin & clams are on 15 seconds and they get by ok. So anything 2 minutes or more won't be an issue.
Hyperstake works at 1 minute time drift with no issues, but they also run at 60 second blocks instead of 30 seconds.
Biggest concern is orphans and that is unknown and dependent on # of people staking.
And will change on a daily basis, don't personally know of anyway to test this, except by doing it and then monitoring the network.
Crypto Bleeding edge, you won't know for sure until you do it.
Jump to: