Add method to create proof of ownership (e.g. signed string containing information regarding owned badges)
Add method to verify create proofs and thus reconstruct badge ownership
Incentive as follows:
Person A likes to give person B 100$ under the condition he completed all of SQ.
The proof functionality shall be a way to allow person A to proof person B to have completed all SQ without a doubt.
Possible implementations:
Use albedo to sign certain data. Verifier can be certain that data stems from owner of account (as private key was required)
Possible data to encode:
Concept 1:
Array of objects containing badge transactions [{name, transaction_hash}]
timestamp of verification (one way of verifying this proof was indented for the receiver)
Unique identifier given by the verifier (thus the verifier can be sure no old proof was 'reused')
Benefits:
Badges could easily be verified with 1 query per badge.
Problems with this approach:
Signed data is quite long:
[name (>=14 byte) + transaction_hash (64 byte)] * num_owned + identifier + timestamp > ~78*n+4 bytes
Thus the proof string will become quite annoying to handle (~1780 bytes as of S03=223 chars)
Concept 2:
Array of badges [{name}]
timestamp of verification (same as above)
unique identifier (same as above)
Benefits:
Lower Data usage: [name (>=14 byte)]*n + identifier + timestamp > 14*n+4 bytes (~340 bytes as of S03=43 chars)
Problems with this approach:
Verifier would need to query whole account (similar to account viewer).
This could in some circumstances require a whole lot of queries (many transactions on quest account)
Implement system which includes
Incentive as follows:
Person A likes to give person B 100$ under the condition he completed all of SQ.
The proof functionality shall be a way to allow person A to proof person B to have completed all SQ without a doubt.
Possible implementations:
Use albedo to sign certain data. Verifier can be certain that data stems from owner of account (as private key was required)
Possible data to encode:
Concept 1:
[{name, transaction_hash}]
Benefits:
Problems with this approach:
[name (>=14 byte) + transaction_hash (64 byte)] * num_owned + identifier + timestamp > ~78*n+4 bytes
Thus the proof string will become quite annoying to handle (~1780 bytes as of S03=223 chars)Concept 2:
[{name}]
Benefits:
[name (>=14 byte)]*n + identifier + timestamp > 14*n+4 bytes
(~340 bytes as of S03=43 chars)Problems with this approach: