Everyday team coordination, progress reports and help requests

Projects
21

[quote=“by321, post:18, topic:1950”][quote=“FuzzyBear, post:16, topic:1950”]4 am here but i got it :slight_smile: 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.[/quote]
I have written some instructions GenesisBlockReadMe file in the repo on the test branch, you will see how far I got with my testing in there…

Fuzzybear

22

This is one of those times that coindesk.com should run an article about the significant $30,000 developer bounty.

I hope they are listening.

23

In the GenesisBlockReadMe it says:

[quote=“FuzzyBear”]+now when you run the code it should be set ready for you to make the initial seed nodes…

+For this you will need two different ip’s[/quote]

We want all shares created to be in the possession of a single issuer initially, so we want there to be a single isolated node for the first 400 blocks. Is there a need or an advantage to have at least two nodes on the network when it first starts?

24

In the GenesisBlockReadMe it says:

[quote=“FuzzyBear”]+now when you run the code it should be set ready for you to make the initial seed nodes…

+For this you will need two different ip’s[/quote]

We want all shares created to be in the possession of a single issuer initially, so we want there to be a single isolated node for the first 400 blocks. Is there a need or an advantage to have at least two nodes on the network when it first starts?[/quote]

It is a need that you have two nodes to start the blockchain…

I think what we are after is a blockchain set up a little more developed than what I first got the impression… u want it 400 blocks in and starting at block 400… from when you open the repo right?.. or to be able to get to this point very quickly… should be able to set a checkpoint at that block and reset the blockchain back to that block…

Ok so bit more work needed on the genesis block work thenyou should not need to generate a genesis block each time, but the code at this point is a useful starting point for what we are after.

Fuzzybear

25

Why? What happens with one node? Is it practical to change things so it does create blocks with one node?

There are a variety of different needs in different contexts. First and foremost, we need to test and fix any problems regarding the creation of the first 400 blocks, which is where all the shares are created. It would be best if we can make it run with a single node. Every implementation of Peershares will have to do this independently so it needs to be reasonably easy and well documented. With later testing we will want to use an established blockchain that is past block 400 but we aren’t there yet.

26

Why? What happens with one node? Is it practical to change things so it does create blocks with one node?[/quote]
You need two nodes connected to each other at the start of the coin or u can not mine and confirm the blocks on the blockchain from my testing experience. We can use the windows box and the linux box as our two nodes. I’ll see if I can get this set up tonight between the two VPS’s. This will give me a chance to test the genesis block generation code and should be able to test if blocks can be mined.

Fuzzybear

27

Hi Fuzzybear,

I ran the code but not sure what happened. It printed out the genesis block stuff but didn’t exit, the CPU miner then started and it connected to some peers and just carried on. Here’s the output in debug.log:

PPCoin version v0.3.0.0-gdd58f70-beta ($Format:%cD)

…

Test Network: genesis=0x00000001f757bb737f65 …
PPCoin Found Genesis Block:
genesis hash=00000001f757bb737f6596503e17cd17b0658ce630cc727c0cca81aec47c9f06
merkle root=3c2d8f85fab4d17aac558cc648a1a58acff0de6deb890c29985690052c5993c2
CBlock(hash=00000001f757bb737f65, ver=1, hashPrevBlock=00000000000000000000, hashMerkleRoot=3c2d8f85fa, nTime=1345090000, nBits=1d0fffff, nNonce=122894938, vtx=1, vchBlockSig=)
Coinbase(hash=3c2d8f85fa, nTime=1345083810, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000, -1), coinbase 04ffff001d020f274b4d61746f6e69732030372d4155472d3230313220506172616c6c656c2043757272656e6369657320416e642054686520526f61646d617020546f204d6f6e65746172792046726565646f6d)
CTxOut(empty)
vMerkleTree: 3c2d8f85fa
PPCoin End Genesis Block
00000001f757bb737f6596503e17cd17b0658ce630cc727c0cca81aec47c9f06
00000001f757bb737f6596503e17cd17b0658ce630cc727c0cca81aec47c9f06
3c2d8f85fab4d17aac558cc648a1a58acff0de6deb890c29985690052c5993c2
CBlock(hash=00000001f757bb737f65, ver=1, hashPrevBlock=00000000000000000000, hashMerkleRoot=3c2d8f85fa, nTime=1345090000, nBits=1d0fffff, nNonce=122894938, vtx=1, vchBlockSig=)
Coinbase(hash=3c2d8f85fa, nTime=1345083810, ver=1, vin.size=1, vout.size=1, nLockTime=0)

…

CPUMiner started for proof-of-stake

…

askfor block 0000000196c391f1acc1 0
askfor block 0000000512863169c9b2 0
…

28

I have found that a good articulation of a problem tends to suggest a solution. Accordingly, I would like to frankly articulate the primary problems we have in the Peershares project at present so that team members will be able to see and enact solutions.

Before I focus on the challenges we are facing, I would like to say that development is progressing quickly – faster than I expected. We are finished with phase two and phase three is half done. Several additional phases will be initiated by developers in the coming days as phase three is wrapped up.

At this point in time the greatest risk to the Peershares project is a shortage of QA and testing. The best way to mitigate this risk is to dedicate more resources to it. I’ll say more about this later. The second best way to mitigate this risk is to communicate more within our team about what is blocking progress in testing and what is needed to resolve those blocking issues.

About dedicating more resources to it: For those who are recruiting such as David and Sentinelrv, please focus on QA personnel over developers. There has been a shortage of QA applicants. If you have the skills to help us with QA, please contact me. I initially asked Ben on the QA team to work on peershares.net content. This was probably a miscalculation of my part and I would ask that Ben spend very little time on peershares.net as it is not the priority now. Ben is presently working on assembling test cases and acceptance criteria for payment of our mini-blockchain bounty. This is important to do now because Cryddit is ready to begin developing it tomorrow, it will take a long time to develop and because it will need extensive testing after being included in the solution, because it is a very high risk feature. So, Ben has not had bandwidth to do QA for phase one or two.

There is another way to dedicate additional resources to it besides adding new team members: While developers shouldn’t stop being developers, please be mindful of our present shortage of QA and do what you can to compensate for it. Perform unit tests of your code and report the results to the team. Take time to work with fishwich and Ben to make sure they understand what the specifications of phase one and phase two are well enough that they can develop test cases for them. If you don’t see this happening, ask what you can do to help. While I am have done most of the development of phase one, I would like to ask FuzzyBear if he could work with fishwich to create and run some unit tests on it (since he has done some work with it) as I am quite busy with implementation related tasks that no one else is in a position to complete.

Regarding more communication within our team about what is blocking progress in testing and what is needed to resolve those blocking issues: Please post in the team coordination thread more often! It looks like we have a genesis block but I haven’t heard anything about subsequent blocks. I heard a second hand rumor that the genesis block contained no shares. While the outputs of this block are likely unspendable and therefore relatively unimportant, it begs the question of whether subsequent blocks are producing the appropriate number of coinbase shares: 2500 per PoW block. Has anyone been able to produce a second block? If not, what problem are you encountering? If so, what was the result and speed of block generation?

Because the phases we are developing have dependencies on prior phases, we are beginning to see the slow progress in QA impair the excellent progress we have seen in development. For instance, phase three has dependencies on phase two. Because phase two has not been tested and cannot be merged into master, we are branching from phase two to develop the portions of phase three with dependencies. All subsequent phases have dependencies on phases one and two. Ideally we would pull phase one and two into master and then branch from master to create a code base for these subsequent phases. In reality we are having to improvise to provide the needed dependencies for the newer phases. This reduces the quality of development substantially.

29

May I suggest we use GitHub issues instead of this thread to discuss development?
I’m afraid this thread will become a little messy if we talk about all the development.

Each phase can have its own issue and be discussed there. And we can easily open new issues for sub tasks or specific problems.

30

Will do! I’ve adjusted our public postings on bitcointalk and odesk, and contacted some recent applicants to inquire about their QA qualifications. I’ve also asked if they know of any QA personnel that they would recommend.

31

There has been a request to have twice weekly team “standups” so that we will have dedicated times that team members can talk to each other real time and so that everyone stays aware of how their work fits in with other team members’ work. A few of us agreed that 18:00 GMT on Sunday and Wednesdays is a good time. Please let us know if this time is a problem for you and propose an alternate time. I expect that there will be times when other obligations prevent the attendance of individual team members. Meetings will be held in the team room on Cryptocat.

32

May I suggest we use GitHub issues instead of this thread to discuss development?
I’m afraid this thread will become a little messy if we talk about all the development.

Each phase can have its own issue and be discussed there. And we can easily open new issues for sub tasks or specific problems.[/quote]

I think there is a place for discussion here and on GitHub. For discussion about specific issues, GitHub will most likely be the right place. The kind of entries I was hoping for here would be the type of content you would normally deliver at a stand up in an office setting.

33

I can commit to the Sunday meetings without issue, but Wednesday will not be possible because of my work schedule.

I doubt I am needed more than once a week right now anyways, so this schedule sounds good to me. If you can forward me the team room info I will join going forward.

34

Sunday 18:00 UTC should work for me, but Wednesday will be difficult (or with a very short attendance).

35

Wednesday and sunday should be possible for me though wednesdays may be a bit busy

Fuzzybear

36

Based on feedback, let’s cancel the Wednesday stand up and just meet on Sundays at 18:00 GMT. If we find weekly meetings very helpful we can talk about another time during the week that aligns with schedules better.

37

@Fuzzy, @SigMike, @Jordan, @by321 (cc: @Fishwich):

When you guys get a chance, could you please do me a favor and take a look at this “Phase 1” Peershares wiki page to help me understand if I’ve caught all of the functions included in the Overview? My goal is to have all of the work included in that overview so that Fishwich and I can make sure that all of the the expected functions have QA checklists and test case coverage. The same effort will need to be conducted for the second and third phases.

Don’t feel like you need to write the business cases or test cases yourselves. I’m primarily concerned with making sure that I understand what development has already been conducted, and that I’m capturing the major functional requirements (such as number of PoW blocks, hardcoded number of shares created during PoW, % of stake reward for PoS blocks, etc.)

Feel free to update that page directly, and I can go back in and normalize the way it is described once we’ve gone through a couple of passes at this and I’ve figured out how to best describe the work that you are doing.

Please bear with me in the beginning, because these will look like they are moving slowly, but in reality, once Fishwich and I have a framework in place, it should be very straight-forward to get each of the phases entered and development itemized so test coverage can be written.

Additionally, I’ve begun to document the steps required to set up each of the development environments. A lot of this is already described, but in many cases, it’s missing updates or subtle steps. For instance, I’ve taken the first pass at setting up the Linux environment, and will be going through these steps locally this afternoon to confirm that I’m not missing anything. Like the phases, if you get a chance to review these pages as you make updates to the code base (or include additional features that require dependencies), I would appreciate it. Here’s the Linux compilation guide to use as a base reference.

@Jordan:

I’ll get a chance this evening to document my thoughts on the acceptance criteria for the mini block chain. It’s just stubbed out right now, but as soon as I get the draft published, you will be able to see the requirements on this Peershares wiki page.

Also, I passed the message on to CoinHash that we’re going to be delayed on getting him the draft content for the web site for a bit, while we move the QA efforts forward. He responded to let me know that he’s seen the status update and will be awaiting the next steps. Does it make sense to shift the website content development work from me to David, as it really is a component of the Peershares marketing effort? If that’s an option, we’ll be able to continue to move things forward with the site, concurrent to our development of the tools to meet the Peershares QA needs. Let me know what you think of this option, and if it is something that will fit into David’s schedule and agreed-to scope of effort.

@Fishwich:

When you get a chance, let’s synchronize on the test case structure and apply it to the “Phase 1” features and functions that I’ve asked the team to identify above.

If anyone has any questions, please let me know.

38

[quote=“Ben, post:37, topic:1950”]@Fuzzy, @SigMike, @Jordan, @by321 (cc: @Fishwich):

When you guys get a chance, could you please do me a favor and take a look at this “Phase 1” Peershares wiki page to help me understand if I’ve caught all of the functions included in the Overview?[/quote]

I added some details to the “Functional Overview”.

I wrote a business case I hope you will find helpful.

[quote=“Ben, post:37, topic:1950”]@Jordan:

I’ll get a chance this evening to document my thoughts on the acceptance criteria for the mini block chain. It’s just stubbed out right now, but as soon as I get the draft published, you will be able to see the requirements on this Peershares wiki page.[/quote]

Thanks. Please send me a Bitmessage letting me know when it’s done as well so I can let Cryddit know and post the bounty as quickly as possible.

I will get back to you on this.

39

@Jordan: BitMessage sent with notes (and link to the in-progress wiki page) about the MBC acceptance criteria. I don’t think it’s quite ready for prime time, but I hope that this pass catches the important things.

40

I am pleased to announce pennybreaker has joined the Peershares QA team.

He suggested among other things that we use VMs to test Peershares, which I have seen work very well in the past. Accordingly, I have asked FuzzyBear to increase the specs of both our VPSs to 4 cores and 4 GB of RAM. If any of you find this to be insufficient, please speak up, because additional hardware is quite affordable.

Please give him the info and cooperation he will need to get productive quickly, particularly Ben and fishwich. pennybreaker’s Bitmessage address is: BM-2cX83izSGqjJLcujBrEwRh4bdt89EW56QV