Attention: For Live support and discussion, please visit our Discord! https://discord.me/curecoin
2.0.0a5 binaries are available here: http://1.curecoinmirror.com/2.0.0a5/2.0.0a5.zip .
As stated earlier, this release adds Proof-of-Stake to the 2.0.0a testnet. Also, the code has been cleaned up, so a compile, in Eclipse, straight from github with java 7 (1.7) should generate absolutely no warnings. The debug output from this new release has been modified to avoid "spamming" the terminal with as much unintelligible gibberish. In order to run, simply download and extract the zip file, and then double-click (on Windows) or run from the command line with java -jar Curecoin 2.0.0a5.jar (Linux/Mac) in order to start the daemon.
Then, use either the GUI, or the command-line Curecoin client to connect and interact with the testnet. Note that, in order to test PoS, you need to have an address WITH coins in it. Also, it can't have sent any coins or mined any PoS blocks in the last 50 network testnet blocks. This testnet purposefully has 50-block-ago coin calculation disabled, so that you can mine a block on a new address, and immediately mine a PoS block, as the network won't make sure that you didn't receive those coins more than 50 blocks ago. Obviously, final releases will be different, this is only so that people can effectively test it without having to mine 50 blocks on a generally-quiet testnet. If people want to schedule something, we could all plan a certain time to all mine on the network and submit PoS blocks, to test the network under more load. Internal simulations of network load have been successful, but a lab can never mimic real life.
In this version, PoS doesn't validate the balance you use for nonces, also for testing purposes. That way, pretty much any attempt at a PoS block will succeed, rather than failing due to missing a target with a low address balance. As such, you can send large amounts of coins to an address, stake, and then immediately move them to a new address and stake again. If anyone notices any bugs BESIDES THESE I would love to hear about them 🙂 The ones I mentioned will be, of course, addressed in future versions where other components of PoS testing (for which these hacks are useful) have completed. It's a simple algorithm--client just "rewinds" the blockchain 50 blocks, checks the address's balance at that time, checks that balance against the claimed certificate balance, and validates/invalidates based on comparison. That way, coins sent to an address less than 50 blocks ago would not be included in the staking.
The PoS difficulty is set at 100000, as opposed to the PoS difficulty of 150000. Each coin in an address is worth 100 nonces, so an address with one PoW block (100 coins) would be as likely to mine a PoS block as a certificate signed for 10,000 nonces. This means that, on average, an address with 100 coins will be able to mine a PoS block every ~15 blocks. So mine a few blocks, get a good balance (300-500 coins) and try mining a PoS block on a few different blocks until it succeeds.
In Order To mine a PoS block you must use the command-line client, and type the undocumented command "trypos" without quotes. This will attempt to mine a PoS block. If you have a few hundred coins in an address, chances are a PoS block can be mined within a few network blocks.
Attempts to mine a PoS block can look like this (when unsuccessful):
Pos mining failed with target score 439887573721212
Which is above target 184467440737095
And like this (when successful, example shown is the address C1I2KUDXXONDURBE2CHM3RXULAE7ADLGBTCZA7 mining block 1215):
Successfully submitted block!
Certificate earned score 126737679078394
Which is below target 184467440737095 so earned PoS!
They can also reflect failures to mine a PoS block because of outgoing transactions occurring too recently from the main address.
Note that the above target (184467440737095) is equal to the maximum value of a signed 64-bit number (9223372036854775807) divided by the difficulty (100000) divided by two.
Subsequent attempts to mine a PoS block without the testnet receiving a new block should fail with the exact same target score as the previous attempt.
You can run the GUI simultaneously with the command line client, and you can run multiple of each simultaneously if you have nothing better to do. RPC is wide open (no authentication) so you can also connect with netcat or similar.
There's nothing in particular this public beta is checking for other than PoS blocks are being awarded at the expected rate, and don't generate any errors or exceptions. If you find other bugs, they probably existed (unless, possibly, they have to do with block validation/stacking) before this release, but I'd still love to hear about them. I am aware that the debug prints don't seem to go in order, this is a natural effect of non-linear syncing. Don't worry if the last block "added" in the command line is 269.
The next release (2.0.0a6 internal, 2.0.0a7 public release) will be a complete revamp of the source code. Everything will be more modular, streamlined, and efficient. In its current state, the goals of 2.0 are outgrowing the bounds of the current source code. Adding PoS involved a significant amount of code rework, so future versions will be more versatile for adding functionality. They will also have additional data embedded in the blocks in order to indicate things like block type. This code rework will be a forking change, and will likely come with a new genesis block.
The GUI is also going to be revamped, as I mentioned earlier, to use a new graphics engine I've been writing.
Quick recap of working 2.0 features in 2.0.0a5:
-Merkle Trees (instead of ECDSA) (Quantum-computer resistant, so large quantum computers couldn't be used to forge signatures for addresses)
-Variable-tree size (for addresses that can sign more transactions, but take more space for private key)
-OB (outstanding balance) table (instead of UTXO, or unspend transaction outputs) (Runtime complexity of finding address balance is O(1) rather than O(n) where n is number of unspent transactions)
-Proof-of-Work based on authority certificates
-Proof-of-Stake based on self-made 'null' certificates and transaction history
-Full transaction history lookup for any address, instantaneous balance lookups due to blockchain design
And the features that the current protocol would support, given a client with client-side code to handle:
-Partial blockchain storage
-Manual multisig (Merkle Tree roots broken up across multiple owners)
In "gethistory" requests, there is (currently) no distinction between PoS and PoW blocks.
Block 1215 is PoS, as would be visible looking at the null certificate for the block.
Testnet is, naturally, about getting things *working* rather than *efficient*, but you suggestions for efficiency improvements for the current code or proposed features are also welcome.
Testnet coins have no value. Don't mine them for profit. Don't sell them. Don't buy them. Testnet can be reset at any time, and coins WILL NOT transfer from the current testnet to any future valuable blockchains.