Bitcoin Forum
December 13, 2017, 10:56:44 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 [903] 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 ... 1016 »
  Print  
Author Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained]  (Read 1323855 times)
Flyskyhigh
Sr. Member
****
Offline Offline

Activity: 292


Ezekiel 34:11, John 10:25-30


View Profile
June 29, 2015, 09:52:40 PM
 #18041

I am still not convinced. I really like the way the coin is right now. Is there a way to test this attack on a mintcoins testnet, to really examine the risk? I am not for hard working anything if it is not absolutely necessary. At this point I'm not convinced that this won't have some unforseen consequential side effects that would be detrimental.
How do you know 2 hours is too long and 15 seconds is too short? It seems really subjective, and if it affects minting rates and difficulty that is a concern. I like the balance mintcoins has to offer on its parameters. How do you know how much to drop it? What would be the problem of making it limited to say, 5 seconds?

LOL ,

Presstab discovered the issue, if he says your coin is at risk.  Then It is.
He could tell CM how to do it , and then observe the block explorer for the results.
Difficulty halving and her mint address getting all of the staking will be your proof.



 Cool

You don't have to mock me. I'm trying to learn and understand.  If it is at risk I want to be sure, not just create FUD. Answering my questions would help. Why is 2 hours too long? Why is 15 seconds too short? How do you know what the right balance is, really? Why do we have to have to allow any amount of time at all? What factors go into affecting it? Does more people connected and staking help prevent against that sort of attack? Mintcoin is pretty established, just comparing it to some other coin that nobody used, is not the same for comparison IMO. I just want my questions answered, because obviously if there is a threat of making it too short, that would be bad too. Maybe 2 hours is actually enough. I'm trying to understand this issue. What is the reasoning for why 2 hours was chosen before?

Sick of mining?  Start minting!  5% per year!  Mintcoin "MINT"
1513205804
Hero Member
*
Offline Offline

Posts: 1513205804

View Profile Personal Message (Offline)

Ignore
1513205804
Reply with quote  #2

1513205804
Report to moderator
1513205804
Hero Member
*
Offline Offline

Posts: 1513205804

View Profile Personal Message (Offline)

Ignore
1513205804
Reply with quote  #2

1513205804
Report to moderator
1513205804
Hero Member
*
Offline Offline

Posts: 1513205804

View Profile Personal Message (Offline)

Ignore
1513205804
Reply with quote  #2

1513205804
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
kiklo
Legendary
*
Offline Offline

Activity: 1092



View Profile
June 29, 2015, 10:18:53 PM
 #18042

You don't have to mock me. I'm trying to learn and understand.  If it is at risk I want to be sure, not just create FUD. Answering my questions would help. Why is 2 hours too long? Why is 15 seconds too short? How do you know what the right balance is, really? Why do we have to have to allow any amount of time at all? What factors go into affecting it? Does more people connected and staking help prevent against that sort of attack? Mintcoin is pretty established, just comparing it to some other coin that nobody used, is not the same for comparison IMO. I just want my questions answered, because obviously if there is a threat of making it too short, that would be bad too. Maybe 2 hours is actually enough. I'm trying to understand this issue. What is the reasoning for why 2 hours was chosen before?

Excuse me, it is my normally playful ways, not meant to insult or degrade.
Take no offense, it's just how I am.  Smiley

Time Drift was created , because not everyone PC clock keeps accurate time.
Without it a network could freeze up due to lacking stake-able blocks.

Mint makes blocks every 30 seconds, which means their should be 120 blocks per hour.
Your Time drift is 2 hours or 240 blocks.
When someone uses the timewarp to cheat , their block timestamp could be up to 200 blocks ahead,
when mint generates the difficulty setting it looks at those timestamps, and think the difficulty was too hard and drops it so that the next block can be found in a 30 second timeframe. This dramically lowers the difficulty.

15 seconds is lower than your generated blocks ,and would cause a massive increase in your # of orphans.
FYI: Mint already has issues with the orphans , that is what is causing new people to have so much trouble syncing, but that is an issue for another day.

More people staking can not stop the timewarp attack as no matter the number, it lets the attacker jump in front of them for staking.

As why 2 hours was chosen, we probably have to PM Sunny to find that out.

FYI:
If dropping your timedrift to 1 minute was a major concern, you could always change your block time to 1 minute and get away with a timedrift of 2 minutes.

 Cool
Flyskyhigh
Sr. Member
****
Offline Offline

Activity: 292


Ezekiel 34:11, John 10:25-30


View Profile
June 29, 2015, 11:06:34 PM
 #18043

Okay, well since mintcoins has faster blocks (approximately 30 seconds) then it makes sense to reduce the time down.

If peercoin is 2 hours, with 10 minute blocks,  it will have a limit of 12 blocks ahead. So in order for mintcoins to be comparable, we should have it set at 6 minutes. Mintcoins should be 6 minutes with 30 second blocks. It will then have a limit of 12 block ahead .

Correct?

Sick of mining?  Start minting!  5% per year!  Mintcoin "MINT"
presstab
Legendary
*
Offline Offline

Activity: 1288


Pivx Core Developer - HyperStake Founder


View Profile
June 29, 2015, 11:16:29 PM
 #18044

Okay, well since mintcoins has faster blocks (approximately 30 seconds) then it makes sense to reduce the time down.

If peercoin is 2 hours, with 10 minute blocks,  it will have a limit of 12 blocks ahead. So in order for mintcoins to be comparable, we should have it set at 6 minutes. Mintcoins should be 6 minutes with 30 second blocks. It will then have a limit of 12 block ahead .

Correct?

Not correct because PPC does not have the exact same difficulty adjustment code. You could stake as many blocks as you so please in the timedrift window. They do not need to have any chronological order according to the network rules. I could stake some MINT that is 30 minutes into the future and it would bring the diff way down low because the network thinks it took 30 minutes between finding blocks. The next block could come in at normal time, but since the code has a section that doesnt allow the diff to calculate as a negative number, the network thinks that it took 1 second to find the next block... thus jumping difficulty up a little bit, but not near as much as it dropped. then i could publish one another 30 minutes in advanced, and rinse and repeat until difficulty is next to nothing.

Pulling it down to 6 minutes would make a lot of difference. My personal recommendation would be 2-3 minutes. With 30 second block times, and the terribly low network stake weight that MINT has, it could really be played with (and I thought about it before, but decided not to get into the business of having too much fun with other peoples money).

Anyways, keep up the discussion, it is interesting.

presstab's Block Explorer Service | Only $10/mo for most coins! | Richlist w/ Address Claim | Market Cap Charts | Stake Weight Tracking | PoS % Rate Tracking
PIVX - Private Instant Verified Tx | HyperStake - Fun & Easy High Reward Staking
Flyskyhigh
Sr. Member
****
Offline Offline

Activity: 292


Ezekiel 34:11, John 10:25-30


View Profile
June 29, 2015, 11:21:42 PM
 #18045

Okay, well since mintcoins has faster blocks (approximately 30 seconds) then it makes sense to reduce the time down.

If peercoin is 2 hours, with 10 minute blocks,  it will have a limit of 12 blocks ahead. So in order for mintcoins to be comparable, we should have it set at 6 minutes. Mintcoins should be 6 minutes with 30 second blocks. It will then have a limit of 12 block ahead .

Correct?

Not correct because PPC does not have the exact same difficulty adjustment code. You could stake as many blocks as you so please in the timedrift window. They do not need to have any chronological order according to the network rules. I could stake some MINT that is 30 minutes into the future and it would bring the diff way down low because the network thinks it took 30 minutes between finding blocks. The next block could come in at normal time, but since the code has a section that doesnt allow the diff to calculate as a negative number, the network thinks that it took 1 second to find the next block... thus jumping difficulty up a little bit, but not near as much as it dropped. then i could publish one another 30 minutes in advanced, and rinse and repeat until difficulty is next to nothing.

Pulling it down to 6 minutes would make a lot of difference. My personal recommendation would be 2-3 minutes. With 30 second block times, and the terribly low network stake weight that MINT has, it could really be played with (and I thought about it before, but decided not to get into the business of having too much fun with other peoples money).

Anyways, keep up the discussion, it is interesting.
How would pulling it down to 6 minutes make a lot of difference? If you say you pull down the difficulty, rinse and repeat, what difference does it make? It is the same effect right?

Edit:

I get that loweribg it to 6, 2 or 3 minutes will make it harder to pull down the difficulty,, but will it be enough to stop it from perpetually going lower? How do you stop difficulty from perpetually going lower by using that technique? What would be a complete fix?

Edit2:
How does network weight affect it? Are you saying if the network stake weight was higher, this issue would be mitigated?

Sick of mining?  Start minting!  5% per year!  Mintcoin "MINT"
presstab
Legendary
*
Offline Offline

Activity: 1288


Pivx Core Developer - HyperStake Founder


View Profile
June 30, 2015, 12:06:14 AM
 #18046

How would pulling it down to 6 minutes make a lot of difference? If you say you pull down the difficulty, rinse and repeat, what difference does it make? It is the same effect right?

Edit:

I get that loweribg it to 6, 2 or 3 minutes will make it harder to pull down the difficulty,, but will it be enough to stop it from perpetually going lower? How do you stop difficulty from perpetually going lower by using that technique? What would be a complete fix?

Edit2:
How does network weight affect it? Are you saying if the network stake weight was higher, this issue would be mitigated?

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.

Just some food for thought.

presstab's Block Explorer Service | Only $10/mo for most coins! | Richlist w/ Address Claim | Market Cap Charts | Stake Weight Tracking | PoS % Rate Tracking
PIVX - Private Instant Verified Tx | HyperStake - Fun & Easy High Reward Staking
deepcreek
Member
**
Offline Offline

Activity: 79


View Profile
June 30, 2015, 12:07:17 AM
 #18047

Listen i am a real scrub when it comes to code and everything around it, but after reading this discussion. Is it possible to let the wallet check the real time and match it with the PC time? And if this is way off unable it from minting.

just some random thought, and again i don`t know what is possible within a wallet and what is not.
Flyskyhigh
Sr. Member
****
Offline Offline

Activity: 292


Ezekiel 34:11, John 10:25-30


View Profile
June 30, 2015, 12:24:11 AM
 #18048

How would pulling it down to 6 minutes make a lot of difference? If you say you pull down the difficulty, rinse and repeat, what difference does it make? It is the same effect right?

Edit:

I get that loweribg it to 6, 2 or 3 minutes will make it harder to pull down the difficulty,, but will it be enough to stop it from perpetually going lower? How do you stop difficulty from perpetually going lower by using that technique? What would be a complete fix?

Edit2:
How does network weight affect it? Are you saying if the network stake weight was higher, this issue would be mitigated?

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.

Just some food for thought.
So if we all keep our wallets online for minting it will help. Good to know. We need to let everyone know to do this.

What would be the downsides of setting the timedrift to 1.5 minutes?  Orphans? How bad would it be? Do you think it would really be an issue? Any adverse side affects?

Edit:
Also, what would be a good network weight level needed to prevent this?

Sick of mining?  Start minting!  5% per year!  Mintcoin "MINT"
coolbeans94
Hero Member
*****
Offline Offline

Activity: 613


Mintcoin: Get some


View Profile
June 30, 2015, 02:24:23 AM
 #18049

Time Drift was created , because not everyone PC clock keeps accurate time.
Without it a network could freeze up due to lacking stake-able blocks.

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?

(1.) Moral happiness depends upon moral order.
(2.) Moral order depends upon the harmonious action of all our powers, as
individuals and as members of society.
kiklo
Legendary
*
Offline Offline

Activity: 1092



View Profile
June 30, 2015, 02:31:14 AM
 #18050

What would be the downsides of setting the timedrift to 1.5 minutes?  Orphans? How bad would it be? Do you think it would really be an issue? Any adverse side affects?

Edit:
Also, what would be a good network weight level needed to prevent this?

Orphans:
Worst case would freeze the mint network and block syncing for a lot of users.
Especially for new People syncing the 1st time.
Best case , then no problem.

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.

 Cool
kiklo
Legendary
*
Offline Offline

Activity: 1092



View Profile
June 30, 2015, 02:43:39 AM
 #18051

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?

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.

 Cool
presstab
Legendary
*
Offline Offline

Activity: 1288


Pivx Core Developer - HyperStake Founder


View Profile
June 30, 2015, 03:19:34 AM
 #18052

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?

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.

 Cool


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.

presstab's Block Explorer Service | Only $10/mo for most coins! | Richlist w/ Address Claim | Market Cap Charts | Stake Weight Tracking | PoS % Rate Tracking
PIVX - Private Instant Verified Tx | HyperStake - Fun & Easy High Reward Staking
coolbeans94
Hero Member
*****
Offline Offline

Activity: 613


Mintcoin: Get some


View Profile
June 30, 2015, 03:33:27 AM
 #18053

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.

 Cool

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.

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?

(1.) Moral happiness depends upon moral order.
(2.) Moral order depends upon the harmonious action of all our powers, as
individuals and as members of society.
kiklo
Legendary
*
Offline Offline

Activity: 1092



View Profile
June 30, 2015, 04:59:26 AM
 #18054

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


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.

 Cool
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425


View Profile
June 30, 2015, 11:24:55 AM
 #18055

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.

Flyskyhigh
Sr. Member
****
Offline Offline

Activity: 292


Ezekiel 34:11, John 10:25-30


View Profile
June 30, 2015, 01:59:03 PM
 #18056

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.



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.

Sick of mining?  Start minting!  5% per year!  Mintcoin "MINT"
publicjud
Legendary
*
Offline Offline

Activity: 980


Proof-of-Asset Protocol


View Profile
June 30, 2015, 02:13:25 PM
 #18057

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.



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?

| 
 
50
| 




                       ▄
           ▄▄▄▄▄▄███████
▄▄▄▄█████  █████████████
█████████  █████████████
█████████  █████████████
█████████  █████████████
█████████  █████████████
█████████  █████████████

█████████  █████████████
█████████  █████████████
█████████  █████████████
█████████  █████████████
█████████  █████████████
▀▀▀▀█████  █████████████
           ▀▀▀▀▀▀███████
                       ▀
| 
 
$1,5 M
|


        ▄▄▄█████████▄▄▄
      ▄█████▀▀███▀▀█████▄
    ▄███▀     ███     ▀███▄
   ████       ███       ████
  ███▀                   ▀███
 ███▀                     ▀███
▄██▀       █████████       ▀██▄
███                         ███
███        █████████        ███
███                         ███
▀██▄       █████████       ▄██▀
 ███▄                     ▄███
  ███▄                   ▄███
   ████       ███       ████
    ▀███▄     ███     ▄███▀
      ▀█████▄▄███▄▄█████▀
        ▀▀▀█████████▀▀▀
 
|
 
<>
<>
<>
<>
 
GITHUB
TWITTER
YOUTUBE
FACEBOOK
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425


View Profile
June 30, 2015, 02:32:47 PM
 #18058

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.



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.
coolbeans94
Hero Member
*****
Offline Offline

Activity: 613


Mintcoin: Get some


View Profile
June 30, 2015, 02:37:07 PM
 #18059

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.

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.

(1.) Moral happiness depends upon moral order.
(2.) Moral order depends upon the harmonious action of all our powers, as
individuals and as members of society.
presstab
Legendary
*
Offline Offline

Activity: 1288


Pivx Core Developer - HyperStake Founder


View Profile
June 30, 2015, 03:35:01 PM
 #18060

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.

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

presstab's Block Explorer Service | Only $10/mo for most coins! | Richlist w/ Address Claim | Market Cap Charts | Stake Weight Tracking | PoS % Rate Tracking
PIVX - Private Instant Verified Tx | HyperStake - Fun & Easy High Reward Staking
Pages: « 1 ... 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 [903] 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 ... 1016 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!