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

[sambiohazard]

Nice to see that we have a dev (thanks Presstab) and lots of talk is going on to fix lots of issues. Here are my 2 cents on

Block Time Issue

I think 30 seconds block time is good & one of the +ve points of MINT. We just need to upload either a torrent or sync file every week. Also, alternate clients like electrum or MultiMINT might not help because AFAIK you can't mint with them.

Timewarp Issue

I dont know much about it so i guess experts have pretty much sorted it out and will take right decision.

Mintcoin Central

Just a reminder to people that I bought the www.mintcoin-central.com domain from the old developer, and I have all the assets for the old site in wordpress format. Now that mintcoin is going so strong, maybe we can table some ideas for what this website can do that would be of benefit to mintcoin.

This whole debacle in Greece, where banks have shuttered and have tiny daily withdrawal limits, really shows how important something like Mintcoin is. We can leave it to Bitcoin to advocate for Cryptos in general and have infastructure in place, while Mintcoin can quietly generate interest and make gains for people that know about it, but what can a new site do to help bring 'Mintcoin to the masses' so to speak?

I will suggest that we publish weekly/monthly updates on our partnerships with charities and show the progress of various fundraisers. This will give new investors/adopters a reason other than speculation to invest in the coin. It will give whole coin a purpose that will be visible and will garner attention of wider non-crypto public.

I would also remid every one to donate to cryptoID block explorer. I am doing a 0.01 BTC every week there. If some other contribution come in & we have hosting for say 6 months then i can send same amount to dev bounty.

Regards

Sam

[1714045060]

1714045060

[1714045060]

1714045060

[1714045060]

1714045060

[sambiohazard]

I am so happy to see such deep discussion. Thanks to all of you

[Derek492]

Regarding the timewarp issue:
I think we should keep it as simple as possible and keep with using more even numbers. I propose 20 seconds for hashdrift, and 30 seconds for timedrift. Open to other opinions though. Just out of curiosity, how is Blackcoin's timedrift and hashdrift setup? Someone said they have a 15 second timedrift....so what is their hashdrift set at? 

[presstab]

Sounds like the block time of 30 seconds for MINT is something that most of you consider enough of the coin's personality, that it would really change too much if that was altered.

Concerning drift. Blackcoin uses a 1 second search interval. Hashdrift is a term I have created myself, as an easier way to describe things to people. So if you see anyone, or the code itself, refer to search interval then think "hashdrift".

So blackcoin and the derivatives of it, will loop through the staking process every second, and look only at only one second worth of timestamps at a time. It isn't really all that different from MINT's current system, except that as is MINT will scan the first 60 timestamps, and then hash each new second at a time.

[coolbeans94]

Sounds like the block time of 30 seconds for MINT is something that most of you consider enough of the coin's personality, that it would really change too much if that was altered.

Concerning drift. Blackcoin uses a 1 second search interval. Hashdrift is a term I have created myself, as an easier way to describe things to people. So if you see anyone, or the code itself, refer to search interval then think "hashdrift".

So blackcoin and the derivatives of it, will loop through the staking process every second, and look only at only one second worth of timestamps at a time. It isn't really all that different from MINT's current system, except that as is MINT will scan the first 60 timestamps, and then hash each new second at a time.

Interesting. I like the term.
So they essentially have their timedrift 15 seconds after their hashdrift (search interval). Correct?
If that seems to work, then we probably want to have 15 seconds more for the timedrift as well.

In light of the above, and past discussions, it seems to me, what would work well for Mintcoin, is to do 15 second hashdrift (search interval) and a a 30 second timedrift.  That seems to cover all the bases now.   

[sambiohazard]

Sounds like the block time of 30 seconds for MINT is something that most of you consider enough of the coin's personality, that it would really change too much if that was altered.

Concerning drift. Blackcoin uses a 1 second search interval. Hashdrift is a term I have created myself, as an easier way to describe things to people. So if you see anyone, or the code itself, refer to search interval then think "hashdrift".

So blackcoin and the derivatives of it, will loop through the staking process every second, and look only at only one second worth of timestamps at a time. It isn't really all that different from MINT's current system, except that as is MINT will scan the first 60 timestamps, and then hash each new second at a time.

Does this also affect the CPU & RAM usage, if i am getting this right, it has to keep 60 timestamps/blocks in RAM thus more RAM usage. I have seen that coins on POS 1.0 which have low block interval, consume a lot of RAM & CPU. For example UTC & MINT both use 625+ MB of RAM & 2-10% of a quad core at regular intervals.

[coolbeans94]

Sounds like the block time of 30 seconds for MINT is something that most of you consider enough of the coin's personality, that it would really change too much if that was altered.

Concerning drift. Blackcoin uses a 1 second search interval. Hashdrift is a term I have created myself, as an easier way to describe things to people. So if you see anyone, or the code itself, refer to search interval then think "hashdrift".

So blackcoin and the derivatives of it, will loop through the staking process every second, and look only at only one second worth of timestamps at a time. It isn't really all that different from MINT's current system, except that as is MINT will scan the first 60 timestamps, and then hash each new second at a time.

Does this also affect the CPU & RAM usage, if i am getting this right, it has to keep 60 timestamps/blocks in RAM thus more RAM usage. I have seen that coins on POS 1.0 which have low block interval, consume a lot of RAM & CPU. For example UTC & MINT both use 625+ MB of RAM & 2-10% of a quad core at regular intervals.

Makes sense to me, that reducing it like we are discussing would lower the CPU & RAM.

[sambiohazard]

Sounds like the block time of 30 seconds for MINT is something that most of you consider enough of the coin's personality, that it would really change too much if that was altered.

Concerning drift. Blackcoin uses a 1 second search interval. Hashdrift is a term I have created myself, as an easier way to describe things to people. So if you see anyone, or the code itself, refer to search interval then think "hashdrift".

So blackcoin and the derivatives of it, will loop through the staking process every second, and look only at only one second worth of timestamps at a time. It isn't really all that different from MINT's current system, except that as is MINT will scan the first 60 timestamps, and then hash each new second at a time.

Does this also affect the CPU & RAM usage, if i am getting this right, it has to keep 60 timestamps/blocks in RAM thus more RAM usage. I have seen that coins on POS 1.0 which have low block interval, consume a lot of RAM & CPU. For example UTC & MINT both use 625+ MB of RAM & 2-10% of a quad core at regular intervals.

Makes sense to me, that reducing it like we are discussing would lower the CPU & RAM.

Cool, that would be good side effect/added benefit!!

[presstab]

If my assumptions are correct it will have no impact on RAM or on CPU.

Although it hashes the first 60 hashes * the amount of mature unspent outputs you have, those hashes are all destroyed the second the code leaves the scope of CheckKernelStakeHash(), as this is how c++ works.

The current code hashes the first 60 seconds, then hashes timestamp 61 after one second passes, then 62 after two seconds pass, etc. Not 60 hashes each time (or else if it is doing so, it is not designed to be this way).

MINT has a very very old codebase, that hasn't been updated much in terms of efficiency, as well as a huge blockchain. The pool of unspent outputs for the entire network is stored in your RAM, thus this means a large amount of ram for an old chain with lost coins or lots of cold storage outputs. The CPU usage is probably a combination of all these items.

[sambiohazard]

so to reduce the RAM usage we need everyone to consolidate there outputs into bigger less numerous outputs.

[coolbeans94]

If my assumptions are correct it will have no impact on RAM or on CPU.

Although it hashes the first 60 hashes * the amount of mature unspent outputs you have, those hashes are all destroyed the second the code leaves the scope of CheckKernelStakeHash(), as this is how c++ works.

The current code hashes the first 60 seconds, then hashes timestamp 61 after one second passes, then 62 after two seconds pass, etc. Not 60 hashes each time (or else if it is doing so, it is not designed to be this way).

MINT has a very very old codebase, that hasn't been updated much in terms of efficiency, as well as a huge blockchain. The pool of unspent outputs for the entire network is stored in your RAM, thus this means a large amount of ram for an old chain with lost coins or lots of cold storage outputs. The CPU usage is probably a combination of all these items.

What do you recommend to improve efficiency specifically how to cut back on RAM usage? I've noticed this too that very gradually the RAM usage has tended to rise.

[Derek492]

If my assumptions are correct it will have no impact on RAM or on CPU.

Although it hashes the first 60 hashes * the amount of mature unspent outputs you have, those hashes are all destroyed the second the code leaves the scope of CheckKernelStakeHash(), as this is how c++ works.

The current code hashes the first 60 seconds, then hashes timestamp 61 after one second passes, then 62 after two seconds pass, etc. Not 60 hashes each time (or else if it is doing so, it is not designed to be this way).

MINT has a very very old codebase, that hasn't been updated much in terms of efficiency, as well as a huge blockchain. The pool of unspent outputs for the entire network is stored in your RAM, thus this means a large amount of ram for an old chain with lost coins or lots of cold storage outputs. The CPU usage is probably a combination of all these items.

What do you recommend to improve efficiency specifically how to cut back on RAM usage? I've noticed this too that very gradually the RAM usage has tended to rise.

Would creating a new Genesis block  help with this and cut down the RAM?

[presstab]

If my assumptions are correct it will have no impact on RAM or on CPU.

Although it hashes the first 60 hashes * the amount of mature unspent outputs you have, those hashes are all destroyed the second the code leaves the scope of CheckKernelStakeHash(), as this is how c++ works.

The current code hashes the first 60 seconds, then hashes timestamp 61 after one second passes, then 62 after two seconds pass, etc. Not 60 hashes each time (or else if it is doing so, it is not designed to be this way).

MINT has a very very old codebase, that hasn't been updated much in terms of efficiency, as well as a huge blockchain. The pool of unspent outputs for the entire network is stored in your RAM, thus this means a large amount of ram for an old chain with lost coins or lots of cold storage outputs. The CPU usage is probably a combination of all these items.

What do you recommend to improve efficiency specifically how to cut back on RAM usage? I've noticed this too that very gradually the RAM usage has tended to rise.

There may be a few areas in the code that have some unpatched memory leaks, but these are fairly small leaks, and the bulk of the RAM usage is not really reversible. Its the fact that there are so many unused outputs in the RAM. So its my opinion that the majority of the RAM consumption will be here to stay, unless you go chain swap which in my opinion should be a last resort reserved for emergencies or disfunctionally large chains.

[Derek492]

Yeah. In my opinion the RAM issue is less critical. I think we do need to patch the timewarp issue and maybe increase the confirmations at this point. Probably anything else can wait for now. Beefing up the security of the coin is the main thing. Is everyone in agreement on that?

I think 15 second hashdrift with 30 second timedrift, and bumping up from 4 to 40 confirmations sounds good to me. I would only increase the confirmations required for new coins that are staking from 50 to maybe 100 confirmations, or it will take over an hour to use any newly minted coins.

[sambiohazard]

+1 from me. Security is of utmost importance. Also I would like to hear Presstab's thoughts on POS 2.0 adoption as it is also related to security.

[Derek492]

+1 from me. Security is of utmost importance. Also I would like to hear Presstab's thoughts on POS 2.0 adoption as it is also related to security.

The reason I am against that is because it involves lowering the minimum waiting time in order to stake. I would much rather increase confirmations instead, which increases security without compromising stakabilty.

[sambiohazard]

+1 from me. Security is of utmost importance. Also I would like to hear Presstab's thoughts on POS 2.0 adoption as it is also related to security.

The reason I am against that is because it involves lowering the minimum waiting time in order to stake. I would much rather increase confirmations instead, which increases security without compromising stakabilty.

I am not sure how low waiting time compromises staking. You get smaller but more frequent rewards. Its all about how you see it. For those who are looking at it as a long term investment which they will sit on would like current scheme but if you want to spend your coins then having long wait times will compromise your overall rewards as you spend. Also, there is issue of people not staking 24x7 but still getting rewards for it. When you are offline you are not securing the network/adding to network weight.

[coolbeans94]

+1 from me. Security is of utmost importance. Also I would like to hear Presstab's thoughts on POS 2.0 adoption as it is also related to security.

The reason I am against that is because it involves lowering the minimum waiting time in order to stake. I would much rather increase confirmations instead, which increases security without compromising stakabilty.

I am not sure how low waiting time compromises staking. You get smaller but more frequent rewards. Its all about how you see it. For those who are looking at it as a long term investment which they will sit on would like current scheme but if you want to spend your coins then having long wait times will compromise your overall rewards as you spend. Also, there is issue of people not staking 24x7 but still getting rewards for it. When you are offline you are not securing the network/adding to network weight.

It compromises the number of people or the number of balances that are able to stake.
You only stake if you find a block and are only so many blocks in a given period of time. If you lower the waiting period before you can stake again, then it queezes out people with lower balances from being able to stake and get a block. With a 20 day waiting period, it allows for roughly 57,600 stakes before those same coins can stake again, (30 second block time x 20 days). If we lowered it to say 1 day, then only the top 2,880 coin weights would stake, then it will cycle over again, and likely be those same 2,880 addresses once again that stake.

[presstab]

I don't really love "PoS2.0". I think stake weight is a well though out system, and when it is properly implemented it is quite safe.

[I2S2SI]

How long before my coins in wallet start minting?

They been maturing for 2 days now