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

[MarSas]

It's better to ask what is going on @Polo

[1713533476]

1713533476

[1713533476]

1713533476

[1713533476]

1713533476

[1713533476]

1713533476

[skyline_king]

this block chain taking to long to download.. most coin 2 years old take 2-3 days max this has now been 6 days and still only half done... it is not gonna help to keep this coin alive

[CoinBreader]

this block chain taking to long to download.. most coin 2 years old take 2-3 days max this has now been 6 days and still only half done... it is not gonna help to keep this coin alive

dogecoin took me 8hrs to catch up 1year on a SSD and on 24mbps ISP, we need a bootstrap

[FreshFund]

this block chain taking to long to download.. most coin 2 years old take 2-3 days max this has now been 6 days and still only half done... it is not gonna help to keep this coin alive

dogecoin took me 8hrs to catch up 1year on a SSD and on 24mbps ISP, we need a bootstrap

I've tried the bootstrap method, takes just as long if not longer.

For me, regular syncing didn't take nearly that long - thankfullky

[skyline_king]

this block chain taking to long to download.. most coin 2 years old take 2-3 days max this has now been 6 days and still only half done... it is not gonna help to keep this coin alive

dogecoin took me 8hrs to catch up 1year on a SSD and on 24mbps ISP, we need a bootstrap

I've tried the bootstrap method, takes just as long if not longer.

For me, regular syncing didn't take nearly that long - thankfullky

bitb took like 30 hours to sync RDD i think was about 2 days. I  don't think ltc even took more then 3 days....

[GrinZ]

is there any fresh node list i can use?? im getting only 1 connection and seems im stuck at 220493 block im using v2.0.2.0 wallet

Code:

trying connection 108.183.45.177:12788 lastseen=19737.2hrs
received block 5c43266faed5b10131d1
ERROR: CheckProofOfStake() : INFO: read txPrev failed
WARNING: ProcessBlock(): check proof-of-stake failed for block 5c43266faed5b10131d1110536a27533b8ec0b089427ef075884e378d31ed76e
connection timeout
trying connection 71.187.67.159:12788 lastseen=19572.8hrs
connection timeout
trying connection 173.57.67.169:12788 lastseen=20095.7hrs
connection timeout
trying connection 2.135.63.55:12788 lastseen=16246.4hrs
received block cf4912bb509c17c90a84
ERROR: CheckProofOfStake() : INFO: read txPrev failed
WARNING: ProcessBlock(): check proof-of-stake failed for block cf4912bb509c17c90a846b88545048619e8f253d6a5a02c7449e06d3e3962446
connection timeout
trying connection 69.196.141.82:12788 lastseen=20953.1hrs
connection timeout
trying connection 84.105.54.10:12788 lastseen=18392.6hrs
connection timeout
trying connection 82.28.249.168:12788 lastseen=20393.8hrs
connection timeout
trying connection 5.153.233.58:12788 lastseen=357.0hrs
connection timeout
trying connection 192.186.114.41:12788 lastseen=21758.8hrs
connection timeout
trying connection 92.55.100.95:12788 lastseen=20615.6hrs
connection timeout
trying connection 108.173.117.45:12788 lastseen=19213.9hrs
connection timeout
trying connection 86.214.65.8:12788 lastseen=19399.0hrs
Flushed 16148 addresses to peers.dat  28ms
connection timeout
trying connection 92.224.251.9:12788 lastseen=20821.4hrs

and my debug window looks like that..

Hi, alive MINT nodes you can see here: http://cryptoguru.tk/NetworkInfo/index.php?Currency=MINT
try to rescan or reindex your wallet.

[Johnny00]

How do you rescan or reindex our wallet. I only have one connection as well.

[CoinBreader]

is there any fresh node list i can use?? im getting only 1 connection and seems im stuck at 220493 block im using v2.0.2.0 wallet

Code:

trying connection 108.183.45.177:12788 lastseen=19737.2hrs
received block 5c43266faed5b10131d1
ERROR: CheckProofOfStake() : INFO: read txPrev failed
WARNING: ProcessBlock(): check proof-of-stake failed for block 5c43266faed5b10131d1110536a27533b8ec0b089427ef075884e378d31ed76e
connection timeout
trying connection 71.187.67.159:12788 lastseen=19572.8hrs
connection timeout
trying connection 173.57.67.169:12788 lastseen=20095.7hrs
connection timeout
trying connection 2.135.63.55:12788 lastseen=16246.4hrs
received block cf4912bb509c17c90a84
ERROR: CheckProofOfStake() : INFO: read txPrev failed
WARNING: ProcessBlock(): check proof-of-stake failed for block cf4912bb509c17c90a846b88545048619e8f253d6a5a02c7449e06d3e3962446
connection timeout
trying connection 69.196.141.82:12788 lastseen=20953.1hrs
connection timeout
trying connection 84.105.54.10:12788 lastseen=18392.6hrs
connection timeout
trying connection 82.28.249.168:12788 lastseen=20393.8hrs
connection timeout
trying connection 5.153.233.58:12788 lastseen=357.0hrs
connection timeout
trying connection 192.186.114.41:12788 lastseen=21758.8hrs
connection timeout
trying connection 92.55.100.95:12788 lastseen=20615.6hrs
connection timeout
trying connection 108.173.117.45:12788 lastseen=19213.9hrs
connection timeout
trying connection 86.214.65.8:12788 lastseen=19399.0hrs
Flushed 16148 addresses to peers.dat  28ms
connection timeout
trying connection 92.224.251.9:12788 lastseen=20821.4hrs

and my debug window looks like that..

Hi, alive MINT nodes you can see here: http://cryptoguru.tk/NetworkInfo/index.php?Currency=MINT
try to rescan or reindex your wallet.

cheers thanks ill add some more nodes on my .conf!

How do you rescan or reindex our wallet. I only have one connection as well.

on command line before you start your wallet type -rescan or -reindex
put this on your .conf and you get 7 connections at least!

Code:

addnode=77.163.157.232:12788 
addnode=164.132.25.194:12788
addnode=81.198.102.237:12788 
addnode=88.198.53.194:12788
addnode=78.56.42.41:12788
addnode=185.108.199.26:12788
addnode=84.175.234.120:12788
addnode=91.139.222.39:12788
addnode=90.113.82.59:12788
addnode=93.103.151.61:12788
addnode=72.241.236.178:12788
addnode=91.134.120.222:12788
addnode=208.104.57.51:12788
addnode=173.51.57.134:12788
addnode=85.179.172.201:12788
addnode=89.42.107.138:12788
addnode=50.92.172.205:12788
addnode=81.243.85.124:12788
addnode=82.8.129.200:12788

[MarSas]

I've tried the bootstrap method, takes just as long if not longer.

Interesting. Bootstrap worked for me very quickly, a matter of hours.

[Johnny00]

I don't have a .conf file and when you say startup I just start it from windows. I don't have a command line.

[Johnny00]

I've tried the bootstrap method, takes just as long if not longer.

Me too. I did the bootstrap from kiklo and overnight I'm all caught up
Interesting. Bootstrap worked for me very quickly, a matter of hours.

[kiklo]

Me too. I did the bootstrap from kiklo and overnight I'm all caught up
Interesting. Bootstrap worked for me very quickly, a matter of hours.

Odds are you used My Snapshot instead of the Bootstrap. (Mint Bootstrap will take days, My Snapshot only a few hours)
Snapshots will be ready very fast compared to a Bootstrap.dat which Mint team recommends.
Difference between a Snapshot & a BootStrap.dat file.
https://bitcointalk.org/index.php?topic=1378653.msg16022247#msg16022247


 

[Fuzzbawls]

Its been a while since I have explained the reasons why the MINT team has chosen to not officially support the "Snapshot" method of getting clients synced up, so let me reiterate them again.

Bootstrapping
"Bootstrapping" is a method by which you provide a single-file copy of all blocks up to a certain point, and let the client run that file through it's verification and processing algorithms to rebuild a full local copy of the blockchain, all without requiring any network connectivity during the process. This is a 100% trustless method as if any of the verifications fail at any point along the chain, the client will simply discard the subsequent data and use the P2P network to continue on. Erroneous data never gets written to the datadir.

There are two accepted methods of creating a bootstrap data file: Simple and Linear.

Simple:
This is a file that contains each and every block (including orphans) in whatever order they were received by the creating client. Usual creation method is just renaming a file (or concating multiple files) from an existing datadir. Such files are often bloated and inefficient due to the unknown block ordering and orphan data they contain.

Linear:
This is a file that contains each and every valid block in linear sequential order. There is no orphan data or block re-organization included in this type of bootstrap file. Such files are an order of magnitude more efficient than simple bootstraps for large/fast chains.


Snapshotting
"Snapshotting" is a method by which you take the data directory from one client and use it with another. The target client does no "importing" or processing of the migrated data (other than a user-configurable 'last n blocks verification'). This method dictates that you put 100% trust in the data provider. Any erroneous data making it's way into the snapshot can (has) and will likely lead to a program crash or a network wide IP ban if that particular data set is required for any future verification.

The "Snapshotting" method carries the same orphan block data and chain re-organization data as the "simple" bootstrapping method above.



So, given the above explanations about what each alternative method of getting a client synced involves, lets look at the Pros/Cons.
Pros/Cons between methods
Bootstrapping
Pros

• 100% trustless
• Smaller initial file size download
• No network connection needed
• Fallback to P2P syncing if an error is encountered
• No-Bloat when using linear bootstraps

Cons

• Slow, each block needs to be verified by the client
• May even be slower than P2P sync (depends on system/network specs)

Snapshotting
Pros

• Fast initial startup time

Cons

• Larger download size
• 100% trust placed on provider
• Erroneous data may lead to a crash at random times
• Unnecessary bloat introduced by chain reorgs/orphans

In the end, it is completely up to the user to decide which method they would like to use, and the MINT team certainly appreciates the efforts of kiklo and other providers for their time and the service they provide. What we as a team mean by "unsupported" is literally that no support for troubleshooting or correcting data errors will be given in the event of using a method (any method) that is not trustless by nature. Kiklo's method of getting a new client up to sync will almost certainly work right now.

So why do we not offer support for users that choose to use a non-trustless method of getting their client synced? The primary reason is because the data distributed in a non-trustless way simply cannot be verified to be good in any way, shape, or form by the client or the network. It is by all accounts completely out of our hands, and as what happened a few months ago, the data provided was incorrect so there wasn't anything to be done aside from having users resync their local clients.




All that being said, we have released a new official bootstrap (Linear method) that includes all blocks up to #2870000 (8/24/2016). It is available automatically for those that are currently using the btsync program and also directly from the websites (www.mintcoinofficial.com and www.mintymintcoin.com)

BTSync Link: Here
Direct Download Link: Here

[FreshFund]

"MINT team certainly appreciates the efforts of kiklo and other providers for their time and the service they provide. What we as a team mean by "unsupported" is literally that no support for troubleshooting" ...... "Kiklo's method of getting a new client up to sync will almost certainly work right now."

That's awesome thanks for the info!

[Derek492]

Its been a while since I have explained the reasons why the MINT team has chosen to not officially support the "Snapshot" method of getting clients synced up, so let me reiterate them again.

Bootstrapping
"Bootstrapping" is a method by which you provide a single-file copy of all blocks up to a certain point, and let the client run that file through it's verification and processing algorithms to rebuild a full local copy of the blockchain, all without requiring any network connectivity during the process. This is a 100% trustless method as if any of the verifications fail at any point along the chain, the client will simply discard the subsequent data and use the P2P network to continue on. Erroneous data never gets written to the datadir.

There are two accepted methods of creating a bootstrap data file: Simple and Linear.

Simple:
This is a file that contains each and every block (including orphans) in whatever order they were received by the creating client. Usual creation method is just renaming a file (or concating multiple files) from an existing datadir. Such files are often bloated and inefficient due to the unknown block ordering and orphan data they contain.

Linear:
This is a file that contains each and every valid block in linear sequential order. There is no orphan data or block re-organization included in this type of bootstrap file. Such files are an order of magnitude more efficient than simple bootstraps for large/fast chains.


Snapshotting
"Snapshotting" is a method by which you take the data directory from one client and use it with another. The target client does no "importing" or processing of the migrated data (other than a user-configurable 'last n blocks verification'). This method dictates that you put 100% trust in the data provider. Any erroneous data making it's way into the snapshot can (has) and will likely lead to a program crash or a network wide IP ban if that particular data set is required for any future verification.

The "Snapshotting" method carries the same orphan block data and chain re-organization data as the "simple" bootstrapping method above.



So, given the above explanations about what each alternative method of getting a client synced involves, lets look at the Pros/Cons.
Pros/Cons between methods
Bootstrapping
Pros

• 100% trustless
• Smaller initial file size download
• No network connection needed
• Fallback to P2P syncing if an error is encountered
• No-Bloat when using linear bootstraps

Cons

• Slow, each block needs to be verified by the client
• May even be slower than P2P sync (depends on system/network specs)

Snapshotting
Pros

• Fast initial startup time

Cons

• Larger download size
• 100% trust placed on provider
• Erroneous data may lead to a crash at random times
• Unnecessary bloat introduced by chain reorgs/orphans

In the end, it is completely up to the user to decide which method they would like to use, and the MINT team certainly appreciates the efforts of kiklo and other providers for their time and the service they provide. What we as a team mean by "unsupported" is literally that no support for troubleshooting or correcting data errors will be given in the event of using a method (any method) that is not trustless by nature. Kiklo's method of getting a new client up to sync will almost certainly work right now.

So why do we not offer support for users that choose to use a non-trustless method of getting their client synced? The primary reason is because the data distributed in a non-trustless way simply cannot be verified to be good in any way, shape, or form by the client or the network. It is by all accounts completely out of our hands, and as what happened a few months ago, the data provided was incorrect so there wasn't anything to be done aside from having users resync their local clients.




All that being said, we have released a new official bootstrap (Linear method) that includes all blocks up to #2870000 (8/24/2016). It is available automatically for those that are currently using the btsync program and also directly from the websites (www.mintcoinofficial.com and www.mintymintcoin.com)

BTSync Link: Here
Direct Download Link: Here

Thanks Fuzzbawls. Everyone, should do the bootstrap or normal sync if they can stand it to ensure network security.  As for the slowness, just keep in mind Mintcoin has over 2-million blocks to sync; more blocks than pretty much any other coin out there be because it's over 2 years old and has a very fast block speed. Mintcoins creates a new block on average under 30 seconds. Most of the slowness in syncing is verifying the correctness of every block. That's why it takes time if you let it go through the verification process (bootstrap or normal sync download). The snapshot removes the verification of the millions of blocks that's why it's faster. Syncing is not just a matter of downloading the blockchain it's a matter of checking out every block too. If you just opened your client it helps if you give it time to find connection too. You don't even really need a conf file. It can take like a half hour or so to get a lot of connections. Sometimes restarting the client can help too.

[kiklo]

I offer the Snapshots , because the Bootstrap is just too slow with mintcoin.

What really needs to happen is simple and it removes needing either a snapshot or a bootstrap.

Mintcoin needs to start using header sync in the next versions.
Synchronizing the block chain by downloading block headers before downloading the full blocks.
Once BTC started it , they no longer needed bootstraps , as it made syncing from the network faster.  


 

[Fuzzbawls]

I offer the Snapshots , because the Bootstrap is just too slow with mintcoin.

What really needs to happen is simple and it removes needing either a snapshot or a bootstrap.

Mintcoin needs to start using header sync in the next versions.
Synchronizing the block chain by downloading block headers before downloading the full blocks.
Once BTC started it , they no longer needed bootstraps , as it made syncing from the network faster. 


 

You're exactly right regarding HDF syncing (Headers First), which one of the things we have been working towards over the past year. Our test branch actually has it, but due to how HDF was designed to work in BTC, the implementation doesn't work properly when the blockchain has a mix of PoW and PoS blocks.

[kiklo]

I offer the Snapshots , because the Bootstrap is just too slow with mintcoin.

What really needs to happen is simple and it removes needing either a snapshot or a bootstrap.

Mintcoin needs to start using header sync in the next versions.
Synchronizing the block chain by downloading block headers before downloading the full blocks.
Once BTC started it , they no longer needed bootstraps , as it made syncing from the network faster. 


 

You're exactly right regarding HDF syncing (Headers First), which one of the things we have been working towards over the past year. Our test branch actually has it, but due to how HDF was designed to work in BTC, the implementation doesn't work properly when the blockchain has a mix of PoW and PoS blocks.

The closest anyone got with HDF syncing for a PoS coin was Pandacoin,
It still had some corruption issues , so most everyone used the original sync method as it was an option in the wallet.
(But the Pandacoin community Dev Old Team collapse soon after the release, so MaNI left and never fixed the corruption problem.)

I believe this was commit that added it.
https://github.com/pandacoin-official/pandacoin/commit/24c836a20a31c7747d63c13fa628b97dc40818c7

The programmer that did the work was MaNI
https://bitcointalk.org/index.php?action=profile;u=402883
He works with guldencoin now, but might have some insight to help.


 

[coolbeans94]

Well it looks like things got interesting around here lately with the Poloniex fiasco.
Do we have any idea going forward what exchange would be the best for us, that we can promote and recommend and allow them to be be our primary exchange? It looks like that Altex exchange is promising, but still seems to have some issues to work out for now. It is good for us if possible to have a plan or an idea after next week for continuing to promote exchange stability. I was thinking Cryptopia, but I haven't used them before; has anyone else, any experiences to share? We need an exchange that will be long-term solvent, and not delist MINT for no reason and have certain unreasonable demands.

[FreshFund]

Well it looks like things got interesting around here lately with the Poloniex fiasco.
Do we have any idea going forward what exchange would be the best for us, that we can promote and recommend and allow them to be be our primary exchange? It looks like that Altex exchange is promising, but still seems to have some issues to work out for now. It is good for us if possible to have a plan or an idea after next week for continuing to promote exchange stability. I was thinking Cryptopia, but I haven't used them before; has anyone else, any experiences to share? We need an exchange that will be long-term solvent, and not delist MINT for no reason and have certain unreasonable demands.

Did Polo start making demands?