Build a docker-compose framework to build and run the validator, REST API, transaction processor, and server the client.

This list should be as comprehensive as possible, but may be updated later. It should include all topics that will need to be covered in the intro app, its related curriculum materials, or (most likely) both.

Topics can be added and commented on here:
https://docs.google.com/document/d/1M3iJx1gBDp0C0anqJ2vOncB_UjRfRtVEJOcz4Dk09_k

• Review and flesh out all docstrings
• Ensure test coverage is adaquate
• Add problemify-style solution/problem comments for splitting staging code into stub and solution code

Include tests to demonstrate it works. Blocked by #19.

Original Design

Closes an Offer and exchanges the cryptomoji in the Offer body and specified response.

Requirements

• Signer must be registered as a collection
• If the specified response is not a request, the signer must own offer
• If the specified response is a request, the signer must be the owner in the response
• The cryptomoji exchanged must all still be owned by the appropriate parties
• The response index must correspond to a valid response on the offer

Payload Schema

{
  "action": "ACCEPT_RESPONSE",
  "offer": <string, address>,
  "index": <int>
}

Generate new cryptomoji on BlockInfo transactions. Make sure the module that generates them is either comprehensive (generates every possible kaomoji ever), or easily expandable. Include tests to demonstrate it is working. Intrinsically tied to #13 , as the DNA generated must be renderable by the client, not just a random string. Blocked by #11, and #14.

Original Design

This payload would be sent to the TP by the publisher themselves. It should never be sent by the client. The TP would handle generating the new gen 0 cryptomoji, and selecting a pseudo-random (but deterministic) collection to give it to.

Requirements

• Signer must be the block publisher

Payload Schema

{
  "action": "ADD_BLOCK_INFO",
  "timestamp": <int>
}

State Schema

{
  "blockNumber": <int>,
  "winner": <string, public key>,
  "timestamp": <int>
}

Users should be able to generate a new private key, which will be analogous to a username/password. Generated private keys should be copyable and/or downloadable. Generating a private key should automatically create a collection and "log in" to the app.

Alternatively, users should be paste in an private key to "log in" with an existing Collection. If this private key has no Collection, one should be generated (possibly after some sort of confirmation that it isn't a typo).

Include tests that demonstrate it is working. Blocked by #17.

Original Design

Deletes an existing Offer without exchanging any cryptomoji.

Requirements

• Signer must be registered as a collection
• Signer must be the owner of the Offer
• Offer must exist

Payload Schema

{
  "action": "CANCEL_OFFER"
  "offer": <string, address>
}

Design the components of the finished intro app. Design should be as comprehensive as is reasonable, and should include some guidance about what will be included in starter code, and what students will be expected to code themselves.

Include any design documents in the shared Gdrive folder:
https://drive.google.com/drive/u/1/folders/1Xsr2SjXgAtMhLNI5fnFyrByxcXinXGwS

Design the components of the finished Cryptobunny app.

Design should be as comprehensive as is possible, and should include some guidance about what will be included in starter code, and what students will be expected to code themselves.

Include any design documents in the shared Gdrive folder:
https://drive.google.com/drive/u/1/folders/1Xsr2SjXgAtMhLNI5fnFyrByxcXinXGwS

Allow users to create Offers to trade one or more of their cryptomoji for one or more of someone elses. They should also be able to accept existing Offers, or make counter-offers (i.e. "responses").

This list should be as comprehensive as possible, but may be updated later. It should include all topics that will need to be covered in the Cryptobunny app, its related curriculum materials, or (most likely) both.

Topics can be added and commented on here:
https://docs.google.com/document/d/1M3iJx1gBDp0C0anqJ2vOncB_UjRfRtVEJOcz4Dk09_k

Users should be able to select one of their cryptomoji as a sire, available for breeding.

They should be able to view the available sires.

They should be able to select a sire and one of their own cryptomoji and breed them. (Moved to #68.)

Add README files to:

• the root directory
• code/part-one
• code/part-two
• code/part-two/client
• code/part-two/processor

These READMEs should include:

• guidance about how to use the repo
• instructions on how to start components
• instructions on how to run tests and complete problems
• design specs for the apps being built

Blocked by #62

Use the Cryptomoji script and slides to record a (short) video lecture explaining the Cryptomoji project.

Include tests to demonstrate it is working. Blocked by #10.

Original Design

Selects a cryptomoji as a collection’s sire, making it available for breeding.

Requirements

• Signer must be registered as a collection
• Signer must own cryptomoji
• Cryptomoji must exist
• Cryptomoji must not be a part of any Offers
• Cryptomoji must not be currently incubating

Payload Schema

{
  "action": "SELECT_SIRE",
  "sire": <string, address>
}

State Schema

{
  "owner": <string, public key>
  "sire": <string, address>
}

State Address

The final 62 characters of a Sire Listing’s address are the first 62 characters of a SHA-512 hash of the owner’s public key.

5f4d76 04 1b96dbb5322e410816dd41d93571801e751a4f0cc455d8bd58f5f8ad3d67cb
  -> 
{
  "owner":
    "034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa",
  ...
}

Requests module should be standardized with tests. Requires pulling in superaget and doing some mocking.

An initial version of the transaction processor that can register with the Sawtooth Validator, and receive and correctly handle a CREATE_COLLECTION action. Should also include unit tests to confirm it works properly. Blocked by #9.

Original Design

Essentially just used to register a public key in the app. Creates a new collection with the transaction signer’s public key and an empty set of cryptomoji.

Requirements

• Signer’s public key must not already be registered

Payload Schema

{
  "action": "CREATE_COLLECTION"
}

State Schema

{
  "key": <string, public key>,
  "moji": [ <strings, addresses> ]
}

State Addressing

Namespace

The first six characters are reserved for an application namespace. In this case, we will use the first six characters of a SHA-512 hash of the application name, “cryptomoji”.

5f4d76

Resource Prefix

Next a one byte (two character) prefix follows which designates what sort of resource will follow:

• 00: BlockInfo
• 01: Collections
• 02: Collection Resources (i.e cryptomoji and offers)
• 03: Sire Listings

Collection Hash

The final 62 characters of a collection’s address are the first 62 characters of a SHA-512 hash of the public key.

5f4d76 01 1b96dbb5322e410816dd41d93571801e751a4f0cc455d8bd58f5f8ad3d67cb
  -> 
{ 
  "key":
    "034f355bdcb7cc0af728ef3cceb9615d90684bb5b2ca5f859ab0f0b704075871aa",
  ...
}

Come up with a way to generate random DNA strings and render those as kaomoji. These strings ideally should be able to represent every existing kaomoji, and should only generate weird garbage 10% of the time or so. Bonus points if it can come up with novel kaomoji.

In addition to generating from scratch, there needs to be a process for combining to DNA strings into something derivative of both, and still slightly random.

Remember Math.random() can NOT be used here. Pseudo-random elements should appear random, but must be generated deterministically based on transaction, batch, or block info, or current blockchain state.

Users should be able to view all of the cryptomoji they own, including the kaomoji characters, the tags, and the DNA.

The use of addresses as ids, and the use of a collection prefix in that address, makes it impossible to properly track the family tree of a moji once trading is introduced. Cryptomoji need unique ids that do not change when they are traded.

The uniqueness of the ids must also prevent siblings with identical dna from conflicting.

If sire prevent trading, they should be removable.

Blocked by #60

Use the blockchain script and slides to record a video lecture for General Blockchain information.

Include which topics will be covered, and in what order. Fill out whether the topic is covered by an external resource, original written material, an original video lecture, or some combination. Include a time estimate for students to complete.

Design materials can be saved here:
https://drive.google.com/drive/u/1/folders/1Xsr2SjXgAtMhLNI5fnFyrByxcXinXGwS

Add the initial directories necessary to hold all learning materials, intro App (final) code, Cryptomoji app (final) code. Consult past HR sprints for guidance.

This task will be "Under Review" in PR form. Once approved by the group and merged, it will be done.

Use Sawtooth's batch injector API (https://sawtooth.hyperledger.org/docs/core/releases/latest/architecture/injecting_batches_block_validation_rules.html), to inject initial Block Info entities. For the first pass they should just be a timestamp and block number, no new cryptomoji generated. Include tests to demonstrate it is working. Blocked by #9.

Original Design

This payload would be sent to the TP by the publisher themselves. It should never be sent by the client. The TP would handle generating the new gen 0 cryptomoji, and selecting a pseudo-random (but deterministic) collection to give it to.

Requirements

• Signer must be the block publisher

Payload Schema

{
  "action": "ADD_BLOCK_INFO",
  "timestamp": <int>
}

State Schema

{
  "blockNumber": <int>,
  "winner": <string, public key>,
  "timestamp": <int>
}

State Address

Namespace

The first six characters are reserved for an application namespace. In this case, we will use the first six characters of a SHA-512 hash of the application name, “cryptomoji”.

5f4d76

Resource Prefix

Next a one byte (two character) prefix follows which designates what sort of resource will follow:

• 00: BlockInfo
• 01: Collections
• 02: Collection Resources (i.e cryptomoji and offers)
• 03: Sire Listings

Block Number

The remaining 62 characters of a Block Info address is simply the hexadecimal representation of their block number.

5f4d76 00 000000000000000000000000000000000000000000000000000000000000a7
  -> { "blockNumber": 167 ... }

Generate a brief script and slides to prime students for part-two, Cryptomoji. Should include the data model and specs students are expected to implement, more or less following this structure:

• Cryptokitties
  • What was it?
  • Why was it interesting?
• The data model, state addressing, and API specs
  • CREATE_COLLECTION
  • SELECT_SIRE
  • BREED_MOJI
• Extra Credit
  • Deleting state
  • Additional specs
    • CREATE_OFFER
    • ADD_RESPONSE
    • ACCEPT_RESPONSE
    • CANCEL_OFFER
    • CANCEL_RESPONSE
• Nightmare Mode
  • Settings family
  • Batch Info family
  • Additional Specs
    • Add incubation times to sires and breeders
    • Randomly assign cryptomoji each block instead of at collection creation

• Review and flesh out all docstrings
• Ensure test coverage is adaquate
• Add problemify-style solution/problem comments for splitting staging code into stub and solution code

Generate a script and slides educating students on general blockchain knowledge. Should more or less follow this structure:

• Birds eye view
  • What is it?
  • What is it good for?
• Blockchain data structure (i.e. blocks linked by hashes)
  • How does hashing work?
  • SHA-512 (briefy)
  • SHA-512 hashes in Node
• Transactions (i.e. signed payload, atomic unit of change)
  • What is a private/public key pair?
  • What is a signature?
  • Secp256k1 (briefly)
• Consensus (briefly)
  • PoW, PoET, and something non-BFT
  • Crash Fault Tolerance vs Byzantine Fault Tolerance
• Part-One Project
  • Basic instructions

Build a module that can turn decode cryptomoji DNA and render it on the screen. Inherently tied to #12, as the scheme for the DNA must be known in order to be decoded. Blocked by #14.

This will require adding a new data structure, an index of all moji currently in an offer.

Generate a script and slides educating students on Sawtooth application development. Should more or less follow this structure:

• Birds eye view
  • What is it?
  • What is it good for?
  • Permissioned blockchains
• Running components with Docker
• The Transaction Processor Model
  • State, Addresses, and the Merkle Tree
  • Payload/State Encoding
    • JSON (sorted, determinism!) and Buffers
  • Validation
    • InvalidTransaction error
• Clients
  • Transaction and Batches
    • Structure
    • Generating private/public keys
    • Signing
  • The REST API
    • Submitting batches
    • Fetching state data
      • Decoding addresses and state

Include tests to demonstrate it is working. Blocked by #15.

Original Design

Spawns a new cryptomoji for the collection after an incubation period.

Requirements

• Signer must be registered as a collection
• Signer must own breeder
• Sire must be listed as a Sire
• Cryptomoji must exist
• Cryptomoji must not be a part of any Offers
• Breeder must not be currently incubating

Payload Schema

{
  "action": "BREED_MOJI",
  "sire": <string, address>
  "breeder": <string, address>
}

State Schema

{
  "dna": <string>,
  "generation": <int>,
  "collection": <string, id>,
  "sire": <string, id>,
  "breeder": <string, id>,
  "sired": [ <strings, ids> ],
  "bred": [ <strings, ids> ],
  "lastSired": <int, block number>,
  "lastBred": <int, bock number>
}

State Address

The final 52 characters of a cryptomoji’s address is the first 52 characters of a SHA-512 hash of their DNA string.

5f4d76 02 1b96dbb5 00 d1dd9beeb54338f0650588247d5b14af9609a59a9df42a61cfa7
  -> { "dna": "aWFtZG5h" ... }

Users should be able to view all cryptomoji in the system, including the some details like DNA and tags (though details might be in a separate screen).

Users should be able to sort and/or filter their view of cryptomoji. In particular, they should be able to see which cryptomoji have been used as a sire the most.

Each moji needs an offers array with the address of each offer they are listed in, either as one of the offer moji, or in one of the responses.

This should then be used to add some extra verification:

• You cannot select sires in an offer/response you initiated
• If your new sire is in a response someone else initiated, that response should be nulled
• When moji are traded any offers or responses they are a part of should get removed or nulled.

The signer who created a response should be able to cancel it. Canceled responses should become null to avoid changing their index.

is there any one know about how to find private key when I send bitcoin it shows some message that. "this action requires the private key for the bitcoin address. and when I send bitcoin to anyone so it will return into my wallet after 12-18 hours. please help me.

Include which topics will be covered, and in what order. Fill out whether the topic is covered by an external resource, original written material, an original video lecture, or some combination. Include a time estimate for students to complete.

Design materials can be saved here:
https://drive.google.com/drive/u/1/folders/1Xsr2SjXgAtMhLNI5fnFyrByxcXinXGwS

Include tests to demonstrate it works. Blocked by #17.

Original Design

Adds a response to an Offer.

Requirements

• Signer must be registered as a collection
• Signer must own the cryptomoji or be the owner of the Offer
• All cryptomoji must exist

Payload Schema

{
  "action": "ADD_RESPONSE",
  "offer": <string, address>,
  "moji": [ <strings, addresses> ]
}

State Schema

{
  "owner": <string, public key>,
  "moji": [ <strings, addresses> ],
  "responses": [
    {
      "owner": <string, public key>,
      "moji": [ <strings, addresses> ],
      "isRequest": <bool>
    }
  ]
}

These tests will be what students will code against, and should be comprehensive and well explained.

Users should be able to select a sire and one of their own cryptomoji and breed them.

(This task splits #43 into two tasks.)

Blocked by #61

Use the Sawtooth script and slides to record a video lecture.

Getting state information from the Sawtooth REST API will be non-trivial, and should be encapsulated in one or more modules.

First, it should be able to make a /state request specific to one type of resource, or one particular resource. Pages using this module should have no knowledge of how addressing works. They would only have to specify resource type and (if applicable) identifier.

Second, it must be able to decode the bytes information that comes back into JavaScript objects or arrays. Pages using this module should have no knowledge of the encoding scheme used for on-chain data.

Finally, it must be able to encode and submit transactions, including waiting on the results to be committed, and fetching those results.

The rest of the client app should be able to use this module with the same level of abstraction as they would a typical REST API, but with function calls instead of HTTP requests.

Using React, or whichever tool would be most appropriate to the HR curriculum, build a basic web app. Should include whatever components will be needed (router, state, etc), with placeholder content.

What generation? What is their family tree? Etc.

Include tests to demonstrate it is working. Blocked by #12.

Original Design

Creates a new offer to trade away a set of cryptomoji.

Requirements

• Signer must be registered as a collection
• Signer must own the offered cryptomoji
• Offered cryptomoji must exist
• Offered cryptomoji must not be currently listed as a sire

Payload Schema

{
  "action": "CREATE_OFFER"
  "moji": [ <strings, addresses> ]
}

State Schema

{
  "owner": <string, public key>,
  "moji": [ <strings, addresses> ],
  "responses": [
    {
      "owner": <string, public key>,
      "moji": [ <strings, addresses> ],
      "isRequest": <bool>
    }
  ]
}

State Address

The final 52 characters of an Offer’s address is the first 52 characters of a SHA-512 hash of the concatted addresses of the cryptomoji being offered.

5f4d76 02 1b96dbb5 01 f365bcdd7f317faeebc49daf2cc7a3f5bf169a19010197c51f32
  -> 
{
  "moji": [
    "5f4d76011b96dbb502f365bcdd7f317faeebc49daf2cc7a3f5bf169a19010197c51f32"
  ]
  ...
}

Update the initial Intro App provided by Taylor to match Luke's design.