I ask that only Peershare team members post in this thread.
This is a place where team members can coordinate their work with one another by posting updates on what they have just finished, what they are working on now, what they need from other team members to progress. This should help the team function as peers instead of me acting as an intermediary for coordination of work.
There is a flaw in the design regarding how a Peershare address will be associated with a Peercoin address for dividends that requires some redesign. I am working with sigmike to redesign this.
This means that Issue 1 may not be needed in the way we had thought. Because it is already coded and will be useful for general purposes, I would still like it committed to branch 0.2.1.
Issue 6 should not be coded as a result of this design change so I have closed the issue.
There is a need to refine and divide the Phase Three specification contained here (http://www.peercointalk.org/index.php?topic=527.45) into as many different GitHub Issues as is practical so that different developers can all take on different pieces of the phase. Any volunteers? There is an urgent need for this as we approaching the end of Phase 2.
I need to attend to several architectural issues including the urgent redesign of associating Peercoin and Peershare addresses instead of this task if possible.
Just to say primarily I am finishing off setting up VPS’s with fully working build environments so everyone can test builds or their code quickly if they are still having build difficulties. Should be ready in a few hours 
Fuzzybear
sigmike has devised an incredibly elegant solution for our need to associate a Peershare address with its Peercoin dividend address. Rather than trying to store the association in the wallet and blockchain, we will simply create Peershare addresses and convert them to their Peercoin equivalent. The user interface will allow these converted Peercoin private keys to be exported to your Peercoin wallet whenever the user desires. This means the Peershare client does not need to be connected to the Peercoin client when creating a new address. The only piece of information needed to derive a Peercoin dividend address is the Peershare public key. Genius! Thank you, sigmike.
I will make adjustments to the GitHub issues accordingly.
branch 0.3.0-Phase-Three has been created so by321 can begin working on phase three while sigmike wraps up phase two in branch 0.2.0. The new branch contains the modified ports and config related values since those were pulled into master before the branch was created.
Phase Two is nearly code complete thanks to sigmike. This means it is likely to be ready for testing this weekend. fishwich is focusing on testing Phase One so I would like to make Phase Two testing the primarily the responsibility of Ben.
Ben and fishwich: Can the two of you discuss what QA standards, procedures and tools you would like the team to adopt and let us know what those are?
I just pushed a branch 0.2.6 and made a pull request: https://github.com/Peershares/Peershares/pull/28
Phase 2 is ready to test.
On it.
Status: Collecting information from the key participants and writing the web site copy. Confirming that I can get the VPS dev environment working and ready to test against the latest builds.
VPS Windows and Linux have both been tested and sucessful builds have been made by other members besides me so I am happy everyone should be able to build the Peershares repo on either server.
One thing was highlighted in that if someone is running ppcoind under their user login the other users will not be able to run ppcoind at the same time due to only one instance of the same network can be run at any given time. Solution is for now to ensure you please stop the ppcoind when you have finished your session. Is there anything we can do at the User level on the servers to resolve this? I don’t think so but I do not know all the tricks of linux user setups for things like this. Changing the port in the conf file will not resolve the issue as well as far as I am aware… comes from the blockchain directory .lock file.
It was raised as well that the genesis block code is not complete. Currently 0.1.1-testing… branch does build but there is still one change I can see that need to be made in order for genesis block generation to happen. Branch 0.1.0 does not build, but the fix for this should be in the 0.1.1-testing-only… branch. I will be looking into both of these issues this later tonight and reporting my status.
Fuzzybear
To run multiple instances you must change the data directory, by providing a “-datadir ” on the command line. If there’s a peershares.conf in this new data directory that changes the port and rpcport, I think it should run fine alongside other instances.
Of course you must provide the same “-datadir” when you run ppcoind to make RPC calls.
I’ll give that a try, thanks, sigmike.
When the genesis block is released, will we need to set the difficulty artificially low to generate lots of blocks (say 100K) quickly ?
I am not sure how quickly the seed PoW blocks will generate. This will need to be observed in testing and then we can adjust if needed. However, there are only 400 PoW seed blocks with the way it is coded right now. After that, the system is pure PoS.
I saw that fishwich was asking about how to create a genesis block earlier today in the team room and did not get his question answered.
My understanding has been that if you have a build from branch 0.1.1 that it should spontaneously create a genesis block when you run the daemon or Qt. FuzzyBear did say today he thought there was one more problem with code preventing the generation of a genesis block. He didn’t elaborate so I don’t know what insight he had about a problem. I would say test it and let’s have FuzzyBear elaborate on what flaw he sees and whether he has it fixed.
4 am here but i got it Issues pushing changes to github as well but that for another day…
The code on 0.1.1-Testing-Only—Do-Not-Merge branch when you build the client and run for the first time it will generate you a genesis block eventually using the local CPU. The progress can be seen in the debug.log file in the directory of the blockchain. Once nonce produces a valid hash the two values need to be put in the code and a check turned back on … so some clean up work could be done to make this better.
Let me know how you get on
Fuzzybear
19 Feb. Update:
[ul][li]Sent CoinHash the overview of content sections that I’ve written (or am in the process of writing) for the site, so he can start developing the layout.[/li]
[li]Coordinating with Fishwich on how we’ll develop, document and work through the QA test cases.[/li][/ul]
[quote=“FuzzyBear, post:16, topic:1950”]4 am here but i got it Issues pushing changes to github as well but that for another day…
The code on 0.1.1-Testing-Only—Do-Not-Merge branch when you build the client and run for the first time it will generate you a genesis block eventually using the local CPU. The progress can be seen in the debug.log file in the directory of the blockchain. Once nonce produces a valid hash the two values need to be put in the code and a check turned back on … so some clean up work could be done to make this better.
Let me know how you get on[/quote]
FuzzyBear, can you write down the details of the steps in a file somewhere in the repo ?
Also, is the end result a couple of files containing the initial blockchain ? If so, maybe they should be in the repo too, to make things easier if we want to restart the blockchain.
I would like to place a $30.000 bounty on delivering an implementation of a mini-blockchain (in addition to bitfreak!'s existing $20.000 bounty) as described here in this whitepaper:
www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf
In order to make sure we can determine whether the project was completed and the bounty should be paid, it is wise to formulate a series of test cases, the passing of which demonstrates completion. Although I would like fishwich and Ben to attend to the genesis block issue as a first priority in cooperation with FuzzyBear and by321, would either of you be interested in creating test cases for this after that is resolved? Perhaps there are some automated bitcoin tests in existence that could be run to verify completion as well because the mini-blockchain should be functionally similar to standard blockchains, just smaller. bitfreak! (not bitfreak) on bitcointalk.org is the whitepaper author and Cryddit on bitcointalk.org is a developer gearing up to attempt to collect the bounty should you wish to speak to those most knowledgeable about the project.
Everyone presently on the Peershares team will be ineligible for the bounty. The idea is to bring more development resources to the project, not shift resources. I need team devs to be working on other phases.
Here is a discussion about development of the mini-blockchain: https://bitcointalk.org/index.php?topic=371601