Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained] - page 131. (Read 1369788 times)

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;
        }

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

I am coding in the fork as we speak. I have set it for:

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

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 am coding in the fork as we speak. I have set it for:

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

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.

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

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

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.

If yes, which?

Is this code already implemented in other coins?

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.

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.