I don't think going blackcoin is really on the table at the moment. And honestly if it is, someone can add that on top of my commits.

So what we now need to decide is if the final decision is 15 second hashdrift/interval and a 30 second timedrift allowance. The other item that will need to be decided is when this fork will occur. MINT is large enough and has enough people and companies running nodes, that it should be at a few weeks from now. This will be a hard fork, so a protocol change cutting off nodes that haven't updated. If we don't cut off all old nodes, then they will get on an incorrect chain and will still be connected to the real chain's nodes and will exhaust their resources by requesting the same thing over and over. Its possible to pull this off in a "soft" approach, but the memory and bandwidth exhaustion is not nearly worth it.

Agreed - We have allot of work to do on top of the fork in order to ensure that we provide the best possible user experience for the community during the transition to the new wallet. Once PressTab has completed his changes we will need to test out the changes in a private group - during that time supasonic has volunteered to add the GUI modifications for the following:

make repairwallet easier to find (under Help) When the wallet opens it would be nice to have the client choose between import wallet or create new wallet. Require verification of password when sending mintcoins - if password option is enabled

He is also researching this comment:

As for syncing time, dooglus from CLAM has made a very interesting commit this last week that I want to play around with. It has to do with bootstrap files that are not all in one file. For example a bootstrap that is block 1-100k, 100k-200k, etc. This adds the ability to start with the appropriate bootstrap file if you are partially synced. I haven't toyed around with it enough yet, but it shows promise.

Once those changes are implemented and tested we will need a mass distribution to exchanges and community members.

The fork will need to be out long enough to ensure we complete all of these tasks for the community members to ensure there are minimal bad vibes during the upgrade.

Do you think 30 days is enough time for the fork for exchanges & community members?

We can send the exchanges a heads up now with a fork estimated date so they can plan ahead and ensure the manpower is available to make the change.

At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.

Seems reasonable, go for it....

DNotesVault“First, they ignore you. Then, they laugh at you. Then, they fight you. Then you win!” – Mahatma Gandhi Prepare for your future now, check out CRISP For Retirement and our complete family of CRISP savings plans.

At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.

Sounds good to me.

Presstab, have you had a chance to look at the code and verify the situation regarding any coin cap?

Yes I looked, sorry forgot to reply to this particular issue. It looks like it is as I expected, and the "max coins" doesn't have anything to do with controlling rewards at a particular point in time, and is simply a cap on the maximum transaction amount allowed for the network.

At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.

Sounds good to me.

Presstab, have you had a chance to look at the code and verify the situation regarding any coin cap?

Yes I looked, sorry forgot to reply to this particular issue. It looks like it is as I expected, and the "max coins" doesn't have anything to do with controlling rewards at a particular point in time, and is simply a cap on the maximum transaction amount allowed for the network.

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! ^ ^

At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.

Sounds good to me.

Presstab, have you had a chance to look at the code and verify the situation regarding any coin cap?

Yes I looked, sorry forgot to reply to this particular issue. It looks like it is as I expected, and the "max coins" doesn't have anything to do with controlling rewards at a particular point in time, and is simply a cap on the maximum transaction amount allowed for the network.

If that is the case, we need to update the announcement page to be clear, and any place that gives the coin description.

Edit: I updated it on Reddit.

(1.) Moral happiness depends upon moral order.(2.) Moral order depends upon the harmonious action of all our powers, asindividuals and as members of society.

Great work by Presstab on researching. Hoping for everything to go smoothly in testing. Finally we are going forward with patching important vulnerabilities & improving UI, thanks to effort of CryptoMommy & other active members. Thanks to @Kiklo for suggesting Presstab as dev for these changes. I am really happy to see this thread updated with latest discussion which was not happening previously. Thanks to all

Hello Everyone. Just been updating myself on the discussion. I spoke with cryptomommy about the UI changes and have a few ideas for the update.

I noticed that a lot of the code is from an early Peercoin fork. Big project to bring it more inline with more recent ideas and revelations. I want to propose adding some statistical gathering code to in a point release before the fork so we can see how blocks are propagating through the network, this way we can see how much time drift is reflected and which limit is best. At this point any lower number is better than two hours but what would be best for MintCoin? Lets find out! I'm working on the UI commits and want to add the data collection as well.

A later and bigger project would be bringing down some memory usage and sync times by packing the block chain into chunks and hashing them and and distributing them among the peers building the db during some idle cycles later. Any ideas or examples of that would be appreciated as I said, it would be a big project.

I'm also taking request for other idea as coding work for me slows down this time of year. I love the Idea of MintCoin and want to see it succeed.

Hello Everyone. Just been updating myself on the discussion. I spoke with cryptomommy about the UI changes and have a few ideas for the update.

I noticed that a lot of the code is from an early Peercoin fork. Big project to bring it more inline with more recent ideas and revelations. I want to propose adding some statistical gathering code to in a point release before the fork so we can see how blocks are propagating through the network, this way we can see how much time drift is reflected and which limit is best. At this point any lower number is better than two hours but what would be best for MintCoin? Lets find out! I'm working on the UI commits and want to add the data collection as well.

A later and bigger project would be bringing down some memory usage and sync times by packing the block chain into chunks and hashing them and and distributing them among the peers building the db during some idle cycles later. Any ideas or examples of that would be appreciated as I said, it would be a big project.

I'm also taking request for other idea as coding work for me slows down this time of year. I love the Idea of MintCoin and want to see it succeed.

Thanks for any input

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.

(1.) Moral happiness depends upon moral order.(2.) Moral order depends upon the harmonious action of all our powers, asindividuals and as members of society.

Hello Everyone. Just been updating myself on the discussion. I spoke with cryptomommy about the UI changes and have a few ideas for the update.

I noticed that a lot of the code is from an early Peercoin fork. Big project to bring it more inline with more recent ideas and revelations. I want to propose adding some statistical gathering code to in a point release before the fork so we can see how blocks are propagating through the network, this way we can see how much time drift is reflected and which limit is best. At this point any lower number is better than two hours but what would be best for MintCoin? Lets find out! I'm working on the UI commits and want to add the data collection as well.

A later and bigger project would be bringing down some memory usage and sync times by packing the block chain into chunks and hashing them and and distributing them among the peers building the db during some idle cycles later. Any ideas or examples of that would be appreciated as I said, it would be a big project.

I'm also taking request for other idea as coding work for me slows down this time of year. I love the Idea of MintCoin and want to see it succeed.

Thanks for any input

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.

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.

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.

We are not talking about changing the confirmation time. Just the number of confirmations. Confirmation time will stay at 30 seconds which is still 20x faster than Bitcoin. You don't personally have to wait for all of the confirmations to know that it's going through, often after the first couple you know it's probably going to be all good and you can move along. Example, you initiate a transaction and in 30 seconds it is confirmed. Even with 40 confirmations, all 40 will complete in 20 minutes, which is still 3x faster than Bitcoin.

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.

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.

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.

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.

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.

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.

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.

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.

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.