Bitcoin Forum
November 24, 2017, 08:56:05 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 954 ... 1015 »
  Print  
Author Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained]  (Read 1312589 times)
presstab
Legendary
*
Offline Offline

Activity: 1288


Pivx Core Developer - HyperStake Founder


View Profile
June 30, 2015, 03:38:30 PM
 #18061

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.

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

Posts: 1511556965

View Profile Personal Message (Offline)

Ignore
1511556965
Reply with quote  #2

1511556965
Report to moderator
1511556965
Hero Member
*
Offline Offline

Posts: 1511556965

View Profile Personal Message (Offline)

Ignore
1511556965
Reply with quote  #2

1511556965
Report to moderator
1511556965
Hero Member
*
Offline Offline

Posts: 1511556965

View Profile Personal Message (Offline)

Ignore
1511556965
Reply with quote  #2

1511556965
Report to moderator
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511556965
Hero Member
*
Offline Offline

Posts: 1511556965

View Profile Personal Message (Offline)

Ignore
1511556965
Reply with quote  #2

1511556965
Report to moderator
1511556965
Hero Member
*
Offline Offline

Posts: 1511556965

View Profile Personal Message (Offline)

Ignore
1511556965
Reply with quote  #2

1511556965
Report to moderator
1511556965
Hero Member
*
Offline Offline

Posts: 1511556965

View Profile Personal Message (Offline)

Ignore
1511556965
Reply with quote  #2

1511556965
Report to moderator
coolbeans94
Hero Member
*****
Offline Offline

Activity: 613


Mintcoin: Get some


View Profile
June 30, 2015, 04:12:22 PM
 #18062

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

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"?

(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, 05:37:01 PM
 #18063


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.

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, 05:50:29 PM
 #18064


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.
Doe this aspect affect CPU?
 What are benefits of searching a large group of timestamps at a time? How much would a 20 second drop affect it?

(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, 06:03:43 PM
 #18065


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.
Doe this aspect affect CPU?
 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.

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, 06:24:41 PM
 #18066


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.
Doe this aspect affect CPU?
 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.
What do you mean those 60 time stamps?

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?

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

Activity: 613


Mintcoin: Get some


View Profile
June 30, 2015, 07:00:55 PM
 #18067

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?

(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, 07:54:39 PM
 #18068

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.

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, 08:00:43 PM
 #18069

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. 

(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.
deepcreek
Member
**
Offline Offline

Activity: 79


View Profile
June 30, 2015, 09:27:55 PM
 #18070

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

Activity: 613


Mintcoin: Get some


View Profile
June 30, 2015, 10:09:17 PM
 #18071

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.

We could increase the confirmations up from 4 to say 40.

Transactions would still confirm in 30 seconds, and individual users could decide if they want to wait a full 20 minutes for all 40 confirmations. Essentially, people can pick their own risk level.  I think that anyone trying to get 40 blocks in a row would find that to be very difficult. Think 40 is enough?

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

Activity: 613


Mintcoin: Get some


View Profile
June 30, 2015, 10:35:35 PM
 #18072

Another thing that I think we should do (if the community agrees) is to remove the 70-billion hard limit coin cap, and instead implement a stable block reward of 1 coin per block, in addition to the transaction fee. This comes out to hard limit increase of 1,036,800 coins per year. I think it is necessary, to maintain a guaranteed block reward indefinitely. This will ensure that people are still motivated to keep their wallets minting to secure the network, and will also ensure coin supply doesn't dry up. By the time 70 billion comes, adding an extra 1-million per year will scarcely make a difference to the limit anyway. What this means is that the first year, after this change, the increase in the money supply would only be .0015%. Basically still a hard limit anyway but ensures the network keeps going. (1,036,800/70,000,000,000=.0015%) Each year thereafter it would even be a fraction of a % less, as the total supply grows by about 1 million per year. This will motivate people to stake and not have to worry about possibly having to rely on transaction fees alone, that they may or may not get. Every block deserves a bit of reward guaranteed IMO. If all these changes were implemented, I'm sure Mintcoins would grow to become the coin of choice that will surely stand the test of time.



(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.
Flyskyhigh
Sr. Member
****
Offline Offline

Activity: 292


Ezekiel 34:11, John 10:25-30


View Profile
June 30, 2015, 11:13:23 PM
 #18073

Sounds good to me.
It seems these few tweaks would be beneficial for security for the long-term, and still stays true to what Mintcoin is all about. Let's make mintcoin flawless.   Smiley
How hard would it be to make all the said changes? Is this something presstab can do for us? I'll be willing to tip him good if this all works out. Cheesy

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

Activity: 1288


Pivx Core Developer - HyperStake Founder


View Profile
July 01, 2015, 12:41:16 AM
 #18074

Cryptomommy contracted me to handle the security fork for the timedrift parameter. If you guys want to throw up some more coins and add in some more work for me I can add some other things on top of that as well.

Concerning the coin cap... for most proof of stake implementations this was actually coded improperlely and is actually a maximum amount per transaction. Unless MINT has been changed specifically to fix this, then I would assume it has this same property. I can look into the code and grab a precise answer as well.

That being said, coding in a predetermined supply growth rate is not at all a bad idea, and is not at all difficult 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
someguy4
Newbie
*
Offline Offline

Activity: 20


View Profile
July 01, 2015, 01:56:53 AM
 #18075

I wrote a small (amatuer) p2p algorithm, just as a test. And I've only half read the things posted lately. But in my little P2p thing I added a constraint on the time per client (assume your time is correct and only accept times that are within a certain range). As I had control over all the computers I tested it on I set it fairly low (1 min). But shouldn't it result in a consensus on the network. I'm not sure I really understand your issue unless you are suggesting multiple clients that all offset by 1 min in my example and enough clients to override the whole system. Dont mintcoin clients have the same priority as far as time is concerned?
Flyskyhigh
Sr. Member
****
Offline Offline

Activity: 292


Ezekiel 34:11, John 10:25-30


View Profile
July 01, 2015, 03:13:25 AM
 #18076

Cryptomommy contracted me to handle the security fork for the timedrift parameter. If you guys want to throw up some more coins and add in some more work for me I can add some other things on top of that as well.

Concerning the coin cap... for most proof of stake implementations this was actually coded improperlely and is actually a maximum amount per transaction. Unless MINT has been changed specifically to fix this, then I would assume it has this same property. I can look into the code and grab a precise answer as well.

That being said, coding in a predetermined supply growth rate is not at all a bad idea, and is not at all difficult to do.
Cool. Thank you for the efforts. Looking into the code for a definite answer would be great. Then we can decide from there. I'll throw up a few million mints for any additional changes we decide we want to do. Let's get this coin set right!

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

Activity: 1288


Pivx Core Developer - HyperStake Founder


View Profile
July 01, 2015, 03:43:33 AM
 #18077

Cool. Thank you for the efforts. Looking into the code for a definite answer would be great. Then we can decide from there. I'll throw up a few million mints for any additional changes we decide we want to do. Let's get this coin set right!

Yes now is the time to think about it all. So is everyone a no for changing block time to be a bit higher in order to preserve the syncability of the chain over the long run?

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
July 01, 2015, 04:43:40 AM
 #18078

Cool. Thank you for the efforts. Looking into the code for a definite answer would be great. Then we can decide from there. I'll throw up a few million mints for any additional changes we decide we want to do. Let's get this coin set right!

Yes now is the time to think about it all. So is everyone a no for changing block time to be a bit higher in order to preserve the syncability of the chain over the long run?
I think I'm happy with the block time the way it is. I like how fast it is and would rather not change it.

Sick of mining?  Start minting!  5% per year!  Mintcoin "MINT"
Derek492
Sr. Member
****
Offline Offline

Activity: 357



View Profile
July 01, 2015, 05:38:26 AM
 #18079

Yes now is the time to think about it all. So is everyone a no for changing block time to be a bit higher in order to preserve the syncability of the chain over the long run?
Yeah. I'm a "No" vote as far as changing the block time. We have the bootstrap that cuts the time to sync down. There is also the option of doing a periodic genesis block every 3 years or so if we decide it is necessary. I think those are better options at this point that a block time change. IMO that would totally change the "feel" of MINT. Part of what makes MINT what it is, is it's block speed, and changing the block time, would also impact how many mintings are able to be completed, etc... so I'm not in favor of messing with that unless it is discovered we absolutely must.

If I understand everything so far, the other proposed changes are things that seem to be good and needed for strong lasting security, so I would be for them. Seems we should really try to get the "time drift" and "hash drift" to where they need to be so to prevent a timewarp attack (under 30 seconds like coolbeans proposed would eliminate the risk entirely?). 
Also, increasing the number of confirmations by 10x seems good to me. Should we also increase the confirmations needed for a new minting to be usable? If I am not mistaken, I believe it is currently it is currently at 50 confirmations - so increasing it by 10x would be 500 confirmations.
And a coin cap hard limit, replaced by 1 new coin per block makes sense. If coins keep getting lost, which is bound to happen, over time, there could be too few coins to function as a usable currency.

Anyway, good discussion. Glad to see some good though being put into this rather than just jumping to conclusions. Any changes, that require a hard fork, we need to be sure will be positively for the benefit of the coin and community. Obviously security is the #1 priority, for without it, you have neither coin or community.

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
coolbeans94
Hero Member
*****
Offline Offline

Activity: 613


Mintcoin: Get some


View Profile
July 01, 2015, 06:41:37 AM
 #18080

I have been giving this timedrift issue a lot of thought.  Roll Eyes

Would it even be anymore beneficial to make it below the block target of 30 seconds? Starting to think it would not.

Maybe the better composition would be to just have the hashdrift set at say 24 seconds, and the timedrift set at say 30 seconds. This way if an attacker were to go to the max 30 seconds, the effect is 0 on the difficulty, since it is line with the block target.

But here is my other thought, Roll Eyes
Is it at all possible, that if someone goes out less than the block time, they could "INCREASE" the difficulty? Is a timewarp attack possible in the other direction so as to attack it by making the difficulty go way way up? (Essentially causing a denial of service type attack?)
What is the effect of the timewarp attack on the the network if the timedrift is below the block target time?

(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.
Pages: « 1 ... 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 954 ... 1015 »
  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!