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

[andeisen]

Android wallet and the foundation of

[1713943742]

1713943742

[rlm42]

Why do people keep piling on sell walls ? 

Giving the price 0 chance to rise.. The coin is worth much more than this.

[sgk]

Why do people keep piling on sell walls ? 

Giving the price 0 chance to rise.. The coin is worth much more than this.

Then this should be a nice opportunity to buy them.

[KSGuy]

Can I downgrade my wallet, this one freezes up when I try to open it.. 1.9.0

oh, I see there is a 1.9.1.. I'll try that  

yup... nvm, 1.9.1 loads much much better now
Happy minting everyone

[rlm42]

Why do people keep piling on sell walls ? 

Giving the price 0 chance to rise.. The coin is worth much more than this.

Then this should be a nice opportunity to buy them.

That doesn't answer the question.. And i don't have an endless supply of money otherwise I would buy more.

[dogechode]

I love how every time someone comments on the massive sell walls, there's always the token bagholder to step in and say ohhhh well it's a great deal so you should buuuuuyyyyyy! How cute.

[Ferris419]

I love how every time someone comments on the massive sell walls, there's always the token bagholder to step in and say ohhhh well it's a great deal so you should buuuuuyyyyyy! How cute.

Lol I hold 1.7mil and your right I basically read this thread for a good laugh while yeah I'm hoping mint does actually succeed but the posts I read here are just comical.

[hellohellooo]

https://www.thunderclap.it/projects/10998-sonoma-county-redwood-reforest?locale=enHello minters

we still have the change to show our support for our first project on mintcoifund.
We have 3 days left to get another 48 people.
So if we work together its easy.
Please support   

I'll support the project. We need 47 people now .

Sweeet. Thank you. We only need 39 more people now. https://www.thunderclap.it/projects/10998-sonoma-county-redwood-reforest?locale=enHello

[WALKEN-COIN]

I think people are waiting to see something "new" from Mintcoin before they buy it. Those sell walls will only come down with new adoption, and lots of it.

Perhaps we could get a screen-shot-laden update from our android developer to interest new blood?

[Ferris419]

I think people are waiting to see something "new" from Mintcoin before they buy it. Those sell walls will only come down with new adoption, and lots of it.

Perhaps we could get a screen-shot-laden update from our android developer to interest new blood?

Exactly. Talking up a coin only goes so far. Any coin that's going to succeed needs something to set it apart from the rest. Period.

[Cryptocoinrank.com]

█ ★Mintcoin (MINT) █→ Now Live on: http://www.cryptocoinrank.com/Mintcoin
Hope you like it! You can also display your Dev news just by creating two widgets and sending me the information like described here: https://bitcointalk.org/index.php?topic=579901.0

Enjoy

[qwizzie]

█ ★Mintcoin (MINT) █→ Now Live on: http://www.cryptocoinrank.com/Mintcoin

i like it, i like it a lot !!  wow .. Mintcoin on position 22

tip 1 : pls add MintPal in the Market Capitalization & Statistics as crypto-exchange, it has the largest trading volume of Mintcoin
tip 2 : maybe you could move the Facebook likes a bit up, perhaps put it in the upper right corner ? its kinda blocking the latest news window

[paspi]

Android wallet update 4:

First a reminder from a few days back:

Just to let you know I'm still working on the android wallet. Bumped to a few walls last week, but I think I found a way around them, been busy implementing it. Will post a detailed update soon.

And the previous status:

Next step is to make the storage on disk instead of memory only (I guess this will be finished tomorrow). Then implementing POS difficulty verification (1 or 2 days). The library will be secure when POS difficulty verification is done. Lots of testing would be required.

I implemented the disk storage after this message, took a little longer than expected, but all was well.

Then as I was implementing POS difficulty verification, just about a few lines left to finish it, I realized that I had been following a very very wrong path: POS difficulty verification required calculation of a value called coinstake modifier (recalculated once every 6 hours). To calculate coinstake modifier, a hash called coinstake hash was needed for all latest POS blocks, without any gap in the blocks. To calculate coinstake hash for a single block, its previous output (which generated the stake) was required. And this was conflicting with my SPV idea, as it was based on "not every transaction is required to be stored".

It was a rough week, but I found a way around the problem. I had to throw away completely some of my time-consuming changes so far, and reimplement some of the things I've already implemented for SPV. But now everything is cleaner, simpler, and even less storage is used than SPV implementation. So I would call it productive, although cost a week. The implementation is not SPV anymore. Now we use a lightweight "full block chain" (which keeps track of all unspent outputs, but only verifies coinstake transactions. Also it still uses some ideas from the previous SPV POS for security). This turned out to be much better than the previous bloated SPV implementation, so I'm happy with this change.


Current status:
Storage is working again. I had to reimplement it after last week. It uses around 50-100 mb disk space (I tested up to block 250,000).

Blockchain is working again. I throw away my SPV implementation, and created something from scratch, very similar to full transaction verifying mode of bitcoinj (But is not that resource intensive).

Almost every piece for coin stake verification is ready in the code (stake modifier calculation, locating stake modifier blocks, calculating stake hashes) , they are in the state I left them last week as I was just about to finish them (when I noticed I was trying to do something impossible). But they need some binding together -- they're scattered across the codebase.

Next steps:
First job is to get coin stake verification working. It is the single big goal since the beginning. There isn't much left, I can clearly see what's ahead. Should be done tomorrow.

Then I will start integration with UI. Hopefully we'll see some action at the end of the weekend

Android wallet update 3:

Hi;

Good news. I almost completed the POS-Secure transaction-tracking SPV wallet I described earlier. Though it proved itself to be a headache to implement, but it's all clear and working now (The difference: It verifies POS coinstake signatures and the stake being unspent yet before accepting the block from network. If it can be proven to be invalid, it rejects the block. If only it cannot be verified (previous stake transaction dropped from storage), it accepts the block without giving its chain an advantage, so an attacker cannot craft a longer chain if he cannot generate verifiable coinstake blocks). I haven't implemented POS difficulty calculations yet, but as the base is there, it'll be very easy to plug it in. And then it'll be easy to reuse POS difficulty calculations to implement stake generation later.

Current status is, we have a working light verifying blockchain controller, and a memory-only storage for that, optimized for its needs (and designed for converting to disk storage). I had to change bitcoinj's primitive storage data structures for its own needs, but everything is simpler now than my first implementation for POS SPV.

Next step is to make the storage on disk instead of memory only (I guess this will be finished tomorrow). Then implementing POS difficulty verification (1 or 2 days). The library will be secure when POS difficulty verification is done. Lots of testing would be required.

Then smooth out the rough edges. Then binding the UI and release. (Minting only in the library level will come some point after POS difficulty verification, but I plan to do UI integration after the initial release)


Regarding other paid POS wallet developments; frankly I don't believe someone outside the community just paid for the job would be able to finish this in a secure manner. POS coins are different animals, and a SPV POS wallet has much different security needs than a SPV POW wallet. The core of bitcoinj was implemented for a POW coin, and it was very hard to get to this stage. So my guess is that anyone getting paid for the job would implement it in the easiest way possible, get his money, and continue with his life. (That easiest way was working for Mintcoin 2 days after I started, but well, it was not secure, it was extremely easy to fool the wallet to follow a custom block chain). Still, marketing matters, I don't think most people will care if secure or not, and they will focus on being the first wallet. I'm trying to be quick.

Android wallet update 2:

Hello everyone;

I'm progressing in the Java MintCoin library. I got the SPV wallet kit distributed with bitcoinj working (ForwardingService) , it can sync from genesis block to latest block (persists on disk). It can generate a MintCoin address, and receive coins sent to that MintCoin address and send a transaction back. It has some problems creating the forwarding transaction though, I haven't digged in that direction yet.


My biggest concern is security vs. being lightweight enough for Android devices. Normally, SPV wallets are used in android wallets, which only store last x block headers (say 5000), and delete the rest. They trust on their peers and the cumulative POW difficulty of the chain. They don't verify any transactions.

In contrast, for a POW+POS coin, header difficulty in POS blocks is not a secure measure at all. Difficulty of the header is relatively low, and easy to forge. The coinstake transaction of POS block provides block's security, and if you're not verifying transactions, you will have problems. So, if you know that your peer is not validating any transactions at all, including coinstake, you know that you can forge a series of POS blocks and send it to your peer. (In order to be able to verify coinstake transaction, you need to have stored the corresponding transaction that generated it from at least 20 days ago. Its time open ended actually, its position can go up to genesis block. In contrast SPV clients only store transactions that relate to their own addresses, and discard the rest)


Currently, I'm working on a lightly-verified SPV blockchain implementation. It stores up to 40 days of blocks and tracks spent/unspent transactions seen in these blocks (this would somewhat affect the resource usage, but not as much as a full verifying blockchain which is almost impossible to run on android devices). As transactions of last 40 days would be always available, client would be able to verify a high percent of generated POS blocks (If they are indeed generated from unspent transactions, and if coin's owner really matches). It won't be able to verify POS blocks that are generated from older transactions.

So this is a mixed approach, although it doesn't verify all POS blocks, it would assume that a few unverifable POS blocks followed by a large number of verifiable POS blocks means that the network accepted the questionable chain, and that chain can be trusted as long as the network does. Actually this is not a verifying implementation, but rather a invalidating one; detecting as much invalid POS blocks as possible before they are appended to any chain.


This implementation is somewhat different than current bitcoinj/mintcoind 's transaction input/output connecting (they keep track of transactions spent only in the main chain, and rely on cumulative Proof of Work on alternative chains. They do a transaction reordering every time an alternative chain becomes longest). They can do this because they can verify any chain at anytime, they keep the whole history, they don't have any risk at all.  In contrast POS with SPV has to keep track of spent/unspent transactions outputs in every possible branch simultaneously, so it can reject invalid POS blocks even before they end up in an alternate chain. This difference proved itself to be highly challenging to implement, although I believe I managed a way out.


So, well, I'm continuing working on this hard, and I believe I resolved most of the problems. Although library is currently working and able to persist on disk and receive transactions, it is not secure until this light verification is done. Hopefully I would be able to fully implement this by the weekend.


I'm working on github, I decided not to publish my changes to public until I can get a wallet android app working, so I avoid pushing my changes there. I'm currently only working only on the java library, it will be very easy to port any wallet to use it once library is properly working. But I don't want any other PoW+PoS coin to grab the library (even unsecure versions of it) and release an android app before us.

I really need some comments / feedbacks on my solution to POS Coin + SPV wallet security issue -- so if you think you have an idea, don't hesitate to contact me, I'll be happy to find out potential security issues and change the design before it's late.

Android wallet update:

Hello everybody; I'm working on a Java MintCoin library and an Android wallet.

For best security and long term development, I forked from latest bitcoinj last week. Converted it to Scrypt. Made it able to communicate with my local Mintcoin wallet over network. I just updated it to understand and accept PoS/PoW hybrid blocks, and I can announce you that it can sync with the blockchain from genesis block up to #239870, which is generated just minutes ago

There are some missing features yet:

- It can validate PoW block difficulties (calculation is a little different in PoW/PoS hybrids than pure PoW coins, PoS blocks affect calculations, and modifying bitcoinj library for this task really had some challenges) ; but it doesn't try to validate PoS block difficulties yet (this is a security issue and will be fixed before releasing)

- It doesn't verify POW block rewards (due to the fact that I couldn't find a specific pseudorandom generator implementation that decides on randomized POW block rewards). I don't think this would be an issue as the main use case would be a Simple Payment Verification wallet, checkpoints will cover our security up to removal of PoW from MintCoin (though it will be nice to have the checks in place)

- Minting: It's now almost clear that minting would be possible even in SPV wallet mode. I will annonuce details later. I have to figure out validating PoS blocks first.

- UI: I'm just trying to get the pure library working properly now. Once the library is working, it'll be very easy to fork/make an Android App that uses it

- Bloom filters: Here is a request for the community: Current Mintcoin wallet doesn't support Bloom filters. Bloom filters allow SPV clients download only the transactions they're interested in (instead of all transactions in blocks), reducing mobile users' data usage dramatically. Please put a bounty on it so that someone can merge it from bitcoin client. Android wallet will work without Bloom Filter support in the main client, but its data usage would be much more.

[WALKEN-COIN]

Damn Paspi, that is some GREAT news.

[stormia]

Android wallet update 4:

First a reminder from a few days back:

Just to let you know I'm still working on the android wallet. Bumped to a few walls last week, but I think I found a way around them, been busy implementing it. Will post a detailed update soon.

And the previous status:

Next step is to make the storage on disk instead of memory only (I guess this will be finished tomorrow). Then implementing POS difficulty verification (1 or 2 days). The library will be secure when POS difficulty verification is done. Lots of testing would be required.

I implemented the disk storage after this message, took a little longer than expected, but all was well.

Then as I was implementing POS difficulty verification, just about a few lines left to finish it, I realized that I had been following a very very wrong path: POS difficulty verification required calculation of a value called coinstake modifier (recalculated once every 6 hours). To calculate coinstake modifier, a hash called coinstake hash was needed for all latest POS blocks, without any gap in the blocks. To calculate coinstake hash for a single block, its previous output (which generated the stake) was required. And this was conflicting with my SPV idea, as it was based on "not every transaction is required to be stored".

It was a rough week, but I found a way around the problem. I had to throw away completely some of my time-consuming changes so far, and reimplement some of the things I've already implemented for SPV. But now everything is cleaner, simpler, and even less storage is used than SPV implementation. So I would call it productive, although cost a week. The implementation is not SPV anymore. Now we use a lightweight "full block chain" (which keeps track of all unspent outputs, but only verifies coinstake transactions. Also it still uses some ideas from the previous SPV POS for security). This turned out to be much better than the previous bloated SPV implementation, so I'm happy with this change.


Current status:
Storage is working again. I had to reimplement it after last week. It uses around 50-100 mb disk space (I tested up to block 250,000).

Blockchain is working again. I throw away my SPV implementation, and created something from scratch, very similar to full transaction verifying mode of bitcoinj (But is not that resource intensive).

Almost every piece for coin stake verification is ready in the code (stake modifier calculation, locating stake modifier blocks, calculating stake hashes) , they are in the state I left them last week as I was just about to finish them (when I noticed I was trying to do something impossible). But they need some binding together -- they're scattered across the codebase.

Next steps:
First job is to get coin stake verification working. It is the single big goal since the beginning. There isn't much left, I can clearly see what's ahead. Should be done tomorrow.

Then I will start integration with UI. Hopefully we'll see some action at the end of the weekend

Android wallet update 3:

Hi;

Good news. I almost completed the POS-Secure transaction-tracking SPV wallet I described earlier. Though it proved itself to be a headache to implement, but it's all clear and working now (The difference: It verifies POS coinstake signatures and the stake being unspent yet before accepting the block from network. If it can be proven to be invalid, it rejects the block. If only it cannot be verified (previous stake transaction dropped from storage), it accepts the block without giving its chain an advantage, so an attacker cannot craft a longer chain if he cannot generate verifiable coinstake blocks). I haven't implemented POS difficulty calculations yet, but as the base is there, it'll be very easy to plug it in. And then it'll be easy to reuse POS difficulty calculations to implement stake generation later.

Current status is, we have a working light verifying blockchain controller, and a memory-only storage for that, optimized for its needs (and designed for converting to disk storage). I had to change bitcoinj's primitive storage data structures for its own needs, but everything is simpler now than my first implementation for POS SPV.

Next step is to make the storage on disk instead of memory only (I guess this will be finished tomorrow). Then implementing POS difficulty verification (1 or 2 days). The library will be secure when POS difficulty verification is done. Lots of testing would be required.

Then smooth out the rough edges. Then binding the UI and release. (Minting only in the library level will come some point after POS difficulty verification, but I plan to do UI integration after the initial release)


Regarding other paid POS wallet developments; frankly I don't believe someone outside the community just paid for the job would be able to finish this in a secure manner. POS coins are different animals, and a SPV POS wallet has much different security needs than a SPV POW wallet. The core of bitcoinj was implemented for a POW coin, and it was very hard to get to this stage. So my guess is that anyone getting paid for the job would implement it in the easiest way possible, get his money, and continue with his life. (That easiest way was working for Mintcoin 2 days after I started, but well, it was not secure, it was extremely easy to fool the wallet to follow a custom block chain). Still, marketing matters, I don't think most people will care if secure or not, and they will focus on being the first wallet. I'm trying to be quick.

Android wallet update 2:

Hello everyone;

I'm progressing in the Java MintCoin library. I got the SPV wallet kit distributed with bitcoinj working (ForwardingService) , it can sync from genesis block to latest block (persists on disk). It can generate a MintCoin address, and receive coins sent to that MintCoin address and send a transaction back. It has some problems creating the forwarding transaction though, I haven't digged in that direction yet.


My biggest concern is security vs. being lightweight enough for Android devices. Normally, SPV wallets are used in android wallets, which only store last x block headers (say 5000), and delete the rest. They trust on their peers and the cumulative POW difficulty of the chain. They don't verify any transactions.

In contrast, for a POW+POS coin, header difficulty in POS blocks is not a secure measure at all. Difficulty of the header is relatively low, and easy to forge. The coinstake transaction of POS block provides block's security, and if you're not verifying transactions, you will have problems. So, if you know that your peer is not validating any transactions at all, including coinstake, you know that you can forge a series of POS blocks and send it to your peer. (In order to be able to verify coinstake transaction, you need to have stored the corresponding transaction that generated it from at least 20 days ago. Its time open ended actually, its position can go up to genesis block. In contrast SPV clients only store transactions that relate to their own addresses, and discard the rest)


Currently, I'm working on a lightly-verified SPV blockchain implementation. It stores up to 40 days of blocks and tracks spent/unspent transactions seen in these blocks (this would somewhat affect the resource usage, but not as much as a full verifying blockchain which is almost impossible to run on android devices). As transactions of last 40 days would be always available, client would be able to verify a high percent of generated POS blocks (If they are indeed generated from unspent transactions, and if coin's owner really matches). It won't be able to verify POS blocks that are generated from older transactions.

So this is a mixed approach, although it doesn't verify all POS blocks, it would assume that a few unverifable POS blocks followed by a large number of verifiable POS blocks means that the network accepted the questionable chain, and that chain can be trusted as long as the network does. Actually this is not a verifying implementation, but rather a invalidating one; detecting as much invalid POS blocks as possible before they are appended to any chain.


This implementation is somewhat different than current bitcoinj/mintcoind 's transaction input/output connecting (they keep track of transactions spent only in the main chain, and rely on cumulative Proof of Work on alternative chains. They do a transaction reordering every time an alternative chain becomes longest). They can do this because they can verify any chain at anytime, they keep the whole history, they don't have any risk at all.  In contrast POS with SPV has to keep track of spent/unspent transactions outputs in every possible branch simultaneously, so it can reject invalid POS blocks even before they end up in an alternate chain. This difference proved itself to be highly challenging to implement, although I believe I managed a way out.


So, well, I'm continuing working on this hard, and I believe I resolved most of the problems. Although library is currently working and able to persist on disk and receive transactions, it is not secure until this light verification is done. Hopefully I would be able to fully implement this by the weekend.


I'm working on github, I decided not to publish my changes to public until I can get a wallet android app working, so I avoid pushing my changes there. I'm currently only working only on the java library, it will be very easy to port any wallet to use it once library is properly working. But I don't want any other PoW+PoS coin to grab the library (even unsecure versions of it) and release an android app before us.

I really need some comments / feedbacks on my solution to POS Coin + SPV wallet security issue -- so if you think you have an idea, don't hesitate to contact me, I'll be happy to find out potential security issues and change the design before it's late.

Android wallet update:

Hello everybody; I'm working on a Java MintCoin library and an Android wallet.

For best security and long term development, I forked from latest bitcoinj last week. Converted it to Scrypt. Made it able to communicate with my local Mintcoin wallet over network. I just updated it to understand and accept PoS/PoW hybrid blocks, and I can announce you that it can sync with the blockchain from genesis block up to #239870, which is generated just minutes ago

There are some missing features yet:

- It can validate PoW block difficulties (calculation is a little different in PoW/PoS hybrids than pure PoW coins, PoS blocks affect calculations, and modifying bitcoinj library for this task really had some challenges) ; but it doesn't try to validate PoS block difficulties yet (this is a security issue and will be fixed before releasing)

- It doesn't verify POW block rewards (due to the fact that I couldn't find a specific pseudorandom generator implementation that decides on randomized POW block rewards). I don't think this would be an issue as the main use case would be a Simple Payment Verification wallet, checkpoints will cover our security up to removal of PoW from MintCoin (though it will be nice to have the checks in place)

- Minting: It's now almost clear that minting would be possible even in SPV wallet mode. I will annonuce details later. I have to figure out validating PoS blocks first.

- UI: I'm just trying to get the pure library working properly now. Once the library is working, it'll be very easy to fork/make an Android App that uses it

- Bloom filters: Here is a request for the community: Current Mintcoin wallet doesn't support Bloom filters. Bloom filters allow SPV clients download only the transactions they're interested in (instead of all transactions in blocks), reducing mobile users' data usage dramatically. Please put a bounty on it so that someone can merge it from bitcoin client. Android wallet will work without Bloom Filter support in the main client, but its data usage would be much more.

Thank you for the update, paspi!

[visual111]

I'm having a problem with the new wallet (1.9.1)

Minting has been much slower and I minted less coins this time around, even with the extra coins from the previous minting.

This is my 2nd mint for the coins I'm talking about, so obviously I should be getting more.


The wallet has said that I'll be earning a reward in 1 hour for a long time now.




I have a fair amount of coins. I'm just below half on the rich list, so number of coins shouldn't be an issue, unless I'm misunderstanding something



here is thread on reddit. two other people said they have this issue too http://www.reddit.com/r/MintCoin/comments/24jc17/expected_time_to_earn_reward_time_not_changing/

[coolbeans94]

https://www.thunderclap.it/projects/10998-sonoma-county-redwood-reforest?locale=enHello minters

we still have the change to show our support for our first project on mintcoinfund.
We have 2 days left to get another 37 people.
So if we work together its easy.
Please support   

[coolbeans94]

█ ★Mintcoin (MINT) █→ Now Live on: http://www.cryptocoinrank.com/Mintcoin
Hope you like it! You can also display your Dev news just by creating two widgets and sending me the information like described here: https://bitcointalk.org/index.php?topic=579901.0

Enjoy

[hyeoam]

Charts here: http://crypto-prices.com/MINT

[Kergekoin]

I'm having a problem with the new wallet (1.9.1)

Minting has been much slower and I minted less coins this time around, even with the extra coins from the previous minting.

This is my 2nd mint for the coins I'm talking about, so obviously I should be getting more.


The wallet has said that I'll be earning a reward in 1 hour for a long time now.




I have a fair amount of coins. I'm just below half on the rich list, so number of coins shouldn't be an issue, unless I'm misunderstanding something



here is thread on reddit. two other people said they have this issue too http://www.reddit.com/r/MintCoin/comments/24jc17/expected_time_to_earn_reward_time_not_changing/

There are no issues with code. It all works fine. Read a my earlier posts in this thread for more info.