GitHub/quartz
1
0
Fork 2
mirror of https://github.com/jackyzha0/quartz.git synced 2026-03-24 23:15:46 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

vault backup: 2023-02-26 17:04:15

Browse Source
This commit is contained in:
Jet Hughes 2023-02-26 17:04:15 +09:00
parent 3de803887a
commit 482ef7bf95
2 changed files with 29 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/notes/scenarios.md
View File

@ -53,4 +53,4 @@ If someone uploads a document by accident that is sensitive, then the chain hard
what if someone found a security vulnerability in the code. would they exploit it? how to change the code. would there be a different process to normal code changes for something critical like this. within the blockchain wallets/accounts are linked to a real world identity. but i guess the person who found the vulnerability could easily (note the "person" is a member of an organisation who has access to the code) tell someone else who is not identifiable and have them exploit the vulnerability. how do organisations decide who has access to the code. if the person does not decide to try to exploit it, they have to bring it to the attention of others or try to fix it themselves. what if someone found a security vulnerability in the code. would they exploit it? how to change the code. would there be a different process to normal code changes for something critical like this. within the blockchain wallets/accounts are linked to a real world identity. but i guess the person who found the vulnerability could easily (note the "person" is a member of an organisation who has access to the code) tell someone else who is not identifiable and have them exploit the vulnerability. how do organisations decide who has access to the code. if the person does not decide to try to exploit it, they have to bring it to the attention of others or try to fix it themselves.
# Proposing Changes/Upgrades to the code or the goverance system # Proposing Changes/Upgrades to the code or the goverance system
How do the participants in the network proposed changes to the code or the system of governance? Could it work similar to the BIP/EIP systems? How do the participants in the network proposed changes to the code or the system of governance? Could it work similar to the BIP/EIP systems? d

51
content/notes/veracity-summary.md
View File

@ -4,35 +4,16 @@ tags:
- -
--- ---
# Plan
- Major points
- reading
- process
- main findings
- scenarios
- solidity contract
- thoughts leading up to it
- what I think it would have been
- what I got implemented
- default contract
### Aim ### Aim
The aim of this project was to consider aspects of a closed public permissioned blockchain. Currently some believe there is an issue with current permissioned blockchains in that they are not sifficiently decentralised. On the other hand open permissionless blockchains such as Bitcoin are cumbersome to use due to their need for an associated cryptocurrency. The aim of this project was to consider aspects of a closed public permissioned blockchain. Currently some believe there is an issue with current permissioned blockchains in that they are not sifficiently decentralised. On the other hand open permissionless blockchains such as Bitcoin are cumbersome to use due to their need for an associated cryptocurrency.
### Process
Stage 1 - understand blockchain and read general literature
Stage 2 - test Hayden's system from last year
Stage 3 - read papers similar to what we are trying to accomplish
Stage 4 - evaluate select scenarios that coild arise with the proposed system, considering how existing technology could be sed and how we could adapt it
Stage 5 - (incomplete) test out ideas for the proposed system in a small scale environment
### Scenarios ### Scenarios
There were three main scenarios that spend time to explore: Adding a new member, removing a member and accidental transactions. This process helped me to understand some of the intricacies of the system I was trying to conceptualise. It made It seem There were three main scenarios that spend time to explore: Adding a new member, removing a member and accidental transactions. This process helped me to understand some of the intricacies of the system I was trying to conceptualise. Before this process I was lost in the infinite number of forms that a solution to our problem count take. By focusing one single aspect of the system I was forced to accept a basic framework of what the solution could be and use it to explore how a given scenario might occur
#### Adding a member
e
### Solidity Contract ### Solidity Contract
@ -46,3 +27,27 @@ Dos attack on the chain targeted at the system of adding new participants. By cr
### %%Three tier system ### %%Three tier system
The propsed three tier system consists of an application "lobby", a set of non-voting participants, and a set of voting participants.er system consists of an application "lobby", a set of non-voting participants, and a set of voting participants. %% The propsed three tier system consists of an application "lobby", a set of non-voting participants, and a set of voting participants.er system consists of an application "lobby", a set of non-voting participants, and a set of voting participants. %%
#### Process
Stage 1 - understand blockchain and read general literature
Stage 2 - test Hayden's system from last year
Stage 3 - read papers similar to what we are trying to accomplish
Stage 4 - evaluate select scenarios that coild arise with the proposed system, considering how existing technology could be sed and how we could adapt it
Stage 5 - (incomplete) test out ideas for the proposed system in a small scale environment
# %%Plan
- Major points
- reading
- process
- main findings
- scenarios
- solidity contract
- thoughts leading up to it
- what I think it would have been
- what I got implemented
- default contract%%