Bitcoin Forum
October 16, 2018, 10:13:22 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 955 956 957 ... 1035 »
  Print  
Author Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained]  (Read 1341995 times)
Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 03, 2015, 01:52:47 PM
 #18121


Okay. I have several questions:
So no hard fork required for adding the statistical gathering code? Can you explain how it works a little more? Would it further affect performance? Would the information be made publicly viewable for analysis? How long would it take to gather sufficient information in order to make a decision? Is this code already implemented in other coins?
From prior discussion here, we were thinking the best option is the 30 second time drift as that would totally eliminate any possibility of a decreasing difficulty timewarp attack since mintcoin has 30 second block target, there is no reason to go lower or higher. And, if other coins are already successful with low time drifts (like 15 seconds), then why not just go ahead and proceed with it in Mintcoin? But, I guess if we need the statistical data, if just to just verify before we proceed, then it is a smart thing to do.


Just a suggestion a by no means a mandatory thing. The code would be about the client and its timing differences, not about the block chain. Most IBM PC variants lose about a second a day. Most OS'es adjust weekly for it and some applications adjust sooner. Ping times can be used to account for network latency on a node to node basis.

 I'm still delving into the innards of the codebase to see how efficiently the protocol is being implemented locally but a drift not set low enough still leaves MintCoin open to attacks although the effects decrease the lower the drift. The information would be public and could become part of the protocol if it helps since we will be forking.  I not aware of other coins that are implementing outside of the testnets.

If the consensus is 30 sec then it works. I myself am still reading up on the detail of this attack, a lot of details on POW coins and most of the POS stuff I'm reading is a little less. I like to see this discussion. Personally i think 30 seconds on a global network can cause issues, nothing to back it up yet still reading nd playing with test net.
If it is an optional wallet, then sure. ...If you don't need to hard fork it to implement that code, and it is simple enough to do with a standard non mandatory updated wallet version release, why not just push it out for us to use real quick, even if it is just a few days. Maybe not everyone will update to the new wallet but it will be good to get feedback, and also help us know how much time we need to give people for them to get updated in preparation for a hard fork. I am sure there will be plenty of people willing to run it to help us make the best decisions. In the meantime we should get everything ready to go for proposed hard fork, and do whatever neccessary testing we can there too.

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

Posts: 1539728002

View Profile Personal Message (Offline)

Ignore
1539728002
Reply with quote  #2

1539728002
Report to moderator
1539728002
Hero Member
*
Offline Offline

Posts: 1539728002

View Profile Personal Message (Offline)

Ignore
1539728002
Reply with quote  #2

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

Posts: 1539728002

View Profile Personal Message (Offline)

Ignore
1539728002
Reply with quote  #2

1539728002
Report to moderator
1539728002
Hero Member
*
Offline Offline

Posts: 1539728002

View Profile Personal Message (Offline)

Ignore
1539728002
Reply with quote  #2

1539728002
Report to moderator
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425
Merit: 250


View Profile
July 03, 2015, 01:58:07 PM
 #18122

Before selling all my Mintcoin before they go on to reach 200 Sat or whatever I did think that someone should demonstrate this attack before hard forking and changing the fast confirming parameters of Mintcoin.  But regardless let's look at strategy first in terms of how Mintcoin co-exists with other cryptos. Let's say Bitcoin is your 'Reserve Crypto' which is a standard bearer for cryptos as a usable and practical currency alternative in a 21st century environment. The scheme I proposed for http://poisonedchalice.io for instance, supposes that a stable currency with a 4 billion dollar market cap is mature enough to leverage for some fixed term investment over a four year period. You want Bitcoin to be relatively stable as the lynchpin to this kind of financial product (stable after a 2015 Q4 correction, that is).

Mintcoin on the other hand, can adopt a slower confirmation time, IF it is leaning more towards the investment side of things, and less towards the Point of Sale transactions/merchant space. This space is better filled by something like Zetacoin or Quark, which are superior alternatives to Bitcoin in this instance, held back only by a lack of productive community output and shallow trading volumes at this stage. But these are not POS coins, maybe you want to stick a percentage of savings into a POS coin and security becomes much more important.  So if an answer to timedrift is to increase the confirmation time, that means you are making a trade off where Mintcoin becomes more secure at the loss of 30, 60, 90 seconds on average (or whatever it is) each time you shift it around. I think that's a trade off most community members would be happy to make.  Personally I have just got 4 BTC out of Mintcoin, but, that's after buying and holding over the space of a year or so (I'll buy back under 29 Sat and before another rate drop) so as you can see fast confirmation times haven't really been all that important so far.

I agree on that note - one thing we should not alter is the speed of Mintcoin - Its flipping amazing and extremely helpful whether sending / receiving to exchanges or a friend. We need the speed.

Have you or any of the community ever put any though into reducing the target block time? Current looks like 30 seconds. My concern would be long term syncability of the chain. It isn't too easy to sync it at the current 1.5 million blocks, and a few years from now it will be even harder. Raising the block time could be a beneficial long term change to throw in while a hard fork occurs.
This sounds very sensible to me with the understanding that our block chain is going to continue to grow - questions?

  • is it any less secure and why / why not?
    will this affect the speed of the coin in transactions (including confirmations)
  • Does it require a hard fork

I would say that mints biggest security risk is the 2 hour time drift allowance. Read about the vulnerability here http://bitcoinist.net/interview-presstab-pos-vulnerabilities/
The goal is to have as little vulnerability to timedrift as possible, while not compromising the ability to stake. Blackcoin and all of its derivatives are using 16 second timedrift now. I am using 60 second for HyperStake. But would think something along the lines of 3 minutes would work well for MINT.

PressTab - Can you give us three recommended timedrift parameters from high to low and explain how the timedrift will affect the coins speed / confirmation time on the exchanges / security benefits

I would like to have these decisions finalized by the end of the day so PressTab can begin phase 1 of the wallet.



Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 03, 2015, 01:59:51 PM
 #18123



Keep in mind that the code adjusts each nodes time. So you could be over 30 seconds out of time but still be issuing the correct timestamps to the network when you stake.

Yeah. This is why I'm not too worried about it. I mean occasionally there may be a leap second, (not sure if that would affect it). I think there was one a few days ago actually to get universal standard time back in being correct with the suns alignment.

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

Activity: 23
Merit: 0


View Profile
July 03, 2015, 02:06:01 PM
 #18124

Kind of off topic but I'm an owner of mintcoin and a developer so I thought I'd try to go through the code. I've downloaded the code and I was going to build it but I wonder what the recommended IDE is.  Are you guys use QT-Creator?  That's what robo guy said he was using.  I'm mostly a windows guy.  Is it possible to successfully build the mintcoin wallet in windows or is that not recommended?  Thanks is advance.
Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 03, 2015, 02:07:47 PM
 #18125

Before selling all my Mintcoin before they go on to reach 200 Sat or whatever I did think that someone should demonstrate this attack before hard forking and changing the fast confirming parameters of Mintcoin.  But regardless let's look at strategy first in terms of how Mintcoin co-exists with other cryptos. Let's say Bitcoin is your 'Reserve Crypto' which is a standard bearer for cryptos as a usable and practical currency alternative in a 21st century environment. The scheme I proposed for http://poisonedchalice.io for instance, supposes that a stable currency with a 4 billion dollar market cap is mature enough to leverage for some fixed term investment over a four year period. You want Bitcoin to be relatively stable as the lynchpin to this kind of financial product (stable after a 2015 Q4 correction, that is).

Mintcoin on the other hand, can adopt a slower confirmation time, IF it is leaning more towards the investment side of things, and less towards the Point of Sale transactions/merchant space. This space is better filled by something like Zetacoin or Quark, which are superior alternatives to Bitcoin in this instance, held back only by a lack of productive community output and shallow trading volumes at this stage. But these are not POS coins, maybe you want to stick a percentage of savings into a POS coin and security becomes much more important.  So if an answer to timedrift is to increase the confirmation time, that means you are making a trade off where Mintcoin becomes more secure at the loss of 30, 60, 90 seconds on average (or whatever it is) each time you shift it around. I think that's a trade off most community members would be happy to make.  Personally I have just got 4 BTC out of Mintcoin, but, that's after buying and holding over the space of a year or so (I'll buy back under 29 Sat and before another rate drop) so as you can see fast confirmation times haven't really been all that important so far.

I agree on that note - one thing we should not alter is the speed of Mintcoin - Its flipping amazing and extremely helpful whether sending / receiving to exchanges or a friend. We need the speed.

Have you or any of the community ever put any though into reducing the target block time? Current looks like 30 seconds. My concern would be long term syncability of the chain. It isn't too easy to sync it at the current 1.5 million blocks, and a few years from now it will be even harder. Raising the block time could be a beneficial long term change to throw in while a hard fork occurs.
This sounds very sensible to me with the understanding that our block chain is going to continue to grow - questions?

  • is it any less secure and why / why not?
    will this affect the speed of the coin in transactions (including confirmations)
  • Does it require a hard fork

I would say that mints biggest security risk is the 2 hour time drift allowance. Read about the vulnerability here http://bitcoinist.net/interview-presstab-pos-vulnerabilities/
The goal is to have as little vulnerability to timedrift as possible, while not compromising the ability to stake. Blackcoin and all of its derivatives are using 16 second timedrift now. I am using 60 second for HyperStake. But would think something along the lines of 3 minutes would work well for MINT.

PressTab - Can you give us three recommended timedrift parameters from high to low and explain how the timedrift will affect the coins speed / confirmation time on the exchanges / security benefits

I would like to have these decisions finalized by the end of the day so PressTab can begin phase 1 of the wallet.
30 block time translates to 30 second confirmations. As far as I know, we are all in consensus we are not going to change that.
What we were talking about earlier is increasing how many confirmations are required as the network standard. 4 which mintcoin currently us at is very low (low security). An attacker, would only need to control the network for 2 minutes in order to 51% attack it.  Increasing the # of confirmations to 40 would be exponentially more secure.

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

Activity: 1316
Merit: 1000


Pivx Core Developer - HyperStake Founder


View Profile
July 03, 2015, 02:14:00 PM
 #18126



Keep in mind that the code adjusts each nodes time. So you could be over 30 seconds out of time but still be issuing the correct timestamps to the network when you stake.

Yeah. This is why I'm not too worried about it. I mean occasionally there may be a leap second, (not sure if that would affect it). I think there was one a few days ago actually to get universal standard time back in being correct with the suns alignment.

The underlying security flaw really doesn't have anything to do with whether or not nodes are correctly in sync. The conversation about whats the correct time drift to use is more about security update than it is about having the perfect balance of time.

I think 15/30 should work well. How much longer do you guys want to delay this? I have already started coding it in, but can hold off any final commits until there is a clear consesus about the hashdrift, interval, and fork time.

presstab's Block Explorer Service | available 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
URSAY
Legendary
*
Offline Offline

Activity: 1932
Merit: 1000



View Profile
July 03, 2015, 02:56:04 PM
 #18127

Is this code already implemented in other coins?

If yes, which?
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425
Merit: 250


View Profile
July 03, 2015, 03:15:43 PM
 #18128

Is this code already implemented in other coins?

If yes, which?

PressTab has implemented this code in his own personal project HyperStake - another great coin making headway
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425
Merit: 250


View Profile
July 03, 2015, 03:19:54 PM
 #18129

I think 15/30 should work well. How much longer do you guys want to delay this? I have already started coding it in, but can hold off any final commits until there is a clear consesus about the hashdrift, interval, and fork time.

Please continue with 15/30 listening to the community this seems to be the most agreed upon. Once this is completed SupaSonic will implement the GUI modifications while I contact the exchanges with the raw wallet (only modification including the fork)

For the time please allow 30 days - this should give me plenty of time to work with the exchanges - they usually take 15 days or so to complete upgrades. I can also let them know when the expected fork will happen.

RoboGuy stuck in a network alert a few upgrades ago - please make sure to update the message to alert everyone when they open the wallet to upgrade to the newest version to help us get out the message.

Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 03, 2015, 04:24:07 PM
 #18130

Is this code already implemented in other coins?

If yes, which?

PressTab has implemented this code in his own personal project HyperStake - another great coin making headway
Cool beans was referring to suprasonics statistics coding, not presstab timedrift coding.

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

Activity: 357
Merit: 250



View Profile
July 03, 2015, 04:26:38 PM
 #18131

I think 15/30 should work well. How much longer do you guys want to delay this? I have already started coding it in, but can hold off any final commits until there is a clear consesus about the hashdrift, interval, and fork time.

Please continue with 15/30 listening to the community this seems to be the most agreed upon. Once this is completed SupaSonic will implement the GUI modifications while I contact the exchanges with the raw wallet (only modification including the fork)

For the time please allow 30 days - this should give me plenty of time to work with the exchanges - they usually take 15 days or so to complete upgrades. I can also let them know when the expected fork will happen.

RoboGuy stuck in a network alert a few upgrades ago - please make sure to update the message to alert everyone when they open the wallet to upgrade to the newest version to help us get out the message.


Sounds good. I guess the higher the price goes the more secure it is too, by making it harder more consequential to attack, so that's a good thing.

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

Activity: 425
Merit: 250


View Profile
July 03, 2015, 04:28:57 PM
 #18132

Cool beans was referring to suprasonics statistics coding, not presstab timedrift coding.

Dope! Gotcha

The statistics coding is something I have been trying to figure out for awhile now - If this does not interfere with the wallet itself I would love to test it out (especially if we can swap if need be back without a hard fork)
Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 03, 2015, 04:46:36 PM
 #18133

So the fork will be at about 85,000 blocks from now?

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

Activity: 425
Merit: 250


View Profile
July 03, 2015, 04:51:05 PM
 #18134

So basically it will just be 5% gain per year forever. Cool. I actually think that is better because it will always motivate people to keep minting. Like a goid savings bond not too low, but not too high. BTW, Mintcoin just hit a new all time high.  80 sats! ^ ^

Indeed RoboGuy pointed this out to me when he first started and we agreed to leave it - this will make up for the coins "lost" for whatever reason. Mintpal.com (no relations to Mintcoin) was holding a significant amount of coins when they went under. We have no idea if those coins were lost of cashed out.
presstab
Legendary
*
Offline Offline

Activity: 1316
Merit: 1000


Pivx Core Developer - HyperStake Founder


View Profile
July 03, 2015, 04:53:18 PM
 #18135

So the fork will be at about 85,000 blocks from now?

I am coding in the fork as we speak. I have set it for:
Code:
static const unsigned int FORK_TIME = 1438444800; // Sat, 01 Aug 2015 16:00:00 GMT

This is a time and date when I will be available to provide some QR code if needed (quick response Tongue )

Watch https://github.com/presstab/Mintcoin-Desktop-Wallet/commits/master today if you want to watch the fork commits. It will be merged with the main mintcoin repo after proper scrutiny.


presstab's Block Explorer Service | available 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
Crestington
Legendary
*
Offline Offline

Activity: 868
Merit: 1020



View Profile
July 03, 2015, 06:00:03 PM
 #18136

So the fork will be at about 85,000 blocks from now?

I am coding in the fork as we speak. I have set it for:
Code:
static const unsigned int FORK_TIME = 1438444800; // Sat, 01 Aug 2015 16:00:00 GMT

This is a time and date when I will be available to provide some QR code if needed (quick response Tongue )

Watch https://github.com/presstab/Mintcoin-Desktop-Wallet/commits/master today if you want to watch the fork commits. It will be merged with the main mintcoin repo after proper scrutiny.



I would suggest that if coding in a fork to also bump the protocol number and reject old clients once the fork is in effect. Even if the fork is set a month in advance, there are many that would not upgrade and will just use their old client and this can lead to chain conflicts, stuck blocks. If you reject old protocols then they will not be able to sync with the rest of the network, this is fine because if someone cannot sync, they will come here anyways and ask why, realize they need to be on the latest version and upgrade and back up to speed. If you do not reject old clients then they may be able to sync, it won't be apparent they need to upgrade and won't so it's best not to allow that to happen.

You can add it to the main.cpp file and Block old clients based on time and protocol number, this is an example from PayCon.

        if (nTime > 1430124800 && pfrom->nVersion < 70122)
        {
            // Since February 20, 2012, the protocol is initiated at version 209,
            // and earlier versions are no longer supported
            printf("partner %s using obsolete version %i; disconnecting\n", pfrom->addr.ToString().c_str(), pfrom->nVersion);
            pfrom->fDisconnect = true;
            return false;
        }
Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 03, 2015, 06:53:04 PM
 #18137

So the fork will be at about 85,000 blocks from now?

I am coding in the fork as we speak. I have set it for:
Code:
static const unsigned int FORK_TIME = 1438444800; // Sat, 01 Aug 2015 16:00:00 GMT

This is a time and date when I will be available to provide some QR code if needed (quick response Tongue )

Watch https://github.com/presstab/Mintcoin-Desktop-Wallet/commits/master today if you want to watch the fork commits. It will be merged with the main mintcoin repo after proper scrutiny.



Does it happen according to a specific date or a specific block? Im a little confused.

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

Activity: 4
Merit: 0


View Profile
July 03, 2015, 07:03:54 PM
 #18138

So the fork will be at about 85,000 blocks from now?

I am coding in the fork as we speak. I have set it for:
Code:
static const unsigned int FORK_TIME = 1438444800; // Sat, 01 Aug 2015 16:00:00 GMT

This is a time and date when I will be available to provide some QR code if needed (quick response Tongue )

Watch https://github.com/presstab/Mintcoin-Desktop-Wallet/commits/master today if you want to watch the fork commits. It will be merged with the main mintcoin repo after proper scrutiny.



Does it happen according to a specific date or a specific block? Im a little confused.

Specific block. Estimated date.
supasonic
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
July 03, 2015, 07:15:11 PM
 #18139

Kind of off topic but I'm an owner of mintcoin and a developer so I thought I'd try to go through the code. I've downloaded the code and I was going to build it but I wonder what the recommended IDE is.  Are you guys use QT-Creator?  That's what robo guy said he was using.  I'm mostly a windows guy.  Is it possible to successfully build the mintcoin wallet in windows or is that not recommended?  Thanks is advance.

I code on Mint! The Debian version, a linux distro, using qtCreator and sublime. It can be done on windows using minGW but its an involved process which makes you think like a linux user. At that point just become one with virtualbox and any free distro.

Sticking with windows I saw a thread that may be helpful in trying it.
https://bitcointalk.org/index.php?topic=149479.0

I am working on a guide for a partner getting into crypto and linux. Might just post that when its done.
mchrist152
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
July 03, 2015, 07:20:23 PM
 #18140

So the fork will be at about 85,000 blocks from now?

I am coding in the fork as we speak. I have set it for:
Code:
static const unsigned int FORK_TIME = 1438444800; // Sat, 01 Aug 2015 16:00:00 GMT

This is a time and date when I will be available to provide some QR code if needed (quick response Tongue )

Watch https://github.com/presstab/Mintcoin-Desktop-Wallet/commits/master today if you want to watch the fork commits. It will be merged with the main mintcoin repo after proper scrutiny.



I would suggest that if coding in a fork to also bump the protocol number and reject old clients once the fork is in effect. Even if the fork is set a month in advance, there are many that would not upgrade and will just use their old client and this can lead to chain conflicts, stuck blocks. If you reject old protocols then they will not be able to sync with the rest of the network, this is fine because if someone cannot sync, they will come here anyways and ask why, realize they need to be on the latest version and upgrade and back up to speed. If you do not reject old clients then they may be able to sync, it won't be apparent they need to upgrade and won't so it's best not to allow that to happen.

You can add it to the main.cpp file and Block old clients based on time and protocol number, this is an example from PayCon.

        if (nTime > 1430124800 && pfrom->nVersion < 70122)
        {
            // Since February 20, 2012, the protocol is initiated at version 209,
            // and earlier versions are no longer supported
            printf("partner %s using obsolete version %i; disconnecting\n", pfrom->addr.ToString().c_str(), pfrom->nVersion);
            pfrom->fDisconnect = true;
            return false;
        }


I agree with this completely.  People don't always pay attention to wallet releases and if the wallet appears to be working normally they just let it go.  This will let them know that they need to upgrade.
Pages: « 1 ... 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 955 956 957 ... 1035 »
  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!