Re: [ANN][MINT]Mintcoin, Energy Saving Coin *44 Merchants *WALLET 1.8 RECOMMENDED!
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.
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.
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.