I'm working on the client / chain / ₱oA workflow tonight and wanted to get any insight or suggestions you have. at this point I've got a crypto challenge / response exchange similar to those used to log in to sites without sending your password to the server. This will essentially prove that
- 1, You requested the "work",
- 2, You (and not someone else) did the work.
- 3, You performed some action along with the work.
The ₱oA chain will not worry about ordering, each action will be atomic. At least for initial release. As actions become more advanced we will work out ordering (find x page, click y link, comment in z field)
If actions are not ordinal they can not be consistently hashed into an authenticated structure. Well ordering is critical not only block to block, but over the whole structure. (Bitcoin orders transactions within a block for a reason.)
The Client:
Technology stack:
- awesomium (in proccess browser chromeium browser)
- peer.js (webrtc)
- btsync (Blockchain storage and distribution)
- nodejs (server)
These are all fine technology stack pieces (I am particularly a fan of both Nodejs and peer.js) but it isn't clear how they will fit together to form a node. Can you elaborate this some?
General flow of client (How to mine ₱ROZ)
..
I will try and include a cloud build environment that will let you inspect code before issuing a build. This will allow all the haters to understand exactly what's being built into the client and not have to trust a binary they download from the internet.
My only suggestion here would be to not reinvent the wheel. Gitian or similar makes light work of this concern.
How mining works:- You will navigate the CoinProz website and affiliate sites using the client. The Client will inject logic into the pages you visit to place "₱ Deposits" throughout the mineable areas. (People might be able to purchase blocks of actionable activity for anyone to mine later)
Already we hit our first major question! How will the authenticity of these tokens be traced in verification? It seems like this step should be the first place where there is some mention of some crypto primitives. Maybe Rabin's OT distributes some partial Shamir share, which can only later be reassembled after independent validation over action? I'm not sure of the details you intend, but somehow this initial handshake needs to be both authenticated and preserved in order to be able to root the rest of the proof structure, no?
- Each page the client visits will also include an incremental nonce from the client.
Why? If the client is injecting the initial handshake token (which is presumably unique) why does the client need to introduce a secondary identifier here?
- The server takes the client nonce, a server nonce and session salt and creates the deposits.
What exactly is the "deposit" in this step, how is it "created" and by whom? Your use of "the server" is ambiguous throught this explanation, can you restate this with more clear terms?.
- The client upon receipt of the deposits from the network will inject them into the page present in the client.
So now we have a tuple of <ClientNonce, ServerNonce, Salt> that is somehow encoded as a "deposit"? Is ServerNonce the same thing as the handshake token from step 1? If not, what happened to that?
- In order to mine a deposit you will need to perform the action, performing the action usually involves submission of a form. The form will contain a piece of the solution to the crypto puzzle, this will be stored in the chain.
Huh? What, specifically, is the crypto puzzle, and what is this "piece" of it that the form contains, and how does that relate to the deposit? Who submits this "piece" to the network and how is authenticated into the chain? (Who is producing the blocks, and how? How do they confirm this "piece" as a legitimate partial token? How is this confirmation later retraced in verify steps?)
- Upon submission the client will receive the last piece of the crypto puzzle, allowing a user's client to build the pieces into a transaction and sign it with the client's current pubkey.
Now we have a full ("completed?") puzzle, that is signed and submitted. Why is this done separately from the last step?
- The server can determine from the resulting transaction that the owner of the pubkey is the signer of the transaction, that the server verified that the action was completed, and that the rest of the deposit was actually placed there by the network.
Sure. I agree that the server the form was submitted to can verify that the action was completed, and that the "deposit dance" was done. However it is not immediately clear how anyone *else* can now trace this claim. A verify agent (third party peer on the network) can see the pubkey of the proving (person doing the action) agent, the encoded "deposit" tuple marking nonces from the proving agent and challenging (the server hosting the action) agent and session token, and the completed and signed "puzzle" result. How do they reassemble these into a proof trace that asserts the constraint that the action was actually performed?
What is the criteria by which a transaction is valid? What is the criteria by which a block is valid? These are the critical questions, and appear to be unanswered in your explanation.
This is a very high level view of the puzzle/proof process, a more detailed description will live on our github page.
It is so very high level that it can basically be restated as:
1. Prover requests a token from challenger
2. Challenger requests a token from Prover and from the network and generates a deposit
3. ? ? ? ? ? ? ?
4. PROFIT!
Sorry for the lame joke.
Seriously though, your outline does not actually explain anything about how workflow can work. It says there will be some tokens and some form of crypto puzzle, and then everyone will be happy and everything will work out. It seems like there's an excluded "and then some magic happens" step where those tokens and that puzzle somehow make everyone happy and make everything work out!
Probably the most missing part of the missing parts is the "fourth agent." You've mentioned the proving agent, the challenging agent, and (briefly) the verification agents. Under traditional certification network models, this would probably be enough roles. For a differently structured coin (one without fully-mined-at-genesis assets) these roles could be all that is necessary. However, for Proz PoA you will, of course, need a fourth role which we can call the "bursar" role. The bursar is the entity which is currently holding the actual key to the coin to be distributed. Somehow we need to go from a challenger issuing a challenge for a proving agent, to the proving agent issuing a solution and consequent claim to a bursar agent, to the bursar agent transferring claim of the coin (or key) to the proving agent, to the whole flow being independently retraced as valid and authenticated by the verifying agents.
So far, I don't see how any of that can be done with just what you have described.
Thoughts? Improvements, Glaring holes?
I think this is a
seemingly very weak effort on something that should have been solved long before this project was even mentioned in public as a "PoA coin."
I can't really comment on potential improvements until there is a more complete explanation to improve upon. Right now my most pertinent suggestion for improvement would be "explain *all* the steps fully."
The glaring holes that will need to be filled in are many and large, perhaps starting with an exposition of what actual cryptography primitives will be employed, how, when, and by which agent. This would go a long way toward making your explanation of the contribution start to fit the claim of the contribution. We don't need complete implementation details, just a workable theory.
The theory that you've presented here is just, for lack of a better word, humorous.
