[ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained] - page 132.

cryptomommy

sr. member

Activity: 425

Merit: 250

Quote from: dragonseer on July 02, 2015, 11:29:04 PM

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

Activity: 356

Merit: 250

Quote from: supasonic on July 03, 2015, 08:21:06 AM

Quote from: coolbeans94 on July 02, 2015, 10:44:26 PM

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.

presstab

legendary

Activity: 1330

Merit: 1000

Blockchain Developer

Quote from: supasonic on July 03, 2015, 08:21:06 AM

Quote from: coolbeans94 on July 02, 2015, 10:44:26 PM

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.

supasonic

newbie

Activity: 4

Merit: 0

Quote from: coolbeans94 on July 02, 2015, 10:44:26 PM

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.

Derek492

sr. member

Activity: 356

Merit: 250

Quote from: dragonseer on July 02, 2015, 11:29:04 PM

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.

dragonseer

hero member

Activity: 611

Merit: 500

Anglo Saxon Crypto Enthusiast

Quote from: coolbeans94 on July 02, 2015, 10:44:26 PM

Quote from: supasonic on July 02, 2015, 07:34:32 PM

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.

coolbeans94

hero member

Activity: 613

Merit: 500

Mintcoin: Get some

Quote from: supasonic on July 02, 2015, 07:34:32 PM

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.

supasonic

newbie

Activity: 4

Merit: 0

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

sambiohazard

hero member

Activity: 840

Merit: 1000

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

coolbeans94

hero member

Activity: 613

Merit: 500

Mintcoin: Get some

Quote from: presstab on July 02, 2015, 11:45:28 AM

Quote from: coolbeans94 on July 02, 2015, 11:10:34 AM

Quote from: Derek492 on July 02, 2015, 10:24:20 AM

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.

Flyskyhigh

sr. member

Activity: 291

Merit: 250

Ezekiel 34:11, John 10:25-30

Quote from: presstab on July 02, 2015, 11:45:28 AM

Quote from: coolbeans94 on July 02, 2015, 11:10:34 AM

Quote from: Derek492 on July 02, 2015, 10:24:20 AM

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

presstab

legendary

Activity: 1330

Merit: 1000

Blockchain Developer

Quote from: coolbeans94 on July 02, 2015, 11:10:34 AM

Quote from: Derek492 on July 02, 2015, 10:24:20 AM

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.

coolbeans94

hero member

Activity: 613

Merit: 500

Mintcoin: Get some

I'm positive if we pull this off mintcoin is going to soar and may one day even overtake bitcoin itself.

RJF

hero member

Activity: 616

Merit: 500

Online since '89...

Quote from: Derek492 on July 02, 2015, 10:24:20 AM

Quote from: cryptomommy on July 02, 2015, 06:58:10 AM

Quote from: presstab on July 01, 2015, 11:30:11 PM

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

coolbeans94

hero member

Activity: 613

Merit: 500

Mintcoin: Get some

Quote from: Derek492 on July 02, 2015, 10:24:20 AM

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?

Derek492

sr. member

Activity: 356

Merit: 250

Quote from: cryptomommy on July 02, 2015, 06:58:10 AM

Quote from: presstab on July 01, 2015, 11:30:11 PM

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.

litemaster

full member

Activity: 169

Merit: 100

Quote from: I2S2SI on July 01, 2015, 08:10:52 PM

Quote from: sambiohazard on July 01, 2015, 08:07:14 PM

Quote from: I2S2SI on July 01, 2015, 07:44:48 PM

How long before my coins in wallet start minting?

They been maturing for 2 days now

It takes them 20 days to become mature for minting.

Fucking hell...

I know right? Huh

? I have answered this question a few time myself on here. The site need to put this featured more prominently or something.

cryptomommy

sr. member

Activity: 425

Merit: 250

Quote from: presstab on July 01, 2015, 11:30:11 PM

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.

sambiohazard

hero member

Activity: 840

Merit: 1000

Here is why i don't like the current arrangement of people coming online once in 20 days or expecting rewards for keeping coins in their wallet while not securing the network. Also this explains why who invest more should be rewarded proportionately.

http://shreysfinanceblog.com/2015/06/24/why-socialism-fails/

sambiohazard

hero member

Activity: 840

Merit: 1000

Quote from: Derek492 on July 02, 2015, 12:43:11 AM

I understand your point, but I would rather increase confirmations to increase security, than reduce the amount of people able to mint. Confirmations is the other way to accomplish the same security goal. Mintcoin is about minting, and if people cannot stake/mint then I think you will lose a lot of potential users right there.

Thanks for understanding. The issue you are discussing is timewarp attack which will be solved by discussed adjustments. I am talking about low network weight which wont be solved by these adjustments. We need people to remain online to strengthen the network.

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