cryptoeconomics-study / code Goto Github PK

There's a lot of links that point to old repos that were hosted on @burrrata's repos or the cryptoeconomics-study-dao repos. We need to update all links to point to repos, files, and stuff within this GitHub org, cryptoeconomics-study

• Client implementation
• Timestamp attack
• Double Spend attack

Currently we're using the network simulations test the code, but mocha tests would the student more iterative feedback as they develop each function. Chapter 1 was a great example of what this might look like.

If a PoWClient receives a block that points to a block which has not been received yet (is not included in this.allBlocks), then the client fails. One simple way to handle is to just reject that block. The realistic way to handle this is to request the missing block(s) from peers. The realistic solution increases complexity fairly drastically as the implementation will involve use of asynchronous functions (e.g. async, await).

Create a script for section 2.3 to implement the attack described in https://vitalik.ca/general/2018/08/07/99_fault_tolerant.html

Create an observer client that just checks the timestamp and rebroadcasts messages (doesn't sign)

"In the case where one node is honest, can we guarantee that passive observers (ie. non-consensus-participating nodes that care about knowing the outcome) can also see the outcome, even if we require them to be watching the process the whole time? With the scheme as written, there’s a problem. Suppose that a commander and some subset of k (malicious) validators produce a message v : i[1] : .... : i[k], and broadcast it directly to some “victims” just before time T + k * D. The victims see the message as being “on time”, but when they rebroadcast it, it only reaches all honest consensus-participating nodes after T + k * D, and so all honest consensus-participating nodes reject it."

Everything relevant needs to be merged into the master or deleted before we ship the MVP.

As posted on the forum, we're looking for feedback on the new Course!

We have a new website, new coding-challenges, and a new DAO. If this sounds interesting to you, you're in the right place. We would be happy to give you some 🥕 tokens in our community DAO exchange for your feedback on the new website and chapter 1 of the course.

Our bounties are as follows:

Basic Review: 100 🥕

• You read the docs, tried the app, and answered the questions.

Bonus Review: 300 🥕

• You read the docs, tried the app, and answered the questions.
• You then provided detailed suggestions to fix any problems you encountered (just like with Bug Bounties, we'll assess the severity of the problem you described as well as if your suggestions would actually fix the problem).

Above and Beyond Review: 500 (or more) 🥕

• You read the docs, tried the app, and answered the questions.
• You then provided detailed suggestions to fix any problems you encountered (just like with Bug Bounties, we'll assess the severity of the problem you described as well as if your suggestions would actually fix the problem).
• You actually wrote code that fixed the problem, submitted a PR, and we merged the PR.

Website

• the beta of the new Cryptoeconomics.Study website can be found here: https://www.burrrata.ch/ces-website/

Was it clear to you what the purpose of Cryptoeconomics.Study was from your first visit to the website?

Please describe the purpose and value of Cryptoeconomics.Study in your own words.

What parts of the website were confusing?

What do you wish was on the website, but wasn't?

Course: getting started

• the getting started section of the course can be found here: https://www.burrrata.ch/ces-website/docs/en/getting-started/welcome

After going to the welcome page, were you excited to start the course and learn more?

• if not, what was lacking?

Were you able to get your development environment setup correctly?

• if not, where did you get stuck? (this is our fault for writing poor documentation, not your fault for not figuring it out)

Course: chapter 1

• chapter 1 of the course can be found here: https://www.burrrata.ch/ces-website/docs/en/ch1/

Did you find the lectures engaging?

• if not, what would have improved the experience for you?

Did the coding challenge format make sense to you (readme, code, demo, tests)?

• if not, what part of it was confusing

What coding challenges did you get stuck on?

What bugs did you discover?

General

Overall, what was your impression of the Cryptoeconomics.Study and the course?

Are you excited to take chapter 2 when it is released?

What do you wish was different about the course?

Thank you! 🎉

We really appreciate you taking the time to beta test our course. Our goal is to make it as easy and fun as possible to learn about cryptoeconomics. Your valuable feedback helps us make the course better for everyone involved :)

Where should we contribute exercises to for the lecture videos in this repo:

E.g. for the exercise box displayed:

Use EthCrypto.hash.keccak256(message) when calling the sign method on tests.js file of Section 1.1.

This prevents the following error:

TypeError: str.startsWith is not a function
      at addTrailing0x (/Users/santteegt/cryptoeconomics.study/code/node_modules/eth-crypto/dist/lib/util.js:13:14)
      at Object.sign (/Users/santteegt/cryptoeconomics.study/code/node_modules/eth-crypto/dist/lib/sign.js:20:36)

Adding the #hacktoberfest label for this issue is much appreciated :)

E.g. If I have just the genesis block (block 0), and miner A finds block 1 and block 2 in quick succession. If the PoWClient receives block 2 before block 1 it does not know how to behave

Build off of current PoA implementation to support a consortium of Authority nodes, with clients requiring a threshold (e.g. 3/4 of Auth nodes) of signatures before accepting.
This implementation will require multiple Authority nodes to all agree on the ordering of transactions before signing and broadcasting to clients, which is non-trivial. One possible solution is to have the authority nodes run latency-based consensus from 2.3.

Currently, only the single oldest tx in the pool is added to the block. Instead add a blockSize variable, and fill in up to blockSize transactions per block.

• Authority Client
• PoA User Client

Is the README format in 1.1 better where there's hints under each code section, or 1.5 where there's an explicit TODO over each code section?

Clean up https://github.com/cryptoeconomics-study/code/tree/master/c3_ProofOfWork,
making it more modular, create a separate file for the test case(s)

For more inspiration, also see: https://github.com/karlfloersch/lessons/blob/master/lessons/02_proofOfWork.js#L16-L26