Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained] - page 374. (Read 1369778 times)
April 15, 2014, 08:31:21 PM
Fantastic paspi! Keep up the good work!
April 15, 2014, 08:17:51 PM
Android update 2.2
Client does not have bloom filters or "getheaders" support. Importing any of them into current wallet would be useful in the long run, but now not a priority, new development (both on main client and android library) has to be made to make them useful.
Converting bitcoinj from Sha256 to Scrypt is just a few lines of change, and it is nothing compared to converting it to support a Proof Of Stake coin
I decided that bitcoinj is the most actively developed library compared to its forks, and it's not worth it to start development from any fork just for scrypt.
I haven't integrated unit tests yet, but I plan to do so in the long run. New unit tests would have to be written too, there are lots of changes in critical paths to support POS.
Client does not have bloom filters or "getheaders" support. Importing any of them into current wallet would be useful in the long run, but now not a priority, new development (both on main client and android library) has to be made to make them useful.
Converting bitcoinj from Sha256 to Scrypt is just a few lines of change, and it is nothing compared to converting it to support a Proof Of Stake coin
I decided that bitcoinj is the most actively developed library compared to its forks, and it's not worth it to start development from any fork just for scrypt.I haven't integrated unit tests yet, but I plan to do so in the long run. New unit tests would have to be written too, there are lots of changes in critical paths to support POS.
client should have bloom filter after 0.8.5 already forked...
Why not use litecoinj as a base? Are unit tests integrated?
Why not use litecoinj as a base? Are unit tests integrated?
April 15, 2014, 08:08:07 PM
How can I send with a specific address to avoid resetting coinage in a wallet?
Or are the coins moved the only ones whose coinage resets?
You can use Coin control features of MintCoin 1.8. Just enable it from Settings/Display, and you can access it on Send Coins tab. Or are the coins moved the only ones whose coinage resets?
April 15, 2014, 08:06:43 PM
Android update 2.1 :
As it turned out we have to keep track of every unspent transaction of last XX days, I don't think bloom filters would be that useful anymore. I'm thinking of ways to alter bloom filter features to improve android wallet's network usage, but it's really low priority as it won't be just a code import anymore, but new development has to be made.
As it turned out we have to keep track of every unspent transaction of last XX days, I don't think bloom filters would be that useful anymore. I'm thinking of ways to alter bloom filter features to improve android wallet's network usage, but it's really low priority as it won't be just a code import anymore, but new development has to be made.
April 15, 2014, 07:57:17 PM
How can I send with a specific address to avoid resetting coinage in a wallet?
Or are the coins moved the only ones whose coinage resets?
Or are the coins moved the only ones whose coinage resets?
April 15, 2014, 07:56:59 PM
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.
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.
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.
April 15, 2014, 06:05:21 PM
Coin voting for MyWl: https://mywl.lt/voting/ voting ends May 1st!
Also, can't hurt to keep voting at: http://www.lovecrypto.com/vote
Also, can't hurt to keep voting at: http://www.lovecrypto.com/vote
April 15, 2014, 06:00:25 PM
The bottom line is the price would be increasing if people weren't selling. HBN is a great example of this - the price keeps going up because sell pressure is so low. Nobody is really selling in any significant quantity.
Now, mint does have a larger cap but still, if everyone (or even MOST users) were just holding and minting, then the price should naturally be rising. It's not. Therefore, people are selling, and significant amounts.
Now, mint does have a larger cap but still, if everyone (or even MOST users) were just holding and minting, then the price should naturally be rising. It's not. Therefore, people are selling, and significant amounts.
I think it was noted a few pages back that the biggest holder of Mint was selling? Not dumping in a destructive way, but selling enough to keep the price relatively stable and keep Mint under the radar. So that might seem like the action of many people, but maybe not... Anyway I do expect some rises but even if Mint stays at this price while Bitcoin rises then that's fine.
Isn't the biggest holder the dev? (it's a serious question I'm not being facetious.) I thought there was a sizable pre-mine, so unless someone bought up a ton at the right times it would be hard to rival that.
Impossible to say which address is the dev's for certain: http://mint.blockx.info/richlist/
They have already used some of the premine for bounties and the Mintcoin Fund, so hard to guess exactly how much is left. I think the dev has big long-term plans for this coin, which is why they have been hesitant to use the premine as quickly as some might prefer.
Thanks for the link...
I was just looking for it for a research
April 15, 2014, 03:49:55 PM
Got lots of 'minted' coins but they havent actually minted but showing on the transaction thingy. Is this normal?
Yes, those are orphaned blocks. Your coin age is not affected by them, and soon you will actually Mint coins, it just may take a bit longer. It all depends on the amount of coins in your wallet that are at least 20 days old.
April 15, 2014, 03:42:37 PM
Got lots of 'minted' coins but they havent actually minted but showing on the transaction thingy. Is this normal?
April 15, 2014, 02:34:30 PM
Impossible to say which address is the dev's for certain: http://mint.blockx.info/richlist/
They have already used some of the premine for bounties and the Mintcoin Fund, so hard to guess exactly how much is left. I think the dev has big long-term plans for this coin, which is why they have been hesitant to use the premine as quickly as some might prefer.
They have already used some of the premine for bounties and the Mintcoin Fund, so hard to guess exactly how much is left. I think the dev has big long-term plans for this coin, which is why they have been hesitant to use the premine as quickly as some might prefer.
Is it correct that the premine was 700million mint or was that just an outright lie? Many times throughout this thread it has come up that they supposedly pre-mined 700million coins. I am not complaining about the pre-mine or the devs holding on to it (if they in fact still are, it sounds like we don't really know.) I just want to understand the whole situation here.
April 15, 2014, 02:23:27 PM
We need more people on the Reddit community as well.
Lots of new investors with questions lately.
http://www.reddit.com/r/mintcoin
Lots of new investors with questions lately.
http://www.reddit.com/r/mintcoin
April 15, 2014, 02:18:22 PM
Impossible to say which address is the dev's for certain: http://mint.blockx.info/richlist/
They have already used some of the premine for bounties and the Mintcoin Fund, so hard to guess exactly how much is left. I think the dev has big long-term plans for this coin, which is why they have been hesitant to use the premine as quickly as some might prefer.
They have already used some of the premine for bounties and the Mintcoin Fund, so hard to guess exactly how much is left. I think the dev has big long-term plans for this coin, which is why they have been hesitant to use the premine as quickly as some might prefer.
Is it correct that the premine was 700million mint or was that just an outright lie? Many times throughout this thread it has come up that they supposedly pre-mined 700million coins. I am not complaining about the pre-mine or the devs holding on to it (if they in fact still are, it sounds like we don't really know.) I just want to understand the whole situation here.
April 15, 2014, 02:14:23 PM
The bottom line is the price would be increasing if people weren't selling. HBN is a great example of this - the price keeps going up because sell pressure is so low. Nobody is really selling in any significant quantity.
Now, mint does have a larger cap but still, if everyone (or even MOST users) were just holding and minting, then the price should naturally be rising. It's not. Therefore, people are selling, and significant amounts.
Now, mint does have a larger cap but still, if everyone (or even MOST users) were just holding and minting, then the price should naturally be rising. It's not. Therefore, people are selling, and significant amounts.
I think it was noted a few pages back that the biggest holder of Mint was selling? Not dumping in a destructive way, but selling enough to keep the price relatively stable and keep Mint under the radar. So that might seem like the action of many people, but maybe not... Anyway I do expect some rises but even if Mint stays at this price while Bitcoin rises then that's fine.
Isn't the biggest holder the dev? (it's a serious question I'm not being facetious.) I thought there was a sizable pre-mine, so unless someone bought up a ton at the right times it would be hard to rival that.
Impossible to say which address is the dev's for certain: http://mint.blockx.info/richlist/
They have already used some of the premine for bounties and the Mintcoin Fund, so hard to guess exactly how much is left. I think the dev has big long-term plans for this coin, which is why they have been hesitant to use the premine as quickly as some might prefer.
April 15, 2014, 01:42:31 PM
The bottom line is the price would be increasing if people weren't selling. HBN is a great example of this - the price keeps going up because sell pressure is so low. Nobody is really selling in any significant quantity.
Now, mint does have a larger cap but still, if everyone (or even MOST users) were just holding and minting, then the price should naturally be rising. It's not. Therefore, people are selling, and significant amounts.
Now, mint does have a larger cap but still, if everyone (or even MOST users) were just holding and minting, then the price should naturally be rising. It's not. Therefore, people are selling, and significant amounts.
I think it was noted a few pages back that the biggest holder of Mint was selling? Not dumping in a destructive way, but selling enough to keep the price relatively stable and keep Mint under the radar. So that might seem like the action of many people, but maybe not... Anyway I do expect some rises but even if Mint stays at this price while Bitcoin rises then that's fine.
Isn't the biggest holder the dev? (it's a serious question I'm not being facetious.) I thought there was a sizable pre-mine, so unless someone bought up a ton at the right times it would be hard to rival that.
April 15, 2014, 01:40:45 PM
I agree I'm very happy with my investment so far.
When did you buy into MINT?
I've bought in at all different levels but I know that Mintcoin has a promising future / plans so I will continue buying when I can. I also recommend it to family and friends as I believe it's a great solid long term investment.
April 15, 2014, 01:15:36 PM
I agree I'm very happy with my investment so far.
When did you buy into MINT?
April 15, 2014, 01:00:04 PM
Mintcoin, with calm because we are on a hurry.
Fast price rise, fast correction arrives and make you look pump and dumped (even if you are not
Hold your mints, a buy PPC
Estable POS is the future
Fast price rise, fast correction arrives and make you look pump and dumped (even if you are not
Hold your mints, a buy PPC
Estable POS is the future
I agree I'm very happy with my investment so far.
April 15, 2014, 12:56:15 PM
Mintcoin, with calm because we are on a hurry.
Fast price rise, fast correction arrives and make you look pump and dumped (even if you are not
Hold your mints, a buy PPC
Estable POS is the future
Fast price rise, fast correction arrives and make you look pump and dumped (even if you are not
Hold your mints, a buy PPC
Estable POS is the future
April 15, 2014, 12:26:34 PM
The bottom line is the price would be increasing if people weren't selling. HBN is a great example of this - the price keeps going up because sell pressure is so low. Nobody is really selling in any significant quantity.
Now, mint does have a larger cap but still, if everyone (or even MOST users) were just holding and minting, then the price should naturally be rising. It's not. Therefore, people are selling, and significant amounts.
Now, mint does have a larger cap but still, if everyone (or even MOST users) were just holding and minting, then the price should naturally be rising. It's not. Therefore, people are selling, and significant amounts.
I think it was noted a few pages back that the biggest holder of Mint was selling? Not dumping in a destructive way, but selling enough to keep the price relatively stable and keep Mint under the radar. So that might seem like the action of many people, but maybe not... Anyway I do expect some rises but even if Mint stays at this price while Bitcoin rises then that's fine.
Jump to: