Added documents for design decision explorations and zkp+transactions design #2
Conversation
Currently it has a discussion of the UTXO vs Account models. Later we can more. The idea is that as new people join the project this will help them get up to speed quickly on history of our thought process and the design decisions.
docs/ppl-zkp-design.md
Outdated
| - IOUType | ||
| - UOM (Unit of Measurement) | ||
| - PublicKey | ||
| - NotaryID (the primary notary for this wallet) |
There was a problem hiding this comment.
Should we keep the primary notary to be decided at run time by the notary pool?
There was a problem hiding this comment.
Actually, based on our discussion regarding how Notaries are assigned and possibly changed, I'll need to make bunch of small changes throughout the document. Will do that next week.
| - TxCoreHash | ||
| - SIn1ID, SIn1Hash, TxCoreHash, SIn1Proof | ||
| - SIn1ID, SIn1Hash, TxCoreHash, SIn1Proof | ||
| - SOut1ID, SOut1Hash |
There was a problem hiding this comment.
I suspect all attributes for out states that need to be recorded in the public ledger will be required here.
|
@ngkabra , apropos of "Proof of knowledge of the PrivateKey matching the PublicKey in SIn1Sleeve" in this as a separate proof from the statehash proof (which is how I read it), I was wondering if we should have proof of the whole state itself being signed by the (user's) Private Key .. this would be like the user authorizing the dropping of that UTXO? This would be to get over the possibility that the Wallet Ooperator could otherwise reuse the isolated proof over spurious transactions? In fact perhaps @ngkabra the end user of the input utxo being extinguished could sign the transaction and that signature could be included in the transaction? |
Yes, the owners of all the input states being extinguished need to sign the entire transaction. I will clarify that in the document. |
Used attributes consistently to refer to members of states and data-members for other uses. The term _owners_ is now used instead of signatories. Notary now adds a timestamp, computes a transaction_id by hashing the transaction contents, and signs to the transaction. The transaction_id is returned to the caller. Clarified how the list of owners is computed. Clarified the difference between public and private inputs to the ZKP program
Transaction creator and other owners' are treated differently. Transaction creator directly proves proof of knowledge of private id. The other owners only sign a hash of the transaction core (not the full transaction core).
Other owners now sign only the hash of the transaction core. The requirements of the ZKP digital signature scheme now clarify that only the signature verification needs to be ZKP friendly Appendix of rejected ideas added Creator private id is now a private input to the ZKP program
Added 2 new documents: one for exploring architectural design decisions (currently UTXO vs account models) and one for zkp+transactions+public/private ledger design